On Wed, Aug 14, 2024, Rick P Edgecombe wrote: > On Wed, 2024-08-14 at 06:35 -0700, Sean Christopherson wrote: > > > One scenario where "fixed-1" bits can help is: we discover a security issue > > > and > > > release a microcode update to expose a feature indicating which CPUs are > > > vulnerable. if the TDX module allows the VMM to configure the feature as 0 > > > (i.e., not vulnerable) on vulnerable CPUs, a TD might incorrectly assume > > > it's > > > not vulnerable, creating a security issue. > > > > > > I think in above case, the TDX module has to add a "fixed-1" bit. An example > > > of > > > such a feature is RRSBA in the IA32_ARCH_CAPABILITIES MSR. > > > > That would be fine, I would classify that as reasonable. However, that > > scenario > > doesn't really work in practice, at least not the way Intel probably hopes it > > plays out. For the new fixed-1 bit to provide value, it would require a guest > > reboot and likely a guets kernel upgrade. > > If we allow "reasonable" fixed bits, we need to decide how to handle any that > KVM sees but doesn't know about. Not filtering them is simpler to implement. > Filtering them seems a little more controlled to me. > > It might depend on how reasonable, "reasonable" turns out. Maybe we give not > filtering a try and see how it goes. If we run into a problem, we can filter new > bits from that point, and add a quirk for whatever the issue is. I'm still on > the fence. As I see it, it's ultimately unlikely to be KVM's problem. If Intel ships a TDX-Module that does bad things, and someone's setup breaks when they upgrade to that TDX-Module, then their gripe is with Intel. KVM can't do anything to remedy the problem. If the upgrade breaks a setup because it confuses _KVM_, then I'll care, but I suspect/hope that won't happen in practice, purely because KVM has so little visiblity into the guest, i.e. doesn't care what is/isn't advertised to the guest. FWIW, AMD has effectively gone the "fixed-1" route for a few things[*], e.g. KVM can't intercept XCR0 or XSS writes. And while I detest the behavior, I haven't refused to merge support for SEV-ES+. I just grumble every time it comes up :-) [*] https://lore.kernel.org/all/ZUQvNIE9iU5TqJfw@xxxxxxxxxx
