linux-kernel - Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKv+Gu9Leaq_s2kVNzHx+zkdKFXgQVkouN3M56u5nou5WX=cKg@mail.gmail.com>
Date:   Thu, 6 Jun 2019 08:55:29 +0200
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Rolf Eike Beer <eb@...ix.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x
 (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers <ndesaulniers@...gle.com> wrote:
>
> On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel
> <ard.biesheuvel@...aro.org> wrote:
> > For the record, this is an example of why I think backporting those
> > clang enablement patches is a bad idea.
>
> There's always a risk involved with backports of any kind; more CI
> coverage can help us mitigate some of these risks in an automated
> fashion before we get user reports like this.  I meet with the
> KernelCI folks weekly, so I'll double check on the coverage of the
> stable tree's branches.  The 0day folks are also very responsive and
> I've spoken with them a few times, so I'll try to get to the bottom of
> why this wasn't reported by either of those.
>
> Also, these patches help keep Android, CrOS, and Google internal
> production kernels closer to their upstream sources.
>
> > We can't actually build those
> > kernels with clang, can we? So what is the point? </grumpy>
>
> Here's last night's build:
> https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434
>

If you are saying that plain upstream 4.9-stable defconfig can be
built with Clang, then I am pleasantly surprised.

> Also, Android and CrOS have shipped X million devices w/ 4.9 kernels
> built with Clang.  I think this number will grow at least one order of
> magnitude imminently.
>

I know that (since you keep reminding me :-)), but obviously, Google
does not care about changes that regress GCC support.

> > Alternatively, we can just revert this patch from 4.9
>
> That would break at least the above devices next time Android and CrOS
> pulled from stable.
>
> > It would be helpful to get a relocation dump (objdump -r) of
> > arm64-stub.o to figure out which symbol needs a 'hidden' annotation to
> > prevent GCC from emitting it as a PIC reference requiring a GOT.
>
> Sounds like the best way forward, as well as having more info on which
> config/toolchain reliably reproduces the issue.

Let me know once you can reproduce it, I will have a look as well.