[arch-dev-public] Add -fstack-protector{-all} to default CFLAGS?

Allan McRae allan at archlinux.org
Wed May 12 03:15:55 EDT 2010

On 12/05/10 16:49, Jan de Groot wrote:
> On Wed, 2010-05-12 at 12:35 +1000, Allan McRae wrote:
>> Hi,
>> We have a bug report asking to enable stack-smashing protection in our
>> package building.  Looking at the overhead estimates by other distros
>> that use it, overall it appears fairly minimal (OpenBSD says 1.3% on
>> average).  There used to be some build issues (see bottom of this page
>> for Ubuntu report: https://wiki.ubuntu.com/GccSsp), but I am not sure of
>> the current status.  Also, it can be disabled with -fno-stack-protector
>> if needed.
>> I am in favour of doing this.  I think adding -fstack-protector is
>> enough as that adds protection to only functions "vulnerable" to buffer
>> overflows (as defined by gcc...  mainly character arrays) while
>> -fstack-protector-all adds it to all functions.
>> We should maybe also add -D_FORTIFY_SOURCE=2.  This detects some buffer
>> overflows compile time and others at run time.  It was designed to have
>> minimal runtime overhead.
>> Any opinions?
> Given the fact that GCC 4.5 produces broken binaries with software that
> needs -fno-strict-aliasing (busybox comes to mind, but also others), I
> don't think it's good to introduce such a change now. Our toolchain
> should get fixed before we attempt to add more features to our compiler
> flags.

There is a fix on the gcc bug tracker but I am waiting for it to be 
backported to gcc-4.5.  If it has not been done by the next toolchain 
rebuild (I expect in the next week), I will backport it myself.

Anyway, it was not going to happen immediately.  Sadly, nothing of this 
sort can be achieved in under a multiple month timeframe around here. 
But it could possibly happen with the next pacman release given that 
makepkg.conf will need changed.  Hence starting discussion now.   Well 
actually I started it a month ago on the bug tracker but only one of the 
five people I assigned answered my request for comments...

The reason I bought this up again now is that there is a glibc release 
tagged and the glibc package will need preparation for both this and the 
new shared library stripping behaviour in makepkg so I though I would 
begin this now if comments seemed positive.


More information about the arch-dev-public mailing list