From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Leif Lindholm <leif.lindholm@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
Laszlo Ersek <lersek@redhat.com>,
"Feng, Bob C" <bob.c.feng@intel.com>,
"Gao, Liming" <liming.gao@intel.com>
Subject: Re: [PATCH] BaseTools/GenFw ARM: don't permit R_ARM_GOT_PREL relocations
Date: Tue, 11 Dec 2018 12:21:04 +0100 [thread overview]
Message-ID: <CAKv+Gu8qV319ppTyK3jAddFgn2RMdtpMLCMYvTYCUQ4hAZccEg@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu84QxP_-KVej9w7wKjZv4iQyZYiEE_cbH4kKT2v+r_+Ew@mail.gmail.com>
On Tue, 11 Dec 2018 at 12:19, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Tue, 11 Dec 2018 at 10:53, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> >
> > On Tue, Dec 11, 2018 at 10:37:15AM +0100, Ard Biesheuvel wrote:
> > > We currently permit R_ARM_GOT_PREL relocations in the ELF32 conversion
> > > routines, under the assumption that relative relocations are fine as
> > > long as the section layout is the same between ELF and PE/COFF.
> > >
> > > However, as is the case with any proxy generating relocation, it is
> > > up to the linker to emit an entry in the GOT table and populate it
> > > with the correct absolute address, which should also be fixed up at
> > > PE/COFF load time. Unfortunately, the relocations covering the GOT
> > > section are not emitted into the static relocation sections processed
> > > by GenFw, but only in the dynamic relocation section as a R_ARM_RELATIVE
> > > relocation, and so GenFw fails to emit the correct PE/COFF relocation
> > > data for GOT entries.
> > >
> > > Since GOT indirection is pointless anyway for PE/COFF modules running
> > > in UEFI context, let's just drop the references to R_ARM_GOT_PREL from
> > > GenFw, resulting in a build time failure rather than a runtime failure
> > > if such relocations do occur.
> > >
> > > Cc: Bob Feng <bob.c.feng@intel.com>
> > > Cc: Liming Gao <liming.gao@intel.com>
> > > Cc: Leif Lindholm <leif.lindholm@linaro.org>
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >
> > Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
> >
> > Ouch. This sounds like the best move for now. But how do we deal with
> > builds that actually break?
> >
>
> So the only builds that are breaking due to this are ones where we run
> the linker in PIE mode (which only happens in
> ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf), and using the
> GNU gold linker. The reason we need the -pie option is to force the
> linker to emit dynamic relocations into the binary so it can relocate
> itself. This is necessary because the firmware image may execute from
> a a priori unknown memory offset.
>
> I am playing around with hidden visibility and other tweaks to coerce
> the linker into emitting direct relative references instead of GOT
> based ones, and it is very tedious. The GOLD linker really doesn't
> appear to be set up for bare metal binaries.
Oh, and on AARCH64 it is even more annoying, given that the relative
GOT references are emitted as ADRP/ADD pairs, which means we have the
4 KB alignment issue as well.
next prev parent reply other threads:[~2018-12-11 11:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 9:37 [PATCH] BaseTools/GenFw ARM: don't permit R_ARM_GOT_PREL relocations Ard Biesheuvel
2018-12-11 9:53 ` Leif Lindholm
2018-12-11 11:19 ` Ard Biesheuvel
2018-12-11 11:21 ` Ard Biesheuvel [this message]
2018-12-11 13:40 ` Gao, Liming
2018-12-11 13:45 ` Ard Biesheuvel
2018-12-12 0:24 ` Gao, Liming
2018-12-12 7:38 ` Ard Biesheuvel
2018-12-11 15:57 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKv+Gu8qV319ppTyK3jAddFgn2RMdtpMLCMYvTYCUQ4hAZccEg@mail.gmail.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox