Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue

TDXploit: Novel Techniques for Single-Stepping and Cache Attacks on Intel TDX

Speakers: Fabian Rauscher (Graz University of Technology); Luca Wilke (University of Lübeck); Hannes Weissteiner (Graz University of Technology); Thomas Eisenbarth (University of Lübeck); Daniel Gruss (Graz University of Technology)

Conference: USENIX Security

Paper page: https://www.usenix.org/conference/usenixsecurity25/presentation/rauscher

Paper PDF: https://www.usenix.org/system/files/usenixsecurity25-rauscher.pdf

Overview

Intel Trust Domain Extensions (TDX) represent the second generation of Trusted Execution Environments (TEEs), designed to protect entire virtual machines (VMs), known as trust domains (TDs), from a potentially malicious host system. While TDX aims to provide robust memory and state isolation, the shared underlying hardware often introduces side channels, posing a significant security challenge. This paper, "TDXploit: Novel Techniques for Single-Stepping and Cache Attacks on Intel TDX," authored by Fabian Rauscher, Luca Wilke, Hannes Weissteiner, Thomas Eisenbarth, and Daniel Gruss, unveils critical vulnerabilities in Intel's latest TDX implementations, specifically addressing its single-stepping mitigations and memory access defenses.

The research introduces TDXploit, a groundbreaking technique that revives instruction-granular single-stepping attacks on Intel TDX, even against the most recent module version (1.5.06) designed to thwart such exploits. Intriguingly, TDXploit not only bypasses Intel's countermeasures but achieves a higher single-stepping accuracy than if no mitigation were present. Furthermore, the paper reveals a novel Flush+Flush attack on TDX private memory, demonstrating that the clflush instruction on 5th generation Intel Xeon Scalable CPUs bypasses architectural isolation, enabling powerful cache-based side-channel attacks without requiring shared memory.

These findings are profoundly significant for the field of confidential computing. Single-stepping is considered one of the most potent attack primitives against TEEs, as it grants attackers precise control over victim execution, amplifying the effectiveness of various side-channel attacks. The discovery that clflush can directly target and evict private TD memory fundamentally undermines TDX's memory isolation guarantees. The authors demonstrate the real-world impact through end-to-end attacks, including full key recovery on AES and TOTP secrets, underscoring the necessity for further hardware and software mitigations to secure Intel TDX against these sophisticated threats.

Background

The evolution of confidential computing has seen two primary generations of Trusted Execution Environments. The first generation, exemplified by Intel Software Guard Extensions (SGX) and ARM TrustZone, focuses on protecting application components or enclaves from a compromised host, typically on personal computers. While effective, these often require applications to be specifically adapted for the TEE environment, limiting their broad applicability.

The second generation of TEEs, including AMD Secure Encrypted Virtualization (SEV) and Intel Trust Domain Extensions (TDX), addresses this limitation by allowing entire virtual machines to run within a secure environment, known as confidential virtual machines (CVMs) or trust domains (TDs). Intel TDX, specifically, encrypts guest memory and state, managed by the TDX module running in a new SEAM root execution mode, protected from the host. It leverages Intel's existing VMX extensions for VM management and Total Memory Encryption - Multi Key (TME-MK) to encrypt TD memory using unique Key IDs (HKIDs). TDX splits guest physical memory into private (encrypted, managed by TDX module) and shared (accessible by host and guest) parts. Despite these isolation mechanisms, the underlying CPU hardware and memory subsystem remain shared resources, creating an inherent attack surface for side channels.

Side-channel attacks have historically plagued TEEs, with early work on SGX demonstrating vulnerabilities to cache attacks (e.g., Flush+Reload, Prime+Probe), branch prediction unit attacks (PHT, BTB), and power analysis. A particularly potent primitive in the TEE threat model is single-stepping, which allows an attacker to execute a victim's code one instruction at a time. This fine-grained control enables powerful attacks such as instruction counting, precise timing of operations, and the targeted application of side channels to specific code segments. Previous single-stepping frameworks like SGX-Step for Intel SGX and SEV-Step for AMD SEV relied on mechanisms like APIC timer interrupts to force TEE exits after each instruction.

Recognizing the threat, Intel incorporated a mitigation against single-stepping into the TDX module. The initial mitigation attempted to detect single-stepping attempts by observing interrupt-based VM exits and small instruction pointer changes within a short time frame, relying on the timestamp counter (TSC). If detected, it would execute a random number of guest instructions (between 1 and 32) before returning control to the host, obscuring the precise instruction count. However, Wilke et al. [55] bypassed this initial defense (dubbed TDXdown) by manipulating CPU frequency to trick the TSC-based detection. In response, Intel released TDX module version 1.5.06, introducing the Instruction-Count Single-Step Defense (ICSSD). ICSSD utilizes performance counters instead of the TSC for detection, making it resilient to CPU frequency manipulations and effectively stopping all previously known single-stepping attacks on TDX. Prior to the work presented in this paper, no known reliable single-stepping primitive existed for Intel TDX with ICSSD enabled, leaving attackers with only fuzzy instruction count information.

Key Findings

This research introduces several critical findings that significantly impact the security posture of Intel TDX:

1. TDXploit: Revival of Reliable Single-Stepping: The paper introduces TDXploit, a novel technique that completely bypasses Intel's ICSSD mitigation in TDX module version 1.5.06, re-enabling precise single-stepping. This attack achieves an exceptional accuracy of >99.99% (observing only 2 misclassifications over 85 million instructions) and can perform one single-step every 3.7 ms. Remarkably, this accuracy is higher than what would be achieved without any mitigation in place.
2. Exploitation of Mitigation's Internal State: TDXploit's success stems from exploiting a fundamental flaw in Intel's single-stepping mitigation. The mitigation uses a per-core 32-bit Linear-Feedback Shift Register (LFSR) for generating the "random" number of instructions to execute. The authors discovered that this LFSR state is shared across all TDs on the same core and can be fully recovered with just 32 samples using an attacker-controlled TD. This allows the attacker to not only predict the mitigation's behavior without side channels but also manipulate it for reliable single- and multi-stepping.
3. Novel Flush+Flush Attack on TDX Private Memory: A significant discovery is that the clflush instruction on 5th generation Intel Xeon Scalable CPUs (e.g., Intel Xeon Silver 4514Y) ignores HKIDs and flushes all cache lines associated with a physical address, regardless of the encryption key. This contradicts Intel's documentation and prior findings on 4th generation CPUs. This behavior enables Flush+Flush attacks on any TDX guest physical memory location, even without requiring shared memory between the attacker (host) and the victim (guest).
4. Systematic Side-Channel Evaluation: The paper systematically evaluates six state-of-the-art side-channel attack techniques (Flush+Reload, Evict+Reload, Flush+Flush, PortSmash, Prime+Probe (L1), HKID Coherence) against Intel TDX.

• Host-to-Guest: Flush+Flush, PortSmash, Prime+Probe (L1), and HKID Coherence are all found to be effective.
• Guest-to-Host & Guest-to-Guest: Only PortSmash and Prime+Probe (L1) are found to work in these "malicious guest" scenarios, which had not been extensively studied for TDX prior to this work. Flush+Reload and Evict+Reload are deemed ineffective due to the lack of shared memory.

1. Potent End-to-End Attacks: The practical impact of these findings is demonstrated through several end-to-end attacks:

• AES T-Table Key Recovery: Using only the novel Flush+Flush primitive, the authors performed a full key recovery on an OpenSSL AES T-Table implementation, requiring only 8,986 encryption traces.
• TOTP Secret Leakage: By combining TDXploit with the novel Flush+Flush, the authors successfully leaked Time-based One-Time Password (TOTP) secret keys with a single trace. This attack was previously only demonstrated on AMD SEV using performance counter leakage, which is mitigated on TDX.
• OpenSSL ECDSA Attack Re-enabled: TDXploit successfully re-enables a previously mitigated attack on the OpenSSL ECDSA implementation, demonstrating its ability to bypass Intel's ICSSD. This attack requires observing 33 biased signatures, amounting to approximately 200,000 signature generations.

In summary, TDXploit fundamentally undermines Intel's single-stepping mitigation, while the clflush vulnerability exposes TDX private memory to powerful cache side-channel attacks. These findings highlight the persistent challenges in securing TEEs against sophisticated microarchitectural exploits.

Technical Deep Dive

The core of TDXploit lies in the meticulous deconstruction and exploitation of Intel's single-stepping mitigation mechanism. Intel's mitigation, part of the TDX module, aims to prevent precise instruction-granular control over guest execution by introducing noise. This noise manifests as the execution of a random number of instructions (between 1 and 32) within the guest before returning control to the host. The determination of this "random" number is central to the attack.

The mitigation employs two detection methods. The first is a heuristic that flags single-stepping if a VM entry occurred less than 2-3 µs ago and the instruction pointer changed by less than 32 bytes. This heuristic was previously bypassed by manipulating CPU frequency. The second, more robust method is the Instruction-Count Single-Step Defense (ICSSD), which uses performance counters to measure executed instructions. ICSSD is activated if the guest is not allowed to use performance counters; otherwise, the heuristic is used. When a potential attack is detected, the TDX module uses a per-core 32-bit Linear-Feedback Shift Register (LFSR), initialized once when the TDX module loads, to generate the random number. The 5 least significant bits of the LFSR output, plus one, determine the number of instructions to execute. The VMX monitor flag is then used to single-step the guest for this determined count, masking external interrupts to prevent host interference.

TDXploit's Exploitation of the LFSR:

The key insight of TDXploit is that this LFSR, while generating a sequence that appears random, is fundamentally predictable due to its linear nature and fixed polynomial (0xB4BCD35C). The LFSR's state is also per-core, meaning an attacker-controlled TD running on the same logical CPU core as a victim TD will interact with the same LFSR state.

The attack proceeds in two main phases:

1. LFSR State Recovery: The attacker launches an attacker-controlled TD on the target logical CPU core. This TD executes a small assembly loop (Listing 1 in the paper) that repeatedly signals the Virtual Machine Monitor (VMM) via a VM call that it's ready for a measurement. The VMM then sets up the APIC timer to immediately trigger an external interrupt and resumes the attacker TD. As interrupts are masked until the TD is entered, the pending interrupt causes a VM exit before any instruction in the attacker TD is executed. This triggers the ICSSD mitigation. The attacker TD's code following the VM call consists of add instructions that increment a counter in a shared, unencrypted memory location. When control returns to the VMM, it reads the counter's delta, which reveals the number of instructions executed by the mitigation. By repeatedly triggering the mitigation (32 times), the attacker can recover 32 bits of the LFSR's output (specifically, the least significant bit of the instruction count), allowing them to reverse-engineer the full 32-bit internal state of the LFSR.
2. Predictive Single-Stepping: Once the LFSR state is recovered, the VMM can predict all future outputs of the LFSR for that specific core. To achieve single-stepping, the VMM continuously triggers the mitigation using the attacker TD until the predicted next output of the LFSR is exactly '1'. At this precise moment, the VMM pauses the attacker TD and schedules the victim TD. The victim TD then executes exactly one instruction, enforced by the TDX mitigation itself, which ironically becomes the attacker's tool. After the single-step, the victim TD is paused, and the attacker TD is resumed to advance the LFSR state until the next '1' output is predicted. This method ensures reliable single-stepping because the number of instructions executed is architecturally guaranteed by the TDX module, eliminating zero-steps or multi-steps. This technique also enables controlled multi-stepping by scheduling the victim when the LFSR predicts a desired number of steps greater than one.

TDX Flush+Flush on Private Memory:

Traditional Flush+Flush attacks rely on shared memory to detect cache accesses. An attacker flushes a shared memory line (clflush) and measures the time it takes for a subsequent access. If the victim accesses the line, the attacker's subsequent access will be slower (a miss). This attack has been considered challenging on TDX private memory due to architectural isolation.

TDX protects guest private memory using TME-MK, where each memory region is associated with a unique HKID. A host attempting to read memory encrypted with a private HKID receives all-zero data, preventing direct information leakage. Prior work on 4th generation Intel Xeon Scalable CPUs indicated that clflush would respect HKIDs, meaning a host flushing with a public HKID would not affect a cache line loaded with a private HKID.

However, the authors discovered a critical microarchitectural change on 5th generation Intel Xeon Scalable CPUs (e.g., the Intel Xeon Silver 4514Y used in their evaluation). On these CPUs, the clflush instruction ignores HKIDs. This means that a host, even when using the public HKID (or zero HKID), can issue a clflush instruction to a physical memory address that is privately mapped and encrypted for a TD, and this clflush will successfully evict the corresponding cache line from the CPU's caches (L1, L2, L3).

This finding fundamentally bypasses TDX's memory isolation for cache side channels. The host, having control over physical memory mappings, can map any physical memory address used by a TD. By repeatedly flushing a target memory location and timing its own subsequent access, the host can detect if the TD has recently accessed that memory location. This new Flush+Flush variant does not require shared memory, nor does it rely on the HKID coherence mechanism (which Intel plans to mitigate), making it a robust and persistent threat. Experimental results show that while miss timings are similar to native Flush+Flush (~80 cycles), hit timings for TDX private memory are higher (~160 cycles), indicating additional overhead but maintaining a clear hit-miss distinction for effective exploitation (Figure 2 in the paper). Crucially, guest access timings after a host-initiated clflush (250.6 cycles) are almost identical to guest-initiated flushes (252.5 cycles), confirming the host's ability to evict guest private memory from the cache (Figure 3 in the paper).

Demo / Proof of Concept

The researchers demonstrate the practical impact of TDXploit and the novel Flush+Flush attack through several end-to-end proofs of concept, showcasing their ability to extract sensitive information from Intel TDX guests.

OpenSSL ECDSA Key Recovery (TDXploit)

The first demonstration re-creates a previously mitigated attack on the OpenSSL ECDSA implementation, originally presented by Wilke et al. [55]. This attack targets the modular reduction routine bn_div_fixed_top within OpenSSL's bn_div.c (simplified in Listing 2 of the paper). The vulnerability arises because the amount of instructions executed by this function varies depending on the secret nonce k used for ECDSA signature generation. Specifically, for the brainpoolp224r1 curve, certain instruction counts leak the 7 most significant bits of the nonce k. Signatures generated with these biased nonces can then be used to recover the full secret key, requiring 33 biased signatures out of approximately 200,000 signature generations due to the low probability of the biasing event.

To orchestrate this attack, the malicious VMM first uses page fault tracking (or similar techniques) to identify unique page fault patterns that indicate the victim TD is about to execute the vulnerable bn_div_fixed_top function. Once the relevant code section is identified, TDXploit is employed to precisely single-step the victim TD through this vulnerable code. The instruction count variations are observed, allowing the attacker to deduce information about the nonce. While the TDXploit-enabled attack is slower than the original, now-mitigated, single-stepping attack (119.7 ms per signature vs. 0.06258 ms per signature), its significance lies in its ability to reliably bypass Intel's ICSSD and re-enable this high-impact cryptographic side channel on the latest TDX platforms.

AES T-Table Key Recovery (Flush+Flush Standalone)

To demonstrate the standalone effectiveness of the novel Flush+Flush attack on TDX private memory, the authors perform a full key recovery on an OpenSSL AES T-Table implementation. Unlike traditional Flush+Flush attacks, this does not require shared memory.

The attack proceeds as follows:

1. Locating T-Tables: The attacker, as the host, cannot directly read the guest's private memory. Instead, they use Flush+Flush as a profiling tool to search the guest's physical address space for the AES T-Tables. During an AES encryption, almost all cache lines within the T-Tables are accessed. By observing which memory locations become cached after an AES operation (detected, for example, by network traffic or page fault tracking), and matching these to the known page offsets and size of T-Tables, the attacker can pinpoint the correct memory locations. This process achieves 99.2% accuracy in locating T-Tables after only 10 encryptions.
2. Last-Round Attack: With the T-Table locations identified, the attacker performs a last-round AES attack, assuming known ciphertext. By continuously flushing the T-Table memory locations and observing accesses during AES encryption, the attacker can deduce information about the secret key. The attack successfully recovers the full AES key after 8,986 encryptions (with a standard deviation of 119 over 100 runs). This figure is comparable to results from native Flush+Flush attacks, highlighting that the TDX-based Flush+Flush introduces no significant additional noise (Figure 5 in the paper compares hit-miss heatmaps for native vs. TDX Flush+Flush, showing similar diagonal visibility, indicating low noise).

TOTP Secret Leakage (TDXploit + Flush+Flush Combination)

The most impactful demonstration showcases the combined power of TDXploit and the novel Flush+Flush to leak TOTP secret keys with exceptional efficiency. This attack targets a vulnerable TOTP library [46], previously exploited on AMD SEV using performance counters.

The vulnerability lies in the base32 decoding loop (Listing 3 in the paper) used to process the TOTP secret. For each character of the secret, the algorithm iterates through a lookup table (OTP_DEFAULT_BASE32_CHARS) to find a match. When a match is found, the comparison loop breaks, and the index is saved. The lookup table is small enough (32 bytes) to fit into a single cache line.

The combined attack works as follows:

1. Single-Stepping with TDXploit: TDXploit is used to provide instruction-granular control over the execution of the TOTP base32 decoding function.
2. Monitoring with Flush+Flush: Concurrently, Flush+Flush is used to monitor the single cache line containing OTP_DEFAULT_BASE32_CHARS.
3. Deducing Secret: As the library compares a character with entries in the lookup table, the Flush+Flush attack detects accesses. The key insight is that the processing of correct characters causes a different branch to execute, leading to a delay of 6 instructions between accesses, whereas incorrect character comparisons result in 5 instructions between accesses. By distinguishing these subtle timing differences in memory accesses, the attacker can track the decoding algorithm's execution and determine the exact characters of the secret. Additional overheads (e.g., 58 instructions after every 8 characters decoded) are also accounted for.

Even with some noise from branch prediction and out-of-order execution, the attack successfully extracts the TOTP secret key from a single trace in 79.2% of cases. By taking three traces and using a majority vote, the success rate increases to 99.0%. The entire attack takes approximately 9.1 seconds to generate a single trace, resulting in a total attack time of less than 30 seconds for key recovery. This demonstrates a critical synergy: neither single-stepping alone (which would only provide total instruction count) nor Flush+Flush alone (which lacks the temporal resolution to differentiate instruction counts precisely) could achieve this result.

Defensive Implications

The findings presented in "TDXploit" highlight several critical areas where Intel TDX requires immediate and significant defensive enhancements, spanning both software and potentially hardware changes.

Mitigations for TDXploit (Single-Stepping)

The attack on Intel's single-stepping mitigation, TDXploit, reveals fundamental flaws that can be addressed:

1. Improved RNG Implementation: The current reliance on a per-core LFSR for generating random instruction counts is a severe vulnerability. LFSRs are notoriously poor for security-critical randomness due to their linearity and ease of state recovery. Intel must replace the LFSR with a cryptographically secure pseudo-random number generator (CSPRNG). Given that the mitigation is rarely triggered and involves expensive VM exits, the minor performance overhead of a proper CSPRNG would be negligible compared to the security benefits.
2. Per-vCPU RNG State: TDXploit relies on the fact that the LFSR state is per-core, allowing an attacker-controlled TD to recover and manipulate the state for a victim TD on the same core. Implementing a per-TD or per-vCPU RNG state would effectively isolate the random number generation, preventing one TD from inferring or influencing the mitigation behavior of another. While this alone might not fully mitigate attacks if the RNG is weak (e.g., if another side channel could still leak LFSR state), it significantly increases the attack complexity. The existing TDVPS mechanism already provides per-vCPU state storage, making this a feasible change.
3. Improved RNG Range and Stepping Mechanism: The current range of 1 to 32 steps is too limited. The authors recommend excluding '1' from the random step count, as executing a single instruction is precisely what the mitigation aims to prevent. Furthermore, the mechanism for executing these steps (using the VMX monitor flag, leading to multiple expensive VM entries/exits) limits the practical range. They propose alternative mechanisms like the VMX-preemption timer or Performance Monitoring Interrupts (PMIs).

• The VMX-preemption timer decrements with every guest cycle, triggering a VM exit at zero. This would allow a significantly larger number of instructions to be executed in the guest with a constant number of VM exits, drastically increasing the attacker's overhead and reducing the precision of side channels trying to infer instruction counts. It would require combining with performance counters to ensure enough instructions are executed.
• PMIs can be configured to trigger on performance counter overflows. Using the same performance counter already employed by ICSSD, PMIs could trigger after a random number of instructions, again increasing the instruction count without scaling VM exit overhead. This would require buffering interrupts within the TDX module until the mitigation completes.

These changes would increase the noise introduced by the mitigation and reduce the ability of an attacker to precisely control or measure execution flow.

Mitigations for Flush+Flush on TDX Private Memory

The discovery that clflush ignores HKIDs on 5th generation Intel Xeon Scalable CPUs is a critical hardware-level vulnerability that cannot be fully addressed by software changes alone.

1. Hardware Fix for HKID-Aware clflush: The most robust mitigation is a hardware change to make the clflush instruction respect HKIDs, as it reportedly did on 4th generation Xeon Scalable CPUs. If clflush were HKID-aware, a host using a public HKID would not be able to evict cache lines belonging to a TD's private memory (which uses a private HKID). There is no known valid use case for clflush ignoring HKIDs in a TEE context.
2. Dedicated Page-Granular Flushing Mechanism: As an alternative or complementary measure, Intel could implement a dedicated, page-granular flushing mechanism similar to what AMD SEV provides. This would allow explicit flushing of memory pages when they are transitioned between private and shared states, or when returned to the host, ensuring that no stale data or cache state remains accessible to a malicious entity.

General Implications

The paper concludes that further mitigations against single-stepping and side channels on TDX are necessary. Single-stepping, in particular, acts as a powerful amplifier for other side-channel attacks. The ability to precisely control execution flow dramatically increases the efficacy of cache attacks, port contention attacks, and other microarchitectural side channels, making it easier to extract sensitive data like cryptographic keys or secrets. The findings underscore the continuous cat-and-mouse game between TEE developers and security researchers, highlighting that even robust architectural isolation can be undermined by subtle microarchitectural behaviors and implementation flaws.

Key Takeaways

• TDXploit bypasses Intel's ICSSD: A novel technique re-enables reliable, instruction-granular single-stepping on Intel TDX module version 1.5.06, achieving >99.99% accuracy by exploiting flaws in the mitigation itself.
• LFSR RNG vulnerability: TDXploit exploits the per-core 32-bit LFSR used in Intel's single-stepping mitigation, demonstrating that its state can be fully recovered with just 32 samples, allowing for precise prediction and manipulation of TD execution.
• Novel Flush+Flush on TDX private memory: The clflush instruction on 5th generation Intel Xeon Scalable CPUs ignores HKIDs, enabling Flush+Flush attacks on any TDX guest physical memory without requiring shared memory, fundamentally undermining TDX's memory isolation.
• Powerful end-to-end attacks demonstrated: The combined use of TDXploit and the novel Flush+Flush allows for single-trace TOTP secret key leakage and re-enables previously mitigated OpenSSL ECDSA attacks. The Flush+Flush alone enables full AES key recovery in ~8,986 encryptions.
• Systematic side-channel evaluation: The research systematically evaluates six state-of-the-art side channels against TDX, confirming the viability of Flush+Flush, PortSmash, Prime+Probe (L1), and HKID Coherence in host-to-guest scenarios, and PortSmash and Prime+Probe (L1) in malicious guest scenarios.
• Urgent need for further mitigations: Intel TDX requires significant defensive enhancements, including replacing the vulnerable LFSR with a secure RNG, implementing per-vCPU RNG states, improving the random step range, and a hardware fix to make clflush HKID-aware.

About the Speaker(s)

The research presented in "TDXploit" is a collaborative effort by a team of distinguished security researchers from two prominent European universities.

Fabian Rauscher, Hannes Weissteiner, and Daniel Gruss are affiliated with the Graz University of Technology. Daniel Gruss is particularly well-known in the security community for his extensive work on microarchitectural side-channel attacks, including groundbreaking research on Spectre, Meltdown, and various cache-based exploits, frequently pushing the boundaries of TEE security. Their contributions to this paper likely stem from their deep expertise in these areas.

Luca Wilke and Thomas Eisenbarth are from the University of Lübeck. Luca Wilke has prior work cited in this paper (e.g., TDXdown, SEV-Step), indicating a specialization in TEE single-stepping attacks and related bypass techniques on platforms like AMD SEV and Intel TDX. Thomas Eisenbarth's involvement likely adds expertise in cryptographic implementations and their vulnerabilities to side-channel attacks.

Collectively, the authors represent a formidable team with significant experience in confidential computing, microarchitectural security, and the development of sophisticated attacks against trusted execution environments, making their findings particularly impactful for the security of modern cloud infrastructure.