grsecurity forums

Hey all,

Thanks to encouraging advice from Pax Team a while ago (thanks!) I'm trying to get grsec (and especially pax) working on an old custom PPC board, based on the 6xx processor.
I'm using the 2.6.32.21 version of the patch (which I downloaded last week - so it's not the most recent, if this has been fixed I will be quite embarrased ). Without grsec, the system boots fine and everything works.

With grsec it doesn't and I don't even get a console, the kernel simply outputs nothing (and probably freezes). I've tried reading __log_buf after resetting the board from the bootloader (uBoot), and the only thing there is the "using machine" line (arch/powerpc/kernel/setup-common.c #563, which is called from machine_init, which is called from head_32.S # 982). Unfortunately I don't have access to a JTAG debugger so I have no idea where it freezes.

If anyone can provide me with a solution I'll be eternally grateful - but I could also use tips on how to debug the early boot process with no console (I've tried writing stuff to junk variables, but since the early code plays with the MMU a lot that doesn't work well).

P.S by "with grsec" I mean with all the menuconfig flags turned OFF. So it must be some change to the code that isn't affected by the flags.

Thanks...

AngelicLiar wrote:If anyone can provide me with a solution I'll be eternally grateful - but I could also use tips on how to debug the early boot process with no console (I've tried writing stuff to junk variables, but since the early code plays with the MMU a lot that doesn't work well).

the best debug strategy is to isolate the failure down to a specific line in the source code somewhere, then we can think of why that particular line fails. now to achieve that you'll need some means of communication, in particular you'll need to be able to emit a single bit somehow that you can observe externally. then what you do is a sort of binary search where you emit this one bit and enter an infinite loop then move the whole thing around in the boot code and find out where it begins/stops crashing and eventually arrive at the line of failure. this single bit of output can be many things, like a direct write to some framebuffer (if you have one) or turning some led on/off, etc, anything that you can reliably observe.