[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Switch on compiler hardening defaults


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

> 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 Cook                                            @debian.org

Reply to: