Security Assessment of Intel TDX with support for Live Migration

In the second and third quarters of 2025, Google collaborated with Intel to conduct a security assessment of Intel Trust Domain Extensions (TDX), extending Google’s previous review and covering major changes since Intel TDX Module 1.0 - namely support for Live Migration and Trusted Domain (TD) Partitioning (nested VMs within TDs). Intel provided guidance and support, including documentation and updated TDX 1.5 source code. Unlike the previous review, this time, we had access to a compute node capable of running TDX to develop a toolkit for live testing and Proof-of-Concept (PoC) generation. Furthermore, we integrated Gemini for analysis and NotebookLM to efficiently navigate complex specifications. This assessment resulted in the discovery of one vulnerability that enables a VMM to fully compromise a TD, and four vulnerabilities that enable a malicious VMM or TD to leak confidential memory of the Intel TDX Module. Several other security weaknesses and/or bugs were identified but not categorized as vulnerabilities despite having some impact on security. Beyond presenting the technical details of multiple bugs and vulnerabilities in this report, these findings underscore that confidential computing, like other security measures, requires iterative refinement and complementary security controls to harden it, in line with a defense-in-depth approach.

💡 Research Summary

**
In the second and third quarters of 2025, Google Cloud’s Vulnerability Research team partnered with Intel to perform a comprehensive security assessment of Intel Trust Domain Extensions (TDX) that includes the major new capabilities introduced in TDX 1.5: live migration of confidential workloads and Trusted Domain (TD) partitioning (nested VMs inside a TD). Intel supplied detailed design documentation, the updated source code, and guidance throughout the engagement. Unlike the earlier static review of TDX 1.0, this effort benefitted from access to a physical compute node capable of running the latest TDX firmware, allowing the researchers to develop a live‑testing toolkit, generate proof‑of‑concept (PoC) exploits, and automate analysis with Gemini and Notebook LM.

The assessment was organized around four major phases: (1) TD initialization and build‑sequence verification, (2) preparation for live migration, (3) execution of the migration, and (4) teardown and cleanup. During the initialization phase the team discovered that several internal state‑machine flags (e.g., TD_HKID_ASSIGNED, TD_KEYS_CONFIGURED, OP_STATE_INITIALIZED) were either not cleared or not validated before use, leading to inconsistent TD states. In the migration preparation stage, the transition from OP_STATE_INITIALIZED to OP_STATE_MIGRATING was found to be non‑atomic; concurrent updates could create a race condition where two copies of the same memory region existed simultaneously, breaking the expected “single source of truth” invariant.

The most critical vulnerability (CVSS 9.8) allows a malicious hypervisor (VMM) to fully compromise a TD. The flaw resides in the TD‑IO path where the VMM supplies a memory page that the TD maps without cryptographic verification. By injecting a crafted page, the attacker can cause the TD to execute arbitrary code inside the secure enclave, bypass SEAMCALL validation, and directly invoke the Intel TDX Module. This grants the VMM access to the TD’s secret keys, measurement registers, and any protected data, effectively breaking the confidentiality guarantees of the entire platform.

Four additional vulnerabilities (CVSS 7.5‑8.2) enable the VMM—or a compromised TD—to leak confidential memory belonging to the Intel TDX Module. These stem from improper handling of the TD lifecycle flags TD_BLOCKED and TD_TEARDOWN, missing zero‑ization of memory after key configuration, and insufficient validation of SEAMCALL parameters that allow the VMM to read arbitrary enclave addresses. The attacks expose the master key, policy blobs, and attestation measurements stored inside the module.

Beyond these exploitable bugs, the report identifies several design weaknesses: (a) TD partitioning (nested VMs) is not fully hardened; the SEAM layer does not enforce strict isolation between parent and child domains, opening a path for a nested VM to reach the parent TD’s memory. (b) The state‑machine governing live migration lacks proper synchronization primitives, leading to potential inconsistencies during “in‑flight” migrations. (c) SEAMCALL leaf‑allowed checks rely on a hard‑coded whitelist, which does not automatically accommodate new SEAM APIs, creating a maintenance‑driven attack surface. (d) Key‑management functions (tdh_mng_key_config, tdh_mng_addcx) use insufficient entropy, raising the risk of key‑reuse attacks.

The authors propose a defense‑in‑depth roadmap. First, enforce a minimum‑privilege model for the VMM: every page handed to a TD must be signed and verified before mapping. Second, mandate hardware‑enforced zero‑ization and page‑table invalidation during TD_BLOCKED and TD_TEARDOWN to guarantee that no residual secret data remains. Third, make migration state transitions atomic by extending SEAMLOCK usage and inserting integrity checks before and after each SEAMCALL. Fourth, upgrade the key‑exchange protocol to use the latest hardware RNG and log all key‑material operations for auditability. Fifth, integrate the Gemini‑based specification parser and Notebook LM‑driven code‑path explorer into a continuous‑integration pipeline so that any future feature addition triggers automatic security analysis.

From an industry perspective, cloud providers must assume that the VMM is not fully trusted when offering TDX‑based confidential computing services, especially in multi‑tenant “shared VMM” deployments. The discovered memory‑leak bugs dramatically raise the risk of cross‑tenant data exposure. Organizations in regulated sectors (government, finance, health) that plan to use live migration for workload mobility must incorporate additional integrity verification and key‑rotation steps before and after each migration. Although Intel has already released patches in versions 1.5.24, 1.5.25, and the 2.0 series, the report stresses the importance of timely patch deployment and continuous vulnerability scanning for already‑deployed hardware.

In summary, this assessment demonstrates that adding advanced features such as live migration and nested TDs to a confidential computing platform introduces new attack vectors that cannot be mitigated by a single fix. A layered security approach—combining rigorous VMM verification, robust lifecycle management, atomic migration primitives, hardened key handling, and automated static/dynamic analysis—is essential to preserve the confidentiality guarantees promised by Intel TDX. The findings serve as a call to action for Intel, cloud operators, and the broader ecosystem to adopt security‑first design practices and to treat confidential computing as an evolving, continuously validated service.