Intel TDX: Confidential VM Architecture
- Intel TDX is a VM-based confidential computing technology that creates hardware-isolated Trust Domains with encrypted memory and remote attestation.
- Its architecture leverages Intel Virtual Machine Extensions and multi-key total memory encryption to protect legacy applications without requiring major code changes.
- TDX presents a trade-off between operational compatibility and granular isolation, offering strong performance on memory- and I/O-intensive workloads while exposing vulnerabilities in interrupt mediation and device interfaces.
Searching arXiv for recent TDX papers to ground the article. arXiv search query: Intel Trust Domain Extensions TDX confidential VMs attestation migration interrupt confidential containers Kubernetes replication LLM
Intel Trust Domain Extensions (TDX) is Intel’s VM-based confidential-computing architecture for creating hardware-isolated virtual machines called Trust Domains (TDs), with encrypted memory, protected virtual CPU state, integrity protection, and remote attestation. In recent literature, TDX is consistently placed within the transition from process-based TEEs such as Intel SGX toward VM-based confidential VMs designed for legacy software and cloud workloads. Its distinguishing objective is to protect data in use at the virtual-machine boundary, so that existing guest operating systems and applications can be deployed in untrusted cloud infrastructure with minimal or no code changes, rather than being restructured into enclave-aware processes (Cheng et al., 2023, Coppolino et al., 2024).
1. Position in the evolution of trusted execution environments
The comparative literature presents TDX as Intel’s answer to a deployment problem that SGX never fully resolved. SGX offered process-based protection by isolating selected code and data inside enclaves, but this came with constrained enclave memory, enclave refactoring, system-call restrictions, and substantial porting complexity. Runtimes such as Gramine-SGX and Occlum-SGX reduced some of that burden through LibOS-style mediation, yet they also enlarged the trusted computing base and introduced additional overheads related to enclave exits and host interaction. AMD SEV then changed the deployment model by protecting an entire virtual machine with hardware-managed memory encryption, enabling “lift-and-shift” migration of legacy applications. TDX is framed as Intel’s adoption of that VM-based model, with the same basic aim of confidential execution for unmodified workloads (Coppolino et al., 2024).
This positioning has an explicit security consequence in the surveyed papers. Process-based TEEs are described as having a stronger trust model because they shrink the trusted boundary more aggressively, whereas VM-based TEEs such as TDX and SEV protect a larger isolation unit and therefore offer weaker protection in exchange for substantially better usability and compatibility. The literature does not treat TDX as a replacement for SGX in every setting; rather, it treats TDX as a different architectural point in the confidentiality–deployability trade space, especially attractive when operational transparency for legacy software is the dominant constraint (Coppolino et al., 2024).
2. Architectural organization of Trust Domains
At the architectural level, TDX is described as a confidential-VM system built from Intel Virtual Machine Extensions, multi-key total memory encryption, and an Intel-signed TDX Module running in Secure-Arbitration Mode (SEAM). A protected guest is a Trust Domain. The hypervisor remains responsible for ordinary virtualization tasks, but security-sensitive TD lifecycle and state transitions are mediated by the TDX Module through host-side TDH.* interfaces and guest-side TDG.* interfaces. The core protected structures include the Trust Domain Root (TDR), the Trust Domain Control Structure (TDCS), the Trust Domain Virtual Processor State (TDVPS), the Secure Extended Page Table (SEPT), and the Physical Address Metadata Table (PAMT) (Cheng et al., 2023).
The memory model is central. TDX uses MKTME with per-TD private HKIDs, and the key never leaves the processor. The literature describes private memory as plaintext only within the processor package, with encryption applied at cache-line granularity. TDX also introduces integrity mechanisms. “Logical Integrity” uses the TD Owner bit to detect unauthorized software-level writes, while “Cryptographic Integrity” adds a MAC to detect direct physical tampering or bit flips. The same overview emphasizes that TDX aims to exclude firmware, software, devices, and cloud platform operators from the TCB for TD protection, while preserving confidentiality and integrity of TD memory and CPU state (Cheng et al., 2023, Coppolino et al., 2024).
The threat model is nonetheless bounded. TDX is repeatedly described as protecting against memory snooping, malicious or compromised host software, and some physical-memory attacks, including offline DRAM analysis and active attacks on DRAM interfaces. At the same time, the 2024 benchmarking study explicitly states that TDX does not defend against replay of memory content through physical attacks. The top-down architectural analysis also excludes availability, side-channel attacks, and fault injection from the TDX 1.0 threat model, and stresses that shared memory used for I/O lies outside TDX confidentiality and integrity guarantees (Coppolino et al., 2024, Cheng et al., 2023).
3. Measurement, attestation, and the scope of what TDX proves
TDX attestation is based on build-time and runtime measurement registers. The architectural survey defines MRTD as the build-time measurement register and RTMR[0..3] as the runtime measurement registers, with runtime extension performed by
via TDCALL[TDG.MR.RTMR.EXTEND] (Cheng et al., 2023).
Remote attestation follows a local-report-plus-quote model. A TD generates a local report, and a Quoting Enclave signs it so that a remote verifier can validate the result under Intel’s certificate chain. The same literature notes that TDX leverages SGX enclaves internally to bootstrap remote attestation. In practical systems, the verifier checks the quote signature, certificate chain, revocation status, TCB state, and expected measurements, then compares MRTD and RTMRs against reference values before releasing secrets or accepting a secure channel (Cheng et al., 2023, Li et al., 25 Mar 2026).
A recurrent theme across later papers is that TDX attestation proves a measured execution environment, not semantic correctness. The replication-framework paper is explicit that TEE attestation provides the same guarantee that a data editor currently provides—namely, that the submitted code runs and reproduces reported outputs in an attested environment—but does not verify that the code faithfully implements the methodology described in the paper. The same paper also notes unresolved nomenclature around Intel attestation infrastructure, because it refers both to “Intel DCAP / IAS” and to “Intel Attestation Service (IAS) logs” without resolving the distinction rigorously (Li et al., 25 Mar 2026).
More recent systems extend TDX attestation upward. Arca binds TDX ReportData to application identity through
so that verification covers not only the TD measurement but also the application public key, freshness nonce, and image identity (Lu et al., 3 Jan 2026). At Kubernetes scope, dstack-capsule uses TDX runtime measurements for static platform trust and the TDX quote report field for dynamic Pod identity, with RTMR[3] frozen after an irreversible “privilege fuse” and the report field carrying a SHA-256 binding over user_report_data, pod_uid, pod_spec_hash, and workload_id. That paper reports that RTMR[3] remained byte-identical across deployment of 20 Pods post-fuse, indicating that dynamic Pod churn was excluded from the static TDX measurement chain (Yang et al., 2 Jun 2026).
4. Empirical performance and deployment trade-offs
The most detailed comparative performance study in the supplied corpus benchmarks TDX against native execution, AMD SEV, Gramine-SGX, and Occlum-SGX on a research-access Intel Xeon Platinum 8480C TDX server. The evaluation is notable because TDX was not publicly available at the time of writing; stable Linux kernel support was still lacking, and the software stack depended on patched Linux, QEMU, and libvirt. The benchmark suite covered TensorFlow and PyTorch for CPU-intensive workloads, Redis and Vault for memory-intensive workloads, and NGINX and NodeJS for I/O-intensive workloads, with each experiment repeated 10 times to reach a 95% confidence interval target (Coppolino et al., 2024).
The reported results portray TDX as strongest on memory-intensive workloads and generally favorable on I/O-intensive workloads relative to other transparent TEE approaches. In Redis, TDX had “surprisingly the highest throughput,” with latency comparable to native. In Vault, TDX again delivered the highest throughput. In NGINX, native remained best, but TDX outperformed the SGX runtime approaches; the paper reports an average overhead of TDX with respect to native of , and after CPU adjustment estimates SEV to be slower than TDX. The same study also states that TDX was “the most efficient in terms of CPU usage across a range of applications, closely followed by Gramine” (Coppolino et al., 2024).
The CPU-bound picture is less uniform. For PyTorch, native was fastest, and Gramine-SGX behaved better than TDX across all PyTorch benchmarks; Occlum was on the same level as TDX. For TensorFlow, by contrast, TDX had low inference time and was sometimes even better than native in the reported runs, while Occlum was worst, with inference time up to higher. The study therefore does not support the claim that TDX dominates all alternatives; it supports the narrower claim that TDX is often the best transparent option for legacy VM deployment, especially for memory- and I/O-heavy workloads, while process-based TEEs can remain attractive for CPU-bound workloads when stronger isolation is desired (Coppolino et al., 2024).
A second performance line concerns LLM inference inside TDX. Two 2025 papers evaluate DeepSeek and other lightweight models in TDX against CPU-only and CPU-GPU baselines. Their shared result is that TDX can outperform plain CPU execution for smaller models but remains far slower than GPU acceleration. For DeepSeek-R1-1.5B, one study reports 25.67 tokens/s in TDX versus 10.25 tokens/s for CPU only and 202.88 tokens/s for CPU-GPU; for DeepSeek-7B, TDX falls to 6.42 tokens/s and becomes slower than CPU only at 8.53 tokens/s. The SoC-design paper adds that quantization is decisive in TDX: for DeepSeek-R1 1.5B, throughput rises from 8.89 tokens/s in FP16 to 25.67 tokens/s in Q4KM, consistent with its claim of up to improvement for Q4 and up to for Q8 (Dong et al., 17 Feb 2025, Ben et al., 22 Jul 2025).
5. Systems and application domains built around TDX
Several recent systems use TDX as an enabling substrate rather than as an isolated hardware primitive. In research reproducibility, a 2026 framework proposes running replication packages in cloud-based TDX VMs and submitting attestation proofs rather than requiring journals or conferences to rerun the code. The pilot study reports 352 replication packages from Management Science Volume 70, with mean runtime 2.3 hours, overhead “typically 7–12% relative to non-confidential VM baselines,” Google Cloud TDX cost from \$0.27 to \$7.69 per package with average \$1.80, Azure TDX cost from \$0.22 to \$3.21 with average \$1.35, and first-run success rates of 68% on Google Cloud and 95% on Azure. The paper’s key claim is operational: TDX makes attested execution economically plausible for confidential or proprietary-data replication without enclave-specific engineering (Li et al., 25 Mar 2026).
In confidential containers, Arca argues against moving the entire container runtime into a confidential VM. Its “TEE-in-Container” architecture instead places only the sensitive execution context inside a dedicated TDX-backed TD VM while leaving orchestration logic outside the TEE. The paper states that Arca achieves near-native performance and outperforms CoCo in most benchmarks, and its TDX attestation design binds application identity, nonce, and image identity into ReportData, thereby narrowing the attested software image relative to heavier Container-in-TEE designs (Lu et al., 3 Jan 2026).
At Kubernetes scale, dstack-capsule reworks the granularity problem. Rather than one Pod per confidential VM, it allows multiple Pods to share a single TDX-protected CVM while preserving Pod-level evidence. The paper reports total attestation latency of about 24 ms, Pod startup latency of 6.25 s versus 8.85 s for CoCo, platform baseline memory of 793 MB, incremental overhead of about 2 MB per idle Pod, and 86 Pods on a 64 GB CVM before hitting kubelet --max-pods, with memory use at 1.1 GB / 64 GB (1.7%). These numbers are presented precisely to show that TDX-backed attestation need not imply one-VM-per-Pod economics (Yang et al., 2 Jun 2026).
TDX also appears in confidential AI workflows. The SoC-design and DeepSeek evaluations treat TDX as a practical way to keep model weights, design data, and inference computation inside a Trust Domain when GPU acceleration cannot yet be brought under the same trust boundary. Their common conclusion is narrow but concrete: lightweight, distilled, and quantized models are the best fit for current CPU-bound TDX inference, especially where confidentiality matters more than peak throughput (Ben et al., 22 Jul 2025, Dong et al., 17 Feb 2025).
6. Vulnerabilities, limitations, and ongoing hardening
A substantial body of work emphasizes that TDX’s guarantees are conditional and incomplete. One line of attack targets the interrupt interface that remains under hypervisor influence. “Heckler” shows that a malicious hypervisor can inject non-timer interrupts into confidential VMs and exploit guest interrupt handlers with global architectural effects. For Intel TDX, the measured surface was narrower than for SEV-SNP—interrupts 0–31 are blocked by hardware except an NMI path, and the paper found only int 0x80 to have a clear explicit effect on user applications—but that was still sufficient to bypass authentication in OpenSSH and sudo on TDX guests. The same paper reports practical mitigations: disabling CONFIG_IA32_EMULATION, or patching the guest kernel to detect externally injected int 0x80; the latter required only 14 lines of code and added about 460 cycles overhead for a genuine int 0x80 (Schlüter et al., 2024).
A second line of criticism concerns device interfaces. VIA argues that confidential computing creates a new trust boundary between protected VMs and hypervisor-controlled virtual devices, and that this boundary had been underexamined. The paper analyzed 22 Linux drivers in Linux 5.10.0-rc6, found 50 bugs, and reports that the resulting attacks enable a malicious hypervisor to corrupt memory and gain code execution in protected VMs with SEV-ES and are theoretically applicable to SEV-SNP and TDX. Its central lesson for TDX is that memory encryption and integrity protection do not sanitize MMIO, PIO, DMA, descriptor rings, or shared-memory metadata; guest drivers must treat device input as hostile (Hetzelt et al., 2021).
A third line of work shows that TDX’s own implementation surface can become large and fragile as features accumulate. Google’s 2025 security assessment of TDX 1.5, which added Live Migration and TD Partitioning, reports one vulnerability enabling a VMM to fully compromise a TD and four vulnerabilities enabling a malicious VMM or TD to leak confidential memory of the Intel TDX Module. The most severe issue, CVE-2025-30513, allowed a malicious destination VMM to make a migratable TD debuggable during migration and then read MIG_DEC_WORKING_KEY, thereby breaking confidentiality and integrity of the migrated TD. The paper’s broader conclusion is not that TDX is unusable, but that TDX requires iterative hardening, careful attestation policy, and defense in depth; it explicitly advises customers to attest that migration support is disabled if they do not need it (Swidowski et al., 11 Feb 2026).
Finally, several papers identify structural gaps rather than implementation bugs. The top-down architectural survey excludes side channels, fault injection, trusted device I/O, nested virtualization, live migration, and SGX-in-TD from the TDX 1.0 design envelope (Cheng et al., 2023). The replication paper notes unresolved concerns about side channels and vendor-root trust (Li et al., 25 Mar 2026). “Proof of Cloud” adds that standard TDX attestation proves that a TD was launched on a genuine TDX platform with particular measurements, but reveals nothing about the location of the hosting machine, even though TDX’s threat model excludes physical attackers. Its proposed Data Center Execution Assurance therefore binds TDX quotes to TPM or vTPM evidence so that a verifier can check that the confidential VM and the platform attestation refer to the same physical chassis, thereby aligning deployment evidence more closely with the TDX threat model (Rezabek et al., 14 Oct 2025).
Taken together, these results define the current research consensus with unusual clarity. TDX is a confidential-VM architecture optimized for compatibility, measured launch, and remote attestation at VM granularity. It is stronger operationally than enclave-centric systems for legacy deployment, yet weaker than process-based TEEs in isolation granularity; it performs well on many memory- and I/O-heavy workloads, yet not uniformly across CPU-bound tasks; and its real security posture depends not only on memory encryption and attestation, but also on interrupt mediation, virtual-device interfaces, attestation policy, feature minimization, and the quality of the surrounding confidential-computing stack (Coppolino et al., 2024, Swidowski et al., 11 Feb 2026).