Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux Development (http://www.linux-archive.org/archlinux-development/)
-   -   Add -fstack-protector{-all} to default CFLAGS? (http://www.linux-archive.org/archlinux-development/369847-add-fstack-protector-all-default-cflags.html)

Allan McRae 05-12-2010 02:35 AM

Add -fstack-protector{-all} to default CFLAGS?
 
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?

Allan

Jan de Groot 05-12-2010 06:49 AM

Add -fstack-protector{-all} to default CFLAGS?
 
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.

Allan McRae 05-12-2010 07:15 AM

Add -fstack-protector{-all} to default CFLAGS?
 
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

Thomas Bächler 05-12-2010 07:29 AM

Add -fstack-protector{-all} to default CFLAGS?
 
Am 12.05.2010 09:15, schrieb Allan McRae:
> 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.

Yeah, but there's even more breakage in busybox as you might have
noticed, unrelated to that fix.

Allan McRae 05-12-2010 07:46 AM

Add -fstack-protector{-all} to default CFLAGS?
 
On 12/05/10 17:29, Thomas Bächler wrote:

Am 12.05.2010 09:15, schrieb Allan McRae:

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.


Yeah, but there's even more breakage in busybox as you might have
noticed, unrelated to that fix.



Honestly, if I wanted comments about gcc and busybox, the subject of
this email would have been something like "busybox build issues with
gcc-4.5". And then I would have scolded myself for not using the bug
tracker.


Can I just have comments on the proposed CFLAGS?

Allan

Thomas Bächler 05-12-2010 08:31 AM

Add -fstack-protector{-all} to default CFLAGS?
 
Am 12.05.2010 09:46, schrieb Allan McRae:
> Honestly, if I wanted comments about gcc and busybox, the subject of
> this email would have been something like "busybox build issues with
> gcc-4.5". And then I would have scolded myself for not using the bug
> tracker.
>
> Can I just have comments on the proposed CFLAGS?

Okay, then you'll get a comment on that: Our toolchain is terribly
broken as it is, let's break it further by adding more flags.

Allan McRae 05-12-2010 08:57 AM

Add -fstack-protector{-all} to default CFLAGS?
 
On 12/05/10 18:31, Thomas Bächler wrote:

Am 12.05.2010 09:46, schrieb Allan McRae:

Honestly, if I wanted comments about gcc and busybox, the subject of
this email would have been something like "busybox build issues with
gcc-4.5". And then I would have scolded myself for not using the bug
tracker.

Can I just have comments on the proposed CFLAGS?


Okay, then you'll get a comment on that: Our toolchain is terribly
broken as it is, let's break it further by adding more flags.



Terribly broken? 17% of our repo has been rebuilt since it moved to
[core] and 1 package has been reported broken due to gcc. That is 0.07%
of packages and even that has a workaround. How terrible...


So, do I really have to wait until that is fixed before we can discuss
_future_ changes?


Allan

Thomas Bächler 05-12-2010 09:14 AM

Add -fstack-protector{-all} to default CFLAGS?
 
Am 12.05.2010 10:57, schrieb Allan McRae:
> Terribly broken? 17% of our repo has been rebuilt since it moved to
> [core] and 1 package has been reported broken due to gcc. That is 0.07%
> of packages and even that has a workaround. How terrible...

I know of three cases of breakage, one of which is an application not in
our repositories, and another one being any kernel older than 2.6.32
(Andy fixed that though I think).

The fact alone that all these applications BUILT with the new gcc
doesn't mean they behave correctly. What happens with the new gcc is
that applications build fine and without any warnings, but still behave
incorrectly. You don't know how many of those 17% we already rebuilt
actually are broken in a way we haven't seen yet.

> So, do I really have to wait until that is fixed before we can discuss
> _future_ changes?

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.

Andreas Radke 05-12-2010 01:20 PM

Add -fstack-protector{-all} to default CFLAGS?
 
Am Wed, 12 May 2010 11:14:48 +0200
schrieb Thomas Bächler <thomas@archlinux.org>:

> > So, do I really have to wait until that is fixed before we can
> > discuss _future_ changes?
>
> 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.

-Andy

Dan McGee 05-12-2010 02:24 PM

Add -fstack-protector{-all} to default CFLAGS?
 
On Wed, May 12, 2010 at 8:20 AM, Andreas Radke <a.radke@arcor.de> wrote:
> Am Wed, 12 May 2010 11:14:48 +0200
> schrieb Thomas Bächler <thomas@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


All times are GMT. The time now is 07:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.