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.
