[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.
Allan
More information about the arch-dev-public
mailing list