On Wed, 19 Apr 2023 at 07:54, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > On Sun, Apr 16, 2023 at 02:07:26PM +0200, Ard Biesheuvel wrote: > > This series is a proof-of-concept that implements support for the EFI > > zboot decompressor for x86. It replaces the ordinary decompressor, and > > instead, performs the decompression, KASLR randomization and the 4/5 > > level paging switch while running in the execution context of EFI. > > > > This simplifies things substantially, and makes it straight-forward to > > abide by stricter future requirements related to the use of writable and > > executable memory under EFI, which will come into effect on x86 systems > > that are certified as being 'more secure', and ship with an even shinier > > Windows sticker. > > > > This is an alternative approach to the work being proposed by Evgeny [0] > > that makes rather radical changes to the existing decompressor, which > > has accumulated too many features already, e.g., related to confidential > > compute etc. > > > > EFI zboot images can be booted in two ways: > > - by EFI firmware, which loads and starts it as an ordinary EFI > > application, just like the existing EFI stub (with which it shares > > most of its code); > > - by a non-EFI loader that parses the image header for the compression > > metadata, and decompresses the image into memory and boots it. > > I like the idea to have all EFI archs handle compressed kernels the same > way. > > But given that going EFI-only on x86 isn't a realistic option for > distros today this isn't really an alternative for Evgeny's patch > series, we have to fix the existing bzImage decompressor too. > I tend to agree, although some clarification would be helpful regarding what is being fixed and why? I *think* I know, but I have not been involved as deeply as some of the distro folks in getting these requirements explicit. > Realistically, the second option is unlikely to ever be used on x86, > > What would be needed to do so? Teach kexec-tools and grub2 parse and > load zboot kernels I guess? > I already implemented this for mach-virt here, so we can load Fedora kernels without firmware: https://gitlab.com/qemu-project/qemu/-/commit/ff11422804cd03494cc98691eecd3909ea09ab6f On arm64, this is probably more straight-forward, as the bare metal image is already intended to be booted directly like that. However, the x86 uncompressed image requires surprisingly little from all the boot_params/setup_header cruft to actually boot, so perhaps there it is easy too. There is an unresolved issue related to kexec_load_file(), where only the compressed image is signed, but the uncompressed image is what ultimately gets booted, which either needs the decompression to occur in the kernel, or a secondary signature that the kernel can verify after the decompression happens in user space. Dave and I have generated several ideas here, but there hasn't been any progress towards a solution that seems palatable for upstream.
