Re: [RFC] TDX module configurability of 0x80000008

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Thu, 2024-04-25 at 16:28 -0700, Sean Christopherson wrote:
> > > > 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-
> 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.

I might have been thinking that as well? Wasn't the fullest thought. Sorry for
the confusion.

In any case it should be moot for the solution we are going for in KVM. I'll
mention it to them though, because just because KVM will not do GPA_48 and 5-
level EPT, doesn't mean another VMM wont.

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux