Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Rebecca Cran]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

I have an armplatbld.sh script that goes through and tries to build as 
many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.

I'm think this used to work for these, but I'm getting some errors now.

I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and 
edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.


Drivers/ASIX/Asix.dsc (fails with undefined references to 
__stack_chk_guard and __stack_chk_fail)

Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with 
undefined references to __stack_chk_guard and __stack_chk_fail)
Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad 
definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported 
symbol type.  For example, absolute and undefined symbols are not 
supported.)

Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined references 
to __stack_chk_guard and __stack_chk_fail)
Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc(fails 
with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or 
unsupported symbol type.  For example, absolute and undefined symbols 
are not supported.)


-- 
Rebecca Cran

[-- Attachment #2: Type: text/html, Size: 8902 bytes --]

Re: Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Ard Biesheuvel]

On Sat, 20 Aug 2022 at 01:35, Rebecca Cran <rebecca@bsdio.com> wrote:
>
> I have an armplatbld.sh script that goes through and tries to build as many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.
>
> I'm think this used to work for these, but I'm getting some errors now.
>
> I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>
>
> Drivers/ASIX/Asix.dsc (fails with undefined references to __stack_chk_guard and __stack_chk_fail)
>
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with undefined references to __stack_chk_guard and __stack_chk_fail)
> Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported symbol type.  For example, absolute and undefined symbols are not supported.)
>
> Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined references to __stack_chk_guard and __stack_chk_fail)
> Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported symbol type.  For example, absolute and undefined symbols are not supported.)
>

Hello Rebecca,

Which compiler and linker are you using?

The *Mm.dsc targets are a bit tricky to build, as they self-relocate
while running in a secure partition, which has restrictions in terms
of memory permissions. I don't remember the exact details, but it is
likely we never bothered to test Clang, and Visual Studio definitely
doesn't work.

As for the stack protector - as you already identified, this is a
matter of adding the appropriate NULL library class resolution. The
heuristics regarding which functions need a stack cookie and which
don't is not set in stone, nor is the default strength, which can vary
per compiler build between distros.

Re: Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Rebecca Cran]

On 8/21/22 03:13, Ard Biesheuvel wrote:
> Which compiler and linker are you using?
I'm using gcc from Ubuntu 22.04:


gcc version 11.2.0 (Ubuntu 11.2.0-17ubuntu1)

GNU ld (GNU Binutils for Ubuntu) 2.38


-- 

Rebecca Cran

Re: Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Ard Biesheuvel]

On Sun, 21 Aug 2022 at 12:08, Rebecca Cran <rebecca@bsdio.com> wrote:
>
> On 8/21/22 03:13, Ard Biesheuvel wrote:
> > Which compiler and linker are you using?
> I'm using gcc from Ubuntu 22.04:
>
>
> gcc version 11.2.0 (Ubuntu 11.2.0-17ubuntu1)
>
> GNU ld (GNU Binutils for Ubuntu) 2.38
>

I am failing to reproduce this with both the DEBUG and RELEASE builds
of either Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
or Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc

using

gcc version 12.1.0 (Debian 12.1.0-8)
GNU ld (GNU Binutils for Debian) 2.38.90.20220713

and the GCC5 toolchain definition.

The NOOPT build of DeveloperBoxMm.dsc does display the symptom (but
PlatformStandaloneMmRpmb.dsc fails to build for NOOPT with a different
error). The GCC49 toolchain definition fails to build these target in
DEBUG and RELEASE mode as well.

So this means the issue is likely related to linking PIE executables
that were built without LTO, and I suspect that
StandaloneMmPkg/Core/StandaloneMmCore.inf in the EDK2 repository
currently simply requires LTO when using GCC on AArch64. However, this
does not seem to be a fundamental issue, but simply a difference on
how LD emits GOT based symbol references at different optimization
levels and LTO vs !LTO.

GenFw on AArch64 already contains an optimization that converts
R_AARCH64_ADR_GOT_PAGE+R_AARCH64_LD64_GOT_LO12_NC pairs into
R_AARCH64_ADR_PREL_PG_HI21+R_AARCH64_ADD_ABS_LO12_NC pairs (converting
'load the address of symbol <s> from the GOT' into 'take the address
of symbol <s> by adding to the program counter'). Those GOT based
relocations never reference the _GLOBAL_OFFSET_TABLE_ symbol directly,
though - it simply resolves to a direct reference to the GOT entry
that should carry the absolute address after loading. Given that we
don't cover the ELF GOT with PE/COFF relocations after conversion, we
must relax all GOT based references using the method above (X86_64
does something similar)

I suspect we might be able to work around this by adding special
treatment for the _GLOBAL_OFFSET_TABLE_ symbol. The fact that some
linkers qualify it as absolute is a historical mistake [0], as the
location inside the binary of the GOT is obviously dependent on the
placement of the binary. Note that the relocation pair that LD emits
here is also place relative (R_AARCH64_ADR_PREL_PG_HI21 +
R_AARCH64_LD64_GOTPAGE_LO15) which means that we could simply
disregard it and end up with the correct address of the GOT entry.
*However*, since we don't actually load the GOT with the right values,
that wouldn't actually help us, although it would silence the error.

This means we'll need special treatment for
R_AARCH64_LD64_GOTPAGE_LO15, and convert the LDR instruction at the
site into a ADR instruction referring to the symbol directly (instead
of to the GOT entry that is supposed to carry its absolute address.)
Then, if we also disregard _GLOBAL_OFFSET_TABLE_ references, the
resulting binary should run as expected.

I'll try to code this up for GenFw in the coming days.


[0] https://binutils.sourceware.narkive.com/3VY9kxpd/dynamic-and-global-offset-table