Hi,

A host state clobbering feature on new TDX modules/platforms can lead
to host state corruption if KVM does not explicitly save and restore
the related MSR(s) during host/guest transitions. If such a feature is
blindly exposed to and used by TDs, it will result in unexpected behavior
on the host.

The v1 RFC [1] attempted to solve this by introducing a comprehensive
CPUID paranoid verification framework across VMX, SVM, and TDX. However,
as Sean pointed out in [2] and the discussion in the PUCK meeting, this
approach was overly complex and bled too many TDX-specific details into
common KVM code, creating an unnecessary maintenance burden.

This v2 takes a significantly simpler, TDX-contained approach. It strictly
validates only the TDX directly configurable CPUID bits—those reported by
the TDX module in CPUID_CONFIG fields that the VMM can configure for a TD.
This is sufficient to address the host clobbering issue, as no new host
state clobbering features will be fixed-1. All filtering and validation
logic is entirely isolated within TDX code.

Feedback is highly appreciated, particularly on whether this contained
approach strikes an acceptable balance regarding complexity.

Specifically, this series builds a KVM-side allowlist of supported TDX
directly configurable CPUID bits to:
 - Filter KVM_TDX_CAPABILITIES:
   Replace the hardcoded denylist to only report configurable bits that
   KVM explicitly supports.
 - Validate KVM_TDX_INIT_VM:
   Reject any configurable bit that the TDX module allows but KVM does
   not yet support.

With this allowlist, newly added TDX configurable CPUID bits will not be
exposed to userspace until KVM explicitly opts-in after fulfilling the
necessary virtualization requirements.

Open:
- This series doesn't implement validation for KVM_SET_CPUID2.
  TDX has two interfaces for userspace to set CPUID bits: KVM_TDX_INIT_VM
  and KVM_SET_CPUID2. A malicious userspace VMM could lie to KVM through
  KVM_SET_CPUID2 by setting a TDX directly configurable CPUID bit to a
  different value than what it set via KVM_TDX_INIT_VM. KVM does not
  currently use its own view of vCPU capabilities to manage host clobbering
  features for TDs. The consistency check is not a must have action so
  far. It could be added later if KVM really relies on its own view
  to make decisions to manage host clobbering features for TDX.

Changes from v1:
 - Dropped the overarching CPUID paranoid verification framework across
   VMX/SVM/TDX and the opt-in interface. (Sean)
 - Shifted focus entirely to isolating and validating TDX directly
   configurable CPUID bits.

[1] https://lore.kernel.org/kvm/20260417073610.3246316-1-binbin.wu@linux.intel.com/
[2] https://lore.kernel.org/kvm/agsiQGikhZA0CGTY@google.com/

Binbin Wu (4):
  KVM: x86: TDX: Track supported configurable CPUID bits
  KVM: x86: TDX: Hide unsupported configurable CPUID bits
  KVM: x86: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM
  KVM: x86: TDX: Report CORE_CAPABILITIES as supported

 arch/x86/kvm/vmx/tdx.c | 251 +++++++++++++++++++++++++++++++++++------
 1 file changed, 214 insertions(+), 37 deletions(-)


base-commit: d4bfaa66fa171089b9b9fb2dc17af9245f2b9b34
-- 
2.46.0