Re: [RFC PATCH v2 0/4] KVM: x86: TDX: Validate directly configurable CPUID bits

[Binbin Wu <binbin.wu@linux.intel.com>]

On 6/4/2026 10:33 AM, Binbin Wu wrote:
> 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.

Hi Sean,

Do you think this proposal is the direction to go?

> 
> 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