| Message ID | 20241216105053.246204-4-kraxel@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [PULL,1/7] x86/loader: only patch linux kernels | expand |
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 <kraxel@redhat.com> > Message-ID: <20240905141211.1253307-5-kraxel@redhat.com> > --- > 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
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 <kraxel@redhat.com> > > Message-ID: <20240905141211.1253307-5-kraxel@redhat.com> > > --- > > 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. take care, Gerd
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 <kraxel@redhat.com> > > > Message-ID: <20240905141211.1253307-5-kraxel@redhat.com> > > > --- > > > 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
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); + if (sev_enabled()) { sev_add_kernel_loader_hashes(&sev_load_ctx, &error_fatal); }
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 <kraxel@redhat.com> Message-ID: <20240905141211.1253307-5-kraxel@redhat.com> --- hw/i386/x86-common.c | 3 +++ 1 file changed, 3 insertions(+)