Architecture

Prerequisites

TDX comprises two main components:

TDX-enabled processors

These processors provide essential architectural functionalities, including hardware-assisted virtualization, memory encryption/integrity protection, and the capability to certify Trusted Execution Environment (TEE) platforms.

TDX Module

The TDX Module is an Intel-signed and CPU-attested software module that harnesses the capabilities of TDX-enabled processors to facilitate the creation, execution, and termination of TDs (Trusted Domains) while ensuring robust security guarantees.

Architecture

The TDX Module offers two interface functions: host-side interface functions for a TDX-enlightened hypervisor and guest-side interface functions for TDs. This module is loaded and executed within the Secure-Arbitration Mode (SEAM) RANGE, a reserved portion of system memory set up through UEFI/BIOS. The P-SEAM Loader, also residing in the SEAM RANGE, manages the installation and updates of the TDX Module.

SEAM is an extension of the VMX (Virtual Machine Extensions) architecture, introducing SEAM VMX root mode and SEAM VMX non-root mode. A TDX-enlightened hypervisor operates in the traditional VMX root mode. Still, it can transition into SEAM VMX root mode using the SEAMCALL instruction to invoke host-side interface functions (identified by function names starting with TDH) within the TDX Module. Once the task is completed, the logical processor returns to the hypervisor in VMX root mode through the SEAMRET instruction.

In contrast, TDs run in the SEAM VMX non-root mode. They can access the TDX Module through a TD exit or the TDCALL instruction. In both cases, the logical processor switches from SEAM VMX non-root mode to SEAM VMX root mode to execute code within the TDX Module. The guest-side interface functions responsible for handling TDCALLs have names starting with TDG.

Intel TDX Architecture

I/O Model

The TDX threat model considers hypervisors and peripheral devices untrusted, prohibiting direct access to the private memory of TDs. Therefore, TDs and their owners must secure I/O data before it crosses the trust boundary. This involves sealing I/O data buffers and placing them in shared memory, identified by the shared bit in the Guest's Physical Address. Hypervisors and peripheral devices can move data to and from the shared memory. Consequently, the guest kernel requires modifications to support this I/O model. Additionally, all I/O data entering TDs from hypervisors or peripheral devices must undergo thorough examination and validation, as it can no longer be considered trustworthy.

In Linux guest support for TDX, all MMIO (Memory Mapped I/O) regions and DMA (Direct Memory Access) buffers are mapped as shared memory within TDs. The Linux guest enforces using SWIOTLB (Software I/O Translation Lookaside Buffer) to allocate and convert DMA buffers to unified locations. This protects against malicious inputs from I/O, and only a limited number of hardened drivers are permitted within TDs.