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

[Nikolay Borisov <nik.borisov@suse.com>]

On 27.10.26 г. 5:17 ч., Binbin Wu wrote:
> 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@linux.intel.com
>>>       v3: https://lore.kernel.org/all/20260827031837.2863609-1-binbin.wu@linux.intel.com
>>>       v2: https://lore.kernel.org/all/20260604023314.3907511-1-binbin.wu@linux.intel.com
>>>       v1: https://lore.kernel.org/all/20260417073610.3246316-1-binbin.wu@linux.intel.com
>>> [2] https://lore.kernel.org/all/20260911213659.2025974-1-sohil.mehta@intel.com
>>> [3] https://lore.kernel.org/all/e7182b3c03a0e39cb60392b4d75111255418d6cf.camel@intel.com
>>> [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@suse.com>
> 
> 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?

Yep, overall the whole series LGTM in isolation but given that it 
intersects with Sean's series I decided to give explicit RB to the 
patches that won't change.

> 
> 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@google.com/
>