grsecurity forums

There is now a kernel option in kernel hascking that protects some parts of kernel
making it read only - CONFIG_DEBUG_RODATA

Whas is relation of that function to protection provided by grsecurity (KEXEC?)
Should I turn it on (to have even more extra protection for cost of small performence impact)
Must it be turned off since its conflicting
Or is it the same thing?

blackelf wrote:There is now a kernel option in kernel hascking that protects some parts of kernel
making it read only - CONFIG_DEBUG_RODATA

Whas is relation of that function to protection provided by grsecurity (KEXEC?)
Should I turn it on (to have even more extra protection for cost of small performence impact)
Must it be turned off since its conflicting
Or is it the same thing?

RODATA is a (small) subset of KERNEXEC, and due to implementation details, they're mutually exclusive (the .config system enforces it). basically, RODATA is a step towards more robustness, not security, whereas KERNEXEC is explicitly security oriented and it happens to enforce read-only kernel pages among others.

Today i had a problem with grsecurity-2.1.9-2.6.19.1-200612121859.patch on 2.6.19.1-vanilla

I had set CONFIG_DEBUG_RODATA set from an old config and the config-system did not unset it !

The compile went ok but upon boot i got a crash in "rwsem.c" on line 20 !

(I tried FC6 and RH4 with latest patches)

Some bug in the config-logic or rathead-tools maybe?