On Friday October 24 2025 at 10:05 am UTC, a recent timing-based attack targeting Intel TDX came to our attention. As a result, we conducted an internal analysis to assess its potential impact on our products.
According to our analysis, the attack can potentially recover data from non-constant-time functions inside TDX. For the attack to be successful, it requires full control of the host, modifications to the hypervisor, and the ability to identify the guest’s target code pages. We concluded that none of our current TEE products are directly impacted by the T-Time attack, as our deployments are hosted on trusted cloud providers, where we trust that they do not perform any malicious actions at the hypervisor level, in accordance with the shared responsibility model.
Nevertheless, as the authors suggest, we will audit all code running inside our TEEs to ensure that security-critical components, such as key generation and secret handling, use constant-time implementations.
Details:
The attack is a fine-grained, timing-based controlled-channel that targets page faults on critical code pages to extract sensitive information by measuring the dwell time between faults. The prerequisites for the attack are a fully-privileged, malicious host with control of the system (see the “Attack requirements” section below). The attack also uses cache-eviction/aliasing techniques to amplify timing differences and improve accuracy. The authors demonstrated the attack against vulnerable libraries and the affected maintainers issued fixes. Notably, Intel replied “no further actions required” (page 2) to the disclosure.
Attack requirements:
- Access to the host machine is required to install custom hypervisor and kernel modules. See the authors’ experimental setup for details.
- It also requires adjusting the VM configuration, such as pinning a single core and its sibling core (in case of hyperthreading enabled) to the VM. Then setting the CPU core frequency and Turbo Boost to a fixed small value to avoid timing discrepancies due to CPU non-deterministic throttling.
- The attack also requires running custom code inside the TDX guest to extract values needed for the exploit and to implement the necessary attack logic. (See here and here).
- The documentation is slightly unclear about whether some kernel-command-line changes must be applied to the guest or the host. If the change is applied to the guest TDX VM, it would be detectable in our attestation measurements (RTMR values). If it is applied only to the host, it falls under the host-level attacker capabilities described above.