Intel TDX (Trust Domain Extensions) is a hardware virtualization feature introduced in Intel's 4th Generation Xeon Scalable processors (Sapphire Rapids, 2023) that extends the confidential computing capabilities of the CPU itself. It is architecturally different from Intel SGX, which created application-level protected enclaves, and represents Intel's response to the cloud-scale confidential VM problem. Understanding what TDX actually does at the hardware level — and where its boundary ends — is essential for any platform security architect designing a confidential compute stack today.
The Core Architectural Concept: Trust Domains
TDX introduces a new hardware concept called a Trust Domain (TD) — a hardware-isolated execution environment that operates at the virtual machine granularity rather than the application granularity of SGX enclaves. A TD is a guest VM whose memory is encrypted by a dedicated key managed by the Intel TDX Module, a signed firmware component that runs at a new CPU privilege level (SEAM, for Secure Arbitration Mode) that is above even the hypervisor's ring -1.
The memory encryption uses AES-128-XTS with a per-TD key managed by the Memory Encryption Engine (MEE) built into the CPU's memory controller. When the TD accesses memory, the MEE transparently decrypts the cache line. When the TD writes back to DRAM, the MEE encrypts it. The hypervisor (VMM) running in ring -1 cannot read the TD's memory because the decryption key is held in the MEE and never exposed to software — including the hypervisor.
This is the core confidentiality guarantee: a compromised or malicious cloud hypervisor cannot directly read a TDX guest VM's DRAM contents. This addresses a real and well-documented threat — the hypervisor has historically been a trusted component that tenants had no way to verify, and hypervisor-level compromises have exposed tenant memory in multiple documented incidents.
The TDX Module: A Trusted Intermediary
The TDX Module is the component that manages Trust Domains, enforces isolation policies, and handles the transitions between the VMM and TDs. It runs in SEAM mode — a new CPU execution context that Intel introduced to provide a privilege level above the hypervisor but below full hardware control. The TDX Module carries Intel's digital signature, and its measurement (a hash of its code) is included in the TD's attestation report.
This is an important architectural choice. Rather than having the CPU hardware enforce TD isolation with no software intermediary (which would require significant hardware complexity), Intel moved the isolation enforcement logic into a signed firmware component. This allows TDX features to be updated via microcode and module updates without hardware respins. The tradeoff is that the trust model now includes "trust Intel's TDX Module signing process" as a required assumption.
The TDX Module handles TD creation, memory management, TLB flushing isolation (critical for preventing cross-TD cache attacks), and the SEAMCALL/SEAMRET interfaces that the VMM uses to manage TDs. It is not application code — it runs with CPU hardware privilege — but it is software, and it has had vulnerabilities disclosed since launch.
Attestation: How a Relying Party Verifies a TDX Guest
TDX attestation is the mechanism that allows a workload inside a TD to prove to an external party that it is running in a genuine TDX environment. The attestation flow works as follows:
- The TD's initial memory state is cryptographically measured by the TDX Module during TD launch and stored as the MRTD (TD Measurement Register) value.
- The TD runtime can extend additional measurements into RTMR registers as it loads software components, creating a chain of measurements analogous to TPM PCRs.
- To generate an attestation quote, the TD calls the TDX Quoting Enclave (a specialized SGX enclave that runs outside the TD) via the host.
- The Quoting Enclave signs the TD's measurement report with a key that chains to Intel's Provisioning Certification Key (PCK).
- A relying party verifies the quote against Intel's Provisioning Certification Service (PCS), which provides the certificate chain.
The relying party's verification therefore requires trusting Intel's attestation infrastructure — the PCS, the PCK certificate chain, and Intel's key management practices. This is a reasonable assumption for many enterprise scenarios, but it is not equivalent to a self-sufficient, hardware-immutable trust anchor.
What TDX Protects — and What It Does Not
Being precise about TDX's guarantees avoids both overselling and underselling the technology.
| Threat | TDX Protection | Notes |
|---|---|---|
| Malicious or compromised hypervisor reading TD DRAM | Protected | MEE encryption prevents direct DRAM reads by the VMM |
| Cloud provider management plane reading tenant VM memory | Protected (with attestation) | Requires guest to verify attestation before trusting the environment |
| TDX Module vulnerability exploitation | Not protected | Several CVEs disclosed 2023–2025 against the TDX Module |
| Timing side-channel attacks on shared CPU resources | Partially mitigated | Mitigations reduce but do not eliminate Spectre-class surface |
| Key material exfiltration via covert channel | Not protected | Requires hardware-isolated key storage outside the TD |
| Physical DRAM access (cold boot, DMA attack) | Protected | MEE encryption makes cold boot attacks against TD memory unproductive |
Where a Hardware Co-Processor Extends TDX Coverage
The gap in TDX's protection model that matters most for cryptographic workloads is key material isolation. A TDX guest VM can perform key operations in software, but those key operations run on the same physical CPU cores that also run other TDs and the VMM — making them potentially observable through timing side channels, as covered in our Spectre/Meltdown analysis.
The hardware co-processor model (using a chip like the Bastionchip ASIC as a TDX-adjacent device) addresses this gap. The chip communicates with the TDX guest over a PCIe IOMMU-protected DMA channel — the guest can issue key operations to the chip without the host VMM being able to read the transaction content. The key derivation and cryptographic operations execute in the chip's physically isolated enclave, never touching a bus or CPU cache that is shared with untrusted software.
In this combined architecture, TDX handles memory confidentiality and workload attestation (what code is running), while the hardware HSM handles persistent key storage and cryptographic operation isolation (where key material lives and where crypto happens). The two components complement each other rather than competing.
TDX is a genuine advance in confidential VM security. We've validated our co-processor integration on Azure DCsv3 instances running TDX, and the combined attestation model — TDX guest measurement plus chip attestation — produces a verifiable chain that covers both the workload and the hardware handling key material. Neither component alone closes the full threat model; together they come closer than any purely software approach.
