Wearing my KVM hat and not my Google hat...

On Thu, Feb 09, 2023, Michael Kelley (LINUX) wrote:

From: Dave Hansen <redacted> Sent: Wednesday, February 8, 2023 9:24 AM

quoted

On 2/7/23 04:41, Borislav Petkov wrote:

quoted

Or are there no similar TDX solutions planned where the guest runs
unmodified and under a paravisor?

I actually don't think paravisors make *ANY* sense for Linux.

I 100% agree, but Intel made what I think almost entirely irrelevant by refusing
to allow third party code to run in SEAM.

quoted

If you have to modify the guest, then just modify it to talk to the
hypervisor directly.  This code is... modifying the guest.  What does
putting a paravisor in the middle do for you?

One of the original goals of the paravisor was to make fewer
modifications to the guest, especially in areas that aren't directly related
to the hypervisor.  It's arguable as to whether that goal played out in
reality.

But another significant goal is to be able to move some device emulation
from the hypervisor/VMM to the guest context.  In a CoCo VM, this move
is from outside the TCB to inside the TCB.  A great example is a virtual
TPM.  Per the CoCo VM threat model, a guest can't rely on a vTPM
provided by the host.

I vehemently disagree with this assertion.  It's kinda sorta true, but only
because Intel and AMD have gone down the road of not providing the mechanisms and
ability for the hypervisor to run and attest to the integrity, functionality, etc.
of (a subset of) the hypervisor's own code.

Taking SEAM/TDX as an example, if the code running in SEAM were an extension of
KVM instead of a hypervisor-agnostic nanny, then there would be no need for a
"paravisor" to provide a vTPM.  It would be very feasible to teach the SEAM-protected
bits of KVM to forward vTPM accesses to a host-provided, signed, attested, and open
source software running in a helper TD.

I fully realize you meant "untrusted host", but statements like "the host can't
be trusted" subconciously reinforce the, IMO, flawed model of hardware vendors
and _only_ hardware vendors providing the trusted bits.

The idea that firmware/software written by hardware vendors is somehow more
trustworthy than fully open source software is simultaneously laughable and
infuriating.  

Anyways, tying things back to the actual code being discussed, I vote against
CC_ATTR_PARAVISOR.  Being able to trust device emulation is not unique to a
paravisor.  A single flag also makes too many assumptions about what is trusted
and thus should be accessed encrypted.