From: Binbin Wu <binbin.wu@linux.intel.com>
To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: seanjc@google.com, pbonzini@redhat.com,
dave.hansen@linux.intel.com, andrew.cooper3@citrix.com,
nik.borisov@suse.com, kas@kernel.org, rick.p.edgecombe@intel.com,
xiaoyao.li@intel.com, chao.gao@intel.com,
tony.lindgren@linux.intel.com, kishen.maloor@intel.com,
dedekind1@gmail.com, binbin.wu@linux.intel.com
Subject: [PATCH v4 0/4] KVM: TDX: Validate directly configurable CPUID bits
Date: Thu, 17 Sep 2026 15:25:44 +0800 [thread overview]
Message-ID: <20260917072548.2314491-1-binbin.wu@linux.intel.com> (raw)
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.
For this version, I'm hoping to collect some RBs and Acks. The key
discussions from v3 [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:
- Whether to restrict the TDX feature bits to kvm_cpu_caps[].
Xiaoyao and Sean preferred not to restrict the TDX feature bits to
kvm_cpu_caps[], to avoid an unnecessary dependency on feature enabling
for non-TDX VMs [3][4]. However, Rick pointed out that ideally the TDX
arch would not be finalized before the normal VM KVM design reaches some
level of maturity [5]. Also, it's safer for TDX to respect KVM's logic
around disabling certain features, since the reasons for disabling them
could apply to TDX as well [6].
This version still restricts the TDX feature bits to kvm_cpu_caps[], with
a few exceptions. If TDX feature enabling turns out to be consistently
blocked by non-TDX VM enabling, a solution can be worked out then.
Note that the final allowlist is the same either way, i.e. whether or
not the TDX feature bits are restricted to kvm_cpu_caps[].
- 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 [7].
- 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 [8].
Changes since v3:
- Audited the directly configurable CPUID bits outside of kvm_cpu_caps[],
added XTPR and HT to the allowlist, in addition to MWAIT and
CORE_CAPABILITIES. The remaining bits are left out of the allowlist
because they are either not supported or can't be properly virtualized.
- Improved comments/changelogs. (Xiaoyao, Kishen)
- Updated documentation/comment about the ABI change. (Xiaoyao, Rick)
- Renamed functions for better readability. (Tony)
- Collected two RBs from Tony.
The series follows the CSV version of the CPUID virtualization document
from "Intel TDX Module ABI Definitions" [9], updated in June 2026.
AI tools were used to:
- Polish the cover letter and commit messages.
- Do code review.
[1] 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/9abeed40-bcdc-48d9-8cbb-cb87154bb9f6@intel.com
[4] https://lore.kernel.org/all/aqHdwkOFVR4XoS2M@google.com
[5] https://lore.kernel.org/all/c967dc3eb6b128055e415bae45d1c14a52dc4acd.camel@intel.com
[6] https://lore.kernel.org/all/4c379b90da893c5d1ffea46dc7e40303e7923872.camel@intel.com
[7] https://lore.kernel.org/all/c6b240bd-3c45-4abe-b17c-72a1a7da582f@linux.intel.com
[8] https://lore.kernel.org/all/1deddc78d14326b378ddd62ad99c21d66da401e6.camel@intel.com
[9] https://cdrdv2.intel.com/v1/dl/getContent/795381
Binbin Wu (4):
KVM: TDX: Track configurable CPUID bits allowed by KVM
KVM: TDX: Report CORE_CAPABILITIES as configurable
KVM: TDX: Filter configurable CPUID bits
KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM
Documentation/virt/kvm/x86/intel-tdx.rst | 10 +
arch/x86/include/uapi/asm/kvm.h | 2 +
arch/x86/kvm/vmx/tdx.c | 279 ++++++++++++++++++++---
3 files changed, 262 insertions(+), 29 deletions(-)
base-commit: 70c944caf570fda2d79baa71435589a8db39f048
--
2.46.0
next reply other threads:[~2026-09-17 7:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 7:25 Binbin Wu [this message]
2026-09-17 7:25 ` [PATCH v4 1/4] KVM: TDX: Track configurable CPUID bits allowed by KVM Binbin Wu
2026-09-17 7:25 ` [PATCH v4 2/4] KVM: TDX: Report CORE_CAPABILITIES as configurable Binbin Wu
2026-09-17 7:25 ` [PATCH v4 3/4] KVM: TDX: Filter configurable CPUID bits Binbin Wu
2026-09-17 7:25 ` [PATCH v4 4/4] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM Binbin Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260917072548.2314491-1-binbin.wu@linux.intel.com \
--to=binbin.wu@linux.intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dedekind1@gmail.com \
--cc=kas@kernel.org \
--cc=kishen.maloor@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tony.lindgren@linux.intel.com \
--cc=xiaoyao.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®