Re: [RFC] TDX module configurability of 0x80000008

[Sean Christopherson <seanjc@google.com>]

On Thu, Apr 25, 2024, Rick P Edgecombe wrote:
> On Thu, 2024-04-25 at 14:39 -0700, Sean Christopherson wrote:
> > On Thu, Apr 25, 2024, Rick P Edgecombe wrote:
> > > On Thu, 2024-04-25 at 09:59 -0700, Sean Christopherson wrote:
> > > > > accessing a GPA beyond [23:16] is similar to accessing a GPA with no
> > > > > memslot.
> > > > 
> > > > No, it's not.  A GPA without a memslot has *very* well-defined
> > > > semantics in KVM, and KVM can provide those semantics for all
> > > > guest-legal GPAs regardless of hardware EPT/NPT support.
> > > 
> > > Sorry, not following. Are we expecting there to be memslots above the guest
> > > maxpa 23:16? If there are no memslots in that region, it seems exactly like
> > > accessing a GPA with no memslots. What is the difference between before and
> > > after the introduction of guest MAXPA? (there will be normal VMs and TDX
> > > differences of course).
> > 
> > If there are no memslots, nothing from a functional perspectives, just a
> > very slight increase in latency.  Pre-TDX, KVM can always emulate in
> > reponse to an EPT violation on an unmappable GPA.  I.e. as long as there is
> > no memslot, KVM doesn't *need* to create SPTEs, and so whether or not a GPA
> > is mappable is completely irrelevant.
> 
> Right, although there are gaps in emulation that could fail. If the emulation
> succeeds and there is an MMIO exit targeting a totally unknown GPA, then I guess
> it's up to userspace to decide what to do.
> 
> KVM's done its job.

Yep.

> But userspace still has to handle it. It can, but I was under the impression
> it didn't (maybe bad assumption).

I'm pretty sure QEMU handles accesses to non-existent MMIO with PCI abort semantics,
i.e. ignores writes and returns all FFs for reads.

> > > Also, it adds complexity for cases where KVM maps GPAs above guest maxpa
> > > anyway.
> > 
> > That should be disallowed.  If KVM tries to map an address that it told the
> > guest was impossible to map, then the TDX module should throw an error.
> 
> Hmm. I'll mention this, but I don't see why KVM needs the TDX module to filter
> it. It seems in the range of userspace being allowed to create nonsense
> configurations that only hurt its own guest.

Because the whole point of TDX is to protect the guest from the bad, naughty host?

> If we think the TDX module should do it, then maybe we should have KVM sanity
> filter these out today in preparation.

Nope.  KVM isn't in the guest's TCB, TDX is.  KVM's stance is that userspace is
responsible for providing a sane vCPU model, because defining what is "sane" is
extremely difficult unless the definition is super prescriptive, a la TDX. 

E.g. letting the host map something that TDX's spec says will cause #VE would
create a novel attack surface.