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