Significant problems with Aarch64 (and Arm?) builds

[steve-mcintyre]

For x86 platforms, we use support in binutils for making EFI apps (objcopy ... --target efi-app-x86_64 or --target efi-app-ia32) and that seems to work OK. For Arm-based platforms, we don't have such support.

Instead, we have some locally-crafted CRT and linker script hacks to try and make things work. Pre-SBAT this seemed to work, but since then I've been seeing significant issues in this area.

1. Older versions of binutils will not create an aarch64 shim that works with Secure Boot enabled. (I've bisected binutils to find that the specific commit that makes things "work" is https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8c803a2dd7d3d742a3d0071914f557ef465afe71 . Older builds (before release 2.35, basically) will cause a Synchronous Exception during early boot of shim. Comparing builds shows only small changes to the binaries, high up in the address range.

2. Even using a later version of binutils, I've seen another worrying problem. We normally expect shim builds to be reproducible, and this is important. As part of the release process for Debian's shim, I build and test shim locally. I then compare checksums to ensure that exactly the same binaries are produced by Debian's build machines. Building the same source (Debian's 15.4-1 release) on my aarch64 development machine (Cortex-A72 Macchiatobin) consistently gives the same output. However, building that exact same release using the same build setup (gcc, binutils, etc.) on other machines gives me different results. On that 15.4-1 release, I tested found that 5 different aarch64 machines repeatably gave me 4 different binaries. The differences between the binaries all appear in the same place as the differences found in (1) here.

As a result of these issues, I have decided to abandon Secure Boot support on Debian's arm64 port. Until we have proper reliable toolchain support for what we're building, I don't think work on this platform is sustainable.

[xnox]

If you look at

https://github.com/rhboot/shim/blob/main/elf_aarch64_efi.lds#L84

you will see that we include .note.gnu.build-id inside the .rodata section.

 . = ALIGN(4096);
  .rodata :
  {
...
    . = ALIGN(16);
    *(.note.gnu.build-id)
    . = ALIGN(4096);
    *(.vendor_cert)
...
} 

One can easily find the vendor_cert section by looking for vendor name or some such.

gnu.build-id starts with "GNU\0" and then followed by 20 hexadecimals of the 160 bit sha1 value.

Note that on other architectures .gnu.build-id is a standalone secttion in the elf file, which is copied to debug, but is not copied / included in the PE/COFF binary.

And even then, most distributions strip, reseed packagname/version, and recalculate build-id sections. (i.e. ubuntu's dh_strip, and fedora's rpmscripts)

I have no idea why we include build-id in aarch64_efi.lds script the way we do.

[ema]

@steve-mcintyre with binutils 2.38 supporting PE/COFF on aarch64 and shim building reproducibly I think this can now be closed?

[steve-mcintyre]

Agreed!