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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAKv+Gu_=aUmN76Wzy5kokgP6hcZPWAwW_7=ekqOawkfg7LPE3g@mail.gmail.com>
Date:   Thu, 6 Jun 2019 10:58:45 +0200
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>,
        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 Thu, 6 Jun 2019 at 09:08, Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote:
> > 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.
>
> I know some specific configs can, there's no rule that I know of that
> 'defconfig' support is required.  But then again, it might also work,
> try it and see :)
>

Well, it is the rule that the arm64 maintainers use.

> > > 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.
>
> What are you talking about?  Bugs happen all the time, what specifically
> did "Google" do to break gcc support?  If you are referring to this
> patch, and it is a regression, of course I will revert it.  But note
> that gcc and 4.9 works just fine for all of the other users right now,
> remember we do do a lot of testing of these releases.
>

Don't get me wrong: I am not blaming Google for this. But having
strict Documented/ stable-rules, violating them by backporting patches
that are clearly not bug fixes, and *then* saying 'bugs happen all the
time' makes no sense to me at all.