linux-kernel - Re: [PATCH hyperv-next v4 15/16] Drivers: hv: Support establishing the confidential VMBus connection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <68a4ddff258de_2709100ba@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 19 Aug 2025 13:26:39 -0700
From: <dan.j.williams@...el.com>
To: Roman Kisel <romank@...ux.microsoft.com>, <alok.a.tiwari@...cle.com>,
	<arnd@...db.de>, <bp@...en8.de>, <corbet@....net>,
	<dave.hansen@...ux.intel.com>, <decui@...rosoft.com>,
	<haiyangz@...rosoft.com>, <hpa@...or.com>, <kys@...rosoft.com>,
	<mhklinux@...look.com>, <mingo@...hat.com>, <rdunlap@...radead.org>,
	<tglx@...utronix.de>, <Tianyu.Lan@...rosoft.com>, <wei.liu@...nel.org>,
	<linux-arch@...r.kernel.org>, <linux-coco@...ts.linux.dev>,
	<linux-doc@...r.kernel.org>, <linux-hyperv@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <x86@...nel.org>
CC: <apais@...rosoft.com>, <benhill@...rosoft.com>, <bperkins@...rosoft.com>,
	<sunilmut@...rosoft.com>
Subject: Re: [PATCH hyperv-next v4 15/16] Drivers: hv: Support establishing
 the confidential VMBus connection

Roman Kisel wrote:
> To establish the confidential VMBus connection the CoCo VM guest
> first attempts to connect to the VMBus server run by the paravisor.
> If that fails, the guest falls back to the non-confidential VMBus.
> 
> Implement that in the VMBus driver initialization.
> 
> Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
> ---
>  drivers/hv/vmbus_drv.c | 189 ++++++++++++++++++++++++++++-------------
>  1 file changed, 130 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
[..]
> @@ -1401,41 +1474,42 @@ static int vmbus_bus_init(void)
>  		}
>  	}
>  
> -	ret = hv_synic_alloc();
> -	if (ret)
> -		goto err_alloc;
> -
> -	works = alloc_percpu(struct work_struct);
> -	if (!works) {
> -		ret = -ENOMEM;
> -		goto err_alloc;
> -	}
> -
>  	/*
> -	 * Initialize the per-cpu interrupt state and stimer state.
> -	 * Then connect to the host.
> +	 * Attempt to establish the confidential VMBus connection first if this VM is
> +	 * a hardware confidential VM, and the paravisor is present.
> +	 *
> +	 * All scenarios here are:
> +	 *	1. No paravisor,
> +	 *  2. Paravisor without VMBus relay, no hardware isolation,
> +	 *  3. Paravisor without VMBus relay, with hardware isolation,
> +	 *  4. Paravisor with VMBus relay, no hardware isolation,
> +	 *  5. Paravisor with VMBus relay, with hardware isolation.
> +	 *
> +	 * In the cloud, scenarios 1, 4, 5 are most common, and outside the cloud,
> +	 * scenario 1 should be the most common at the moment. Detecting of the Confidential
> +	 * VMBus support below takes that into account running `vmbus_alloc_synic_and_connect()`
> +	 * only once (barring any faults not related to VMBus) in these cases. That is true
> +	 * for the scenario 2, too, albeit it might be not as feature-rich as 1, 4, 5.
> +	 *
> +	 * However, the code will be doing much more work in scenario 3 where it will have to
> +	 * first initialize lots of structures for every CPU only to likely tear them down later
> +	 * and start again, now without attempting to use Confidential VMBus, thus taking a
> +	 * performance hit. Such systems are rather uncomoon today, don't support more than
> +	 * ~300 CPUs, and are rarely used with many dozens of CPUs. As the time goes on, that
> +	 * will be even less common. Hence, the preference is to not specialize the code for
> +	 * that scenario.

I read this blurb looking for answers to my question below, no luck, and
left further wondering what is the comment trying to convey to future
maintenance?

>  	 */
> -	cpus_read_lock();
> -	for_each_online_cpu(cpu) {
> -		struct work_struct *work = per_cpu_ptr(works, cpu);
> +	ret = -ENODEV;
> +	if (ms_hyperv.paravisor_present && (hv_isolation_type_tdx() || hv_isolation_type_snp())) {
> +		is_confidential = true;

In comparison to PCIe TDISP where there is an explicit validation step
of cryptographic evidence that the platform is what it claims to be, I
am missing the same for this.

I would expect something like a paravisor signed golden measurement with
a certificate that can be built-in to the kernel to validate that "yes,
in addition to the platform claims that can be emulated, this bus
enumeration is signed by an authority this kernel image trusts."

My motivation for commenting here is for alignment purposes with the
PCIe TDISP enabling and wider concerns about accepting other devices for
private operation. Specifically, I want to align on a shared
representation in the device-core (struct device) to communicate that a
device is either on a bus that has been accepted for private operation
(confidential-vmbus today, potentially signed-ACPI-devices tomorrow), or
is a device that has been individually accepted for private operation
(PCIe TDISP). In both cases there needs to be either a golden
measurement mechanism built-in, or a userspace acceptance dependency in
the flow.

Otherwise what mitigates a guest conveying secrets to a device that is
merely emulating a trusted bus/device?