On Tue, Aug 09, 2022 at 10:09:38AM +0200, Ard Biesheuvel wrote: > The only slight downside is that when UEFI secure boot is enabled, the > generic LoadImage/StartImage only allow signed images to be loaded and > started, and we prefer to avoid the need to sign both the inner and > outer PE/COFF images. This series adopts the EFI shim approach, i.e., to > override an internal UEFI/PI protocol that is used by the image loader, > to allow the inner image to be booted after decompression. This has been > tested to work with Tianocore based EFI implementations on arm64, but > u-boot will need some interoperability tweaks as well, ideally just a > protocol that exposes a LoadImage/StartImage combo that the decompresor > can use directly to circumvent the signature check. (Note that EFI apps > have full control over the CPU, page tables, etc. so having code that > circumvents authentication checks is not as crazy as it sounds, given > that the app can do anything it pleases already.) I think it's worth mentioning that Shim doesn't do this by default because it's not guaranteed that something implementing the UEFI DXE layer also implements the PI layer. I don't have an objection to it being an expectation on any Linux-supporting platform that the implementation works this way, but it should maybe be made clear that this could unexpectedly fail on generic platforms.