Jan Janssen

@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`, though.

> However, the fwvol2 approach may still be interesting for sd-stub or shim, so hopefully this wasn't a wasted effort. Yeah, the only reason I found this was because I...

I've changed this so that the payload is exposed using `EFI_FIRMWARE_VOLUME2_PROTOCOL`. It really has some nice properties: We don't hack into anything, the firmware will happily load it if its...

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. :crying_cat_face:...

I changed it back to using security arch protocol, but this time using `ReinstallProtocolInterface`. I also made sd-boot do the same for loading shim verified stuff.

Mind you, `EFI_DECOMPRESS_PROTOCOL` is zlib only.

> Yeah, we'd have to embedd a minimal copy of zlib decompress (or whatever format is en vogue today) in our codebase i fear. yuck. You mean zstd here, right?...

En vouge is `zstd` today. I even looked at the headers and it seems to provide a sane minimalist API that wouldn't require any libc stuff (afaik). Question is whether...

To make our lifes miserable?

> 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 issue...