linux-kernel - RE: [PATCH hyperv-next v4 01/16] Documentation: hyperv: Confidential VMBus

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:
 <SN6PR02MB41576579D0A53239690DA57ED45CA@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Tue, 22 Jul 2025 17:43:26 +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>, "rdunlap@...radead.org" <rdunlap@...radead.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "Tianyu.Lan@...rosoft.com"
	<Tianyu.Lan@...rosoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
	"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 v4 01/16] Documentation: hyperv: Confidential
 VMBus

From: Roman Kisel <romank@...ux.microsoft.com> Sent: Monday, July 14, 2025 3:16 PM
> 
> Define what the confidential VMBus is and describe what advantages
> it offers on the capable hardware.
> 
> Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
> Reviewed-by: Alok Tiwari <alok.a.tiwari@...cle.com>

Overall, this version looks good. I'm good with the overall
characterization of the scenarios where Confidential VMBus is
beneficial, and with the overview of how it works.

I've noted one nit below. But otherwise,
Reviewed-by: Michael Kelley <mhklinux@...look.com>

> ---
>  Documentation/virt/hyperv/coco.rst | 140 ++++++++++++++++++++++++++++-
>  1 file changed, 139 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/virt/hyperv/coco.rst b/Documentation/virt/hyperv/coco.rst
> index c15d6fe34b4e..e8515acfe306 100644
> --- a/Documentation/virt/hyperv/coco.rst
> +++ b/Documentation/virt/hyperv/coco.rst

[snip]

> +
> +The data won't ever leave the VM when a device is attached to VTL2, and the

Two things:

1) At face value, saying "the data won't ever leave the VM" is counter to what I/O
is supposed to be doing -- the data leaves the VM to go to the device! I guess the
wording here struck me as funny. :-)

2) Being more precise about "attached to VTL2" would be helpful. This specifically
means a vPCI device assigned to VTL2.

I'd suggest something like:

The data is transferred directly between the VM and a vPCI device (a.k.a. a PCI
pass-thru device) that is directly assigned to VTL2 and that supports encrypted
memory. In such a case, neither the host partition nor the hypervisor has any
access to the data.

You could even include a link to the documentation topic on Hyper-V vPCI devices.

> +device supports encrypted memory. Therefore, neither the host partition nor the
> +hypervisor can access the data being processed at all. The guest needs to
> +establish a VMBus connection only with the paravisor for the channels that
> +process sensitive data, and the paravisor abstracts the details of
> +communicating with the specific devices away providing the guest with the
> +well-established VSP (Virtual Service Provider) interface that has had support
> +in the Hyper-V drivers for a decade.
> +