Ard Biesheuvel

> which kernel versions is the StartImage/LoadImage stuff compatible with btw? > > @ardbiesheuvel would love your take on all of this! This is definitely a huge improvement, and hopefully...

> Soooo. What are the implications of this: > > https://marc.info/?l=linux-efi&m=166505106716940&w=2 > > I take it we can avoid patching around in protocol vtables once that has landed? > >...

> @ardbiesheuvel I think the signature for `fwvol_read_file` and `fwvol_get_next_file` are wrong: the `attr` arg is a pointer to `EFI_FV_FILE_ATTRIBUTES` which is a typedef to `uint32_t`. Your signature uses `u64`,...

> Welp. A slightly more modern asus mobo still insist on verifying the image even if loaded by the provided firmware volume. So this approach doesn't look too promising either....

The reason for avoiding a decompressor in the arm64 tree is not to make your lives miserable, I can assure you :-) The problem is not decompression per se -...

> > I had a stab at implementing a generic EFI decompressor for all non-x86 EFI architectures in Linux (arm64, ARM, RISC-V, LoongArch) [here](https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=efi-decompressor-v2), which mostly works fine. The only...

> With secure boot in the mix there really are only three options: > > 1. Have the payload be signed (yuck) > 2. Do the work of LoadImage/StartImage ourselves...

> So I've been testing @ardbiesheuvel's generic compressed boot for efi patchset (https://lore.kernel.org/lkml/[email protected]/T/), and while it works perfectly for the regular linux image scenario started using sd-boot, it doesn't quite...

> I am in the process of switching to LoadImage/StartImage in our stub. There is a neat hack using the EFI_SECURITY_ARCH_PROTOCOL to work around any unsigned payloads (effectively the same...

so why do we need to enable this in the first place?