Thread (34 messages) flat view 34 messages, 3 authors, 5d ago

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

From: Wei Liu <wei.liu@kernel.org>
Date: 2026-09-02 22:58:38
Also in: linux-efi, lkml

On Wed, Sep 02, 2026 at 12:22:37PM -0400, Thara Gopinath wrote:

On 9/2/2026 12:37 AM, Wei Liu wrote:
quoted
On Tue, Sep 01, 2026 at 09:55:21AM -0700, Thara Gopinath wrote:
quoted
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)
quoted
quoted
Signed-off-by: Stanislav Kinsburskii <redacted>
Signed-off-by: Thara Gopinath <redacted>
---
 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
[...]
quoted
+
+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
quoted
Wei
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help