Switch on compiler hardening defaults

Kees Cook · External Since: May 06, 2009 Posts: 13

Hello,

I would like to propose enabling[1] the GCC hardening patches that Ubuntu
uses[2]. Ubuntu has used it successfully for 1.5 years now (3 releases),
and many of the issues have already been fixed in packages that needed
adjustment[3]. After all this time, use of the hardening-wrapper[4]
package is still very low, so I think the right thing to do is to just fix
this in the compiler and everyone wins. I'm not suggesting that there
won't be added work to fix problems, but I believe that for Debian the
benefits now out-weigh the risks.

I do not expect to reach consensus with all developers on this, so I'm
not sure who I need to convince to move it forward. (Perhaps just the
GCC maintainers?) Regardless, if you agree with this, please speak up.
I think it's very important that this change happens.

My candid commentary and possible trolling...

Arguments for:
- users of Debian become safer (real[5] security vulnerabilities are
either non-issues or reduced to a DoS).
- security team has less work to do.
- software quality improves by finding subtle bugs (and not just
packaged software -- anything compiled with the Debian gcc).

Arguments against:
- makes the compiler's behavior different than stock compiler.
Rebuttal: honestly, I don't care -- it seems like such a
huge win for safety and is easy to debug. Debian
already carries plenty of patches anyway -- there
is no such thing as the "stock compiler".
- makes more work for dealing with warnings.
Rebuttal: those warnings are there for a reason -- they can
be real security issues, and should be fixed.
- lacks documentation.
Rebuttal: that may have been true a while ago, but I've worked
hard to document the features and how to handle
problems. See [2]. Even the gcc man pages are patched.
- makes running Debian slower.
Rebuttal: no, nothing supports this. The bulk of _FORTIFY_SOURCE
is compile-time. Run-time checks, including those from
-fstack-protector are just not measurable. The burden of
evidence for anyone claiming this is on them. I'm not
suggesting we turn on PIE; that option can be a problem.

Inflammatory observation: Debian may be the single remaining major Linux
distribution that does not use the stack protector and _FORTIFY_SOURCE
when building its packages. I find this embarrassing. Check[6] for
yourself.

Thanks,

-Kees

[1] http://outflux.net/hardening-for-all.patch
(Note that the gcc hardening does NOT turn on PIE, which has
measurable performance problems on some architectures.)

[2] https://wiki.ubuntu.com/CompilerFlags

[3] Sampling of bugs I've personally filed:
Closed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521108
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529074
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479398
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488456
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488457
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497833
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497865
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505734
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505233
Open
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523807
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488460
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488462

[4] http://wiki.debian.org/Hardening

[5] Many vulnerabilities have been blocked in Ubuntu, but I will give one
good example of a remote root vulnerability with functional exploits
in the wild that was a non-issue on versions of Ubuntu with the
hardened compiler defaults:
http://www.debian.org/security/2009/dsa-1833

[6] Are there _chk functions in common binaries?
$ objdump -R /bin/df | grep _chk
0000000000612048 R_X86_64_JUMP_SLOT __fprintf_chk
0000000000612068 R_X86_64_JUMP_SLOT __printf_chk
00000000006120c0 R_X86_64_JUMP_SLOT __memcpy_chk
00000000006121c0 R_X86_64_JUMP_SLOT __stack_chk_fail
0000000000612220 R_X86_64_JUMP_SLOT __sprintf_chk
0000000000612230 R_X86_64_JUMP_SLOT __snprintf_chk

--
Kees Cook @debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Russell Coker · External Since: Dec 23, 2004 Posts: 179

On Monday 26 October 2009 09:22:26 Marco d'Itri wrote:
> > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > uses[2].
>
> Seconded.

Thirded.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Romain Francoise · External Since: Apr 07, 2004 Posts: 309

Kees Cook <kees DeleteThis @debian.org> writes:

> I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> uses[2]. Ubuntu has used it successfully for 1.5 years now (3 releases),
> and many of the issues have already been fixed in packages that needed
> adjustment[3]. After all this time, use of the hardening-wrapper[4]
> package is still very low, so I think the right thing to do is to just fix
> this in the compiler and everyone wins. I'm not suggesting that there
> won't be added work to fix problems, but I believe that for Debian the
> benefits now out-weigh the risks.

Agreed. The freeze is months away, there's plenty of time to deal
with the potential fallout of enabling this, so let's just do it.

--
Romain Francoise <rfrancoise DeleteThis @debian.org>
http://people.debian.org/~rfrancoise/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Bastian Blank · External Since: Nov 21, 2004 Posts: 774

On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> uses[2].

How do they work? Do they also change the free-standing compiler or only
the hosted one? There is a lot of software, which (I would say) missuse
the hosted compiler to build non-userspace-code, including the Linux
kernel.

Bastian

--
History tends to exaggerate.
-- Col. Green, "The Savage Curtain", stardate 5906.4

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Gabor Gombas · External Since: Mar 22, 2005 Posts: 154

On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > uses[2].
>
> How do they work? Do they also change the free-standing compiler or only
> the hosted one? There is a lot of software, which (I would say) missuse
> the hosted compiler to build non-userspace-code, including the Linux
> kernel.

It seems the kernel will not be happy if the stack protector is switched
on unconditionally:

http://osdir.com/ml/linux-kernel/2009-10/msg07064.html

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Florian Weimer · External Since: Nov 10, 2004 Posts: 648

* Kees Cook:

> I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> uses[2].

Seems a good idea to me. But I think we should defer the required
full archive rebuild until we've got the hardening patch for operator
new[] (which currently can return a heap block which is smaller than
requested). I've got a preliminary version, but it's got a hole when
operator new[] is invoked on a variable-length array. The easy fix
would probably to outlaw heap allocation of VLAs (it's one of those C
GCC extensions that leaked into C++, and it's arguably less needed for
C++).

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Kees Cook · External Since: May 06, 2009 Posts: 13

Hi,

On Mon, Oct 26, 2009 at 01:36:28PM +0100, Florian Weimer wrote:
> * Kees Cook:
> > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > uses[2].
>
> Seems a good idea to me. But I think we should defer the required
> full archive rebuild until we've got the hardening patch for operator
> new[] (which currently can return a heap block which is smaller than
> requested). I've got a preliminary version, but it's got a hole when
> operator new[] is invoked on a variable-length array. The easy fix
> would probably to outlaw heap allocation of VLAs (it's one of those C
> GCC extensions that leaked into C++, and it's arguably less needed for
> C++).

Right, I agree with this -- I figure this release can be seen as a
transition release, where not everything is compiled that way. I don't
want to introduce so much archive churn anyway.

-Kees

--
Kees Cook @debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Christoph Anton Mitterer · External Since: Jan 11, 2006 Posts: 16

Hi.

Ever thought about integrating PaX [0] per default in Debian?
I'm however not sure how much this actually breaks Wink

Cheers,
Chris.

[0] http://pax.grsecurity.net/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Paul Wise · External Since: Jan 30, 2007 Posts: 81

On Tue, Oct 27, 2009 at 4:41 AM, Christoph Anton Mitterer
<calestyo DeleteThis @scientia.net> wrote:

> Ever thought about integrating PaX [0] per default in Debian?
> I'm however not sure how much this actually breaks Wink

Any idea if these patches will be merged upstream?

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Paul Wise · External Since: Jan 30, 2007 Posts: 81

On Tue, Oct 27, 2009 at 2:52 PM, Yves-Alexis Perez <corsac.DeleteThis@debian.org> wrote:
> On mar., 2009-10-27 at 09:32 +0800, Paul Wise wrote:
>> On Tue, Oct 27, 2009 at 4:41 AM, Christoph Anton Mitterer
>> <calestyo.DeleteThis@scientia.net> wrote:
>>
>> > Ever thought about integrating PaX [0] per default in Debian?
>> > I'm however not sure how much this actually breaks Wink

>>
>> Any idea if these patches will be merged upstream?
>
> I don't think so.

I guess that answers the question of integrating PaX into Debian:

http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
http://kernel-handbook.alioth.debian.org/ch-source.html#s-acceptance

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Henrique de Moraes Holsch · External Since: Nov 11, 2004 Posts: 648

On Mon, 26 Oct 2009, Gabor Gombas wrote:
> On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > uses[2].
> >
> > How do they work? Do they also change the free-standing compiler or only
> > the hosted one? There is a lot of software, which (I would say) missuse
> > the hosted compiler to build non-userspace-code, including the Linux
> > kernel.
>
> It seems the kernel will not be happy if the stack protector is switched
> on unconditionally:
>
> http://osdir.com/ml/linux-kernel/2009-10/msg07064.html

Indeed. The kernel build system needs to be able to command whether
stackprotect is enabled or not without surprises...

I assume very performance-critical applications will also need it disabled,
if they have hot paths where dcache footprint matters. But I think we can
safely assume these will be quite rare, so as long as one can disable the
stackprotector easily enough through CFLAGS, we could just do it in a
case-by-case basis on debian/rules.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Kees Cook · External Since: May 06, 2009 Posts: 13

On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > uses[2].
>
> How do they work? Do they also change the free-standing compiler or only
> the hosted one? There is a lot of software, which (I would say) missuse
> the hosted compiler to build non-userspace-code, including the Linux
> kernel.

The stack protector is conditional on being linked with libc, so, if you
build with -nostdlib (as the kernel does), it is implicitly disabled.

--
Kees Cook @debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Samuel Thibault · External Since: May 08, 2009 Posts: 47

Kees Cook, le Tue 27 Oct 2009 14:11:43 -0700, a écrit :
> On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > uses[2].
> >
> > How do they work? Do they also change the free-standing compiler or only
> > the hosted one? There is a lot of software, which (I would say) missuse
> > the hosted compiler to build non-userspace-code, including the Linux
> > kernel.
>
> The stack protector is conditional on being linked with libc, so, if you
> build with -nostdlib (as the kernel does), it is implicitly disabled.

-nostdlib is a linker option, not a compiler option. The compiler
would still emit references to __stack_chk_fail. What you probably
mean is -ffreestanding, but it doesn't prevent references to
__stack_chk_fail either, and it even produces TLS references, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838

Samuel

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Kees Cook · External Since: May 06, 2009 Posts: 13

Hi,

On Tue, Oct 27, 2009 at 01:30:12PM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 26 Oct 2009, Gabor Gombas wrote:
> > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > > uses[2].
> > >
> > > How do they work? Do they also change the free-standing compiler or only
> > > the hosted one? There is a lot of software, which (I would say) missuse
> > > the hosted compiler to build non-userspace-code, including the Linux
> > > kernel.
> >
> > It seems the kernel will not be happy if the stack protector is switched
> > on unconditionally:
> >
> > http://osdir.com/ml/linux-kernel/2009-10/msg07064.html
>
> Indeed. The kernel build system needs to be able to command whether
> stackprotect is enabled or not without surprises...
>
> I assume very performance-critical applications will also need it disabled,
> if they have hot paths where dcache footprint matters. But I think we can
> safely assume these will be quite rare, so as long as one can disable the
> stackprotector easily enough through CFLAGS, we could just do it in a
> case-by-case basis on debian/rules.

Right, -fno-stack-protector via CFLAGS will disable it (as will
-nostdlib). The work-arounds for the default are all documented both in the
gcc manpage[1] (though this would need tweaking since it currently says
"Ubuntu") and on the Ubuntu wiki page I mentioned earlier[2].

The specific set of patch that would be enabled are:
- http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-...ault-fo
- http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-...ault-fo
- http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-...ault-re
- http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-...ault-ss
- http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/test...te-hard
- http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/test...te-hard
- http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/test...te-hard

(I am trying[3], since they are general improvements, to get the latter
2 accepted by upstream gcc so our gcc package doesn't need to carry them.)

-Kees

[1] http://manpages.ubuntu.com/manpages/karmic/man1/gcc.1.html
...
NOTE: In Ubuntu 6.10 and later versions this option is enabled by default
for C, C++, ObjC, ObjC++, if neither @option{-fno-stack-protector}
nor @option{-nostdlib} are found.
...

[2] https://wiki.ubuntu.com/CompilerFlags

[3] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39536
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39537

--
Kees Cook @debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Christoph Anton Mitterer · External Since: Jan 11, 2006 Posts: 16

On Tue, 2009-10-27 at 09:32 +0800, Paul Wise wrote:
> Any idea if these patches will be merged upstream?
It's probably quite unlikely,... although I never understood why,..
Even though it's available for some architectures,.. it would improve
security at least on them.

Cheers,

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Christoph Anton Mitterer · External Since: Jan 11, 2006 Posts: 16

On Tue, 2009-10-27 at 15:48 +0800, Paul Wise wrote:
> http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
> http://kernel-handbook.alioth.debian.org/ch-source.html#s-acceptance
The thing is,..
A patch like PaX would (IMHO) improve security a lot,... and it would be
worth thinking for a distribution, whether to take this burden and to
manually maintain it...

Apart from that,.. if something like PaX is used in a mainline distro,
it could get a development boost and perhaps be even included in the
vanilla tree at some time.

As PaX needs PIC as far as I remember, this decision would have to be
made at a global level for the distribution anyway, as everything would
have to be compiled with PIC.

Cheers,
Chris.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Bastian Blank · External Since: Nov 21, 2004 Posts: 774

On Mon, Oct 26, 2009 at 09:41:59PM +0100, Christoph Anton Mitterer wrote:
> Ever thought about integrating PaX [0] per default in Debian?

What features does the grsecurity patch provide currently? I know that
several of the mentioned PaX features are supported in vanilla kernel in
the meantime:
- Non-executable memory on x86-32 with PAE.
- Randomized stack and heap bases.
- /dev/mem is highly restricted now, /dev/kmem removed.

What would be a step forward:
- Move all newer x86 32bit machines to PAE to support non-executable
pages.
- Make any code PIC, including binaries (PIE) and static libs.

> I'm however not sure how much this actually breaks Wink

It takes to much compile time configuration, so don't even think about
it.

Bastian

--
Phasers locked on target, Captain.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Henrique de Moraes Holsch · External Since: Nov 11, 2004 Posts: 648

On Tue, 27 Oct 2009, Kees Cook wrote:
> > > It seems the kernel will not be happy if the stack protector is switched
> > > on unconditionally:
> > >
> > > http://osdir.com/ml/linux-kernel/2009-10/msg07064.html
> >
> > Indeed. The kernel build system needs to be able to command whether
> > stackprotect is enabled or not without surprises...

....

> Right, -fno-stack-protector via CFLAGS will disable it (as will
> -nostdlib). The work-arounds for the default are all documented both in the
> gcc manpage[1] (though this would need tweaking since it currently says
> "Ubuntu") and on the Ubuntu wiki page I mentioned earlier[2].

Well, the issue raised in LKML is that you absolutely should *not* enable
-fstack-protector-all unless you _really_ know what you're doing, and most
certainly not by default. It has nothing to do with -fstack-protector, just
with -fstack-protector-all. But it does show that extra stack usage CAN
have bad effects on performance in pathological cases (which -all seems
to cause more readly :-p ).

http://osdir.com/ml/linux-kernel/2009-10/msg08763.html looks like an
horror tale (caused by -fstack-protector-all).

Assuming you guys are _not_ enabling -fstack-protector-ALL by default, just
-fstack-protector, my only worry is this:

What would happen if the kernel people start using -fstack-protector only on
_some_ files for very good reasons, and you end up with both the
-fno-stack-... and -fstack-... in a gcc invocation?

Maybe this calls for a env. variable or special parameter (for CFLAGS) to
cause gcc stack-protector defaults not to be changed in that invocation (as
opposed to the direct use of -f and -fno). We'd need to use that on kernel
builds as well as on any packages that DO know about -fstack-protector to
avoid headaches and surprises long-term, I think.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Kees Cook · External Since: May 06, 2009 Posts: 13

Hi,

On Tue, Oct 27, 2009 at 10:19:22PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 27 Oct 2009, Kees Cook wrote:
> > > > It seems the kernel will not be happy if the stack protector is switched
> > > > on unconditionally:
> > > >
> > > > http://osdir.com/ml/linux-kernel/2009-10/msg07064.html
> > >
> > > Indeed. The kernel build system needs to be able to command whether
> > > stackprotect is enabled or not without surprises...
>
> ...
>
> > Right, -fno-stack-protector via CFLAGS will disable it (as will
> > -nostdlib). The work-arounds for the default are all documented both in the
> > gcc manpage[1] (though this would need tweaking since it currently says
> > "Ubuntu") and on the Ubuntu wiki page I mentioned earlier[2].
>
> Well, the issue raised in LKML is that you absolutely should *not* enable
> -fstack-protector-all unless you _really_ know what you're doing, and most
> certainly not by default. It has nothing to do with -fstack-protector, just
> with -fstack-protector-all. But it does show that extra stack usage CAN
> have bad effects on performance in pathological cases (which -all seems
> to cause more readly :-p ).
>
> http://osdir.com/ml/linux-kernel/2009-10/msg08763.html looks like an
> horror tale (caused by -fstack-protector-all).

Right, the kernel does its own thing, and isn't exactly related to this
default.

> Assuming you guys are _not_ enabling -fstack-protector-ALL by default, just
> -fstack-protector, my only worry is this:

Correct, -fstack-protector-all is not sane for the general case.

Mildly related to this, I would note that while the upstream default for
the compiler to decide between adding and not adding the prefix/suffix
code to functions is when a function has an 8 byte stack or more.
I noticed when examining SUSE builds that they seem to force this to 4
bytes (--param ssp-buffer-size=4). I do not have a strong opinion on
this, and lacking further evidence, would stick to the 8 byte default.

> What would happen if the kernel people start using -fstack-protector only on
> _some_ files for very good reasons, and you end up with both the
> -fno-stack-... and -fstack-... in a gcc invocation?

AIUI, the kernel builds with -nostdlib, so gcc would not include
-fstack-protector. Additionally, if -fno-stack-protector is seen on the
invocation, no -fstack-protector is added. If, for some reason, something
built with both -fno-stack-protector and -fstack-protector on the
invocation, the latter setting wins.

I don't think this will be problem.

> Maybe this calls for a env. variable or special parameter (for CFLAGS) to
> cause gcc stack-protector defaults not to be changed in that invocation (as
> opposed to the direct use of -f and -fno). We'd need to use that on kernel
> builds as well as on any packages that DO know about -fstack-protector to
> avoid headaches and surprises long-term, I think.

I don't see any reason to do this -- Ubuntu has used the -fstack-protector
default for 3 years now. This is a very well tested area. (I'm not
saying it'll be perfect, but I think the issues are well understood by a
lot of people, and solutions will be straight forward.)

-Kees

--
Kees Cook @debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Christoph Anton Mitterer · External Since: Jan 11, 2006 Posts: 16

On Tue, 2009-10-27 at 22:19 -0200, Henrique de Moraes Holschuh wrote:
> Well, the issue raised in LKML is that you absolutely should *not* enable
> -fstack-protector-all unless you _really_ know what you're doing, and most
> certainly not by default. It has nothing to do with -fstack-protector, just
> with -fstack-protector-all. But it does show that extra stack usage CAN
> have bad effects on performance in pathological cases (which -all seems
> to cause more readly :-p ).
Isn't this what they've done starting with the 2.6.31 debian packages?
CONFIG_CC_STACKPROTECTOR_ALL=y
CONFIG_CC_STACKPROTECTOR=y

Should we bugreport this agains src:linux2.6 ?

Cheers,
Chris.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org