↓ Skip to main content
Le Site de François
  1. Index/

TDX (Intel Trust Domain Extensions)

Security Confidential-Computing Hardware Attestation Virtualization
Table of Contents

Intel Trust Domain Extensions (TDX) is a confidential computing technology built into Intel CPUs that allows entire virtual machines — called Trust Domains (TDs) — to run with hardware-enforced isolation from the host hypervisor, VMM, and any other software on the platform, including privileged system software with administrative access. Unlike SGX, which protects small application-level enclaves, TDX operates at the VM level, making it suitable for lifting existing workloads into a confidential environment without significant code changes.

TDX achieves this through two key mechanisms. First, a new CPU operation mode called SEAM (Secure Arbitration Mode) hosts the TDX module — a CPU-measured firmware module that sits between the host VMM and the guest TD, managing their separation. The host cannot directly access TD register state or memory; interactions that would normally cause a VMEXIT are instead handled inside the guest via a Virtualization Exception (#VE). Second, all TD private memory is encrypted with a per-TD AES-XTS 128-bit key managed by the CPU, ensuring that even physical memory access yields only ciphertext.

For measured boot and attestation, TDX uses RTMR registers (Runtime Measurement Registers) — analogous to TPM PCRs but scoped to the TD — to record hashes of the initial TD state, kernel image, firmware, command line, initrd, and ACPI tables. The TD can produce a TDREPORT: a CPU-signed structure containing those measurements, which can be forwarded to an Intel SGX Quoting Enclave to produce a remotely verifiable Quote for remote attestation. This allows a relying party to verify the exact software stack running inside a TD before sending it sensitive data. TDX is a foundational building block in Confidential Computing stacks and pairs naturally with TPM-based and UKI-based measured boot pipelines in Linux guests.

Additional Information
#

= Intel TDX Demystified: A Top-Down Approach (Apr 2024)

Related

SEV-SNP (AMD Secure Encrypted Virtualization – Secure Nested Paging)

Security Confidential-Computing Hardware Attestation Virtualization Amd
SEV-SNP is AMD’s third-generation confidential computing technology for EPYC processors, and the generation in production use across major cloud providers (AWS, Google Cloud) and Linux distributions today. It builds on two predecessors: SEV (2016), which encrypted each VM’s memory with a per-VM AES key managed by the AMD Secure Processor, and SEV-ES (2017), which additionally encrypted CPU register state on VM exit to prevent the hypervisor from reading guest execution state. SEV-SNP’s defining addition is memory integrity: using Secure Nested Paging, the firmware enforces that if a guest can read an encrypted memory location, the value returned must be exactly what the guest last wrote there — closing the replay, remap, and memory aliasing attacks that made earlier generations insufficient for a fully untrusted hypervisor threat model.

TCB (Trusted Computing Base)

Security Confidential-Computing Virtualization Attestation Linux
The Trusted Computing Base (TCB) is everything you must trust for your security guarantees to hold: CPU and firmware, the host kernel, the hypervisor, the container runtime, the kubelet, identity and secrets infrastructure, and any management plane that can change workload configuration. If any component in the TCB is buggy, misconfigured, or controlled by an adversary, the whole security argument fails — regardless of how well the application itself is written. The classic design principle is TCB minimisation: keep this set as small as possible, because every added component is another place where a flaw can void your policy. “Trusted” here does not mean “trustworthy in practice”; it means “assumed correct by the security model.”

TEE (Trusted Execution Environment)

Security Confidential-Computing Hardware Attestation Tee
A Trusted Execution Environment (TEE) is a hardware-enforced isolated execution context whose confidentiality and integrity are protected by the CPU itself, rather than by software policy. The defining property of a TEE is that its guarantees hold against an adversary with full control of the software stack outside it — the hypervisor, the host operating system, the BIOS firmware, and even a user with physical access to the machine — because the enforcement is implemented in silicon and cannot be overridden by software. Code and data inside a TEE are encrypted in DRAM using a key held within the CPU’s memory controller or on-die security processor, CPU register state is isolated from the host at context switch boundaries, and memory integrity protection prevents the host from replaying, remapping, or aliasing TEE memory pages. The threat model TEEs are designed against is therefore the infrastructure provider: a cloud operator, a data centre staff member, or a co-tenant who controls the hypervisor layer — the party that traditional virtualisation, namespaces, and access control cannot protect against because they depend on a trusted host kernel.