On Fri, 21 Apr 2023 at 15:30, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > > > On Sun, Apr 16, 2023, at 5:07 AM, 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. > > I like the concept. A couple high-level questions, since I haven’t dug into the code: > > Could zboot and bzImage be built into the same kernel image? That would get this into distros, and eventually someone could modify the legacy path to switch to long mode and invoke zboot (because zboot surely doesn’t need actual UEFI — just a sensible environment like what UEFI provides.) > That's an interesting question, and to some extent, that is actually what Evgeny's patch does: execute more of what the decompressor does from inside the EFI runtime context. The main win with zboot imho is that we get rid of all the funky heuristics that look for usable memory for trampolines and decompression buffers in funky ways, and instead, just use the EFI APIs for allocating pages and remapping them executable as needed (which is the important piece here) I'd have to think about whether there is any middle ground between this approach and Evgeny's - I'll have to get back to you on that. > Does zboot set up BSS correctly? I once went down a rabbit hole trying to get the old decompressor to jump into the kernel with BSS already usable and zeroed, and the result was an incredible mess — IIRC the decompressor does some in-place shenanigans that looked incompatible with handling BSS without a rewrite. And so we clear BSS in C after jumping to the kernel, which is gross. > Zboot pads the image to include BSS, so that the zboot metadata covers the actual memory footprint of the image rather than just the image size, and it will get zeroed out as a result of the decompression too, which is a nice bonus. I did this mainly to try and make it idiot proof for other (non-EFI) consumers of the zboot header and compressed payload, but it means that the zboot EFI loader doesn't have to bother either.
