linux-kernel - Re: [PATCH 3/7] [HACK] pass endianess flag to LTO linker

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:   Wed, 21 Feb 2018 10:09:53 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Nicolas Pitre <nico@...aro.org>, Andi Kleen <ak@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 3/7] [HACK] pass endianess flag to LTO linker

On 21 February 2018 at 09:48, Arnd Bergmann <arnd@...db.de> wrote:
> On Wed, Feb 21, 2018 at 9:37 AM, Ard Biesheuvel
> <ard.biesheuvel@...aro.org> wrote:
>> On 20 February 2018 at 21:59, Arnd Bergmann <arnd@...db.de> wrote:
>>> We need some way to pass -mbig-endian to the linker during the
>>> LTO link stage, otherwise we get a waning like
>>>
>>> arm-linux-gnueabi/bin/ld: arch/arm/lib/clearbit.o: compiled for a big endian system and target is little endian
>>>
>>> for each file we link in.
>>>
>>> There is probably a better method of passing that flag, I'm just
>>> adding it to a different hack that I added earlier for x86 LTO
>>> here.
>>>
>>
>> In general, LTO requires that *all* C flags are passed to the linker.
>> Given that linking now involves code generation, any C flag that
>> affects code generation must be visible to the linker as well, which
>> includes all the tweaks and overrides that we add per-file or
>> per-directory. It is not clear to me how much of this is carried in
>> the intermediate representation as metadata, but we should probably
>> err on the side of caution here, and update the Kbuild routines to
>> pass the complete value of KBUILD_CFLAGS (or whatever it is called) to
>> ld as well.
>
> It looks like we're just missing KBUILD_CPPFLAGS.
>
> However, I wonder for the more general case what happens to files
> that require non-standard CFLAGS.

That was kind of my point, yes.

> In some cases we turn off
> some optimization step for a file, we might remove '-pg', or build for
> a particular target architecture. Do we have to turn off -flto for any file
> that requires this for correct behavior?
>

Excellent question. I think the problem is that the file boundary is
becoming blurred with LTO, and so any option that is absolutely
required to build a single file correctly may need to be applied to
vmlinux as a whole. Whether that is the case for any particular option
depends on which compiler pass(es) is (are) affected by the option,
i.e., whether it is taken into account when creating the intermediate
representation.