Description of problem: Gnat crashes with a Storage_Error on even the simplest program. Version-Release number of selected component (if applicable): 4.1.0-3 How reproducible: Always. Steps to Reproduce: 1. yum install gcc-gnat 2. hello_world.adb: with Ada.Text_IO; procedure Hello_World is begin Ada.Text_IO.Put_Line("Hello World!"); end Hello_World; 3. gnatmake hello_world.adb Actual results: gcc -c hello_world.adb +===========================GNAT BUG DETECTED==============================+ | 4.1.0 20060304 (Red Hat 4.1.0-3) (i386-redhat-linux-gnu) Storage_Error stack overflow (or erroneous memory access)| | Error detected at a-tags.adb:448:7 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html. | | Use a subject line meaningful to you and us to track the bug. | | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==========================================================================+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. hello_world.adb compilation abandoned gnatmake: "hello_world.adb" compilation error Expected results: The compiler should not crash. Additional info: Both the system compiler and a home-compiled GCC 4.1.0 worked fine in Fedora 4, so this must have something to do with some difference between Fedora 4 and 5.
I'd say this is selinux preventing executable stack eventhough gnat1 and some other gnat utilities are marked with PT_GNU_STACK PT_R|PT_W|PT_X: execstack /usr/libexec/gcc/*/*/gnat1 /usr/bin/gnat* X /usr/libexec/gcc/x86_64-redhat-linux/4.1.0/gnat1 - /usr/bin/gnat X /usr/bin/gnatbind - /usr/bin/gnatbl - /usr/bin/gnatchop - /usr/bin/gnatclean - /usr/bin/gnatfind - /usr/bin/gnatgcc - /usr/bin/gnatkr - /usr/bin/gnatlink X /usr/bin/gnatls X /usr/bin/gnatmake - /usr/bin/gnatname - /usr/bin/gnatprep - /usr/bin/gnatxref Guess they need to be labeled some way that SELinux allows executable stack for them, but not sure how exactly. In any case, that's something /etc/selinux/targeted/contexts/files/file_contexts needs to include rather than gcc-gnat.
setsebool -P allow_execstack=1 allow_execmem=1 should make it work for FC5 for now. You could also label the executables java_exec_t, since the ada policy will be the same. jave_t is an unconfined context that allows execstack and execmem.
Setsebool doesn't help. It says "SELinux is disabled", and sure enough, in /etc/selinux/config I have "SELINUX=disabled". Can SELinux cause this even though it's disabled?
No.
Then it is a kernel bug, it doesn't honor PT_GNU_STACK any longer. Try: void __attribute__((noinline)) bar (void (*fn) (void)) { fn (); } int main (void) { int i = 1; void foo (void) { i--; } bar (foo); return i; } Compile with gcc -g -o /tmp/test /tmp/test.c sudo chcon system_u:object_r:java_exec_t /tmp/test # To rule SELinux out /tmp/test Clearly, the stack is not executable: 7fffffc96000-7fffffcac000 rw-p 7fffffc96000 00:00 0 [stack]
*** Bug 187687 has been marked as a duplicate of this bug. ***
I don't understand "7fffffc96000-7fffffcac000 rw-p 7fffffc96000 00:00 0", but Jakub Jelinek's test program segfaults. I can confirm Joachim Frieben's observation in bug 187687 that the regression is in the kernel update. I can also report that the latest kernel for Fedora 4 has the same problem. If I boot Fedora 4 with Linux 2.6.15-1.1833_FC4 or Fedora 5 with Linux 2.6.15-1.2054_FC5, then Gnat can compile hello_world and Jakub's test runs without error. If I boot Fedora 4 with Linux 2.6.16-1.2069_FC4 or Fedora 5 with Linux 2.6.16-1.2080_FC5, then Gnat and Jakub's test both crash.
*** Bug 188412 has been marked as a duplicate of this bug. ***
*** Bug 189289 has been marked as a duplicate of this bug. ***
In http://people.redhat.com/mingo/exec-shield/exec-shield-nx-2.6.15.patch, the variable exec_shield is initialized to 2, which would make stacks non-executable no matter what. Yet, when I boot Linux 2.6.15-1.2054_FC5 the value found in /proc/sys/kernel/exec-shield is 1, so somehow the default value gets changed to honor PT_GNU_STACK. In exec-shield-nx-2.6.16.patch the default value is 11, which also makes all stacks non-executable, and this value does not get changed: $ uname -r 2.6.16-1.2096_FC5 $ cat /proc/sys/kernel/exec-shield 11 Whatever it was that changed exec_shield in Linux 2.6.15 it should be restored for 2.6.16 to allow executable code on the stack for marked programs. I'd recommend a value of 9 if the new vDSO mapping feature is desired. (It's ironic that a security measure against buffer overflows ends up hurting the compiler for a language that's pretty much immune to buffer overflows. I find surprisingly few files with the executable stack flag set, but other than Gnat there are /usr/bin/eu-nm and /usr/lib/libGL.so. Outside of Core there are also Mplayer and Lame.)
I think the following hunk in the current exec-shield patch causes the problem: + if (current->personality == PER_LINUX && (exec_shield & 2)) { + executable_stack = EXSTACK_DISABLE_X; + current->flags |= PF_RANDOMIZE; + } + It's located immediately after the the check for the presence of a PT_GNU_STACK phdr entry and unconditionally disables an exectuable stack for everything, even binaries which the kernel just decided needed an executable stack. (On a related note, the "have_pt_gnu_stack" variable is never used after it's set. Also, gnat binaries don't actually have a PT_GNU_STACK segment, but I don't think that's an issue.)
*** Bug 191543 has been marked as a duplicate of this bug. ***
My tests indicate that this bug is fixed in kernel-2.6.16-1.2122_FC5.
I second that - works fine for me with kernel-2.6.16-1.2122_FC5. Whoever fixed it, thanks - I can jettison my 2.6.15 kernel now ;-)
*** Bug 193969 has been marked as a duplicate of this bug. ***
Summary for the kernel folks (in hopes that this'll actually get fixed instead of papered over; no 2122 didn't fix it, it just changed the exec-shield sysctl default from 11 to 9): Exec Shield does not give an executable stack to apps that are correctly labeled with an executable PT_GNU_STACK ELF phdr. My understanding of the semantics of the PT_GNU_STACK phdr (ignoring SELinux): doesn't exist: app gets the kernel default as specified in bit two of /proc/sys/kernel/exec-shield exists, not-executable: app gets a non-executable stack exists, executable: app gets an executable stack At the very least, the third case is broken. -- Björn Persson (rombo.bjorn.persson): you should probably change the Summary of this bug to something like "exec shield doesn't give an executable stack to apps that request it" so that it gets better visibility. (I'm not a sufficiently empowered user, so I can't do it.)
actually, the default change should have been the right thing to do. setting bit 2 of the execshield sysctl means nothing gets an executable stack, even apps that request it. It's the uber-paranoid mode. Clearly, that's not practical, so changing it so that isn't the default should mean that everything works again. I've looked over the section of diff you pointed out vs the .17 based update kernel, and it looks to be right to me. We *could* skip that whole section of elf header parsing to determine EXSTACK, but the way its currently done is less invasive, and it's only a tiny microoptimisation anyway. Unless there are applications that are continuing to break with the .17 update with the sysctls in their default state, I think this can be closed.
(note, when I said 'bit 2' I actually mean 1<<1) As documented in the patch.. + (1<<1) 2: noexecstack by default
I agree that it can be closed. I'm using 2.6.17-1.2145_FC5 now, and I no longer have this problem.