grsecurity forums

Hey all,

I'm (still) trying to get PaX to work properly on an ancient ppc_6xx processor, which has no NX bit. PaX Team told me PaX uses the guarded bit to emulate the NX, but apparantly it isn't working at all...

When I run PaX Test, it reports "Killed" on most tests (like executable stack), but by inserting printks into the kernel's exception handlers I can see that it does NOT die from a protection fault in the page fault handler, but due to an "Illegal Instruction" exception.

Also, I've written a simple run-code-from-stack program that's very similar to execstack.c but doesn't use all the fancy infrastructure (copy_shellcode, itworked). This program succesfully runs code from the stack - so PaX clearly isn't working. I've tried both compiling with EI_FLAGS and with PT_FLAGS and using paxctl, so it's not that.

I've also tried debugging to find out what's going on, but PaX makes gdb not work on my platform (gdb complains it has I/O errors while placing breakpoints).

Any help would be welcome...

AngelicLiar wrote:When I run PaX Test, it reports "Killed" on most tests (like executable stack), but by inserting printks into the kernel's exception handlers I can see that it does NOT die from a protection fault in the page fault handler, but due to an "Illegal Instruction" exception.

which paxtest did you try? only the one in spender's home directory has arch support, including powerpc.

Also, I've written a simple run-code-from-stack program that's very similar to execstack.c but doesn't use all the fancy infrastructure (copy_shellcode, itworked). This program succesfully runs code from the stack - so PaX clearly isn't working.

what you should do is instrument arch/powerpc/mm/fault.c:do_page_fault() with a few printk's and see what paths are taken for various access violations, then trace back the lack of proper non-exec response. if you keep me posted with your logs, i can probably guide you through the whole process .

I've also tried debugging to find out what's going on, but PaX makes gdb not work on my platform (gdb complains it has I/O errors while placing breakpoints).

if gdb wants to place breakpoint insns into the target, you'll need to disable MPROTECT on it (the target, not gdb). but this is a kernel issue so userland debugging won't get you far...

The powerpc/sparc shellcode in paxtest is broken on some systems -- I haven't fixed it yet.

-Brad

Thanks for the replies!

Spender - I'm already past using paxtest, now I'm just using an execstack.c-ish program with a "shellcode"="<return in machine code>". Once that works (=gets killed by PaX) I'll try paxtest

PaX Team - That's the problem, I don't even get a Page Fault! At least not a bad one (=one that leads eventually to bad_area). I get a program exception, and the kernel decides it's an illegal instruction exception because that's it's catch-all (=it isn't anything other than illegal instruction, so it must be that). I've looked into the PPC ref manual and I'm still not sure how to tell if it really is an illegal instruction exception...

What could help is if you told me where exactly PaX turns on the guarded bit for NX pages. I've tried looking for it but can't find it - maybe it doesn't even turn it on?

AngelicLiar wrote:PaX Team - That's the problem, I don't even get a Page Fault! At least not a bad one (=one that leads eventually to bad_area). I get a program exception, and the kernel decides it's an illegal instruction exception because that's it's catch-all (=it isn't anything other than illegal instruction, so it must be that). I've looked into the PPC ref manual and I'm still not sure how to tell if it really is an illegal instruction exception...

i'm somewhat confused here . when a non-exec violation should occur in paxtest or your own, what happens exactly? does the CPU generate any kind of exception or none at all? if it does generate an exception, which one is it exactly?

What could help is if you told me where exactly PaX turns on the guarded bit for NX pages. I've tried looking for it but can't find it - maybe it doesn't even turn it on?

it's in arch/powerpc/include/asm/pte-hash32.h but i have no idea if your CPU uses that or some other pte-*.h file that i didn't patch yet. feel free to experiment .