Re: (Proposal) New TDX Global Metadata To Report FIXED0 and FIXED1 CPUID Bits

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Wed, 2024-12-18 at 18:33 -0800, Sean Christopherson wrote:
> > So that is how I arrived at that we need some list of host affecting bits to
> > verify match in the TD.
> 
> At the end of the day, the list is going to be human-generated.  For the UX
> side
> of things, it makes sense to push that responsibility to the TDX Module,
> because
> it should be trivially easy to derive from the source code.

The other reason to push it to the TDX module is because newly invented bits on
future CPUs can only be known by TDX Modules that start to use them.

[snip]

> > 
> > There already is an interface to get CPUID bits (fixed and dynamic). But it
> > only
> > works after a TD is configured. So if we want to do extra verification or
> > adjustments, we could use it before entering the TD. Basically, if we delay
> > this
> > logic we don't need to wait for the fixed bit interface.
> 
> Oh, yeah, that'd work.  Grab the guest CPUID and then verify that bits KVM
> needs
> to be 0 (or 1) are set according, and WARN+kill if there's a mismatch.
> 
> Honestly, I'd probably prefer that over using the fixed bit interface, as my
> gut
> says it's less likely for the TDX Module to misreport what CPUID it has
> created
> for the guest, than it is for the TDX module to generate a "fixed bits" list
> that
> doesn't match the code.  E.g. KVM has (had?) more than a few CPUID features
> that
> KVM emulates without actually reporting support to userspace.

Ok, so we have a plan to:
1. Verify if there are more bits that affect host state
2. Encode this list in KVM for now
3. Check the bits match via the existing CPUID bit interface before the vCPU
enters the TD

Still to decide (not today):
I guess KVM=0,TDX=1 is the one to worry about, but might as well also check for
KVM=1,TDX=0. When KVM finds a conflict it must prevent entering the TD and
return an error to userspace. We could do this enforcement either on the first
enter, or with an additional per-vcpu "verify" ioctl.

We can take a look at the list of bits to decide. The current solution of
preventing configuration of the two known troublesome bits seems ok if that's
all.