On 9/2/2026 12:43 AM, Wei Liu wrote: > On Tue, Sep 01, 2026 at 09:55:20AM -0700, Thara Gopinath wrote: >> Linux VBS (LVBS) uses Hyper-V's Virtual Secure Mode to run a small >> trusted kernel in VTL1 alongside the regular VTL0 kernel, so that >> security-sensitive state (e.g. hypervisor-enforced code integrity, >> credential isolation) can live behind a higher-privilege boundary >> that VTL0 compromise cannot cross. Bringing that up from Linux >> requires the VTL0 kernel to drive the VSM setup itself. >> >> Add drivers/hv/hv_vsm_boot.c as the entry point for that sequence. >> This first step handles partition-level VTL1 enable only: >> >> - Probe VSM / VP-register privileges and SynIC availability before >> doing anything. >> - Pin init to the VTL0 boot CPU so VTL1 comes up on the same CPU >> (later patches rely on this). >> - Read HV_REGISTER_VSM_PARTITION_STATUS, and if VTL1 is not already >> enabled, issue HVCALL_ENABLE_PARTITION_VTL with MBEC and confirm >> by re-reading the register. >> >> Signed-off-by: Thara Gopinath <[email protected]> >> --- > [...] >> + cpumask_copy(mask, ¤t->cpus_mask); >> + boot_cpu = cpumask_first(cpu_online_mask); >> + set_cpus_allowed_ptr(current, cpumask_of(boot_cpu)); >> + >> + ret = hv_vsm_bootstrap_vtl(); >> + /* >> + * At this point VTL0 has already advertised VSM support to the >> + * bootloader/firmware via the Hyper-V OsLoaderIndications EFI >> + * variable (see the x86-stub change). That signals the platform >> + * that a trusted VTL1 will be brought up. If we fail to actually >> + * set VTL1 up here, the partition is left in a state where an >> + * attacker could race to configure VTL1 themselves and gain a >> + * higher-privilege foothold than VTL0. Panic rather than continue >> + * running with that exposure. >> + */ > > Okay, I think this answers my question in the previous patch -- if VTL1 > is not used by us, that's a security problem. > > It is unclear to me, if this code is enabled, how a generic kernel can > work without a secure kernel. There should be a way to configure the > system such that not enabling VTL1 is okay. Is there any pre-EFI command > line parsing we can do? Yes, we can do a pre-efi-exit-boot-service command line parsing and not set the OsLoaderIndications EFI variable asking HYPER-V to allow VTL1 setup. We can rename the securekernel command line option to mshv_securekernel and repurpose it for this as well. Basically if CONFIG_HYPER_VSM is enabled but if mshv_securekernel command line is not set VTL1 support will not be enabled and kernel will boot. I did quickly prototype this and it is doable. Having said that generic kernel should not enable CONFIG_HYPERV_VSM at all. I can update the KConfig to state the same as well. Warm Regards Thara > > Wei > > >> + if (ret) >> + panic("VTL1 boot failure caused kernel panic; consult log for >> more details.\n"); >> + >> + set_cpus_allowed_ptr(current, mask); >> + free_cpumask_var(mask); >> + return ret; >> +} >> +device_initcall(hv_vsm_boot_init); >> -- >> 2.34.1 >> >>
