* [PATCH v5 1/5] KVM: TDX: Check unsupported CPUID bits against the TDX module's subleaf
2026-10-16 9:14 [PATCH v5 0/5] KVM: TDX: Validate directly configurable CPUID bits Binbin Wu
@ 2026-10-16 9:14 ` Binbin Wu
2026-10-16 15:25 ` Sean Christopherson
2026-10-16 9:14 ` [PATCH v5 2/5] KVM: TDX: Track configurable CPUID bits allowed by KVM Binbin Wu
` (3 subsequent siblings)
4 siblings, 1 reply; 9+ messages in thread
From: Binbin Wu @ 2026-10-16 9:14 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: seanjc, pbonzini, dave.hansen, andrew.cooper3, nik.borisov, kas,
rick.p.edgecombe, xiaoyao.li, chao.gao, tony.lindgren,
kishen.maloor, dedekind1, adrian.hunter, binbin.wu
Check for unsupported CPUID bits using the subleaf reported by the TDX
module instead of the index of the matching userspace entry, so that KVM
validates the same subleaf that the values are copied into.
setup_tdparams_cpuids() walks the directly configurable CPUID leaves
reported by the TDX module and looks up the corresponding userspace entry
via kvm_find_cpuid_entry2(). If userspace doesn't set
KVM_CPUID_FLAG_SIGNIFCANT_INDEX on an entry, kvm_find_cpuid_entry2()
ignores the entry's index, i.e. the matched entry's index can differ from
the TDX module's subleaf. tdx_unsupported_cpuid() checks HLE, RTM and
WAITPKG based on the userspace entry's index, while the register values
are applied to the TDX module's subleaf, which allows userspace to bypass
the check.
E.g. if userspace provides a CPUID.0x7 entry with index 3, WAITPKG set,
and KVM_CPUID_FLAG_SIGNIFCANT_INDEX cleared, the entry is matched for the
TDX module's subleaf 0. The check sees index 3 and passes, while ECX is
copied into td_params for CPUID.0x7.0, where WAITPKG is directly
configurable. The TDX module accepts the value, and the TD ends up with
WAITPKG enumerated despite KVM not supporting it. The same applies to RTM
and HLE.
Don't reject the mismatch outright, as the ABI allows userspace to provide
an arbitrary index when KVM_CPUID_FLAG_SIGNIFCANT_INDEX is cleared. It's
userspace's responsibility to provide the intended entries; KVM only needs
to ensure that the values it validates are the values it applies.
Fixes: 6d415778f106 ("KVM: TDX: Disable support for TSX and WAITPKG")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/kvm/20260604024927.E22311F00893@smtp.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
---
v5:
- Split out from "KVM: TDX: Validate userspace CPUID input for
KVM_TDX_INIT_VM" as a standalone fix. Sashiko reported the issue
against the TDX CPUID validation patch, but it also applies to the
existing code, so split it out to allow backporting to stable
independently of the rest of the series.
- Check the userspace values against the subleaf reported by the TDX
module instead of rejecting the request when there is a mismatch.
A simpler alternative would be to require a zero index when
KVM_CPUID_FLAG_SIGNIFCANT_INDEX is cleared, but that would be an ABI
change.
---
arch/x86/kvm/vmx/tdx.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index ee1d412b0ee6..ae7135784878 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -119,9 +119,9 @@ static u32 tdx_set_guest_phys_addr_bits(const u32 eax, int addr_bits)
#define TDX_FEATURE_TSX (__feature_bit(X86_FEATURE_HLE) | __feature_bit(X86_FEATURE_RTM))
-static bool has_tsx(const struct kvm_cpuid_entry2 *entry)
+static bool has_tsx(const struct kvm_cpuid_entry2 *entry, u32 index)
{
- return entry->function == 7 && entry->index == 0 &&
+ return entry->function == 7 && index == 0 &&
(entry->ebx & TDX_FEATURE_TSX);
}
@@ -130,9 +130,9 @@ static void clear_tsx(struct kvm_cpuid_entry2 *entry)
entry->ebx &= ~TDX_FEATURE_TSX;
}
-static bool has_waitpkg(const struct kvm_cpuid_entry2 *entry)
+static bool has_waitpkg(const struct kvm_cpuid_entry2 *entry, u32 index)
{
- return entry->function == 7 && entry->index == 0 &&
+ return entry->function == 7 && index == 0 &&
(entry->ecx & __feature_bit(X86_FEATURE_WAITPKG));
}
@@ -143,16 +143,16 @@ static void clear_waitpkg(struct kvm_cpuid_entry2 *entry)
static void tdx_clear_unsupported_cpuid(struct kvm_cpuid_entry2 *entry)
{
- if (has_tsx(entry))
+ if (has_tsx(entry, entry->index))
clear_tsx(entry);
- if (has_waitpkg(entry))
+ if (has_waitpkg(entry, entry->index))
clear_waitpkg(entry);
}
-static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry)
+static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry, u32 index)
{
- return has_tsx(entry) || has_waitpkg(entry);
+ return has_tsx(entry, index) || has_waitpkg(entry, index);
}
#define KVM_TDX_CPUID_NO_SUBLEAF ((__u32)-1)
@@ -2381,7 +2381,13 @@ static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
if (!entry)
continue;
- if (tdx_unsupported_cpuid(entry))
+ /*
+ * Check the userspace values against the subleaf reported by
+ * the TDX module, i.e. the subleaf the values are applied to,
+ * not the index of the userspace entry, which may differ if
+ * KVM_CPUID_FLAG_SIGNIFCANT_INDEX isn't set.
+ */
+ if (tdx_unsupported_cpuid(entry, tmp.index))
return -EINVAL;
copy_cnt++;
--
2.46.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v5 1/5] KVM: TDX: Check unsupported CPUID bits against the TDX module's subleaf
2026-10-16 9:14 ` [PATCH v5 1/5] KVM: TDX: Check unsupported CPUID bits against the TDX module's subleaf Binbin Wu
@ 2026-10-16 15:25 ` Sean Christopherson
2026-10-16 22:15 ` Binbin Wu
0 siblings, 1 reply; 9+ messages in thread
From: Sean Christopherson @ 2026-10-16 15:25 UTC (permalink / raw)
To: Binbin Wu
Cc: linux-kernel, kvm, pbonzini, dave.hansen, andrew.cooper3,
nik.borisov, kas, rick.p.edgecombe, xiaoyao.li, chao.gao,
tony.lindgren, kishen.maloor, dedekind1, adrian.hunter
[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]
On Fri, Oct 16, 2026, Binbin Wu wrote:
> Don't reject the mismatch outright, as the ABI allows userspace to provide
> an arbitrary index when KVM_CPUID_FLAG_SIGNIFCANT_INDEX is cleared. It's
> userspace's responsibility to provide the intended entries; KVM only needs
> to ensure that the values it validates are the values it applies.
>
> Fixes: 6d415778f106 ("KVM: TDX: Disable support for TSX and WAITPKG")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/kvm/20260604024927.E22311F00893@smtp.kernel.org
> Cc: stable@vger.kernel.org
> Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
> ---
> v5:
> - Split out from "KVM: TDX: Validate userspace CPUID input for
> KVM_TDX_INIT_VM" as a standalone fix. Sashiko reported the issue
> against the TDX CPUID validation patch, but it also applies to the
> existing code, so split it out to allow backporting to stable
> independently of the rest of the series.
> - Check the userspace values against the subleaf reported by the TDX
> module instead of rejecting the request when there is a mismatch.
>
> A simpler alternative would be to require a zero index when
> KVM_CPUID_FLAG_SIGNIFCANT_INDEX is cleared, but that would be an ABI
> change.
The even simpler change is to reject the incoming CPUID if userspace doesn't set
KVM_CPUID_FLAG_SIGNIFCANT_INDEX as expected. Yes, that's an ABI change. No, we
don't care. The rule isn't "never change the ABI", it's "don't break userspace",
and there's basically zero chance a TDX guest can function properly if userspace
doesn't set KVM_CPUID_FLAG_SIGNIFCANT_INDEX as appropriate.
diff --git arch/x86/kvm/vmx/tdx.c arch/x86/kvm/vmx/tdx.c
index 75a86d64892a..7e0d81066420 100644
--- arch/x86/kvm/vmx/tdx.c
+++ arch/x86/kvm/vmx/tdx.c
@@ -151,8 +151,12 @@ static void tdx_clear_unsupported_cpuid(struct kvm_cpuid_entry2 *entry)
clear_waitpkg(entry);
}
-static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry)
+static bool tdx_is_unsupported_cpuid_entry(const struct kvm_cpuid_entry2 *entry)
{
+ if (cpuid_function_is_indexed(entry->function) !=
+ !!(entry->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX))
+ return true;
+
return has_tsx(entry) || has_waitpkg(entry);
}
@@ -2386,7 +2390,7 @@ static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
if (!entry)
continue;
- if (tdx_unsupported_cpuid(entry))
+ if (tdx_is_unsupported_cpuid_entry(entry))
return -EINVAL;
copy_cnt++;
Can you test the attached patches? If they boot TDX with QEMU, I'll go ahead
and post.
[-- Attachment #2: 0001-x86-cpuid-Mark-CPUID-function-0x23-as-being-index.patch --]
[-- Type: text/x-diff, Size: 990 bytes --]
From 73ab6386bac6625333526ab6b137c445d22ab5db Mon Sep 17 00:00:00 2001
From: Sean Christopherson <seanjc@google.com>
Date: Thu, 15 Oct 2026 18:34:12 -0700
Subject: [PATCH 1/4] x86/cpuid: Mark CPUID function 0x23 as being index
Add function 0x23 to the set of CPUID functions that are index, as per the
SDM and the many sub-leafs defined in leaf_types.h.
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/include/asm/cpuid/api.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
index 82eddfa2347b..25b22b173f2a 100644
--- a/arch/x86/include/asm/cpuid/api.h
+++ b/arch/x86/include/asm/cpuid/api.h
@@ -181,6 +181,7 @@ static __always_inline bool cpuid_function_is_indexed(u32 function)
case 0x1d:
case 0x1e:
case 0x1f:
+ case 0x23:
case 0x24:
case 0x8000001d:
return true;
base-commit: dea4f6380f4ec96e8f3b0aaf2343764bd0d25ef4
--
2.56.0.176.g3575e65682-goog
[-- Attachment #3: 0002-KVM-TDX-Set-SIGNIFCANT_INDEX-flag-as-appropriate-whe.patch --]
[-- Type: text/x-diff, Size: 2148 bytes --]
From 90bd7cecc21de49fc30eda93de1d9f59d0c9a428 Mon Sep 17 00:00:00 2001
From: Changyuan Lyu <changyuanl@google.com>
Date: Thu, 15 Oct 2026 18:39:30 -0700
Subject: [PATCH 2/4] KVM: TDX: Set SIGNIFCANT_INDEX flag as appropriate when
filling CPUID entries
Set the KVM_CPUID_FLAG_SIGNIFCANT_INDEX flag in the kvm_cpuid_entry2
structures returned by KVM_TDX_CAPABILITIES if the CPUID is indexed,
otherwise KVM could confuse userspace and induce a configuration error.
This also ensures consistency with the CPUID entries returned by
KVM_GET_SUPPORTED_CPUID.
Fixes: 61bb28279623 ("KVM: TDX: Get system-wide info about TDX module on initialization")
Cc: stable@vger.kernel.org
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Changyuan Lyu <changyuanl@google.com>
[sean: keep the WARN, don't key off KVM_TDX_CPUID_NO_SUBLEAF]
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/vmx/tdx.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index ee1d412b0ee6..bcfecd2b1f31 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -2,6 +2,7 @@
#include <linux/cleanup.h>
#include <linux/cpu.h>
#include <asm/cpufeature.h>
+#include <asm/cpuid/api.h>
#include <asm/fpu/xcr.h>
#include <linux/misc_cgroup.h>
#include <linux/mmu_context.h>
@@ -163,11 +164,18 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
entry->function = (u32)td_conf->cpuid_config_leaves[idx];
entry->index = td_conf->cpuid_config_leaves[idx] >> 32;
+ entry->flags = 0;
entry->eax = (u32)td_conf->cpuid_config_values[idx][0];
entry->ebx = td_conf->cpuid_config_values[idx][0] >> 32;
entry->ecx = (u32)td_conf->cpuid_config_values[idx][1];
entry->edx = td_conf->cpuid_config_values[idx][1] >> 32;
+ if (cpuid_function_is_indexed(entry->function))
+ entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
+
+ WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=
+ (entry->index != KVM_TDX_CPUID_NO_SUBLEAF));
+
if (entry->index == KVM_TDX_CPUID_NO_SUBLEAF)
entry->index = 0;
--
2.56.0.176.g3575e65682-goog
[-- Attachment #4: 0003-KVM-TDX-Don-t-zero-non-significant-CPUID-entry-indic.patch --]
[-- Type: text/x-diff, Size: 1362 bytes --]
From c5cb713d03fa7cc41b999db8b014da6aa3d2a424 Mon Sep 17 00:00:00 2001
From: Sean Christopherson <seanjc@google.com>
Date: Thu, 15 Oct 2026 18:42:36 -0700
Subject: [PATCH 3/4] KVM: TDX: Don't zero non-significant CPUID entry indices
Now that KVM sets KVM_CPUID_FLAG_SIGNIFCANT_INDEX when filling CPUID
entries based on output from the TDX Module, don't zero the index for
entries without a signficant index, as doing so incorrectly suggests that
zero is somehow special, which it is not. The critical piece of info is
the SIGNIFCANT_INDEX flag, which tells KVM (and userspace) to simply ignore
the index.
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/vmx/tdx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index bcfecd2b1f31..75a86d64892a 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -176,9 +176,6 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
WARN_ON_ONCE(cpuid_function_is_indexed(entry->function) !=
(entry->index != KVM_TDX_CPUID_NO_SUBLEAF));
- if (entry->index == KVM_TDX_CPUID_NO_SUBLEAF)
- entry->index = 0;
-
/*
* The TDX module doesn't allow configuring the guest phys addr bits
* (EAX[23:16]). However, KVM uses it as an interface to the userspace
--
2.56.0.176.g3575e65682-goog
[-- Attachment #5: 0004-KVM-TDX-Reject-KVM_TDX_INIT_VM-if-indexed-CPUID-func.patch --]
[-- Type: text/x-diff, Size: 2662 bytes --]
From c38351fecf16d9bbb694f3a08127ab90ae64484b Mon Sep 17 00:00:00 2001
From: Sean Christopherson <seanjc@google.com>
Date: Fri, 16 Oct 2026 07:41:34 -0700
Subject: [PATCH 4/4] KVM: TDX: Reject KVM_TDX_INIT_VM if indexed CPUID
functions don't match
Reject KVM_TDX_INIT_VM if userspace doesn't configure the canonical CPUID
entries correctly with respect to KVM_CPUID_FLAG_SIGNIFCANT_INDEX to fix a
bug where userspace could bypass the TSX and WAITPKG checks by simply not
marking a CPUID.0x7 entry as being indexed. This also sets the stage for
more in-depth validation of the incoming CPUID configuration.
This is obviously an ABI change and diverges from KVM's general approach of
"let userspace do what it wants". In practice, no "real" VMM that supports
TDX misconfigures a TD's CPUID entries in this way, i.e. the probability of
actually breaking userspace is basically nil. And unlike normal VMs, where
KVM has full control and thus can deal with bizarre CPUID input without too
much fuss, TDX VMs require extra care due to the TDX Module also reacting
to the CPUID configuration, i.e. KVM_TDX_INIT_VM needs to be more strict
than KVM_SET_CPUID{,2} to avoid creating potentially dangerous-to-the-host
setups.
Opportunistically rename the helper to make it more obvious that it's
checking if the passed in @entry is unsupported, as opposed to returning a
set of unsupported entries or something.
Fixes: 6d415778f106 ("KVM: TDX: Disable support for TSX and WAITPKG")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/kvm/20260604024927.E22311F00893@smtp.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/vmx/tdx.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 75a86d64892a..7e0d81066420 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -151,8 +151,12 @@ static void tdx_clear_unsupported_cpuid(struct kvm_cpuid_entry2 *entry)
clear_waitpkg(entry);
}
-static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry)
+static bool tdx_is_unsupported_cpuid_entry(const struct kvm_cpuid_entry2 *entry)
{
+ if (cpuid_function_is_indexed(entry->function) !=
+ !!(entry->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX))
+ return true;
+
return has_tsx(entry) || has_waitpkg(entry);
}
@@ -2386,7 +2390,7 @@ static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
if (!entry)
continue;
- if (tdx_unsupported_cpuid(entry))
+ if (tdx_is_unsupported_cpuid_entry(entry))
return -EINVAL;
copy_cnt++;
--
2.56.0.176.g3575e65682-goog
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v5 1/5] KVM: TDX: Check unsupported CPUID bits against the TDX module's subleaf
2026-10-16 15:25 ` Sean Christopherson
@ 2026-10-16 22:15 ` Binbin Wu
0 siblings, 0 replies; 9+ messages in thread
From: Binbin Wu @ 2026-10-16 22:15 UTC (permalink / raw)
To: Sean Christopherson
Cc: linux-kernel, kvm, pbonzini, dave.hansen, andrew.cooper3,
nik.borisov, kas, rick.p.edgecombe, xiaoyao.li, chao.gao,
tony.lindgren, kishen.maloor, dedekind1, adrian.hunter
On 10/16/2026 11:25 PM, Sean Christopherson wrote:
> On Fri, Oct 16, 2026, Binbin Wu wrote:
>> Don't reject the mismatch outright, as the ABI allows userspace to provide
>> an arbitrary index when KVM_CPUID_FLAG_SIGNIFCANT_INDEX is cleared. It's
>> userspace's responsibility to provide the intended entries; KVM only needs
>> to ensure that the values it validates are the values it applies.
>>
>> Fixes: 6d415778f106 ("KVM: TDX: Disable support for TSX and WAITPKG")
>> Reported-by: Sashiko <sashiko-bot@kernel.org>
>> Closes: https://lore.kernel.org/kvm/20260604024927.E22311F00893@smtp.kernel.org
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
>> ---
>> v5:
>> - Split out from "KVM: TDX: Validate userspace CPUID input for
>> KVM_TDX_INIT_VM" as a standalone fix. Sashiko reported the issue
>> against the TDX CPUID validation patch, but it also applies to the
>> existing code, so split it out to allow backporting to stable
>> independently of the rest of the series.
>> - Check the userspace values against the subleaf reported by the TDX
>> module instead of rejecting the request when there is a mismatch.
>>
>> A simpler alternative would be to require a zero index when
>> KVM_CPUID_FLAG_SIGNIFCANT_INDEX is cleared, but that would be an ABI
>> change.
>
> The even simpler change is to reject the incoming CPUID if userspace doesn't set
> KVM_CPUID_FLAG_SIGNIFCANT_INDEX as expected. Yes, that's an ABI change. No, we
> don't care. The rule isn't "never change the ABI", it's "don't break userspace",
> and there's basically zero chance a TDX guest can function properly if userspace
> doesn't set KVM_CPUID_FLAG_SIGNIFCANT_INDEX as appropriate.
>
> diff --git arch/x86/kvm/vmx/tdx.c arch/x86/kvm/vmx/tdx.c
> index 75a86d64892a..7e0d81066420 100644
> --- arch/x86/kvm/vmx/tdx.c
> +++ arch/x86/kvm/vmx/tdx.c
> @@ -151,8 +151,12 @@ static void tdx_clear_unsupported_cpuid(struct kvm_cpuid_entry2 *entry)
> clear_waitpkg(entry);
> }
>
> -static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry)
> +static bool tdx_is_unsupported_cpuid_entry(const struct kvm_cpuid_entry2 *entry)
> {
> + if (cpuid_function_is_indexed(entry->function) !=
> + !!(entry->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX))
> + return true;
> +
> return has_tsx(entry) || has_waitpkg(entry);
> }
>
> @@ -2386,7 +2390,7 @@ static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
> if (!entry)
> continue;
>
> - if (tdx_unsupported_cpuid(entry))
> + if (tdx_is_unsupported_cpuid_entry(entry))
> return -EINVAL;
>
> copy_cnt++;
>
> Can you test the attached patches? If they boot TDX with QEMU, I'll go ahead
> and post.
Patch 3 "KVM: TDX: Don't zero non-significant CPUID entry indices" breaks QEMU.
QEMU uses zero as index for cpuid entries when index is not significant.
And in QEMU, the lookup function doesn't consult the flags at all.
struct kvm_cpuid_entry2 *cpuid_find_entry(struct kvm_cpuid2 *cpuid,
uint32_t function,
uint32_t index)
{
int i;
for (i = 0; i < cpuid->nent; ++i) {
if (cpuid->entries[i].function == function &&
cpuid->entries[i].index == index) {
return &cpuid->entries[i];
}
}
/* not found: */
return NULL;
}
If KVM doesn't zero the index for the non-significant, QEMU cannot find
any entry for non-significant entries returned by KVM_TDX_CAPABILITIES.
And 0x80000008 is used to pass GPAW, and KVM_TDX_INIT_VM fails when QEMU
doesn't pass it.
After dropping patch 3, QEMU can boot TD.
Also our internal TDX CI cases passed.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v5 2/5] KVM: TDX: Track configurable CPUID bits allowed by KVM
2026-10-16 9:14 [PATCH v5 0/5] KVM: TDX: Validate directly configurable CPUID bits Binbin Wu
2026-10-16 9:14 ` [PATCH v5 1/5] KVM: TDX: Check unsupported CPUID bits against the TDX module's subleaf Binbin Wu
@ 2026-10-16 9:14 ` Binbin Wu
2026-10-16 9:14 ` [PATCH v5 3/5] KVM: TDX: Add CORE_CAPABILITIES to the allowlist Binbin Wu
` (2 subsequent siblings)
4 siblings, 0 replies; 9+ messages in thread
From: Binbin Wu @ 2026-10-16 9:14 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: seanjc, pbonzini, dave.hansen, andrew.cooper3, nik.borisov, kas,
rick.p.edgecombe, xiaoyao.li, chao.gao, tony.lindgren,
kishen.maloor, dedekind1, adrian.hunter, binbin.wu
Add tdx_cpu_cfg_caps[] to track the subset of TDX directly configurable
CPUID feature bits that KVM supports, and initialize it during TDX
hardware setup.
The TDX module reports the CPUID bits that the VMM can directly configure
for a TD, but KVM can't blindly expose every reported bit to userspace.
Some features imply additional state, e.g. MSRs, that KVM must context
switch across host/guest transitions to avoid corrupting host state. The
existing hardcoded denylist can't account for such features introduced by
future TDX modules.
Aside from a few fixed-1 bits required for basic TDX support, features
that can clobber host state are either directly configurable or controlled
by TD ATTRIBUTES/XFAM, which KVM already validates. Thus, an allowlist
covering only the directly configurable bits is sufficient.
Organize tdx_cpu_cfg_caps[] like kvm_cpu_caps[] so that the allowlist can
be built with feature-name based initializers. Directly configurable bits
that aren't feature flags will be handled when building the per-register
masks for KVM_TDX_CAPABILITIES.
Sort the directly configurable CPUID feature bits into three categories:
1) Features that KVM supports and tracks in kvm_cpu_caps[]. Use
TDX_CFG_F() so that they are also capped by kvm_cpu_caps[].
2) Features that KVM supports, or can safely allow, but doesn't track in
kvm_cpu_caps[], i.e. MWAIT and HT. Use TDX_CFG_INDEPENDENT_F().
3) Features that are obsolete or unsupported by KVM, and thus excluded,
i.e. EST, TM2, CID, SDBG, XTPR, DCA, PN (PSN), ACPI, ACC (TM), PBE,
HLE, RTM, CQM (RDT_M), RDT_A, PREFETCHWT1, WAITPKG, TME, PCONFIG,
CORE_CAPABILITIES, RAO_INT, FRED, and AMX-TRANSPOSE.
Excluding the features in category 3 shouldn't break userspace, as
userspace is expected to consult KVM_TDX_CAPABILITIES for the configurable
bits before invoking KVM_TDX_INIT_VM. Nor should it break guests, as the
features are either obsolete or unsupported by KVM, and in the latter case,
a guest relying on them would already have run into problems.
CORE_CAPABILITIES is a special case; it will be allowed separately to
accommodate its legacy fixed-1 definition.
Future changes will use tdx_cpu_cfg_caps[] to filter KVM_TDX_CAPABILITIES
and to reject unsupported CPUID input to KVM_TDX_INIT_VM, so that directly
configurable bits introduced by future TDX modules are neither advertised
to nor configurable by userspace until KVM explicitly opts in.
Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
---
v5:
- Simplify the commit message for excluded bits. (Xiaoyao)
- Use TDX_CFG_INDEPENDENT_F() instead of TDX_CFG_EXTRA_F(). (Xiaoyao)
- Avoid using "patch" in the commit message. (Rick)
- Remove comments for host clobbering features KVM doesn't support yet.
(Xiaoyao)
- AMX_COMPLEX should be added for CPUID_7_1_EDX instead of CPUID_1E_1_EAX,
it was a wrong fix in v4 to add it for CPUID_1E_1_EAX.
- Exclude XTPR since TDX/KVM doesn't actually virtualize the feature and
guests don't need it.
- Move the TDX CPUID allowlist code next to the other CPUID helpers.
v4:
- Add XTPR and HT to the allowlist.
- Explain in the changelog why some directly configurable bits are not
added to the allowlist.
- Improve comments/changelog. (Xiaoyao)
- Fix the bug that AMX_COMPLEX should be added for CPUID_1E_1_EAX instead
of CPUID_7_1_EDX.
v3:
- Drop the new data structure in v2 and only track feature bits by
following the organization of kvm_cpu_caps[], handle non-feature
bits separately. (Sean)
- Use two versions of macros (TDX_CFG_F() vs. TDX_CFG_EXTRA_F()) to
distinguish whether a supported TDX configurable CPUID bit should be
checked against KVM's common cpu capabilities.
- Add AMX_COMPLEX since it has been defined in the CPUID virtualization doc.
---
arch/x86/kvm/vmx/tdx.c | 153 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 153 insertions(+)
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index ae7135784878..b6e096079655 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -57,6 +57,8 @@ bool enable_tdx __ro_after_init;
module_param_named(tdx, enable_tdx, bool, 0444);
static const struct tdx_sys_info *tdx_sysinfo;
+static u32 tdx_cpu_cfg_caps[NR_KVM_CPU_CAPS] __ro_after_init;
+static_assert(ARRAY_SIZE(tdx_cpu_cfg_caps) == ARRAY_SIZE(kvm_cpu_caps));
void tdh_vp_rd_failed(struct vcpu_tdx *tdx, char *uclass, u32 field, u64 err)
{
@@ -117,6 +119,155 @@ static u32 tdx_set_guest_phys_addr_bits(const u32 eax, int addr_bits)
return (eax & ~GENMASK(23, 16)) | (addr_bits & 0xff) << 16;
}
+#define TDX_VALIDATE_CPU_CAP_USAGE(name) \
+ BUILD_BUG_ON(__feature_leaf(X86_FEATURE_##name) != \
+ tdx_cpu_cap_init_in_progress)
+
+/* For features that are dependent on kvm_cpu_caps[]. */
+#define TDX_CFG_F(name) \
+({ \
+ TDX_VALIDATE_CPU_CAP_USAGE(name); \
+ tdx_cfg_caps |= feature_bit(name); \
+})
+
+/*
+ * For features that are not dependent on kvm_cpu_caps[], e.g. MWAIT.
+ * Use this version only when there is a justification.
+ */
+#define TDX_CFG_INDEPENDENT_F(name) \
+({ \
+ TDX_VALIDATE_CPU_CAP_USAGE(name); \
+ tdx_cfg_caps_independent |= feature_bit(name); \
+})
+
+#define tdx_cpu_cfg_cap_init(leaf, feature_initializers...) \
+do { \
+ const u32 __maybe_unused tdx_cpu_cap_init_in_progress = leaf; \
+ u32 tdx_cfg_caps_independent = 0; \
+ u32 tdx_cfg_caps = 0; \
+ \
+ feature_initializers \
+ tdx_cpu_cfg_caps[leaf] = (tdx_cfg_caps & kvm_cpu_caps[leaf]) | \
+ tdx_cfg_caps_independent; \
+} while (0)
+
+/*
+ * Initialize tdx_cpu_cfg_caps[], the list of CPUID features that KVM
+ * supports for TDX guests. It covers only the directly configurable CPUID
+ * bits reported by the TDX module; features controlled by XFAM and
+ * ATTRIBUTES are handled separately.
+ */
+static void __init tdx_initialize_cpu_cfg_caps(void)
+{
+ tdx_cpu_cfg_cap_init(CPUID_1_ECX,
+ /*
+ * KVM allows userspace to enumerate MONITOR+MWAIT support to
+ * the guest, but the MWAIT feature flag is never advertised
+ * to userspace for non-TDX VMs.
+ */
+ TDX_CFG_INDEPENDENT_F(MWAIT),
+ TDX_CFG_F(TSC_DEADLINE_TIMER),
+ TDX_CFG_F(AVX),
+ TDX_CFG_F(F16C),
+ );
+
+ tdx_cpu_cfg_cap_init(CPUID_1_EDX,
+ TDX_CFG_F(MCE),
+ TDX_CFG_F(MTRR),
+ TDX_CFG_F(MCA),
+ TDX_CFG_F(SELFSNOOP),
+ /*
+ * HT is a topology enumeration bit that KVM doesn't care
+ * about, but userspace may want to expose it to the guests.
+ */
+ TDX_CFG_INDEPENDENT_F(HT),
+ );
+
+ tdx_cpu_cfg_cap_init(CPUID_7_0_EBX,
+ TDX_CFG_F(BMI1),
+ TDX_CFG_F(BMI2),
+ TDX_CFG_F(ERMS),
+ TDX_CFG_F(AVX512F),
+ TDX_CFG_F(AVX512DQ),
+ TDX_CFG_F(ADX),
+ TDX_CFG_F(AVX512IFMA),
+ TDX_CFG_F(AVX512PF),
+ TDX_CFG_F(AVX512ER),
+ TDX_CFG_F(AVX512CD),
+ TDX_CFG_F(AVX512BW),
+ TDX_CFG_F(AVX512VL),
+ );
+
+ tdx_cpu_cfg_cap_init(CPUID_7_ECX,
+ TDX_CFG_F(UMIP),
+ TDX_CFG_F(AVX512_VBMI2),
+ TDX_CFG_F(GFNI),
+ TDX_CFG_F(VAES),
+ TDX_CFG_F(VPCLMULQDQ),
+ TDX_CFG_F(AVX512_VNNI),
+ TDX_CFG_F(AVX512_BITALG),
+ TDX_CFG_F(AVX512_VPOPCNTDQ),
+ TDX_CFG_F(LA57),
+ TDX_CFG_F(RDPID),
+ TDX_CFG_F(CLDEMOTE),
+ );
+
+ tdx_cpu_cfg_cap_init(CPUID_7_EDX,
+ TDX_CFG_F(AVX512_4VNNIW),
+ TDX_CFG_F(AVX512_4FMAPS),
+ TDX_CFG_F(FSRM),
+ TDX_CFG_F(AVX512_VP2INTERSECT),
+ TDX_CFG_F(SERIALIZE),
+ TDX_CFG_F(TSXLDTRK),
+ );
+
+ tdx_cpu_cfg_cap_init(CPUID_7_1_EAX,
+ TDX_CFG_F(SHA512),
+ TDX_CFG_F(SM3),
+ TDX_CFG_F(SM4),
+ TDX_CFG_F(AVX_VNNI),
+ TDX_CFG_F(AVX512_BF16),
+ TDX_CFG_F(CMPCCXADD),
+ TDX_CFG_F(FZRM),
+ TDX_CFG_F(FSRS),
+ TDX_CFG_F(FSRC),
+ TDX_CFG_F(LKGS),
+ TDX_CFG_F(WRMSRNS),
+ TDX_CFG_F(AMX_FP16),
+ TDX_CFG_F(AVX_IFMA),
+ TDX_CFG_F(LAM),
+ TDX_CFG_F(MOVRS),
+ );
+
+ tdx_cpu_cfg_cap_init(CPUID_7_1_EDX,
+ TDX_CFG_F(AVX_VNNI_INT8),
+ TDX_CFG_F(AVX_NE_CONVERT),
+ TDX_CFG_F(AMX_COMPLEX),
+ TDX_CFG_F(AVX_VNNI_INT16),
+ TDX_CFG_F(PREFETCHITI),
+ TDX_CFG_F(AVX10),
+ );
+
+ tdx_cpu_cfg_cap_init(CPUID_7_2_EDX,
+ TDX_CFG_F(DDPD_U),
+ TDX_CFG_F(MCDT_NO),
+ );
+
+ tdx_cpu_cfg_cap_init(CPUID_1E_1_EAX,
+ TDX_CFG_F(AMX_FP8),
+ TDX_CFG_F(AMX_TF32),
+ TDX_CFG_F(AMX_AVX512),
+ TDX_CFG_F(AMX_MOVRS),
+ );
+
+ tdx_cpu_cfg_cap_init(CPUID_8000_0008_EBX,
+ TDX_CFG_F(WBNOINVD),
+ );
+}
+
+#undef TDX_CFG_F
+#undef TDX_CFG_INDEPENDENT_F
+
#define TDX_FEATURE_TSX (__feature_bit(X86_FEATURE_HLE) | __feature_bit(X86_FEATURE_RTM))
static bool has_tsx(const struct kvm_cpuid_entry2 *entry, u32 index)
@@ -3529,6 +3680,8 @@ int __init tdx_hardware_setup(void)
return r;
}
+ tdx_initialize_cpu_cfg_caps();
+
KVM_SANITY_CHECK_VM_STRUCT_SIZE(kvm_tdx);
vt_x86_ops.vm_size = max_t(unsigned int, vt_x86_ops.vm_size, sizeof(struct kvm_tdx));
--
2.46.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH v5 3/5] KVM: TDX: Add CORE_CAPABILITIES to the allowlist
2026-10-16 9:14 [PATCH v5 0/5] KVM: TDX: Validate directly configurable CPUID bits Binbin Wu
2026-10-16 9:14 ` [PATCH v5 1/5] KVM: TDX: Check unsupported CPUID bits against the TDX module's subleaf Binbin Wu
2026-10-16 9:14 ` [PATCH v5 2/5] KVM: TDX: Track configurable CPUID bits allowed by KVM Binbin Wu
@ 2026-10-16 9:14 ` Binbin Wu
2026-10-16 9:14 ` [PATCH v5 4/5] KVM: TDX: Report only KVM-allowed CPUIDs in KVM_TDX_CAPABILITIES Binbin Wu
2026-10-16 9:14 ` [PATCH v5 5/5] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM Binbin Wu
4 siblings, 0 replies; 9+ messages in thread
From: Binbin Wu @ 2026-10-16 9:14 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: seanjc, pbonzini, dave.hansen, andrew.cooper3, nik.borisov, kas,
rick.p.edgecombe, xiaoyao.li, chao.gao, tony.lindgren,
kishen.maloor, dedekind1, adrian.hunter, binbin.wu
Add CORE_CAPABILITIES (CPUID.0x7.0.EDX[30]) to KVM's allowlist of TDX
directly configurable CPUID feature bits to accommodate the legacy TDX
module definition of the bit, even though KVM doesn't support
MSR_IA32_CORE_CAPS for TDs.
Older TDX module specs define CORE_CAPABILITIES as fixed-1, so userspace
may expect the bit to be set for TDs. The bit is redefined as directly
configurable due to #VE reduction. Leaving it out of the allowlist would
prevent userspace from setting it once KVM starts validating the CPUID
input to KVM_TDX_INIT_VM, which would be an unexpected behavior change for
such userspace.
Reporting CORE_CAPABILITIES as directly configurable also lets userspace
detect that the bit is no longer fixed-1, and thus update its stale
knowledge.
Keep MSR_IA32_CORE_CAPS unsupported for TDs, as no existing TDX user needs
guest access to the MSR.
Note, CORE_CAPABILITIES is the only bit that is both unsupported by KVM
*and* redefined from fixed-1 to directly configurable due to #VE
reduction, and no further #VE reductions are expected.
Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
---
v5:
- Clarify in the changelog that #VE reduction redefines the bit from
fixed-1 to directly configurable.
- Change the shortlog from "KVM: TDX: Report CORE_CAPABILITIES as
configurable" to "KVM: TDX: Add CORE_CAPABILITIES to the allowlist"
since the patch doesn't change the CPUID reporting behavior yet.
- Add RB from Xiaoyao.
v4:
- Add #VE reduction related background to the changelog. (Kishen)
- Add RB from Tony.
v3:
- Drop the code for MSR_IA32_CORE_CAPS access.
---
arch/x86/kvm/vmx/tdx.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index b6e096079655..13aaf7eb11b5 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -219,6 +219,13 @@ static void __init tdx_initialize_cpu_cfg_caps(void)
TDX_CFG_F(AVX512_VP2INTERSECT),
TDX_CFG_F(SERIALIZE),
TDX_CFG_F(TSXLDTRK),
+ /*
+ * KVM doesn't support MSR_IA32_CORE_CAPS, but older TDX module
+ * specs define this bit as fixed-1. Report it as configurable
+ * to accommodate the legacy TDX module definition, and to let
+ * userspace detect that the bit is no longer fixed-1.
+ */
+ TDX_CFG_INDEPENDENT_F(CORE_CAPABILITIES),
);
tdx_cpu_cfg_cap_init(CPUID_7_1_EAX,
--
2.46.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH v5 4/5] KVM: TDX: Report only KVM-allowed CPUIDs in KVM_TDX_CAPABILITIES
2026-10-16 9:14 [PATCH v5 0/5] KVM: TDX: Validate directly configurable CPUID bits Binbin Wu
` (2 preceding siblings ...)
2026-10-16 9:14 ` [PATCH v5 3/5] KVM: TDX: Add CORE_CAPABILITIES to the allowlist Binbin Wu
@ 2026-10-16 9:14 ` Binbin Wu
2026-10-16 9:14 ` [PATCH v5 5/5] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM Binbin Wu
4 siblings, 0 replies; 9+ messages in thread
From: Binbin Wu @ 2026-10-16 9:14 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: seanjc, pbonzini, dave.hansen, andrew.cooper3, nik.borisov, kas,
rick.p.edgecombe, xiaoyao.li, chao.gao, tony.lindgren,
kishen.maloor, dedekind1, adrian.hunter, binbin.wu
Filter the directly configurable CPUID bits reported through
KVM_TDX_CAPABILITIES against KVM's TDX allowlist, and drop the hardcoded
denylist-based filtering.
The TDX module reports the CPUID bits that the VMM can directly configure
for a TD, but KVM must not advertise bits that it doesn't support, as
blindly exposing a feature that clobbers host state can corrupt the host.
The existing denylist, which clears only TSX and WAITPKG, can't account
for such features introduced by future TDX modules.
Add tdx_get_cpuid_cfg_mask() to compute the mask of directly configurable
bits that KVM allows for a given CPUID register, and apply it to every
CPUID entry reported through KVM_TDX_CAPABILITIES. The mask combines
feature bits, taken from tdx_cpu_cfg_caps[], with non-feature bits, which
are identified by function, index, and register.
Treat CPUID.0x1.{EAX,EBX}, CPUID.{0x4,0x18,0x1F}, and CPUID.0x80000008.EAX
as fully allowed, as these registers enumerate non-feature information,
e.g. family/model/stepping, brand index, CLFLUSH line size, APIC ID,
cache/TLB/topology properties, and address sizes. Allow the reserved bits
in them as well. Though there's no architectural guarantee, given what
these registers enumerate, the reserved bits are expected to be used to
extend the existing information rather than to enumerate new features.
Also allow CPUID.0x24.0.EBX[7:0] (AVX10 version), which the TDX module
reports as directly configurable when AVX10 is supported, even though the
CPUID virtualization table in the "Intel TDX ABI Definitions" currently
lists it as not configurable. The table is expected to be corrected.
As a result, directly configurable bits that aren't in the allowlist,
including bits introduced by future TDX modules, aren't advertised to
userspace until KVM explicitly opts in.
Note, the change is user-visible, as some bits that were previously
reported as configurable no longer are. The ABI itself is unchanged: KVM
already filtered unsupported CPUID bits out of KVM_TDX_CAPABILITIES, albeit
via a denylist, and the set of configurable bits already varies with the
TDX module and KVM versions.
The change isn't expected to break userspace or guests:
- Userspace that honors KVM_TDX_CAPABILITIES simply stops setting the
dropped bits, and KVM_TDX_INIT_VM still succeeds.
- CORE_CAPABILITIES, which older TDX module specs defined as fixed-1, is
still allowed.
- The dropped features are either obsolete or unsupported by KVM, and in
the latter case, a guest relying on them would already have run into
problems.
Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
---
v5:
- Change the shortlog to make the change more clear.
- Update the changelog to call out the user-visible change more loudly.
(Rick)
- Describe CPUID.0x24.0.EBX[7:0] in the changelog rather than in a code
comment, since the comment would become stale once the spec is updated.
- Update the changelog/comments for the CPUIDs that are expected not to be
repurposed to hold feature bits according to their definitions.
- Drop the note in the TDX document as the ABI itself is unchanged.
v4:
- Rename functions. (Tony)
tdx_cfg_non_feature_mask() -> tdx_get_cpuid_cfg_non_feature_mask()
tdx_cfg_feature_mask() -> tdx_get_cpuid_cfg_feature_mask()
tdx_get_allowed_cfg_cpuid_mask() -> tdx_get_cpuid_cfg_mask()
- Update documentation. (Xiaoyao, Rick)
v3:
- Handle non-feature leafs at runtime. (Sean)
- Add CPUID.0x24.0.EBX[7:0] into allowlist. There is a mismatch of the
description about CPUID.0x24.0.EBX[7:0], which is listed as
"XFAM & CPUID_Enabled & Native" but should be "XFAM & CPUID_Enabled &
Configured & Native".
---
arch/x86/kvm/vmx/tdx.c | 95 ++++++++++++++++++++++++++++++++----------
1 file changed, 72 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 13aaf7eb11b5..d617d1a0f63b 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -283,36 +283,81 @@ static bool has_tsx(const struct kvm_cpuid_entry2 *entry, u32 index)
(entry->ebx & TDX_FEATURE_TSX);
}
-static void clear_tsx(struct kvm_cpuid_entry2 *entry)
-{
- entry->ebx &= ~TDX_FEATURE_TSX;
-}
-
static bool has_waitpkg(const struct kvm_cpuid_entry2 *entry, u32 index)
{
return entry->function == 7 && index == 0 &&
(entry->ecx & __feature_bit(X86_FEATURE_WAITPKG));
}
-static void clear_waitpkg(struct kvm_cpuid_entry2 *entry)
-{
- entry->ecx &= ~__feature_bit(X86_FEATURE_WAITPKG);
-}
-
-static void tdx_clear_unsupported_cpuid(struct kvm_cpuid_entry2 *entry)
-{
- if (has_tsx(entry, entry->index))
- clear_tsx(entry);
-
- if (has_waitpkg(entry, entry->index))
- clear_waitpkg(entry);
-}
-
static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry, u32 index)
{
return has_tsx(entry, index) || has_waitpkg(entry, index);
}
+#define TDX_CPUID_ALL_ALLOWED_MASK GENMASK_U32(31, 0)
+
+static u32 tdx_get_cpuid_cfg_non_feature_mask(u32 function, u32 index, int reg)
+{
+ /*
+ * Allow all bits in registers that enumerate non-feature information.
+ * Note, CPUID.0x1.EAX, CPUID.{0x4, 0x18, 0x1f} and CPUID.0x80000008.EAX
+ * contain reserved bits. Though not architecturally guaranteed, the
+ * reserved bits are expected to be used to extend the existing
+ * information rather than to enumerate features, so allow them too.
+ */
+ switch (function) {
+ case 0x1:
+ if (reg == CPUID_EAX || reg == CPUID_EBX)
+ return TDX_CPUID_ALL_ALLOWED_MASK;
+ return 0;
+ case 0x4:
+ case 0x18:
+ case 0x1f:
+ return TDX_CPUID_ALL_ALLOWED_MASK;
+ case 0x24:
+ if (index == 0 && reg == CPUID_EBX)
+ return GENMASK_U32(7, 0);
+ return 0;
+ case 0x80000008:
+ if (reg == CPUID_EAX)
+ return TDX_CPUID_ALL_ALLOWED_MASK;
+ return 0;
+ default:
+ return 0;
+ }
+}
+
+static u32 tdx_get_cpuid_cfg_feature_mask(u32 function, u32 index, int reg)
+{
+ for (int i = 0; i < NR_KVM_CPU_CAPS; i++) {
+ const struct cpuid_reg *cpuid = &reverse_cpuid[i];
+
+ if (!cpuid->function)
+ continue;
+
+ if (cpuid->function == function && cpuid->index == index &&
+ cpuid->reg == reg)
+ return tdx_cpu_cfg_caps[i];
+ }
+
+ return 0;
+}
+
+static u32 tdx_get_cpuid_cfg_mask(u32 function, u32 index, int reg)
+{
+ u32 non_feature_mask = tdx_get_cpuid_cfg_non_feature_mask(function, index, reg);
+
+ /* Skip reverse_cpuid[] walk if it's already all allowed. */
+ if (non_feature_mask == TDX_CPUID_ALL_ALLOWED_MASK)
+ return TDX_CPUID_ALL_ALLOWED_MASK;
+
+ /*
+ * It's possible that a CPUID register contains both feature and
+ * non-feature bits.
+ */
+ return non_feature_mask | tdx_get_cpuid_cfg_feature_mask(function, index, reg);
+}
+
#define KVM_TDX_CPUID_NO_SUBLEAF ((__u32)-1)
static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char idx)
@@ -336,8 +381,6 @@ static void td_init_cpuid_entry2(struct kvm_cpuid_entry2 *entry, unsigned char i
*/
if (entry->function == 0x80000008)
entry->eax = tdx_set_guest_phys_addr_bits(entry->eax, 0xff);
-
- tdx_clear_unsupported_cpuid(entry);
}
#define TDVMCALLINFO_SETUP_EVENT_NOTIFY_INTERRUPT BIT(1)
@@ -360,8 +403,16 @@ static int init_kvm_tdx_caps(const struct tdx_sys_info_td_conf *td_conf,
caps->user_tdvmcallinfo_1_r11 =
TDVMCALLINFO_SETUP_EVENT_NOTIFY_INTERRUPT;
- for (i = 0; i < td_conf->num_cpuid_config; i++)
- td_init_cpuid_entry2(&caps->cpuid.entries[i], i);
+ for (i = 0; i < td_conf->num_cpuid_config; i++) {
+ struct kvm_cpuid_entry2 *e = &caps->cpuid.entries[i];
+
+ td_init_cpuid_entry2(e, i);
+ /* Only report the configurable bits allowed by KVM. */
+ e->eax &= tdx_get_cpuid_cfg_mask(e->function, e->index, CPUID_EAX);
+ e->ebx &= tdx_get_cpuid_cfg_mask(e->function, e->index, CPUID_EBX);
+ e->ecx &= tdx_get_cpuid_cfg_mask(e->function, e->index, CPUID_ECX);
+ e->edx &= tdx_get_cpuid_cfg_mask(e->function, e->index, CPUID_EDX);
+ }
return 0;
}
--
2.46.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH v5 5/5] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM
2026-10-16 9:14 [PATCH v5 0/5] KVM: TDX: Validate directly configurable CPUID bits Binbin Wu
` (3 preceding siblings ...)
2026-10-16 9:14 ` [PATCH v5 4/5] KVM: TDX: Report only KVM-allowed CPUIDs in KVM_TDX_CAPABILITIES Binbin Wu
@ 2026-10-16 9:14 ` Binbin Wu
2026-10-16 9:24 ` sashiko-bot
4 siblings, 1 reply; 9+ messages in thread
From: Binbin Wu @ 2026-10-16 9:14 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: seanjc, pbonzini, dave.hansen, andrew.cooper3, nik.borisov, kas,
rick.p.edgecombe, xiaoyao.li, chao.gao, tony.lindgren,
kishen.maloor, dedekind1, adrian.hunter, binbin.wu
Validate the CPUID configuration provided by userspace through
KVM_TDX_INIT_VM against KVM's TDX allowlist, and drop the hardcoded
denylist-based check.
The TDX module lets the VMM directly configure certain CPUID bits for a TD
at initialization time, but KVM must strictly govern which of those bits
userspace can set, otherwise a feature that clobbers host state could be
enabled behind KVM's back. The existing denylist rejects only TSX and
WAITPKG, and thus would accept any bit that a future TDX module makes
configurable, even if KVM knows nothing about the associated feature.
Add tdx_has_unsupported_cpuid_cfg_bit() and reject KVM_TDX_INIT_VM if
userspace sets any bit outside of the mask returned by
tdx_get_cpuid_cfg_mask(), i.e. the same mask used to filter
KVM_TDX_CAPABILITIES. Don't bother intersecting the userspace input with
the bits that the TDX module reports as directly configurable, as the TDX
module itself rejects any bit outside that set.
As with the existing check, use the subleaf reported by the TDX module to
look up the allowed mask. For leaves without subleaves, the TDX module's
"no subleaf" index is normalized to 0, which matches how such leaves are
tracked in reverse_cpuid[].
Note, the change is user-visible, as KVM_TDX_INIT_VM now rejects some
input that was previously accepted. The ABI itself is unchanged: KVM
already rejected unsupported CPUID bits, albeit via a denylist, and
userspace has always been required to consult KVM_TDX_CAPABILITIES and set
only the bits reported as configurable.
The change isn't expected to break userspace or guests:
- The newly rejected bits are no longer reported as configurable by
KVM_TDX_CAPABILITIES, so userspace that honors KVM_TDX_CAPABILITIES
won't set them.
- CORE_CAPABILITIES, which older TDX module specs defined as fixed-1, is
still allowed.
- The dropped features are either obsolete or unsupported by KVM, and in
the latter case, a guest relying on them would already have run into
problems.
Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
---
v5:
- Update the changelog and call out the user-visible change more loudly.
(Rick)
- Drop the description in TDX document and the uapi header, as the ABI
itself is unchanged.
- Split the CPUID entry index check out to a separate fix patch.
v4:
- Update the comments/documentation.
- Collect RB tag from Tony.
v3:
- Check CPUID entry index mismatch b/t userspace input and TDX sysinfo
configuration. (Sashiko)
- No need to mask the userspace input with TDX module reported directly
configurable bits first, since the userspace input should be subset of
directly configurable bits. Otherwise, the input will be rejected by
the TDX module.
---
arch/x86/kvm/vmx/tdx.c | 29 +++++++++--------------------
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index d617d1a0f63b..78ff0170411b 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -275,25 +275,6 @@ static void __init tdx_initialize_cpu_cfg_caps(void)
#undef TDX_CFG_F
#undef TDX_CFG_INDEPENDENT_F
-#define TDX_FEATURE_TSX (__feature_bit(X86_FEATURE_HLE) | __feature_bit(X86_FEATURE_RTM))
-
-static bool has_tsx(const struct kvm_cpuid_entry2 *entry, u32 index)
-{
- return entry->function == 7 && index == 0 &&
- (entry->ebx & TDX_FEATURE_TSX);
-}
-
-static bool has_waitpkg(const struct kvm_cpuid_entry2 *entry, u32 index)
-{
- return entry->function == 7 && index == 0 &&
- (entry->ecx & __feature_bit(X86_FEATURE_WAITPKG));
-}
-
-static bool tdx_unsupported_cpuid(const struct kvm_cpuid_entry2 *entry, u32 index)
-{
- return has_tsx(entry, index) || has_waitpkg(entry, index);
-}
-
#define TDX_CPUID_ALL_ALLOWED_MASK GENMASK_U32(31, 0)
static u32 tdx_get_cpuid_cfg_non_feature_mask(u32 function, u32 index, int reg)
@@ -2565,6 +2546,14 @@ static int setup_tdparams_eptp_controls(struct kvm_cpuid2 *cpuid,
return 0;
}
+static bool tdx_has_unsupported_cpuid_cfg_bit(const struct kvm_cpuid_entry2 *e, u32 index)
+{
+ return (e->eax & ~tdx_get_cpuid_cfg_mask(e->function, index, CPUID_EAX)) ||
+ (e->ebx & ~tdx_get_cpuid_cfg_mask(e->function, index, CPUID_EBX)) ||
+ (e->ecx & ~tdx_get_cpuid_cfg_mask(e->function, index, CPUID_ECX)) ||
+ (e->edx & ~tdx_get_cpuid_cfg_mask(e->function, index, CPUID_EDX));
+}
+
static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
struct td_params *td_params)
{
@@ -2594,7 +2583,7 @@ static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
* not the index of the userspace entry, which may differ if
* KVM_CPUID_FLAG_SIGNIFCANT_INDEX isn't set.
*/
- if (tdx_unsupported_cpuid(entry, tmp.index))
+ if (tdx_has_unsupported_cpuid_cfg_bit(entry, tmp.index))
return -EINVAL;
copy_cnt++;
--
2.46.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v5 5/5] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM
2026-10-16 9:14 ` [PATCH v5 5/5] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM Binbin Wu
@ 2026-10-16 9:24 ` sashiko-bot
0 siblings, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-10-16 9:24 UTC (permalink / raw)
To: Binbin Wu, kvm
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] kvm: KVM_TDX_INIT_VM rejects CPUID.0x7.0.EAX breaking guest subleaf enumeration
- [High] mm: heap buffer overflow in setup_tdparams_cpuids() via unbounded td_conf->num_cpuid_config
--
commit 8ec54e6006917e96837000de9e4002c7f4499444
Author: Binbin Wu <binbin.wu@linux.intel.com>
KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM
This commit validates the CPUID configuration provided by userspace
through KVM_TDX_INIT_VM against KVM's TDX allowlist. It drops the
hardcoded denylist-based check in favor of a strict allowlist.
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index e53f1e98bb04a..80c6519c13ff5 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
[ ... ]
> @@ -2567,6 +2548,14 @@ static int setup_tdparams_eptp_controls(struct kvm_cpuid2 *cpuid,
> return 0;
> }
>
> +static bool tdx_has_unsupported_cpuid_cfg_bit(const struct kvm_cpuid_entry2 *e, u32 index)
> +{
> + return (e->eax & ~tdx_get_cpuid_cfg_mask(e->function, index, CPUID_EAX)) ||
> + (e->ebx & ~tdx_get_cpuid_cfg_mask(e->function, index, CPUID_EBX)) ||
> + (e->ecx & ~tdx_get_cpuid_cfg_mask(e->function, index, CPUID_ECX)) ||
> + (e->edx & ~tdx_get_cpuid_cfg_mask(e->function, index, CPUID_EDX));
> +}
[Severity: High]
Does this strict allowlist check inadvertently break guest subleaf enumeration
by rejecting valid KVM_TDX_INIT_VM inputs?
CPUID leaf 0x7 subleaf 0 EAX contains the maximum supported subleaf index,
which is non-feature information. However, tdx_get_cpuid_cfg_non_feature_mask()
completely omits leaf 0x7, and reverse_cpuid does not track 0x7.0.EAX as a
feature word.
Because tdx_get_cpuid_cfg_mask(0x7, 0, CPUID_EAX) returns 0, this new check
will reject any non-zero value for CPUID.0x7.0.EAX. This strictly requires
userspace to provide 0, effectively preventing exposure of subleaves 1+
(such as for AMX or AVX-VNNI) and breaking valid VM initialization requests.
> static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
> struct td_params *td_params)
> {
[ ... ]
> @@ -2596,7 +2585,7 @@ static int setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
> * not the index of the userspace entry, which may differ if
> * KVM_CPUID_FLAG_SIGNIFCANT_INDEX isn't set.
> */
> - if (tdx_unsupported_cpuid(entry, tmp.index))
> + if (tdx_has_unsupported_cpuid_cfg_bit(entry, tmp.index))
> return -EINVAL;
>
> copy_cnt++;
[Severity: High]
Can the loop enclosing this code write past the end of the td_params heap
allocation?
td_conf->num_cpuid_config is read from the TDX module and bounded to 128
by KVM in get_tdx_sys_info_td_conf():
if (sysinfo_td_conf->num_cpuid_config > ARRAY_SIZE(sysinfo_td_conf->cpuid_config_leaves))
return -EINVAL;
However, td_params->cpuid_values is an array inside a union with
u8 reserved3[768], which limits it to 48 tdx_cpuid_value structures:
arch/x86/kvm/vmx/tdx_arch.h:struct td_params {
...
union {
DECLARE_FLEX_ARRAY(struct tdx_cpuid_value, cpuid_values);
u8 reserved3[768];
};
} __packed __aligned(1024);
td_params itself is dynamically allocated as a fixed 1024-byte object via
kzalloc_obj(struct td_params) in setup_tdparams().
If the hardware returns a num_cpuid_config value greater than 48, the loop
in setup_tdparams_cpuids() will exceed the 48-element capacity when assigning
value = &td_params->cpuid_values[i] just below this snippet, causing a heap
buffer overflow.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261016091422.3182216-1-binbin.wu@linux.intel.com?part=5
^ permalink raw reply [flat|nested] 9+ messages in thread