Received-SPF: pass (google.com: domain of linux-kernel+bounces-212421-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Michael Kelley <mhklinux@outlook.com>
To: Easwar Hariharan <eahariha@linux.microsoft.com>, "kys@microsoft.com"
	<kys@microsoft.com>, "haiyangz@microsoft.com" <haiyangz@microsoft.com>,
	"wei.liu@kernel.org" <wei.liu@kernel.org>, "decui@microsoft.com"
	<decui@microsoft.com>, "corbet@lwn.net" <corbet@lwn.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>
Subject: RE: [PATCH 1/1] Documentation: hyperv: Add overview of Confidential
 Computing VM support
Thread-Topic: [PATCH 1/1] Documentation: hyperv: Add overview of Confidential
 Computing VM support
Thread-Index: AQHau3TUvOHXX6OB+EKZI1Zfm6ByWLHETxSAgACQwaA=
Date: Thu, 13 Jun 2024 01:01:19 +0000
Message-ID:
 <SN6PR02MB4157CA088C0F84C8B72C8EE3D4C12@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20240610202810.193452-1-mhklinux@outlook.com>
 <cabdb509-83a2-4de7-8e10-4eea7e4c96f2@linux.microsoft.com>
In-Reply-To: <cabdb509-83a2-4de7-8e10-4eea7e4c96f2@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?WmkLZSMt1zd5QRN6bwhlV4WTLN7pgNeL+yU5ZXYUF0mfDKRxUku1QcGD3nmM?=
 =?us-ascii?Q?uG2NADgPDp7pVW8U6io52Y9WY/mpg4dmaL4AWttjmbRrnStGgvaNovpBaqT9?=
 =?us-ascii?Q?ss95R8nGuHUWGfqw0J4eHLaw2BYOhaOhAnbURvMxfuNlkQJu3i+sM3IqnWyr?=
 =?us-ascii?Q?ReJfrOXiTL4O9zQF9uKdGcMuRXIR3w4h/64v4I9CmMiSS5rWmTxj7RMNz6Al?=
 =?us-ascii?Q?MqQb0hWJMTCuI50wxha6L4f1qkbinJ0jmFEThVmL9lxOXF90Pw3Koa9vxkda?=
 =?us-ascii?Q?pId6td14ktepIcSYSzCogh9gf4sWpNc9DgJUuboLng4FOED7wn+eV5ucNKnq?=
 =?us-ascii?Q?E2ZQFFHFgvv7xidwAcOi2O9Vb3K7bFIp0LWngch2/B/iO1Alay1msvdAyL4H?=
 =?us-ascii?Q?SvWLc1i3fdCQSniFN/vmL+oA3hi7uvg3RykYarlBRpwff7ycsViO/gSQvrQc?=
 =?us-ascii?Q?bYr9gu/Bvx0eO/y+VH9CDfmSg7ouQNMKJm6v6vsxdiosE+KRoxNP6+/sX7qV?=
 =?us-ascii?Q?msFanVinC0THrlGNdJgex7f2XhB7ilWuOI/UWYJTMVM/6K+GSHBiOSigjdtO?=
 =?us-ascii?Q?bA7OXrTrN+iMFS4ItcHiiWWmslSnJzzFrQxQxup0ynARJNQN/LCulyDYe7v3?=
 =?us-ascii?Q?FvLZBiZpiiXEYo52fpnhXdCoK8E8HsDgE3e/R3PFl0nnyEVU0I7K6NLMsFoX?=
 =?us-ascii?Q?PcTpy1ySRozC9IYRS+PAUgE0ESVY6NBBIi2Td75Ii43i+YyiF0qKVEFsEx6A?=
 =?us-ascii?Q?5wng2FepN/uCkGI8/SwNl6zuU1IMSA2KYiKMjNla2o+SxFvrbTtoGcKXDNRj?=
 =?us-ascii?Q?i+Vv5KKtDjTLmwM/TZw9Nfsfp+2E8uAKHvcwP5NmFp8DjXnEq1Oupf80KOm8?=
 =?us-ascii?Q?Nhg8T/sReSJgG+i+eZ/OmlcjdkkUHqJlhSVBpAb1WXP7Bcmv+4WnuFG8WMnf?=
 =?us-ascii?Q?svr4WAhPk6kdI6+ptLqWyjp9C/4s9+7d9xvjp84rBu38wet4aQ22tCiiGd9s?=
 =?us-ascii?Q?lxe0J9WkjRrxn4R5dVTOgi92hFaqbXJDDjolE2dBScJxNsHN/6DGTpXs/jmp?=
 =?us-ascii?Q?FfoEljI6/90SBIkXrmTSJxcHs+IuQl/gkYuNB2wS9DQEvohC/Oc3+qhy9LUk?=
 =?us-ascii?Q?qcbwtd0w3YZAysAzOi9+dhJx1fA9exT13DabgD8JFGjIc4Fto90TNAMzwiVF?=
 =?us-ascii?Q?Kf0C3YtZPPBxv40JvD8u8uW+CHb3ETDn3tddIKrFbHeh4lP8fWiKEKYhbw4?=
 =?us-ascii?Q?=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: e2170da5-52a7-4272-a27e-08dc8b4455f2
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2024 01:01:19.5717
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR02MB6522

From: Easwar Hariharan <eahariha@linux.microsoft.com> Sent: Wednesday, June=
 12, 2024 9:10 AM

[snip]

> > +Operational Modes
> > +-----------------
> > +Hyper-V CoCo VMs can run in two modes. The mode is selected when the V=
M is
> > +created and cannot be changed during the life of the VM.
> > +
> > +* Fully-enlightened mode. In this mode, the guest operating system is
> > +  enlightened to understand and manage all aspects of running as a CoC=
o VM.
> > +
> > +* Paravisor mode. In this mode, a paravisor layer between the guest an=
d the
> > +  host provides some operations needed to run as a CoCo VM. The guest =
operating
> > +  system can have fewer CoCo enlightenments than is required in the
> > +  fully-enlightened case.
> > +
> > +Conceptually, fully-enlightened mode and paravisor mode may be treated=
 as
> > +points on a spectrum spanning the degree of guest enlightenment needed=
 to run
> > +as a CoCo VM. Fully-enlightened mode is one end of the spectrum. A ful=
l
> > +implementation of paravisor mode is the other end of the spectrum, whe=
re all
> > +aspects of running as a CoCo VM are handled by the paravisor, and a no=
rmal
> > +guest OS with no knowledge of memory encryption or other aspects of Co=
Co VMs
> > +can run successfully. However, the Hyper-V implementation of paravisor=
 mode
> > +does not go this far, and is somewhere in the middle of the spectrum. =
Some
> > +aspects of CoCo VMs are handled by the Hyper-V paravisor while the gue=
st OS
> > +must be enlightened for other aspects. Unfortunately, there is no
> > +standardized enumeration of feature/functions that might be provided i=
n the
> > +paravisor, and there is no standardized mechanism for a guest OS to qu=
ery the
> > +paravisor for the feature/functions it provides. The understanding of =
what
> > +the paravisor provides is hard-coded in the guest OS.
> > +
> > +Paravisor mode has similarities to the Coconut project, which aims to =
provide
> > +a limited paravisor to provide services to the guest such as a virtual=
 TPM.
>=20
> Would it be useful to add an external link to the Coconut project here?
> https://github.com/coconut-svsm/svsm
>=20

Yes, I'll add the link in a v2.

> > +However, the Hyper-V paravisor generally handles more aspects of CoCo =
VMs
> > +than is currently envisioned for Coconut, and so is further toward the=
 "no
> > +guest enlightenments required" end of the spectrum.
> > +
> > +In the CoCo VM threat model, the paravisor is in the guest security do=
main
> > +and must be trusted by the guest OS. By implication, the hypervisor/VM=
M must
> > +protect itself against a potentially malicious paravisor just like it
> > +protects against a potentially malicious guest.
>=20
> Tangential to this patch, can the guest provide its own paravisor since
> it needs to be trusted and apparently the only way to find out if a
> paravisor will be used is to rely on the (possibly) malicious
> hypervisor/VMM to provide a synthetic MSR?

Conceptually, yes, you want the guest to be able to provide its own
paravisor implementation, or at least to be able to audit the source code
of the default paravisor provided by Hyper-V/Azure. The paravisor is part
of the guest security domain, so the guest must trust the paravisor. It's
easy to envision that customers who are very security-conscious might
want to provide their own Linux and paravisor.

But that's all conceptual. I'm not in the loop any longer on what
Microsoft is currently offering, or planning to offer, along these lines as
product functionality available to customers. As you say, it's somewhat
tangential to the Linux kernel itself. But if someone who knows wants to
flesh out the big picture with a link to existing public documentation,
please do so!

And thanks for your review. :-)

Michael

>=20
> > +
> > +The hardware architectural approach to fully-enlightened vs. paravisor=
 mode
> > +varies depending on the underlying processor.
> > +
> > +* With AMD SEV-SNP processors, in fully-enlightened mode the guest OS =
runs in
> > +  VMPL 0 and has full control of the guest context. In paravisor mode,=
 the
> > +  guest OS runs in VMPL 2 and the paravisor runs in VMPL 0. The paravi=
sor
> > +  running in VMPL 0 has privileges that the guest OS in VMPL 2 does no=
t have.
> > +  Certain operations require the guest to invoke the paravisor. Furthe=
rmore, in
> > +  paravisor mode the guest OS operates in "virtual Top Of Memory" (vTO=
M) mode
> > +  as defined by the SEV-SNP architecture. This mode simplifies guest m=
anagement
> > +  of memory encryption when a paravisor is used.
> > +
> > +* With Intel TDX processor, in fully-enlightened mode the guest OS run=
s in an
> > +  L1 VM. In paravisor mode, TD partitioning is used. The paravisor run=
s in the
> > +  L1 VM, and the guest OS runs in a nested L2 VM.
> > +
> > +Hyper-V exposes a synthetic MSR to guests that describes the CoCo mode=
. This
> > +MSR indicates if the underlying processor uses AMD SEV-SNP or Intel TD=
X, and
> > +whether a paravisor is being used. It is straightforward to build a si=
ngle
> > +kernel image that can boot and run properly on either architecture, an=
d in
> > +either mode.
> > +