Re: [RFC PATCH 07/12] drivers: hv: hv_vsm_boot: load secure kernel image from firmware

[Wei Liu <wei.liu@kernel.org>]

On Wed, Sep 02, 2026 at 12:22:37PM -0400, Thara Gopinath wrote:
> 
> 
> On 9/2/2026 12:37 AM, Wei Liu wrote:
> > On Tue, Sep 01, 2026 at 09:55:21AM -0700, Thara Gopinath wrote:
> >> LVBS bring-up requires loading a secure kernel image into VTL1 before
> >> starting it. Add the VTL0-side loader that stages the image in the
> >> memory region reserved by hv_vsm_securekernel, in preparation for the
> >> VTL1 bring-up.
> >>
> >> The image is a 64-bit ELF fetched via request_firmware("vsm_sk"). It
> >> is expected to ship inside the signed UKI/initramfs so it is
> >> authenticated end-to-end via Secure Boot before the loader consumes
> >> it; sourcing it from an unauthenticated location would break the LVBS
> >> trust model.
> >>
> >> The loader validates the ELF header, stages the PT_LOAD segments into
> >> the reserved region and records the entry point as a physical address
> >> for use at VTL1 start time.
> >>
> >> If VSM support has been advertised to the hypervisor but no secure
> >> kernel region was reserved on the command line, panic: LVBS bring-up
> >> is committed at this point and there is no safe way to continue.
> > 
> > This conflicts with the memory reservation patch, in which there is an
> > automatic allocation when no kernel command line is specified.
> 
> Ah no.. So securekernel= has to be specified in the command line for
> __setup() to be invoked . It can be left blank without parameters like
> securekernel= or with parameters like securekernel=256M@0x80000000. The
> reservation logic will take care of reserving the correct memory if there
> are no parameters but if there is no command line specified __setup will
> not be  called. The other way of solving this and invoking the reservations
> unconditionally will be to call it from setup_arch like how reserve_crashkernel
> is invoked. I am not sure if we want to do that now ?? What do you think ?
> 

I see. No need to do that now. Let's see if others have opinions.

Wei

> But I will reword this and state that the panic happens if there is no
> securekernel memory allocated (either because securekernel= was not
> specified or because memory reservation itself failed)
> 
> > 
> >>
> >> Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
> >> Signed-off-by: Thara Gopinath <tgopinath@linux.microsoft.com>
> >> ---
> >>  drivers/hv/hv_vsm.h      |  17 ++++
> >>  drivers/hv/hv_vsm_boot.c | 201 ++++++++++++++++++++++++++++++++++++++-
> >>  include/hyperv/vsm.h     |  21 ++++
> >>  3 files changed, 238 insertions(+), 1 deletion(-)
> >>  create mode 100644 drivers/hv/hv_vsm.h
> >>  create mode 100644 include/hyperv/vsm.h
> > [...]
> >> +
> >> +static void __init hv_vsm_get_sk_mem(void)
> >> +{
> >> +	/*
> >> +	 * The reserved secure kernel region is mandatory once VSM support has
> >> +	 * been advertised. Without it we cannot load the secure kernel and
> >> +	 * bringing up VTL1 is impossible, so fail hard rather than continuing
> >> +	 * in an unusable state.
> >> +	 */
> >> +	if (!sk_res.start)
> >> +		panic("No memory reserved in cmdline for secure kernel");
> >> +
> > 
> > This log line is wrong.
> 
> I will fix this 
> 
> Warm Regards
> Thara
> > 
> > Wei
>