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

newer
[arch-dev-public] [signoff] popt...

Allan McRae

12 May 2010 12 May '10

4:35 a.m.

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

Show replies by date

Jan de Groot

12 May 12 May

8:49 a.m.

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

9:15 a.m.

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

9:29 a.m.

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

9:46 a.m.

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

10:31 a.m.

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

10:57 a.m.

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

11:14 a.m.

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

3:20 p.m.

Am Wed, 12 May 2010 11:14:48 +0200 schrieb Thomas Bächler :

...

...
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

4:24 p.m.

On Wed, May 12, 2010 at 8:20 AM, Andreas Radke wrote:

...

Am Wed, 12 May 2010 11:14:48 +0200 schrieb Thomas Bächler :

...
...
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

Jan de Groot

5:06 p.m.

On Wed, 2010-05-12 at 09:24 -0500, Dan McGee wrote:

...

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.

This change will make code segfault or assert on exploit attempt. It won't fix code automatically, it just prevents exploiting them.

5107

Age (days ago)

5107

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Allan McRae
Andreas Radke
Dan McGee
Jan de Groot
Thomas Bächler