Re: [PATCH 1/2] KVM: TDX: Allow TDs to read MSR_IA32_PLATFORM_ID

[Sean Christopherson <seanjc@google.com>]

On Tue, Apr 28, 2026, Rick P Edgecombe wrote:
> On Tue, 2026-04-28 at 09:30 -0700, Sean Christopherson wrote:
> > > This patch looks good to me. But the rule for which MSRs should be emulated
> > > by KVM for TDX is not very clear to me.
> > 
> > I would strongly prefer to not take this patch, and instead fix the guest. 
> > This isn't some latent/pre-existing guest behavior, it's brand new
> > functionality. I.e. Linux-as-a-TDX-guest broke itself.
> > 
> > More importantly from a guest security perspective, consuming
> > MSR_IA32_PLATFORM_ID is actively dangerous.  E.g. it could allow the untrusted
> > host to steer the guest's behavior with respect to feature detection and
> > enablement.
> 
> I feel like you could make similar cases about a lot the VMM controlled MSRs.

Oh, for sure.  And far worse (yet another reminder that I need to refresh this
series).

https://lore.kernel.org/all/20250227021855.3257188-1-seanjc@google.com

> > And once KVM allows reads from MSR_IA32_PLATFORM_ID, there's no going back. 
> > E.g. if the TDX-Module wants to emulate MSR_IA32_PLATFORM_ID, because there's
> > an actual *need* to do so, then we're going to have a (minor) mess with KVM's
> > ABI.
> 
> This is a problem with the bare metal KVM behavior too, and it's just super old?

No?  Oh, I see what you're asking.  I'm mostly concerned about the host side of
things.  The problem with TDX is that a TDX-Module update could effectively change
KVM's behavior, i.e. if the TDX-Module decides it needs to emulate PLATFORM_ID for
whatever reason.  So not only would KVM need to enumerate to userspace that the
MSR is supported/emulated for TDX guests, KVM would also need to differentiate
between emulated by KVM and emulated by the TDX-Module.

> For TDX, hmm. I guess the standard thing to do in order to avoid creating a KVM
> ABI problems is just match the arch behavior. But for TDs, it is a very special
> type of VM. The special TDX guest things can't work on bare metal. Furthermore,
> guest opt ins can change what arch is even supposed to be virtualized. So the
> normal KVM default thing to do doesn't always fit.
> 
> So instead we will just virtualize as little as possible to keep Linux guest
> running? Ok.

Yeah, and the sequence of events matters.  Most of KVM's half-hearted emulation
of random MSRs exists because KVM needed to be able to run existing kernels.  But
once KVM (and other hypervisors) existed, kernels learned to run as guests (and
hardware vendors largely did a better job of explicitly enumerating MSRs and
whatnot), and so the need to throw hacks into KVM mostly went away.

> > > Maybe we can document the rule here, if there is one. That would make it
> > > much easier to tell whether future issues like this are guest regressions
> > > or missing KVM handling.
> 
> Speaking in general now about TDX guest ABI, not about this specific MSR. I
> agree it would be good to have some story about how this is supposed to work and
> evolve. Similar to the CPUID bit stuff we are trying to clean up.
> 
> I'm also remembering the debate about what to do about the MTRR bit being forced
> on, but not being able to apply the KVM solution (which got ripped out anyway)
> to the S-EPT. Or the guest maxpfn thing, where we got the TDX module to add
> CPUID bit support we needed. By default, we can try to make it so the TDX module
> will, or will let us, faithfully match the normal x86 arch bit behavior.