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  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:   Fri, 2 Aug 2019 09:57:45 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Rolf Eike Beer <eb@...ix.com>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-efi@...r.kernel.org,
        Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
        stable@...r.kernel.org, Matthias Kaehlcke <mka@...gle.com>,
        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, Jun 06, 2019 at 09:11:00AM +0200, Rolf Eike Beer wrote:
> Nick Desaulniers wrote:
> > On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers
> > 
> > <ndesaulniers@...gle.com> wrote:
> > > On Wed, Jun 5, 2019 at 9:26 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote:
> > > > > I decided to dig out a toy project which uses a DragonBoard 410c. This
> > > > > has
> > > > > been "running" with kernel 4.9, which I would keep this way for
> > > > > unrelated
> > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was
> > > > > buildable, which was good enough.
> > > > > 
> > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail:
> > > > > 
> > > > > aarch64-unknown-linux-gnueabi-ld:
> > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function
> > > > > `handle_kernel_image':
> > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:
> > > > > 63:
> > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_'
> > > > > aarch64-unknown-linux-gnueabi-ld:
> > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation
> > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol
> > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not
> > > > > be used when making a shared object; recompile with -fPIC
> > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:
> > > > > 63:
> > > > > (.init.text+0xc): dangerous relocation: unsupported relocation
> > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux'
> > > > > failed -make[1]: *** [vmlinux] Error 1
> > > > > 
> > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from
> > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be),
> > > > > reverting
> > > > > this commit fixes the build.
> > > > > 
> > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as
> > > > > 9.1.0. See
> > > > > the attached .config for reference.
> > > > > 
> > > > > If you have questions or patches just ping me.
> > > > 
> > > > Does Linus's latest tree also fail for you (or 5.1)?
> > > > 
> > > > Nick, do we need to add another fix that is in mainline for this to work
> > > > properly?
> > > > 
> > > > thanks,
> > > > 
> > > > greg k-h
> > > 
> > > Doesn't immediately ring any bells for me.
> > 
> > Upstream commits:
> > dd6846d77469 ("arm64: drop linker script hack to hide __efistub_ symbols")
> > 1212f7a16af4 ("scripts/kallsyms: filter arm64's __efistub_ symbols")
> > 
> > Look related to __efistub__ prefixes on symbols and aren't in stable
> > 4.9 (maybe Rolf can try cherry picks of those).
> 
> I now have cherry-picked these commits:
> 
> dd6846d77469
> fdfb69a72522e97f9105a6d39a5be0a465951ed8
> 1212f7a16af4
> 56067812d5b0e737ac2063e94a50f76b810d6ca3
> 
> The 2 additional ones were needed as dependencies of the others. Nothing of 
> this has helped.

Did this ever get resolved, or is it still an issue?

thanks,

greg k-h

Powered by blists - more mailing lists