Switch on compiler hardening defaults

[Kees Cook-6]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Marco d'Itri]

On Oct 25, Kees Cook <kees@...> wrote:

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

hardening-wrapper does not looks like a solution to me since it execs
perl for each call to gcc and ld when installed (even when inactive).
And as you noticed, nobody uses it (starting with me).

--
ciao,
Marco

[Russell Coker]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Tautschnig-4]

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

+1.

Thanks for bringing this up,
Michael

[Bastian Blank]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Gabor Gombas]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Weimer]

* 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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kees Cook-6]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Christoph Anton Mitterer-2]

Hi.

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


Cheers,
Chris.


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


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

[Paul Wise-3]

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

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

Any idea if these patches will be merged upstream?

--
bye,
pabs

http://wiki.debian.org/PaulWise


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

[Henrique de Moraes Holschuh]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kees Cook-6]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Samuel Thibault-8]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kees Cook-6]

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-default-format-security.diff
 - http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-default-fortify-source.diff
 - http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-default-relro.diff
 - http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/gcc-default-ssp.diff
 - http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/testsuite-hardening-format.diff
 - http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/testsuite-hardening-fortify.diff
 - http://patch-tracker.debian.org/patch/series/view/gcc-4.4/4.4.2-1/testsuite-hardening-printf-types.diff

(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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Christoph Anton Mitterer-2]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

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 ;)

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Henrique de Moraes Holschuh]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kees Cook-6]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Christoph Anton Mitterer-2]

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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Henrique de Moraes Holschuh]

On Thu, 29 Oct 2009, Christoph Anton Mitterer wrote:

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

I think so.

--
  "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-gcc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...