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 15:53 -0700, Sean Christopherson wrote:
> > > 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?
> 
> DOS naughtiness by the host is allowed though.
> 
> > 
> > > 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.
> 
> I thought that the shared half could be mapped in that range unless KVM gets
> involved. But, no, as long as we tie GPAW, 23:16, ept-level all together, then
> mapping something above it won't even make sense.
> 
> I don't see attack surface risk immediately. I expect this will get more
> internal scrutiny in that regard though.

Oooh, I thought you were talking about KVM mapping a private GPA address in S-EPT
above the reported GPAW.  In hindsight, I don't know _why_ I thought that.

Yeah, trying to sanity check the shared EPT in the TDX module would be comically
pointless.