Created attachment 501431 [details] Testcases Some PIE programs will fail with # echo 0 > /proc/sys/kernel/randomize_va_space I got [root@gnu-68 168.wupwise]# echo 0 > /proc/sys/kernel/randomize_va_space [root@gnu-68 168.wupwise]# ./wupwise Killed [root@gnu-68 168.wupwise]# echo 2 > /proc/sys/kernel/randomize_va_space [root@gnu-68 168.wupwise]# ./wupwise RANDOM SOURCE SEED : 2123 1642 4095 1001 KAPPA : ( 0.23999999999999999 , 0.0000000000000000 ) NITER : 75 [root@gnu-68 168.wupwise]#
This still seems to happen with 2.6.40 (3.0), though your provided testcases never actually works as shown in the output because it's missing some kind of .in file. However, it runs and spits an error out in the randomize_va_space = 2 case, and gets killed otherwise. Poking around with ftrace a bit, it seems it's getting killed around here in load_elf_binary: /* Calling set_brk effectively mmaps the pages that we need * for the bss and break sections. We must do this before * mapping in the interpreter, to make sure it doesn't wind * up getting placed where the bss needs to go. */ retval = set_brk(elf_bss, elf_brk); if (retval) { send_sig(SIGKILL, current, 0); goto out_free_dentry; } if (likely(elf_bss != elf_brk) && unlikely(padzero(elf_bss))) { send_sig(SIGSEGV, current, 0); retval = -EFAULT; /* Nobody gets to see this, but.. */ goto out_free_dentry; } It seems that the set_brk call is failing here, though I don't really know why at the moment.
The place returning an error (-ENOMEM to be exact) is get_unmapped_area_prot in mm/mmap.c around line 1591: if (addr > TASK_SIZE - len) return -ENOMEM; get_area is returning an address, which is valid, but the resulting address is larger than TASK_SIZE minus the area being mapped (I think). The values in question turn out to be: addr: 7ffff81ff000 TASK_SIZE: 7ffffffff000 len: afc8000 (TASK_SIZE - len): 7ffff5037000 I still have little clue why this is an error in the non-randomize case, but it seems that the len value corresponds to the .bss section size (roughly) in the binary: [root@localhost ~]# readelf -S /home/jwboyer/wupwise | grep -3 bss 00000000000000b8 0000000000000008 WA 0 0 8 [26] .data PROGBITS 0000000000207700 00007700 0000000000000004 0000000000000000 WA 0 0 4 [27] .bss NOBITS 0000000000207720 00007720 000000000afc8020 0000000000000000 WA 0 0 32 [28] .comment PROGBITS 0000000000000000 00007704 0000000000000058 0000000000000001 MS 0 0 1
Created attachment 525432 [details] This patch works for me
(In reply to comment #3) > Created attachment 525432 [details] > This patch works for me Can you send that upstream for review?
(In reply to comment #4) > (In reply to comment #3) > > Created attachment 525432 [details] > > This patch works for me > > Can you send that upstream for review? I already did with the upstream bug report.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Created attachment 525432 [details] > > > This patch works for me > > > > Can you send that upstream for review? > > I already did with the upstream bug report. Great! Since nobody can read that at the moment, and Google hasn't indexed it, could you paraphrase any discussion that happened?
(In reply to comment #6) > > Great! Since nobody can read that at the moment, and Google hasn't indexed it, > could you paraphrase any discussion that happened? I don't remember there are any discussions.
(In reply to comment #7) > (In reply to comment #6) > > > > Great! Since nobody can read that at the moment, and Google hasn't indexed it, > > could you paraphrase any discussion that happened? > > I don't remember there are any discussions. That's likely because bugzilla.kernel.org is kind of a wasteland. The patch does look like it would work for this, but I'd really like to get some more review of it before we add it. Can you add a changelog and Signed-off-by to it and send it to andrew morton and al viro with lkml on CC by chance?
(In reply to comment #8) > > The patch does look like it would work for this, but I'd really like to get > some more review of it before we add it. Can you add a changelog and > Signed-off-by to it and send it to andrew morton and al viro with lkml on CC by > chance? Can you do it for me? It is a very small change. Thanks.
(In reply to comment #9) > (In reply to comment #8) > > > > The patch does look like it would work for this, but I'd really like to get > > some more review of it before we add it. Can you add a changelog and > > Signed-off-by to it and send it to andrew morton and al viro with lkml on CC by > > chance? > > Can you do it for me? It is a very small change. Thanks. I'm going to take that as an implicit Signed-off-by addition then. I'll send it upstream with you on CC and we'll see what comes from it.
I've committed Jiri's patch to fix this bug. http://article.gmane.org/gmane.linux.kernel/1198674 If there are further iterations, we can change the patch if necessary. This should be in the next F15 kernel build.
kernel-2.6.40.6-0.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/kernel-2.6.40.6-0.fc15
Package kernel-2.6.40.6-0.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-2.6.40.6-0.fc15' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/kernel-2.6.40.6-0.fc15 then log in and leave karma (feedback).
kernel-2.6.40.6-0.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.