On Tue, 27 Oct 2009, Kees Cook wrote: > > > It seems the kernel will not be happy if the stack protector is switched > > > on unconditionally: > > > > > > http://osdir.com/ml/linux-kernel/2009-10/msg07064.html > > > > Indeed. The kernel build system needs to be able to command whether > > stackprotect is enabled or not without surprises...
... > Right, -fno-stack-protector via CFLAGS will disable it (as will > -nostdlib). The work-arounds for the default are all documented both in the > gcc manpage[1] (though this would need tweaking since it currently says > "Ubuntu") and on the Ubuntu wiki page I mentioned earlier[2]. Well, the issue raised in LKML is that you absolutely should *not* enable -fstack-protector-all unless you _really_ know what you're doing, and most certainly not by default. It has nothing to do with -fstack-protector, just with -fstack-protector-all. But it does show that extra stack usage CAN have bad effects on performance in pathological cases (which -all seems to cause more readly :-p ). http://osdir.com/ml/linux-kernel/2009-10/msg08763.html looks like an horror tale (caused by -fstack-protector-all). Assuming you guys are _not_ enabling -fstack-protector-ALL by default, just -fstack-protector, my only worry is this: What would happen if the kernel people start using -fstack-protector only on _some_ files for very good reasons, and you end up with both the -fno-stack-... and -fstack-... in a gcc invocation? Maybe this calls for a env. variable or special parameter (for CFLAGS) to cause gcc stack-protector defaults not to be changed in that invocation (as opposed to the direct use of -f and -fno). We'd need to use that on kernel builds as well as on any packages that DO know about -fstack-protector to avoid headaches and surprises long-term, I think. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
