Re: [RFC PATCH 11/12] drivers: hv: hv_vsm_boot: Boot primary processor in VTL1

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Ignored error status from VTL1 boot handshake allows the system to continue in an insecure state, bypassing a security-critical kernel panic.
--

commit 91cb8ed727ae4b19c3d3be7dbd03c34def48f245
Author: Thara Gopinath <tgopinath@linux.microsoft.com>

drivers: hv: hv_vsm_boot: Boot primary processor in VTL1

This commit introduces the final step of the primary-CPU bring-up to
transition into VTL1 and start executing the secure kernel. It issues
the first vtlcall on the primary CPU to pass initialization arguments.
It also adds a check to see if Mode-Based Execution Control (MBEC) is
enabled after booting into VTL1.

> diff --git a/drivers/hv/hv_vsm_boot.c b/drivers/hv/hv_vsm_boot.c
> index abe82e03e1897..c4f15c42df1f6 100644
> --- a/drivers/hv/hv_vsm_boot.c
> +++ b/drivers/hv/hv_vsm_boot.c
[ ... ]
> +static int __init hv_vsm_boot_vtl1(void)
> +{
> +	struct hv_vtlcall_param args = {0};
> +	u16 vp_enabled_vtl_set = 0;
> +	u8 active_mbec_enabled = 0;
> +	int ret;
> +	s64 sk_status;
> +
> +	args.a0 = num_possible_cpus();
> +	args.a1 = sk_res.start;
> +	args.a2 = resource_size(&sk_res);
> +
> +	/* Kick start vtl1 boot on the primary cpu. */
> +	sk_status = hv_vsm_vtlcall(&args);
> +	if (sk_status)
> +		pr_warn("VTL1 boot returned status %lld\n", sk_status);
> +
> +	ret = hv_vsm_get_vp_status(&vp_enabled_vtl_set, &active_mbec_enabled);
> +	if (ret)
> +		return ret;
> +
> +	if (!active_mbec_enabled) {
> +		pr_err("Failed to enable MBEC for VP0\n");
> +		hv_vsm_mbec_enabled = false;
> +	}
> +	return 0;
> +}
        ^^^^

[Severity: High]
Does this code silently ignore a VTL1 boot failure?

If hv_vsm_vtlcall() returns a non-zero error in sk_status, this function
merely logs a warning and proceeds to call hv_vsm_get_vp_status().

If hv_vsm_get_vp_status() succeeds despite the VTL1 boot failure,
hv_vsm_boot_vtl1() will return 0, because vp_enabled_vtl_set is never
validated to confirm VTL1 actually booted.

This could allow the system to continue by bypassing failure handling in the
caller. If VTL1 setup fails, could the partition be left in an exposed state
where an attacker might race to configure VTL1 themselves and gain a
higher-privilege foothold than VTL0?

Should this return an error code when hv_vsm_vtlcall() fails?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901165647.3160413-1-tgopinath@linux.microsoft.com?part=11