linux-kernel - Re: [PATCH v3] kbuild: fix linker feature test macros when cross compiling with Clang

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:   Mon, 11 Dec 2017 11:17:16 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michael Davidson <md@...gle.com>,
        Greg Hackmann <ghackmann@...gle.com>, pirama@...gle.com,
        Matthias Kaehlcke <mka@...omium.org>,
        Ingo Molnar <mingo@...nel.org>,
        Douglas Anderson <dianders@...omium.org>,
        Cao jin <caoj.fnst@...fujitsu.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Mark Charlebois <charlebm@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] kbuild: fix linker feature test macros when cross
 compiling with Clang

On Mon, Nov 6, 2017 at 7:47 PM, Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
> I was not seeing my linker flags getting added when using ld-option when
> cross compiling with Clang. Upon investigation, this seems to be due to
> a difference in how GCC vs Clang handle cross compilation.
>
> GCC is configured at build time to support one backend, that is implicit
> when compiling.  Clang is explicit via the use of `-target <triple>` and
> ships with all supported backends by default.
>
> GNU Make feature test macros that compile then link will always fail
> when cross compiling with Clang unless Clang's triple is passed along to
> the compiler. For example:
>
> $ clang -x c /dev/null -c -o temp.o
> $ aarch64-linux-android/bin/ld -E temp.o
> aarch64-linux-android/bin/ld:
> unknown architecture of input file `temp.o' is incompatible with
> aarch64 output
> aarch64-linux-android/bin/ld:
> warning: cannot find entry symbol _start; defaulting to
> 0000000000400078
> $ echo $?
> 1
>
> $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
> $ aarch64-linux-android/bin/ld -E temp.o
> aarch64-linux-android/bin/ld:
> warning: cannot find entry symbol _start; defaulting to 00000000004002e4
> $ echo $?
> 0
>
> This causes conditional checks that invoke $(CC) without the target
> triple, then $(LD) on the result, to always fail.
>
> Suggested-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@...gle.com>
> Reviewed-by: Matthias Kaehlcke <mka@...omium.org>

After this patch, I get the following warning in arm64 kernel builds
with CONFIG_ARM64_ERRATUM_843419:

arch/arm64/Makefile:27: ld does not support --fix-cortex-a53-843419;
kernel may be susceptible to erratum

This only happens on the first build though, when the cached variable
is being set. On the second build we get the contents from the cache
and the warning disappears.

I've tried debugging it further but did not get anywhere with that.

        Arnd