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]

Message-ID: <CAGXu5j+LeV+7GBXCikUfiO-Rzu1Dnv7pMh2sfFLc_RMOSoiStg@mail.gmail.com>
Date:   Tue, 17 Oct 2017 11:26:48 -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 8:52 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Tue, Oct 17, 2017 at 5:34 PM, Kees Cook <keescook@...omium.org> wrote:
>> On Tue, Oct 17, 2017 at 8:26 AM, Kees Cook <keescook@...omium.org> wrote:
>>> On Tue, Oct 17, 2017 at 8:23 AM, Arnd Bergmann <arnd@...db.de> wrote:
>>>> On Tue, Oct 17, 2017 at 1:00 PM, 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.
>>>>>
>>>>> 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?
>>>>
>>>> It's probably a little different. I tried bisecting the gcc commit that fixed
>>>> the issue for me, and ended up with this commit
>>>>
>>>> https://gitlab.indel.ch/thirdparty/gcc/commit/c14bac81551d6769741c2b1cc55e04d94fe8d3a7
>>>>
>>>> that caused the target to change from x86_64-unknown-linux to
>>>> x86_64-pc-linux, and apparently caused the compiler bootstrap
>>>> to incorrectly identify the capabilities of the assembler. As a result,
>>>> the assembler output inside of scripts/gcc-x86_64-has-stack-protector.sh
>>>> that should be
>>>> [snip]
>>>
>>> Yeah, %gs: vs __stack_chk_guard global.
>>>
>>> Do you know which gccs (of the past) had this?
>>>
>>> akpm's build error is different still, there are no warnings at all
>>> and then the build fails with missing __stack_chks. I'm still trying
>>> to figure that one out.
>>
>> Oh, I think I know what's happening. I'm going to try to simulate this
>> and send another patch for testing...
>>
>> (I'm still curious about the compiler versions, since my gcc 4.4.4
>> works fine for stack-protector.)
>
> I've managed to reduce the change that fixed it to this bit in the
> compiler sources:
>
> index dbfb978..d5bc694 100755
> --- a/config.guess
> +++ b/config.guess
> @@ -1021,7 +1021,7 @@ EOF
>         echo ${UNAME_MACHINE}-dec-linux-${LIBC}
>         exit ;;
>      x86_64:Linux:*:*)
> -       echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
> +       echo ${UNAME_MACHINE}-pc-linux-${LIBC}
>         exit ;;
>      xtensa*:Linux:*:*)
>         echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
>
> I still don't know why that makes a difference, but all versions
> prior to gcc-6.1 have the problem for me.

What happens if you add -mstack-protector-guard=tls ?

-Kees

-- 
Kees Cook
Pixel Security