All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Kees Cook <keescook@chromium.org>
Cc: Mark Brown <broonie@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
Subject: Re: more build problems with "Makefile: move stackprotector availability out of Kconfig"
Date: Tue, 17 Oct 2017 17:52:55 +0200	[thread overview]
Message-ID: <CAK8P3a3fHWdgH23LjACzM+htGCY-bHgM5Y6uB8J6K5XgfT8e+g@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5j+1+rLA4uOrEv9yc9RE9Rna4QVsNqfg0zTDSMZ6VwGzaw@mail.gmail.com>

On Tue, Oct 17, 2017 at 5:34 PM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Oct 17, 2017 at 8:26 AM, Kees Cook <keescook@chromium.org> wrote:
>> On Tue, Oct 17, 2017 at 8:23 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Tue, Oct 17, 2017 at 1:00 PM, Arnd Bergmann <arnd@arndb.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.

      Arnd

  reply	other threads:[~2017-10-17 15:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-17 11:00 more build problems with "Makefile: move stackprotector availability out of Kconfig" Arnd Bergmann
2017-10-17 15:20 ` Kees Cook
2017-10-17 15:23 ` Arnd Bergmann
2017-10-17 15:26   ` Kees Cook
2017-10-17 15:33     ` Arnd Bergmann
2017-10-17 15:34     ` Kees Cook
2017-10-17 15:52       ` Arnd Bergmann [this message]
2017-10-17 18:26         ` Kees Cook
2017-10-17 18:41           ` Arnd Bergmann
2017-10-17 18:47             ` Arnd Bergmann
2017-10-17 18:52               ` Mark Brown
2017-10-17 18:53                 ` Kees Cook
2017-10-17 19:56                   ` Andrew Morton
2017-10-17 20:04                     ` Mark Brown
2017-10-17 20:06                     ` Kees Cook
2017-10-19  0:41                       ` Masahiro Yamada
2017-10-19  2:19                         ` Kees Cook
2017-10-17 18:57               ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK8P3a3fHWdgH23LjACzM+htGCY-bHgM5Y6uB8J6K5XgfT8e+g@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.