Re: [PATCH] BaseTools/GenFw ARM: don't permit R_ARM_GOT_PREL relocations

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

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.