On Tue, Dec 17, 2024 at 03:26:35PM +0100, Gerd Hoffmann wrote: > On Tue, Dec 17, 2024 at 02:15:15PM +0000, Daniel P. Berrangé wrote: > > 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 ? > > It's not loaded twice, see 214191f6b574 ("x86/loader: read complete > kernel"), both fw_cfg entries point to the same memory block.
Ah, I see now, that's subtle :-) 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 :|
