Description of problem: There is a compressed aarch64 kernel patch on the list https://lore.kernel.org/linux-arm-kernel/20220827083850.2702465-2-ardb@kernel.org/T/

That set corrects the the compromise that one either has an uncompressed/signed EFI PE/COFF image or one gzip's it. Forcing bootloaders/etc to decompress the image and tying the supported decompression algorithms to the boot loader. Neither choice is good.

Given the above set, its possible to have a signed EFI/PE/COFF image, that self decompresses and places the kernel correctly in memory.

The only problem is the fact that grub2 in fedora and rhel has deviated significantly from upstream, which continues to use the EFI bootservices to load and execute the image on arm64 platforms. In this case there are two problems. First, the arm64 magic number that identifies a PE+raw kernel image is no longer in the image and it simply identifies itself as a correct PE/COFF image, which means the grub specific check for it needs to be dropped.

Secondly, grub2 is assuming that the file length is equal to the header+text+initialized data and that the COFF imagesize is filelen+BSS and simply memset's the difference as a replacement for the bootservices loadimage/startimage. This latter assumption works fine only if the raw=virtual size of the text+data/etc all are equal, or there isn't any data following the section's described by the PE/COFF header. Ideally, the boot services should be used to place the PE/COFF sections in memory, but as an alternative, its possible to further "hack" the existing boot flow by computing the raw/on disk image length from the section data. Which seems also to fix the general problem

My understanding is that this image decompression/signature compromise is part of the problem with actually getting a secure boot path signed on arm, although after looking at the grub code, i'm a bit skeptical that its the only issue.

Version-Release number of selected component (if applicable): 9.0+

How reproducible: 100% boot failures due to malloc_ptr failing to be 0'ed properly when Ard's ZBOOT patches are applied.

Steps to Reproduce:
1. Apply linked patches, and attempt to boot the generated/signed kernel utilizing RH based grub.

Expected results:
It boots in all three modes, non-compressed EFI stubbed kernel, gzipp'ed EFI stubbed kernel, and the new EFI stubbed kernel that self decompresses.

Additional info:

So, I have an open PR open against the fedora sources here: https://src.fedoraproject.org/rpms/grub2/pull-request/20#

Which fixes this, and can be moved to github/etc if needed, although... I tend to think the latter PE/COFF section parsing code is maybe closer to an RFC.