linux-kernel - RE: [PATCH hyperv-next v3 13/15] Drivers: hv: Support confidential VMBus channels

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <SN6PR02MB4157BC99328C8B043749FC90D472A@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Wed, 18 Jun 2025 16:19:32 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Roman Kisel <romank@...ux.microsoft.com>, "alok.a.tiwari@...cle.com"
	<alok.a.tiwari@...cle.com>, "arnd@...db.de" <arnd@...db.de>, "bp@...en8.de"
	<bp@...en8.de>, "corbet@....net" <corbet@....net>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"decui@...rosoft.com" <decui@...rosoft.com>, "haiyangz@...rosoft.com"
	<haiyangz@...rosoft.com>, "hpa@...or.com" <hpa@...or.com>,
	"kys@...rosoft.com" <kys@...rosoft.com>, "mingo@...hat.com"
	<mingo@...hat.com>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"wei.liu@...nel.org" <wei.liu@...nel.org>, "linux-arch@...r.kernel.org"
	<linux-arch@...r.kernel.org>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>
CC: "apais@...rosoft.com" <apais@...rosoft.com>, "benhill@...rosoft.com"
	<benhill@...rosoft.com>, "bperkins@...rosoft.com" <bperkins@...rosoft.com>,
	"sunilmut@...rosoft.com" <sunilmut@...rosoft.com>
Subject: RE: [PATCH hyperv-next v3 13/15] Drivers: hv: Support confidential
 VMBus channels

From: Roman Kisel <romank@...ux.microsoft.com> Sent: Tuesday, June 3, 2025 5:44 PM
> 
> To run a confidential VMBus channels, one has to initialize the

How about:

To make use of Confidential VMBus channels, initialize the

> co_ring_buffers and co_external_memory fields of the channel
> structure.
> 
> Advertise support upon negoatiating the version and compute

s/negoatiating/negotiating/

> values for those fields and initialize them.
> 
> Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
> ---
>  drivers/hv/channel_mgmt.c | 19 +++++++++++++++++++
>  drivers/hv/connection.c   |  3 +++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index ca2fe10c110a..33bc29e826bd 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -1021,6 +1021,7 @@ static void vmbus_onoffer(struct vmbus_channel_message_header *hdr)
>  	struct vmbus_channel_offer_channel *offer;
>  	struct vmbus_channel *oldchannel, *newchannel;
>  	size_t offer_sz;
> +	bool co_ring_buffer, co_external_memory;
> 
>  	offer = (struct vmbus_channel_offer_channel *)hdr;
> 
> @@ -1033,6 +1034,22 @@ static void vmbus_onoffer(struct vmbus_channel_message_header *hdr)
>  		return;
>  	}
> 
> +	co_ring_buffer = is_co_ring_buffer(offer);
> +	if (co_ring_buffer) {
> +		if (vmbus_proto_version < VERSION_WIN10_V6_0 || !vmbus_is_confidential()) {
> +			atomic_dec(&vmbus_connection.offer_in_progress);
> +			return;
> +		}
> +	}
> +
> +	co_external_memory = is_co_external_memory(offer);
> +	if (is_co_external_memory(offer)) {

Use the local variable co_external_memory instead of the function, like with co_ring_buffer?
Consistency .... :-)


> +		if (vmbus_proto_version < VERSION_WIN10_V6_0 || !vmbus_is_confidential()) {
> +			atomic_dec(&vmbus_connection.offer_in_progress);
> +			return;
> +		}

The test for valid vmbus_proto_version and VMBus being confidential is duplicated. You
could do:

	if (co_ring_buffer || co_external_memory)

and have just one copy of the tests. Also I'd suggest adding an error message like
with the "vmbus_is_valid_offer()" test at the start of vmbus_onoffer(). That way
incoming offers aren't silently ignored. Something is wrong on the paravisor or
host side if the tests fail.

Also, since the combination where co_external_memory = true and
co_ring_buffer = false is not allowed, perhaps a check for that invalid
combination should be made here as well.

> +	}
> +
>  	oldchannel = find_primary_channel_by_offer(offer);
> 
>  	if (oldchannel != NULL) {
> @@ -1111,6 +1128,8 @@ static void vmbus_onoffer(struct vmbus_channel_message_header *hdr)
>  		pr_err("Unable to allocate channel object\n");
>  		return;
>  	}
> +	newchannel->co_ring_buffer = co_ring_buffer;
> +	newchannel->co_external_memory = co_external_memory;
> 
>  	vmbus_setup_channel_state(newchannel, offer);
> 
> diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
> index be490c598785..eeb472019d69 100644
> --- a/drivers/hv/connection.c
> +++ b/drivers/hv/connection.c
> @@ -105,6 +105,9 @@ int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo, u32 version)
>  		vmbus_connection.msg_conn_id = VMBUS_MESSAGE_CONNECTION_ID;
>  	}
> 
> +	if (vmbus_is_confidential() && version >= VERSION_WIN10_V6_0)
> +		msg->feature_flags = VMBUS_FEATURE_FLAG_CONFIDENTIAL_CHANNELS;
> +
>  	/*
>  	 * shared_gpa_boundary is zero in non-SNP VMs, so it's safe to always
>  	 * bitwise OR it
> --
> 2.43.0