Re: [PATCH v5 0/5] KVM: TDX: Validate directly configurable CPUID bits

[Binbin Wu]

On 10/22/2026 1:43 AM, Nikolay Borisov wrote:
> 
> 
> On 16.10.26 г. 12:14 ч., Binbin Wu wrote:
>> The TDX module reports a set of CPUID bits that the VMM can directly
>> configure for a TD, but KVM cannot blindly expose all module-supported
>> bits to userspace.  Certain features imply additional architectural state
>> (such as one or more MSRs) that KVM must explicitly manage across
>> host/guest transitions to prevent host state corruption.
>>
>> Today, KVM hardcodes a denylist to filter out host state clobbering
>> features that KVM doesn't support.  However, a denylist doesn't scale as
>> the TDX module evolves, i.e. host state clobbering features added by a
>> future TDX module are not covered by the denylist, and userspace could
>> enable a feature that KVM doesn't support.
>>
>> This series builds an allowlist for directly configurable CPUID bits, and
>> filters and validates userspace input against it, so that newly introduced
>> TDX directly configurable CPUID feature bits can only be enabled by
>> userspace after KVM explicitly opts in.  Except for a few fixed-1 bits
>> required for basic TDX support, host state clobbering features are either
>> directly configurable or gated by TD ATTRIBUTES/XFAM.  KVM already
>> validates ATTRIBUTES/XFAM, so the allowlist only needs to cover directly
>> configurable bits.
>>
>> Patch 1 is a standalone fix for the existing denylist check, which uses
>> the index of the matched userspace entry instead of the subleaf reported
>> by the TDX module, i.e. userspace can bypass the HLE/RTM/WAITPKG check.
>> It is tagged for stable so that it can be backported independently of
>> the rest of the series.
>>
>> Patches 2-5 build the allowlist, add CORE_CAPABILITIES to it, filter
>> KVM_TDX_CAPABILITIES, and validate the CPUID input of KVM_TDX_INIT_VM.
>> The last two patches are user-visible changes, which are now called out
>> in their changelogs, along with why existing userspace and guests are not
>> expected to be affected.
>>
>> For this version, I'm hoping to continue to collect some RBs and Acks.
>> The key discussions from v3/v4 [1] are summarized below.  Note, FRED KVM
>> support is in progress upstream [2], and no TDX module with FRED support
>> exists yet, so there is no immediate issue.  But it would be nice to get
>> this series merged sooner rather than later.
>>
>> Discussions from v3/v4:
>> - Rick asked whether the assumption that the reserved bits in
>>    CPUID.0x1.EAX, CPUID.{0x4,0x18,0x1F} and CPUID.0x80000008.EAX won't be
>>    used to enumerate features can be confirmed by the x86 architects [3].
>>    Confirmation is still pending.  Per the SDM/APM, these leaves/registers
>>    are defined for specific information (version, cache/TLB parameters,
>>    topology, and address sizes), so the reserved bits are expected to be
>>    used to extend the existing information rather than to enumerate
>>    features.  Allowing these registers in full is a best guess, but it's
>>    still far better than the existing denylist-based check.
>>
>> - Whether to restrict the TDX feature bits to kvm_cpu_caps[].
>>    The conclusion from the discussions is to construct the allowlist based
>>    on kvm_cpu_caps[], plus a few bits that KVM can support for TDs
>>    independently of kvm_cpu_caps[].  If TDX feature enabling turns out to
>>    be consistently blocked by non-TDX VM enabling, a solution can be worked
>>    out then.
>>
>> - New opt-in interface vs. backporting.
>>    There are two options for old KVM versions that don't do the filtering
>>    and validation:
>>    1) Add a new opt-in interface to expose features newly introduced by the
>>       TDX module.
>>    2) Backport this series to LTS/stable branches.
>>
>>    The opt-in design vs. backport decision is deferred, since this series
>>    is correct and an improvement either way.
>>
>> - Potential backward compatibility issue when an effective fixed-1 bit
>>    becomes directly configurable due to x86 feature deprecation.
>>    This is left for the future, i.e. it can be addressed if and when such a
>>    deprecation actually happens, e.g. by adding an opt-in interface to let
>>    users/admins choose between migration flexibility and backwards
>>    compatibility on old platforms.
>>
>> Changes since v4 [1]:
>> - Split the CPUID entry index check out into a standalone fix, which
>>    allows it to be backported to stable independently of the rest of the
>>    series.
>> - Exclude XTPR from the allowlist, as neither TDX nor KVM actually
>>    virtualizes the feature and guests don't need it. (Xiaoyao, Rick)
>> - Rename TDX_CFG_EXTRA_F() to TDX_CFG_INDEPENDENT_F(). (Xiaoyao)
>> - Fix AMX_COMPLEX to be added for CPUID_7_1_EDX instead of CPUID_1E_1_EAX.
>> - Drop the descriptions in the TDX documentation and the uapi header, as
>>    the ioctl interfaces for KVM_TDX_CAPABILITIES and KVM_TDX_INIT_VM are
>>    unchanged by this patch series.
>> - Improve changelogs and comments. (Xiaoyao, Rick)
>>
>> The series follows the CSV version of the CPUID virtualization document
>> from "Intel TDX Module ABI Definitions" [4], updated in June 2026.
>>
>> AI tools were used to:
>> - Polish the cover letter and commit messages.
>> - Do code review.
>>
>> [1] v4: https://lore.kernel.org/all/20260917072548.2314491-1-binbin.wu@xxxxxxxxxxxxxxx
>>      v3: https://lore.kernel.org/all/20260827031837.2863609-1-binbin.wu@xxxxxxxxxxxxxxx
>>      v2: https://lore.kernel.org/all/20260604023314.3907511-1-binbin.wu@xxxxxxxxxxxxxxx
>>      v1: https://lore.kernel.org/all/20260417073610.3246316-1-binbin.wu@xxxxxxxxxxxxxxx
>> [2] https://lore.kernel.org/all/20260911213659.2025974-1-sohil.mehta@xxxxxxxxx
>> [3] https://lore.kernel.org/all/e7182b3c03a0e39cb60392b4d75111255418d6cf.camel@xxxxxxxxx
>> [4] https://cdrdv2.intel.com/v1/dl/getContent/795381
>>
>> Binbin Wu (5):
>>    KVM: TDX: Check unsupported CPUID bits against the TDX module's
>>      subleaf
>>    KVM: TDX: Track configurable CPUID bits allowed by KVM
>>    KVM: TDX: Add CORE_CAPABILITIES to the allowlist
>>    KVM: TDX: Report only KVM-allowed CPUIDs in KVM_TDX_CAPABILITIES
>>    KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM
>>
>>   arch/x86/kvm/vmx/tdx.c | 258 ++++++++++++++++++++++++++++++++++++-----
>>   1 file changed, 231 insertions(+), 27 deletions(-)
>>
>>
>> base-commit: dea4f6380f4ec96e8f3b0aaf2343764bd0d25ef4
> 
> 
> For the series:
> 
> Reviewed-by: Nikolay Borisov <nik.borisov@xxxxxxxx>

Hi Nikolay,

Thanks for your reviews!

I noticed you later gave separate RBs for patches 2 and 3. Is that because
patches 4-5 conflict with Sean's series [1] during rebase?

For now, I'll carry your RB only on patches 2 and 3 in the next version.

[1] https://lore.kernel.org/all/20261022210134.612848-1-seanjc@xxxxxxxxxx/