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.
Updated, PR location: https://github.com/rhboot/grub2/pull/110
While there's nothing anyone else can do about how you feel about the state of grub code, as you've observed, patches are welcome :) Applied to Fedora rawhide.
(In reply to Jeremy Linton (ARM) from comment #0) > Description of problem: There is a compressed aarch64 kernel patch on the > list > https://lore.kernel.org/linux-arm-kernel/20220827083850.2702465-2- > ardb/T/ Just to confirm, have you filed a BZ for this?
No, IIRC didn't open a bug for the compressed kernel bits in RH, just the grub fix. PS: My grub fix: https://github.com/rhinstaller/anaconda/pull/4368/files (lol)
More seriously, and maybe it deserves its own defect: https://github.com/rhboot/grub2/pull/107 was one of the things I had just looked at right before posting that. But, along those lines, we really shouldn't be trying to duplicate firmware calls in grub like that. These two PR's are just an example of "hacking" a EFI startimage call in, while ignoring much of the spec. It works until someone decides to utilize some other part of the spec not handed by grub.
Hi Jeremy, Would you be willing to test that this is working as expected with compressed and self-decompressing kernels once we have a RHEL grub build for you?
Yes, I can swap it into a couple of machines I have. Let me know where the build is, and I can pull it from an internal source if that is easier.
Great, thank you. I'll be in touch once we have a build. :)
(In reply to Robbie Harwood from comment #2) > While there's nothing anyone else can do about how you feel about the state > of grub code, as you've observed, patches are welcome :) > > Applied to Fedora rawhide. This had fixed what is now F37 (thanks!), but F36 is still affected (bug 2181825); can you please apply the patch to F36 too? Thanks!