Re: Switch on compiler hardening defaults
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
Reply to: