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. > 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? take care, Gerd
