grsecurity forums

I just tried compiling the latest stable version of Linux-VServer (with the next to latest version of Grsec, 2.1.9) from http://linux-vserver.org. This of course uses the 2.6.17.14 kernel.

I am now getting a few errors which read as follows:

init/built-in.o: In function 'try_name':
do_mounts.c.text+0x503): undefined reference to `__stack_chk_fail'
init/built-in.o: In function 'name_to_dev_t':
(.text+0x7eb): undefined reference to `__stack_chk_fail'
init/built-in.o: In function 'change_floppy':
(.init.text+0x9c1):undefined reference to `__stack_chk_fail'
init/built-in.o: In function 'mount_block_root':
(.init.text+0xc57):undefined reference to `__stack_chk_fail'
init/built-in.o: In function 'do_header':
initramfs.c.init.text+0x4323):undefined reference to `__stack_chk_fail'
arch/i386/kernel/built-in.o.text+0x5261):more undefined references to `__stack_chk_fail' follow
make[1]: *** [vmlinux] Error 1
make[1]: Leaving directory `/usr/src/linux-2.6.17.14'
make: *** [debian/stamp-build-kernel] Error 2

It looks like I've managed to guide the kernel make process all the way through this time by

export CFLAGS="$CFLAGS -fno-stack-protector"

but I have a couple of questions. For one, is -fno-stack-protector really a good idea to have in there or does grsecurity protect against buffer overflows in the kernel?

Secondly would it be possible to relink my gcc build to 4.0 and build the kernel that way, without including the CFLAGS directive? I ask only because certain sources I've come across say that it can be done, and I don't have the time to compile another kernel tonight.

Any answer will be appreciated.

Christian_Rebel wrote:but I have a couple of questions. For one, is -fno-stack-protector really a good idea to have in there or does grsecurity protect against buffer overflows in the kernel?

first, ssp doesn't protect against buffer overflow exploits in general, it protects against stack based ones only, something that you'll find a lot less in kernel code than in userland (the kernel stack is a scarce resource, most buffer allocations are from elsewhere). second, the way ssp is currently implemented makes it pretty useless for kernel use because the cookie is either shared among all processes or within a process at least, all it takes is a kernel memory disclosure bug to bypass it (proper implementation should change the cookie per syscall). third, there're no generic protections against kernel memory corruption bugs, we can prevent only certain classes of bugs from getting exploited.

Secondly would it be possible to relink my gcc build to 4.0 and build the kernel that way, without including the CFLAGS directive? I ask only because certain sources I've come across say that it can be done, and I don't have the time to compile another kernel tonight.

newer 2.6 kernels support the ssp reimplementation of gcc 4.x via CC_STACKPROTECTOR or CC_STACKPROTECTOR_ALL, but only on amd64 and that implementation suffers from the above mentioned flaw. if you don't use that arch or config option, then your compiler defaults to enabling ssp for some reason, check it out with your distro to see how you can turn it off.

Thank you, that was very informative. I'll check it out the next time I have need to build another kernel. Went with the upcoming stable release of VServer+grsec instead.