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.
