Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Miles Lane]

On 7/2/06, Ingo Molnar <mingo@xxxxxxx> wrote:
> * Miles Lane <miles.lane@xxxxxxxxx> wrote:
>
> > >If Ubuntu patched gcc rather than just putting it in the build
> > >environment... then you should switch to a less braindead distribution
> > >really ;)
>
> > Well, from the web page referenced at the top of this message, you can
> > see that they are already aware of these issues:
> >
> > Cons:
> >    *      It breaks current upstream kernel builds and potentially
> > other direct usages of gcc. Kernel is by far the most important use
> > case. Upstream should change the default options to build with
> > -fno-stack-protector by default.
> >    *      It is not conformant to upstream gcc behaviour.
>
> i think the only sane way for a generic distro to introduce an intrusive
> security feature is a 3-phase process:
>
>  #1 - introduce the new security option
>  #2 - increase use of it gradually, map all the exceptions on the way
>  #3 - once exceptions are mapped widely enough, switch the option to
>       default-on
>
> this makes the introduction of security seemless/gradual to
> users/developers, without compromising on the end goal of having the
> security feature on by default.
>
> Ubuntu seems to have opted to go to phase #3 directly, which is no doubt
> quite brutal but it's their choice. In any case, whichever methodology
> is used the kernel got flagged as an "exception" and we should help this
> security effort and change the kernel: i.e. lets apply the
> -fno-stack-protector flag to the kernel build.

Well, I see that Andrew has accepted (mm5)
the -fno-stack-protector patch for the Makefile, but klibc remains
unpatched (scripts/Kbuild.klibc and usr/klibc/arch/i386/MCONFIG).
Would the right person in this dialog submit those changes to Andrew?

Many thanks,
       Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/