On Mon, Dec 16, 2024 at 11:50:49AM +0100, Gerd Hoffmann wrote:
> Add a new "etc/boot/kernel" fw_cfg file, containing the kernel without
> the setup header patches. Intended use is booting in UEFI with secure
> boot enabled, where the setup header patching breaks secure boot
> verification.
>
> Needs OVMF changes too to be actually useful.
>
> Signed-off-by: Gerd Hoffmann <[email protected]>
> Message-ID: <[email protected]>
> ---
> hw/i386/x86-common.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/i386/x86-common.c b/hw/i386/x86-common.c
> index 28341b42d949..1cef3045ad83 100644
> --- a/hw/i386/x86-common.c
> +++ b/hw/i386/x86-common.c
> @@ -962,6 +962,9 @@ void x86_load_linux(X86MachineState *x86ms,
> sev_load_ctx.setup_data = (char *)setup;
> sev_load_ctx.setup_size = setup_size;
>
> + /* kernel without setup header patches */
> + fw_cfg_add_file(fw_cfg, "etc/boot/kernel", kernel, kernel_size);
> +
How concerned should we be about the memory duplication overhead
from loading the kernel image twice ?
A bare modular kernel is 16MB, a non-modular one would be bigger
perhaps 10's of MB, a UKI meanwhile could easily be 100's of MB
in size, and >=1GB is not entirely insane to contemplate with a
UKI depending on how much is put into the embedded initrd.
I don't think the memory for fw_cfg is counted against the guest
RAM, right?
Is there anyway the duplicate kernel gets erased from memory once
the firmware is done, otherwise we live with this extra host RAM
overhead forever ?
> if (sev_enabled()) {
> sev_add_kernel_loader_hashes(&sev_load_ctx, &error_fatal);
> }
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
