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

Dan McGee dpmcgee at gmail.com
Wed May 12 10:24:18 EDT 2010


On Wed, May 12, 2010 at 8:20 AM, Andreas Radke <a.radke at arcor.de> wrote:
> Am Wed, 12 May 2010 11:14:48 +0200
> schrieb Thomas Bächler <thomas at archlinux.org>:
>
>> > So, do I really have to wait until that is fixed before we can
>> > discuss _future_ changes?

+1 from me, especially if we aren't the first distro to jump into this
so we aren't going to hit loads of roadblocks. Let's make sure we have
a standard way of turning it off for packages that do break, however.

>> I think I was already in favor of using the stack protector a year
>> ago. Actually (I already mentioned this last time this discussion
>> came up) we have built our kernels with the stack protector enabled
>> for a long time
>> - to be precise, it was enabled on June 11th when we switched to
>> 2.6.30.
>>
>
> There's a kernel configuration option for this.
>
> I'm not sure if we should change our compiler flags just prevent
> applications to fail. Is this the task of a compiler to be a 2nd stage
> protector for poorly written apps?
>
> I can imagine such a safety option enabled in a security critical
> distribution like firewalls.
>
> But for the rest wouldn't adding such a feature take the pressure from
> the coders to produce proper code? I think the overhead is something
> I wouldn't like to see in ArchLinux. At least as long as this can't be
> switched off at runtime by the user.

This isn't some -fix-all-your-code option. It *will* make things crash
if there are buffer overflows. It doesn't magically prevent them from
happening. That to me would be incentive enough if I was coding
upstream to fix my software.

I'd also like to think we aren't Gentoo either and do care a decent
amount about security. If this prevents a vulnerability from affecting
us, we've made a good choice that 1% overhead is probably not going to
kill us.

-Dan


More information about the arch-dev-public mailing list