The system exhibiting the problem I'm going to describe below has an old Pention IV chip, so it can't make use the nx bit for performance reasons. Hence it had been configured with CONFIG_PAX_SEGMEXEC=y and PAGEEXEC disabled. Now, while looking for the reason why gdb-7.1 does not calculate breakpoint addresses correctly (I remember it once worked with 6.8 on x86 at least), I tried to selectively disable paxflags. When I disabled the SEGMEXEC feature via "pax -zs", the program didn't run at all. Nothing but one line was printed: "Killed", even though core dumps are both enabled and known to work reliably. Generally, this only happens when a program is terminated via signal 9. $ gdb ./test1 GNU gdb (Gentoo 7.1 p1) 7.1 [...] Reading symbols from /home/hm/test1...done. (gdb) run Starting program: /home/hm/test1 During startup program terminated with signal SIGKILL, Killed. (gdb)q Here is a script for those who may want to perform a quick check if this maybe a local problem only: echo "int main(){return 0;}" | gcc -x c - -o test1 \ && echo "program test1 created" || echo "compile failed: error $?" echo "running ldd ./test1:" && ldd ./test1 echo -n "standard pax flags of test1 are: " \ && paxctl -vQ test1 2>&1 | grep test1 echo -n "running ./test1 with standard pax flags: " \ && ./test1 && echo "ok" || echo "error $?" echo -n "now disabling PaX SEGMEXEC: " \ && paxctl -s test1 && paxctl -vQ test1 2>&1 | grep test1 echo -n "running ./test1: " && ./test1 && echo "ok" || echo "error $?" echo -n "again running ldd on ./test1: " \ && ldd ./test1 && echo "ok" || echo "error $?" echo "whereas running '/lib/ld-linux.so.2 --list ./test1' always works:" \ && /lib/ld-linux.so.2 --list ./test1 This script produces the following output: $ sh reproduce.sh program test1 created running ldd ./test1: linux-gate.so.1 => (0x5173d000) libc.so.6 => /lib/libc.so.6 (0x515d6000) /lib/ld-linux.so.2 (0x5173e000) standard pax flags of test1 are: - PaX flags: -------x-e-- [test1] running ./test1 with standard pax flags: ok now disabling PaX SEGMEXEC: - PaX flags: ---s---x-e-- [test1] running ./test1: reproduce.sh: line 6: 27433 Killed ./test1 error 137 again running ldd on ./test1: /usr/bin/ldd: line 126: 27438 Killed LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@" error 1 whereas running '/lib/ld-linux.so.2 --list ./test1' always works: linux-gate.so.1 => (0x515d6000) libc.so.6 => /lib/libc.so.6 (0x5146c000) /lib/ld-linux.so.2 (0x515d7000) As ldd and ld-linux.so are part of glibc, I'm attributing this problem to sys-libs/glibc for now. Feel free to change the topic. Currently it does not look like as if it would depend on several hardened/grsec kernel versions I tested, and it also does not depend on two tested binutils versions (2.20, 2.20.1). Finally, it may be not a bug at all. However, as I understand PaX, it should always be possible to disable features selectively. Perhaps this is simply an inconsistent use case. With PAGEEXEC not configured and SEGMEXEC dynamically disabled, no means remain which could enforce MPROTECT.
Created attachment 241395 [details] /proc/config.gz unzipped, from linux-2.6.34-hardened-r1
(In reply to comment #0) > Finally, it may be not a bug at all. However, as I understand PaX, > it should always be possible to disable features selectively. Perhaps this > is simply an inconsistent use case. With PAGEEXEC not configured and > SEGMEXEC dynamically disabled, no means remain which could enforce MPROTECT. this is exactly the case, you ended up with an invalid combination of PaX flags, hence the sigkill. disable mprotect in addition to segmexec and you should be fine. also i wonder why nobody picked up this bug for so long, i've just run across it completely by accident...
So can there anything be done here?
Hardened-sources is no longer supported so ask upstream.
