Source-linked AI summary
Intel TDX Demystified: A Top-Down Approach
Pau-Chen Cheng, Wojciech Ozga, Enriquillo Valdez, Salman Ahmed, Zhongshu Gu, Hani Jamjoom, Hubertus Franke, James Bottomley
TL;DR
Confidential computing aims to protect sensitive data and outsourced computations on cloud infrastructure, while TDX targets protection against untrusted host platforms. This paper provides a top-down review of TDX based on public documentation and source code. It explains TDX's security principles, technical design, and attestation alongside its scope boundaries and ongoing challenges.
Problem
Regulated industries and sensitive-data holders are concerned about moving data to third-party clouds, motivating end-to-end protection for outsourced computations.
Source: §1 · p. 3Method
The paper reviews TDX from high-level security principles to technical details using publicly available documentation and source code.
Source: remote attestation · p. 3, §10 · p. 28Results
The review covers TDX's security principles, threat model, architecture, memory protection, and remote attestation, and compares it with related technologies.
Source: §10 · p. 28Takeaways & Limitations
The review identifies live migration, secure I/O, and extending trust to peripheral devices and hardware accelerators as ongoing challenges.
Source: §10 · p. 28
Abstract
from arXiv · showhide
Intel Trust Domain Extensions (TDX) is a new architectural extension in the 4th Generation Intel Xeon Scalable Processor that supports confidential computing. TDX allows the deployment of virtual machines in the Secure-Arbitration Mode (SEAM) with encrypted CPU state and memory, integrity protection, and remote attestation. TDX aims to enforce hardware-assisted isolation for virtual machines and minimize the attack surface exposed to host platforms, which are considered to be untrustworthy or adversarial in the confidential computing's new threat model. TDX can be leveraged by regulated industries or sensitive data holders to outsource their computations and data with end-to-end protection in public cloud infrastructure. This paper aims to provide a comprehensive understanding of TDX to potential adopters, domain experts, and security researchers looking to leverage the technology for their own purposes. We adopt a top-down approach, starting with high-level security principles and moving to low-level technical details of TDX. Our analysis is based on publicly available documentation and source code, offering insights from security researchers outside of Intel.
1 INTRODUCTION
Confidential computing seeks to protect outsourced computations and sensitive data throughout their lifecycle, addressing concerns about placing them with third-party cloud providers. The paper reviews Intel TDX from security principles through technical details using public documentation and source code.
1 INTRODUCTION
- TDX provides TEE capabilities on 4th Generation Intel Xeon Scalable Processors, isolating Trust Domains from potentially adversarial privileged host software.It aims to protect TD confidentiality and integrity and lets owners verify remote platform authenticity.Source: §1 · p. 3
- The review aims to give potential adopters, domain experts, and security researchers an objective understanding of TDX based on public documentation and source code.Its sources include documentation and source code.Source: remote attestation · p. 3
- The paper proceeds from security principles and threat model to technology comparisons, Intel building blocks, TDX architecture, memory protection, and remote attestation.It concludes with a summary and provides an acronym list.Source: remote attestation · p. 3
2 SECURITY PRINCIPLES
TDX is intended to isolate tenant Trust Domains from untrusted host software by protecting memory and virtual CPU state. Its guarantees do not extend to shared memory, and it does not add control-flow integrity protection.
2 SECURITY PRINCIPLES
- TDX uses cryptographic isolation among security domains to exclude the hypervisor and cloud operators from the TCB.It combines memory access control, runtime encryption, and an Intel-signed TDX Module; remote attestation gives tenants proof that TDs run on genuine TDX-enabled processors.Source: §2 · pp. 3–4
- TD memory is encrypted with a TD-specific key when offloaded from the processor package, at cache-line granularity.The processor detects tampering when loading data from main memory.Source: §2 · p. 4
- During context switches, TDX clears or isolates TD-specific state from processor registers and buffers.The virtual CPU states are stored in TD metadata protected in main memory with the TD's key.Source: §2 · p. 4
- TDX detects malicious changes to virtual CPU state and private-memory instructions, but provides no additional control-flow integrity guarantees.The TD owner is responsible for applying existing techniques such as CET.Source: §2 · p. 4
- TDX does not protect confidentiality or integrity of data in shared memory regions used for virtualized I/O.TD owners must protect data leaving the trust boundary, for example with TLS; trusted I/O virtualization is planned for TDX 2.0.Source: §2 · p. 4
3 THREAT MODEL
The threat model allows adversaries extensive control over the platform, including host software, devices, inputs, and some physical access. It excludes availability guarantees and leaves some physical and side-channel attacks outside scope.
3 THREAT MODEL
- Adversaries may seek confidential data or interfere with TD execution while controlling firmware, SMM, the host OS, hypervisor, or peripherals.They may also control assigned resources, interrupt TDs, access memory, reconfigure the IOMMU, and manipulate TD inputs.Source: §3 · pp. 4–5
- TDX cannot guarantee availability because adversaries can control TD compute resources and launch denial-of-service attacks.The model also excludes defenses against rollback of arbitrary memory regions, fault injection, and side-channel attacks such as power glitches or timing and power analysis.Source: §3 · pp. 4–5
- Adversaries may invoke host-side TDX Module interface functions in arbitrary order with valid or invalid inputs.These functions build, initialize, measure, and tear down TDs.Source: §3 · p. 5
- The TCB includes Intel processors and built-in technologies, Intel-signed software modules, tenant-owned TD software, and assumptions of sound cryptography and secure implementation.Tenants must trust Intel's development, manufacturing, and signing, the equivalence of reviewed and signed versions, and Intel's Provisioning Certification Service for attestation.Source: §3 · p. 5
4 COMPARISON OF CONFIDENTIAL COMPUTING TECHNOLOGIES
The paper compares confidential-computing designs that share core isolation principles while differing in their mechanisms. It surveys AMD SEV, IBM Secure Execution and PEF, Arm CCA, and RISC-V AP-TEE.
4 COMPARISON OF CONFIDENTIAL COMPUTING TECHNOLOGIES
- Confidential-computing designs commonly use new execution modes or privilege levels, trusted management components, measured launch, memory access control, and encryption.Table 1 summarizes comparable technologies, including AMD, IBM, Arm, and RISC-V offerings.Source: §4 · pp. 5–6, Table 1 · p. 6
4.1 AMD SEV
- AMD SEV assigns VMs ephemeral AES keys for runtime memory encryption and supports attestation of launch measurements and platform trustworthiness.SEV-ES adds CPU register-state protection, while SEV-SNP adds memory integrity protection using the Reverse Mapping Table.Source: §4.1 · p. 6
4.2 IBM Confidential Computing
- IBM Secure Execution uses the Ultravisor to shield SVM memory and state, while IBM PEF uses an Ultravisor in secure state to create and verify SVMs.Secure Execution supports remote attestation from IBM Z16 and LinuxONE Emperor 4; PEF uses TPM-protected seed material to verify and decrypt its payload.Source: §4.2 · pp. 7–8
4.3 Arm CCA
- Arm CCA adds Realm and Root worlds through RME, with a Granule Protection Table tracking page ownership across worlds.The Root-world Monitor manages the table, and CCA supports attestation of the platform and initial Realm state.Source: §4.3 · p. 8
4.4 RISC-V AP-TEE
- RISC-V AP-TEE uses a TEE Security Manager and Memory Tracking Table to manage TVMs, with layered attestation from hardware through the TVM.Each layer is loaded, measured, and certified by the preceding layer, forming a chain of trust.Source: §4.4 · p. 8
5 BUILDING BLOCKS FOR TDX
TDX builds on Intel VT, TME/MKTME, and SGX, adapting their virtualization, memory-encryption, and enclave capabilities to its threat model. The section explains these technologies and their roles as TDX building blocks.
5.1 Intel VT
- VT provides hardware-assisted virtualization, including CPU, memory, and I/O virtualization, and underpins TDX’s VM-based isolation.The section also summarizes VT-x modes, VM transitions, VMCS, EPT address translation, and VT-d device isolation.Source: §5.1 · pp. 8–9
- TDX combines VT-based isolation with TDX Module management and separate EPTs for private and shared memory.The hypervisor is untrusted in TDX’s threat model, so TD management moves into the TDX Module.Source: §5.1 · p. 9
- TDX 1.0 does not support running VMs within a TD, while a specification draft indicates nested virtualization is planned for TDX 1.5.Using VMX instructions within a TD can result in Undefined Instruction exceptions.Source: §5.1 · p. 9
5.2 Intel TME/MKTME
- MKTME extends TME with multiple keys and page-granular encryption, using HKIDs to select keys for memory transactions.Its keys are stored in the Key Encryption Table and are not exposed to software.Source: §5.2 · p. 10
- MKTME provides page-granular, HKID-selected memory encryption, while TDX assigns control of TD encryption to the TDX Module.In virtualized environments, hypervisor-controlled encryption conflicts with TDX’s threat model; TDX partitions HKIDs into private and shared spaces.Source: §5.2 · p. 10
5.3 Intel SGX
- SGX protects selected application code and data in enclaves, and TDX leverages SGX’s remote-attestation mechanism.On the same platform, SGX and TDX are within the same TCB and can locally attest each other.Source: §5.3 · pp. 10–11
6 OVERVIEW OF TDX
The overview describes TDX’s architecture and protections, including shared-memory I/O and remote attestation. It also outlines planned migration and TEE I/O features, which are not supported in TDX 1.0.
6.1 TDX System Architecture
- TDX architecture combines TDX-enabled processor functions with an Intel-signed, CPU-attested TDX Module that manages TD construction, execution, and termination.The module runs in the SEAM RANGE and provides host-side and guest-side interfaces.Source: §6.1 · pp. 11–12, Figure 1 · p. 12
6.2 TDX Memory Protection
- TDX protects TD memory through access control and cryptographic isolation, with the TDX Module managing private-memory address translation.Private memory and metadata use MKTME encryption with TD-specific keys; memory integrity uses Logical Integrity and Cryptographic Integrity mechanisms.Source: §6.2 · pp. 12–14
- TDX partitions physical memory into secure and normal regions, and the TDX Module converts selected pages into secure memory during TD construction.A TD must explicitly accept pages before using them as main memory, and the module checks setup using a Physical Address Metadata Table.Source: §6.2 · p. 13
6.3 TDX I/O Model
- TDs must place I/O buffers in shared memory for hypervisors or devices to transfer them, and validate incoming data as untrusted.TD owners are responsible for protecting data leaving the trust boundary; Linux TDX guests map MMIO regions and DMA buffers as shared memory.Source: §6.3 · p. 14
6.4 TDX Attestation
- A TD quote provides measurements of the TDX TCB and loaded software, allowing a challenger to verify platform authenticity and expected measurements.The quote is produced by the TDX Module, signed by the Quoting Enclave, and includes a certificate chain anchored by an Intel-issued certificate.Source: §6.4 · p. 14
6.5 Future Features
- Live migration and TEE I/O are unsupported in TDX 1.0; the paper describes proposed designs for future versions.Migration uses source and destination Migration TDs to attest platforms, establish a secure channel, and transfer encrypted TD assets; TEE I/O proposes mutual device–TD identity checks and an end-to-end secure channel.Source: §6.5 · pp. 14–15
7 TDX MODULE
The TDX Module is installed and initialized through Intel-signed loaders and hypervisor calls, then manages TD metadata, protected context transitions, temporary buffer mappings, and physical-page attributes.
7.1 Loading the TDX Module
- The P-SEAM Loader verifies and installs the TDX Module image in the SEAM RANGE, establishing a chain of trust from Intel-signed components.Installation includes signature and SVN checks, memory-region setup, image measurement, and recording the module hash and SVN.Source: §7.1 · pp. 16–17
7.2 Memory Layout of the TDX Module
- The P-SEAM Loader establishes the Module’s linear address space, randomizing bits 34–46; keyhole mappings are edited dynamically at runtime.Code, stack, data, and sysinfo_table mappings can be populated in advance, unlike the keyhole mappings.Source: §7.2 · pp. 17–18
7.3 Platform Initialization
- Platform initialization configures the TDX Module, per-LP state, a global private HKID, TDMRs, and PAMT structures through SEAMCALLs.The hypervisor progressively initializes PAMT for each TDMR.Source: §7.3 · p. 18
7.4 Metadata for TDs
- TD metadata includes TDR, TDCS, TDVPS, and SEPT; TDCS, TDVPS, and private memory are associated with the TDR through PAMT ownership.TDCS and TDVPS are protected by the TD’s private key, while the TDR is initially protected by the TDX Module’s global private key.Source: §7.4 · pp. 18–19
7.5 Context Switches
- TD Transfer VMCS state resides in encrypted TDVPS, and TD exits first trap into the TDX Module before minimized requests reach the hypervisor.This limits exposure when the hypervisor must emulate operations such as port I/O, HLT, or CPUID.Source: §7.5 · pp. 20–21
7.6 Keyholes
- Keyholes temporarily map physical memory buffers into the Module’s linear address space, reusing mapped pages and returning unused keyholes to an LRU list.The keyhole-edit region lets the Module update page-table entries for these runtime mappings.Source: §7.6 · p. 21
7.7 Physical Memory Management
- PAMT tracks each physical page’s owner, type, and size so the TDX Module can check valid assignment and consistency with SEPT page sizes.PAMT is organized in levels for 4 KB, 2 MB, and 1 GB pages.Source: §7.7 · pp. 21–22
8 MEMORY PROTECTION
TDX divides TD memory into private and shared pages, applies HKID-based encryption, and detects unauthorized changes to private memory through integrity mechanisms.
8 MEMORY PROTECTION
- TD private memory is accessible only to the TD and TDX Module, while shared memory remains accessible to the hypervisor for cooperative operations such as I/O.Private memory and metadata are encrypted with the TD’s ephemeral private key, bound to an HKID for the TD’s lifetime.Source: §8 · p. 22
- An access outside SEAM mode using a private HKID raises an exception, while the hypervisor can use only shared HKIDs.The TDX Module can use both shared and private HKIDs.Source: §8 · p. 23
8.2 TD Memory Integrity Protection
- Cryptographic Integrity (Ci) detects direct physical writes and bit flips such as Rowhammer that Logical Integrity (Li) cannot detect.Both modes apply to cache-line-sized, cache-line-aligned physical memory segments.Source: §8.2 · p. 23
- Reads of private memory by software outside SEAM mode return zeros, preventing ciphertext analysis and related side channels.With Ci enabled, a MAC mismatch also marks a cache line as poisoned.Source: §8.2 · p. 23
- Writes to private memory from outside SEAM mode clear its TD Owner bit, causing later reads to mark the segment poisoned and potentially terminate the TD.If the TDX Module reads poisoned content, the Module and its hardware extension are disabled.Source: §8.2 · p. 23
9 REMOTE ATTESTATION
TDX attestation measures TD software, produces a signed quote for third-party verification, and supports platform setup and use cases including secure channels and encrypted boot.
9.1 Attestation Process
- TDX measures build-time and runtime software, generates an integrity-protected TD report, and converts it into a digitally signed quote for off-platform verification.The report includes measurements and platform TCB information; a quoting enclave verifies its HMAC before signing it.Source: §9.1 · pp. 24–26
9.2 Platform Setup
- Platform attestation setup registers the platform with Intel PCS and uses PCE and QE enclaves to certify the QE attestation key.The resulting certificate chain connects an Intel-issued PCK certificate to the QE public key used to verify quote signatures.Source: §9.2 · p. 26
- A remote verifier checks the quote’s nonce, certificate signatures and revocation status, TCB currency, and measurements against reference values.A valid quote supports trust that the TD was properly instantiated on a TDX platform.Source: §9.2 · p. 27
9.3 Use Cases
- Attested public-key binding can support secure-channel authentication, while encrypted boot releases a partition key only after quote verification.The encrypted-boot flow lets the tenant’s attestation server verify expected measurements before providing the key to the TD agent.Source: §9.3 · pp. 27–28
10 CONCLUSION
The paper reviews TDX from security principles through implementation details, compares it with other vendors’ technologies, and identifies evolving challenges.
10 CONCLUSION
- The review uses public documentation and source code, and identifies live migration, secure I/O, and extending trust to peripherals and accelerators as ongoing challenges.The authors plan continued security analysis as the technology progresses.Source: §10 · p. 28
A LIST OF ACRONYMS
The acronym list expands terminology used throughout the paper, spanning TDX and trust-domain concepts, memory and virtualization mechanisms, and attestation and measurement.
A LIST OF ACRONYMS
- TDX means Trust Domain Extensions; related entries define Trust Domain (TD), Trusted Computing Base (TCB), and Secure-Arbitration Mode (SEAM).The list also expands TEE as Trusted Execution Environment.Source: A LIST OF ACRONYMS · pp. 29–30
- Memory and virtualization terms include Memory Encryption Engine (MEE), Secure EPT (SEPT), Virtual Machine Monitor (VMM), and Guest Physical Address (GPA).The entries also expand TDMR as Trust Domain Memory Region and TDVPS as Trust Domain Virtual Processor State.Source: A LIST OF ACRONYMS · pp. 29–30
- Attestation and measurement entries include Data Center Attestation Primitives (DCAP), Intel Attestation Service (IAS), and Measurement of Trust Domain (MRTD).The list also defines Runtime Measurement Register (RTMR).Source: A LIST OF ACRONYMS · pp. 29–30