xen/arch/x86/hvm/vmx/vmx.c | 2 ++ xen/arch/x86/hvm/vmx/vvmx.c | 2 ++ xen/arch/x86/include/asm/hvm/vmx/vmx.h | 2 ++ xen/arch/x86/include/asm/perfc_defn.h | 2 +- 4 files changed, 7 insertions(+), 1 deletion(-)
On hardware that supports TDX, guests can cause VMEXIT related to
TDX instructions (SEAMCALL and TDCALL) regardless of VMCS configuration.
Currently, that causes the domain to crash when a domain tries to
use these instructions in kernel-mode, and emit #UD when used in user-mode.
Adjust the behavior so that the guest always gets #UD when trying to
use these instructions regardless of the privilege level that the vCPU
is running.
In the nested virtualization case, also reinject the exit reason to L1
rather than failing on "Unhandled nested vmexit" (leading to a L1 crash
that can be caused by L2 by executing one of the TDX instructions).
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
v2:
- Merge both patches.
- Always #UD on these VMEXIT in the non nested case
xen/arch/x86/hvm/vmx/vmx.c | 2 ++
xen/arch/x86/hvm/vmx/vvmx.c | 2 ++
xen/arch/x86/include/asm/hvm/vmx/vmx.h | 2 ++
xen/arch/x86/include/asm/perfc_defn.h | 2 +-
4 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e55c90ce7f..98ec999cb8 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -4681,6 +4681,8 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs)
case EXIT_REASON_MWAIT_INSTRUCTION:
case EXIT_REASON_MONITOR_INSTRUCTION:
case EXIT_REASON_GETSEC:
+ case EXIT_REASON_SEAMCALL:
+ case EXIT_REASON_TDCALL:
/*
* We should never exit on GETSEC because CR4.SMXE is always 0 when
* running in guest context, and the CPU checks that before getting
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index a5aa5eb163..8ef6529e26 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2497,6 +2497,8 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
case EXIT_REASON_INVEPT:
case EXIT_REASON_XSETBV:
case EXIT_REASON_INVVPID:
+ case EXIT_REASON_SEAMCALL:
+ case EXIT_REASON_TDCALL:
/* inject to L1 */
nvcpu->nv_vmexit_pending = 1;
break;
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index da04752e17..b8219e0408 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -201,6 +201,8 @@ static inline void pi_clear_sn(struct pi_desc *pi_desc)
#define EXIT_REASON_XRSTORS 64
#define EXIT_REASON_BUS_LOCK 74
#define EXIT_REASON_NOTIFY 75
+#define EXIT_REASON_SEAMCALL 76
+#define EXIT_REASON_TDCALL 77
/* Remember to also update VMX_PERF_EXIT_REASON_SIZE! */
/*
diff --git a/xen/arch/x86/include/asm/perfc_defn.h b/xen/arch/x86/include/asm/perfc_defn.h
index ac7439b992..102b9be6ef 100644
--- a/xen/arch/x86/include/asm/perfc_defn.h
+++ b/xen/arch/x86/include/asm/perfc_defn.h
@@ -6,7 +6,7 @@ PERFCOUNTER_ARRAY(exceptions, "exceptions", 32)
#ifdef CONFIG_HVM
-#define VMX_PERF_EXIT_REASON_SIZE 76
+#define VMX_PERF_EXIT_REASON_SIZE 78
#define VMEXIT_NPF_PERFC 166
#define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1)
PERFCOUNTER_ARRAY(vmexits, "vmexits",
--
2.55.0
--
Teddy Astie | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.techOn 10.09.2026 16:17, Teddy Astie wrote: > On hardware that supports TDX, guests can cause VMEXIT related to > TDX instructions (SEAMCALL and TDCALL) regardless of VMCS configuration. > > Currently, that causes the domain to crash when a domain tries to > use these instructions in kernel-mode, and emit #UD when used in user-mode. > > Adjust the behavior so that the guest always gets #UD when trying to > use these instructions regardless of the privilege level that the vCPU > is running. > > In the nested virtualization case, also reinject the exit reason to L1 > rather than failing on "Unhandled nested vmexit" (leading to a L1 crash > that can be caused by L2 by executing one of the TDX instructions). > > Signed-off-by: Teddy Astie <teddy.astie@vates.tech> Acked-by: Jan Beulich <jbeulich@suse.com>
On 10.09.2026 16:17, Teddy Astie wrote: > On hardware that supports TDX, guests can cause VMEXIT related to > TDX instructions (SEAMCALL and TDCALL) regardless of VMCS configuration. Can they? SEAMCALL pseudocode has ELSIF IA32_SEAMRR_MASK.VALID = 0 or events blocked by MOV SS THEN #GP(0); ELSIF SEAM is globally disabled THEN VMFailInvalid; For TDCALL I see IF not in SEAM non-root operation and not in VMX non-root operation THEN #UD; which may indeed not be sufficient, but the SEAMCALL conditions shouldn't be met under present Xen? Jan
Le 21/09/2026 à 13:07, Jan Beulich a écrit : > On 10.09.2026 16:17, Teddy Astie wrote: >> On hardware that supports TDX, guests can cause VMEXIT related to >> TDX instructions (SEAMCALL and TDCALL) regardless of VMCS configuration. > > Can they? SEAMCALL pseudocode has > > ELSIF IA32_SEAMRR_MASK.VALID = 0 or events blocked by MOV SS > THEN #GP(0); > ELSIF SEAM is globally disabled > THEN VMFailInvalid; > Earlier in the if chain, there is ELSIF in VMX non-root operation THEN VM exit; When running inside the guest, we're effectively in VMX non-root mode, which would trigger the VMEXIT. This issue is documented in a dedicated Intel advisory [1] (there is also microcode bug CVE-2024-22374 which makes it triggerable from guest userland). [1] https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel_tdx_joint_security_review_with_microsoft.pdf (Vulnerability 6) > For TDCALL I see > > IF not in SEAM non-root operation and not in VMX non-root operation > THEN #UD; > > which may indeed not be sufficient, but the SEAMCALL conditions shouldn't > be met under present Xen? > TDCALL probably don't need it, but I don't think this is wrong to treat it similarly (like KVM does [2]). > Jan [2] https://lore.kernel.org/all/20251016182148.69085-2-seanjc@google.com/
© 2016 - 2026 Red Hat, Inc.