Re: Switch on compiler hardening defaults
Hi,
On Tue, Oct 27, 2009 at 10:19:22PM -0200, Henrique de Moraes Holschuh wrote:
> 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).
Right, the kernel does its own thing, and isn't exactly related to this
default.
> Assuming you guys are _not_ enabling -fstack-protector-ALL by default, just
> -fstack-protector, my only worry is this:
Correct, -fstack-protector-all is not sane for the general case.
Mildly related to this, I would note that while the upstream default for
the compiler to decide between adding and not adding the prefix/suffix
code to functions is when a function has an 8 byte stack or more.
I noticed when examining SUSE builds that they seem to force this to 4
bytes (--param ssp-buffer-size=4). I do not have a strong opinion on
this, and lacking further evidence, would stick to the 8 byte default.
> 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?
AIUI, the kernel builds with -nostdlib, so gcc would not include
-fstack-protector. Additionally, if -fno-stack-protector is seen on the
invocation, no -fstack-protector is added. If, for some reason, something
built with both -fno-stack-protector and -fstack-protector on the
invocation, the latter setting wins.
I don't think this will be problem.
> 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.
I don't see any reason to do this -- Ubuntu has used the -fstack-protector
default for 3 years now. This is a very well tested area. (I'm not
saying it'll be perfect, but I think the issues are well understood by a
lot of people, and solutions will be straight forward.)
-Kees
--
Kees Cook @debian.org
Reply to: