grsecurity forums

On a X86 P4 Gentoo 2.6.34-hardened-r1 system (essentially grsecurity-2.2.0-2.6.34.1-201007162107.patch), I configured SEGMEXEC but not PAGEEXEC, as suggested for performance reasons. Now, while looking for the cause why gdb-7.1 does evaluate breakpoint addressed correctly any more, I selectively disabled PaX flags via paxctl. When using paxctl -zs on the target, the program gets killed vial signal 9 already during it's startup phase. Me thinks this may be an inconsistent use case not handled properly. paxctl -zms <target> leads to a working target and brings back correct gdb breakpoint addresses. There is nothing about it in dmesg. The identically configured 2.6.32.16-grsec kernel shows the same problem. I don't suppose that this is a problem whithin ld-2.11.2.so?

Hugo Mildenberger wrote:On a X86 P4 Gentoo 2.6.34-hardened-r1 system (essentially grsecurity-2.2.0-2.6.34.1-201007162107.patch), I configured SEGMEXEC but not PAGEEXEC, as suggested for performance reasons. Now, while looking for the cause why gdb-7.1 does evaluate breakpoint addressed correctly any more,

can you tell me how to reproduce this problem? gdb should work fine with PaX, regardless of the non-execute implementation.

I selectively disabled PaX flags via paxctl. When using paxctl -zs on the target, the program gets killed vial signal 9 already during it's startup phase. Me thinks this may be an inconsistent use case not handled properly. paxctl -zms <target> leads to a working target and brings back correct gdb breakpoint addresses.

not all combinations of PT_PAX_FLAGS are meaningful, the kernel checks and enforces them. the same is true for many other ELF features (think about an RW code segment or an R data segment, etc) yet no tool will complain when you create such binaries. after all, you may be testing something else where such, otherwise invalid flag combinations are needed, etc. in short, this is just the usual unix philosophy, with the rope and stuff .