intel TDX

2022-02-17 · 4 min read

#confidential-computing

Intel TDX is designed to isolate virtual machines from the VMM/hypervisor and other non-VMM system software on the platform. TDX is also able to protect the VMs from some forms of hardware attacks

Intel Trust Domain Extensions (Intel TDX) is introducing new, architectural elements to help deploy hardware-isolated, virtual machines (VMs) called trust domains (TDs). Intel TDX is designed to isolate VMs from the virtual-machine manager (VMM)/hypervisor and any other non-TD software on the platform to protect TDs from a broad range of software. source

Secure-Arbitration Mode (SEAM) – a new mode of the CPU designed to host an Intel-provided, digitally-signed, security-services module called the Intel TDX module.
Shared bit in GPA to help allow TD to access shared memory.
Secure EPT to help translate private GPA to provide address-translation integrity and to prevent TD-code fetches from shared memory. Encryption and integrity protection of private-memory access using a TD-private key is the goal.
Physical-address-metadata table (PAMT) to help track page allocation, page initialization, and TLB consistency.
Multi-key, total-memory-encryption (MKTME) engine designed to provide memory encryption using AES-128- XTS and integrity using 28-bit MAC and a TD-ownership bit.
Remote attestation designed to provide evidence of TD executing on a genuine, Intel TDX system and its TCB version.
It looks like you basically run a linux kernel on the host machine, then linux (which now supports TDX) can run these VM isolates (just like containers I guess, but with privacy and isolation).

Roadmap Status (2021/09/24) #

item	status
linux firmware loader	WIP
KVM TD	Under Review
KVM MMU	Under Review
KVM unmapping	Under discussion
QEMU guest BIOS	Under Review
QEMU cpuid	WIP
QEMU guest attestation	WIP
QEMU unmapping	Under discussion

Hardware #

https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/03/hardware_selection/
All DRAM DIMM slots must be occupied

(2026-04-03): wait for RAM prices to drop...

Setup #

Configure host BIOS #

Configure host #

Availability #

Someone running TDX VMs on GCP bare metal :O https://t1protocol.substack.com/p/tdx-on-gcp-baremetal-the-tiny-difference

Tuning #

Intel's TDX Performance Analysis Reference

Features #

Sealing #

The TDG.MR.KEY.GET instruction, which is required for a TD to request a sealing key, doesn't appear to be supported yet.
tdx-guest lists it as not yet implemented?

TDX Module Base Spec

Enumeration: TDX Module support of sealing and TDG.MR.KEY.GET is enumerated by TDX_FEATURES0.SEALING (bit20 12), readable by TDG.SYS.RD.

The TDG.MR.KEY.GET interface function allows a TD to request a persistent sealing key to be derived for the TD. The key derivation is done according to a key request structure, which specifies a measurement register policy (e.g., which RTMRs are used), TD configuration policy (e.g., which bits of the TD’s XFAM and ATTRIBUTES are used) and SVNs. The sealing key can be used to seal information, i.e., encrypt it so later it can be decrypted by a TD that has a compatible set of measurements, configuration and SVNs as used when deriving the sealing key. TDX sealing keys are not migratable.5 Sealing keys are bound to the current platform. Thus, by default, using the hardware-based keys by migratable TD is not allowed. A migratable TD may allow using hardware keys by setting TDCS.TD_CTLS.ALLOW_HW_KEYS to 1. In this case, a key request done after migration will not return the same key as a key request done prior to migration. For further details, see the ABI Spec.