search

ncroxon / gnu-efi

Develop EFI applications for ARM-64, ARM-32, x86_64, IA-64 (IPF), IA-32 (x86), and MIPS platforms using the GNU toolchain and the EFI development environment.
GNU General Public License v2.0
59 stars 11 forks source link

gnu-efi 3.0.16+ breaks AArch64 EFI binaries #7

Closed wegank closed 6 months ago

wegank commented 7 months ago

In Nixpkgs, we've found that gnu-efi 3.0.17 and 3.0.18 have serious regressions (https://github.com/NixOS/nixpkgs/pull/234796#issuecomment-1574199486, https://github.com/NixOS/nixpkgs/pull/307063#issuecomment-2089848178) on aarch64-linux. For example, for efitools, a reverse dependency of gnu-efi:

sbsign --key DB.key --cert DB.crt --output HelloWorld-signed.efi HelloWorld.efi
Invalid DOS header magic
make: *** [Make.rules:123: HelloWorld-signed.efi] Error 1
rm HelloWorld.o

The full error log can be found at https://hydra.nixos.org/build/257666776. There's also a bug report on the same issue for Gentoo: https://bugs.gentoo.org/923101

As a bisection leads to https://github.com/ncroxon/gnu-efi/commit/593e13937c340944ec91e7c8962e8baaaeff7d57, the same commit https://sourceforge.net/p/gnu-efi/bugs/37/ referred to, we believe that the issue on SourceForge is not actually resolved. Also, we're shipping binutils 2.41, if relevent.

gmbr3 commented 7 months ago

In Nixpkgs, we've found that gnu-efi 3.0.17 and 3.0.18 have serious regressions

I very much doubt it, since I tested that. Likely efitools haven't updated toolchain for new version. I'll review further at another time.

ncroxon commented 6 months ago

wegank Did you try newer efitools?

wegank commented 6 months ago

We have efitools 1.9.2, the latest release according to https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git. Is there a more recent version somewhere?

pbatard commented 6 months ago

According to current sbsign (https://github.com/phrack/sbsigntools/blob/master/src/image.c#L215-L219) the only path that can lead to the Invalid DOS header magic error is if the EFI executable doesn't start with 0x4D 0x5A (MZ).

I am not seeing any such issue on the aa64 binaries that gnu-efi produces. You can for instance validate this in the artifacts we produce for aa64 builds at https://github.com/ncroxon/gnu-efi/actions/runs/9173754536. They all start with the expected MZ bytes.

So this would tend to indicate that the the HelloWorld.efi binary generated during your efitools build was not built properly, or using different rules than what we use for our builds.

If you can replicate the issue locally, can you take a look at the generated HelloWorld.efi to confirm that it is missing the MZ bytes at the beginning?

gmbr3 commented 6 months ago

As I expected, efitools isn't maintained and subsequently hasn't updated toolchain per aarch64 objcopy

See line: https://github.com/vathpela/efitools/blob/28687de80b18b3b35271de1d70769eac3c0b1ab4/Make.rules#L56

EDIT: Removing the aarch64 section will fix the issue as it defaults to objcopy

Bug is invalid as not our responsibility

wegank commented 6 months ago

As I expected, efitools isn't maintained and subsequently hasn't updated toolchain per aarch64 objcopy

See line: https://github.com/vathpela/efitools/blob/28687de80b18b3b35271de1d70769eac3c0b1ab4/Make.rules#L56

EDIT: Removing the aarch64 section will fix the issue as it defaults to objcopy

Bug is invalid as not our responsibility

Thanks! I've successfully built efitools by removing the section. Closing the issue.