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

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

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>