Date: Thu, 13 Jun 2024 01:01:19 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Easwar Hariharan <eahariha@...ux.microsoft.com>, "kys@...rosoft.com"
	<kys@...rosoft.com>, "haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
	"wei.liu@...nel.org" <wei.liu@...nel.org>, "decui@...rosoft.com"
	<decui@...rosoft.com>, "corbet@....net" <corbet@....net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>
Subject: RE: [PATCH 1/1] Documentation: hyperv: Add overview of Confidential
 Computing VM support

From: Easwar Hariharan <eahariha@...ux.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 VM 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 CoCo VM.
> > +
> > +* Paravisor mode. In this mode, a paravisor layer between the guest and 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 full
> > +implementation of paravisor mode is the other end of the spectrum, where all
> > +aspects of running as a CoCo VM are handled by the paravisor, and a normal
> > +guest OS with no knowledge of memory encryption or other aspects of CoCo 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 guest OS
> > +must be enlightened for other aspects. Unfortunately, there is no
> > +standardized enumeration of feature/functions that might be provided in the
> > +paravisor, and there is no standardized mechanism for a guest OS to query 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.
> 
> Would it be useful to add an external link to the Coconut project here?
> https://github.com/coconut-svsm/svsm
> 

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 domain
> > +and must be trusted by the guest OS. By implication, the hypervisor/VMM must
> > +protect itself against a potentially malicious paravisor just like it
> > +protects against a potentially malicious guest.
> 
> 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

> 
> > +
> > +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 paravisor
> > +  running in VMPL 0 has privileges that the guest OS in VMPL 2 does not have.
> > +  Certain operations require the guest to invoke the paravisor. Furthermore, in
> > +  paravisor mode the guest OS operates in "virtual Top Of Memory" (vTOM) mode
> > +  as defined by the SEV-SNP architecture. This mode simplifies guest management
> > +  of memory encryption when a paravisor is used.
> > +
> > +* With Intel TDX processor, in fully-enlightened mode the guest OS runs in an
> > +  L1 VM. In paravisor mode, TD partitioning is used. The paravisor runs 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 TDX, and
> > +whether a paravisor is being used. It is straightforward to build a single
> > +kernel image that can boot and run properly on either architecture, and in
> > +either mode.
> > +

Powered by blists - more mailing lists