Wearing my KVM hat and not my Google hat... On Thu, Feb 09, 2023, Michael Kelley (LINUX) wrote: > From: Dave Hansen <dave.hansen@xxxxxxxxx> Sent: Wednesday, February 8, 2023 9:24 AM > > > > On 2/7/23 04:41, Borislav Petkov wrote: > > > 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. > > 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.
