linux-kernel - Re: more build problems with "Makefile: move stackprotector availability out of Kconfig"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 17 Oct 2017 08:20:47 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Mark Brown <broonie@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: more build problems with "Makefile: move stackprotector
 availability out of Kconfig"

On Tue, Oct 17, 2017 at 4:00 AM, Arnd Bergmann <arnd@...db.de> wrote:
> Hi Kees,
>
> On my test box, current linux-next kernels fail to build due to the
> patch that introduces CONFIG_CC_STACKPROTECTOR_AUTO, with my mainline
> gcc
> builds up to gcc-5.5.0. gcc-6 and higher work fine, as
> scripts/gcc-x86_64-has-stack-protector.sh returns 'y' for those.

Do the others fail?

> Using the compilers provided by Ubuntu (4.6/4.7/4.8/4.9), everything
> also works as expected, so my interpretation is that mainline gcc did
> not enable the stack protector until gcc-6, while distributions did.
>
> Do you agree with that interpretation?

No, stock gcc enabled this in gcc 4.2 (though it was broken briefly in
that series).

> If yes, is there anything we can do about it? I can probably rebuild
> my collection of x86 compilers to enable stackprotector if necessary,
> but I wonder how many other people will run into the same problem.

_AUTO should just continue with a warning if stack protector is
unavailable. If it's _broken_, it's suppose to fail only for new
compilers where that failure would be unexpected (there is a patch in
mmots that checks for gcc 4.4, but it turns out this is wrong).

I've been debugging this with akpm, but I can't reproduce the problems
he's seeing.

What failures are you seeing?

-Kees

-- 
Kees Cook
Pixel Security