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 -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
