On 04.09.2024 14:31, Andrew Cooper wrote:
> When booting guests, compressed first executables (the kernel itself for
> direct-boot, or firmware binaries) need decompressing in order to inspect the
> ELF notes or other relevant headers.
>
> However for unclear reasons, libxenguest will also gunzip() all modules which
> happen to be compressed (typically a direct-boot kernel's initrd), before
> loading the contents into guest memory.
I suppose the simple reason was that grub also decompresse{s,d} everything.
> This was an unexpected discovery while trying to test Xen's gunzip()
> logic (Xen as a PVH guest, with a gzipped XTF kernel as dom0).
>
> More generally, it is work that we should not be doing in the domain builder;
> it can and should be done in guest context.
>
> This is unlikely to cause any issues; a kernel incapable of decompression
> wouldn't have a compressed initrd to start with,
Unless relying on the bootloader, which an OS may certainly do.
> and these days there are
> other algorithms typically preferred over gzip.
>
> Furthermore, this change also fixes a bug with Linux guests. Linux is happy
> consuming a initrd constructed of multiple CPIO fragments, including with
> differing compression, and Xen gunzip()'ing from the start would result in all
> subsequent fragments being silently dropped during load.
Now this and perhaps also ...
> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
> ---
> CC: Anthony PERARD <anthony.per...@vates.tech>
> CC: Juergen Gross <jgr...@suse.com>
> CC: Jan Beulich <jbeul...@suse.com>
> CC: Stefano Stabellini <sstabell...@kernel.org>
> CC: Julien Grall <jul...@xen.org>
> CC: Oleksii Kurochko <oleksii.kuroc...@gmail.com>
>
> Furthermore, Linux's habit of prepending an uncompressed CPIO containing
> microcode will also stop it being recognised as a compressed blob.
... this are fair reasons on their own to get rid of that logic. So
let's hope there's not going to be any fallout.
Jan
