Re: [RFC PATCH 06/12] drivers: hv: Add VSM boot driver and enable VTL1 at the partition level

[Thara Gopinath <tgopinath@linux.microsoft.com>]

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 <tgopinath@linux.microsoft.com>
>> ---
> [...]
>> +	cpumask_copy(mask, &current->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
>>
>>