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.