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]>
> ---
[...]
> +static int __init hv_vsm_boot_init(void)
> +{
> + cpumask_var_t mask;
> + unsigned int boot_cpu;
> + int ret;
> +
> + if (!vsm_arch_has_vsm_access())
> + return 0;
> +
> + /*
> + * Copy the current cpu mask and pin rest of the running code to boot
> cpu.
> + * Important since we want boot cpu of VTL0 to be the boot cpu for VTL1.
> + * ToDo: Check if copying and restoring current->cpus_mask is enough
> + * ToDo: Verify the assumption that cpumask_first(cpu_online_mask) is
> + * the boot cpu
Can we get closures on these todos?
I see a bunch of todos in other patches, too. It would be good to close
them as well.
Wei
> + */
> + if (!alloc_cpumask_var(&mask, GFP_KERNEL))
> + panic("Could not allocate cpumask");
> +
> + 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.
> + */
> + 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
>
>
