Lost in Translation: Enabling Confused Deputy Attacks on EDA Software with TransFuzz

Lost in Translation: Enabling Confused Deputy Attacks on EDA Software with TransFuzz

Speakers: Flavien Solt, Researcher

Conference: USENIX Security

YouTube: https://www.youtube.com/watch?v=h5EFvVzBXvs

Overview

In the realm of hardware security, ensuring the integrity and functionality of integrated circuits is paramount. This talk, "Lost in Translation: Enabling Confused Deputy Attacks on EDA Software with TransFuzz," presented by Flavien Solt, delves into a critical and often overlooked vulnerability in the electronic design automation (EDA) toolchain. Solt exposes how bugs within RTL synthesizers and simulators can be maliciously exploited to inject hardware backdoors that are exceptionally difficult, if not practically impossible, to detect using conventional verification methods. The core premise revolves around the "unsoundness" of EDA software, where tools might misinterpret hardware descriptions, leading to a discrepancy between the verified design and the actual synthesized hardware.

The presentation highlights that while functional verification aims to ensure properties like correctness, confidentiality, and integrity, the underlying EDA tools themselves can introduce subtle yet catastrophic flaws. These flaws manifest as "translation bugs" – errors where the tool's internal representation or output differs from the original intent of the hardware description language (HDL) input. Solt demonstrates that these bugs are not only prevalent in widely used open-source EDA tools but can also be reliably weaponized to create sophisticated hardware Trojans. This work fundamentally challenges the assumption of trust in the EDA toolchain, revealing a novel attack surface that could compromise hardware at its most foundational level.

The implications of this research are profound for anyone involved in hardware design, verification, and supply chain security. As hardware development increasingly relies on complex EDA flows and integrates third-party intellectual property (IP), the potential for these "confused deputy" attacks to bypass rigorous verification processes poses a severe threat. Solt's findings compel a re-evaluation of current hardware security practices, emphasizing the need for robust defenses against attacks that leverage the very tools designed to ensure hardware correctness.

Background

▶ Watch: Introduction: Bugs in EDA software enable hardware backdoors (0:00)

The problem addressed by this research stems from what is termed "unsoundness" in hardware verification. Unsoundness refers to a situation where a verification process yields false negatives, meaning it incorrectly asserts that a property holds or a design works as expected, even when a bug exists. This can occur due to human error, but more critically, it can arise from bugs within the software that processes hardware representations. Solt categorizes these software bugs into two types: those directly within the verification tool itself, leading to incorrect verification outcomes, and time-of-check against time-of-use (TOCTOU) bugs. The latter involves a bug introduced after verification, where the design is initially verified as correct but then processed by a subsequent tool that introduces a flaw, leading to a malicious outcome in the final hardware.

The motivation for investigating EDA tool unsoundness is rooted in prior research. Solt references a USENIX presentation from three years prior, concerning information flow tracking (IFT) for hardware. When complex IFT instrumentation is added to a design, different simulators were found to produce conflicting results despite the deterministic nature of the circuits. This led to the first key observation: simulators are unfortunately not reliable. A second motivation came from a USENIX presentation two years prior, involving fuzzing a RISC-V core (CVA6) optimized with Yosys, a standard open-source synthesizer. During fuzzing, a bug was detected in the floating-point unit (FPU) of the CVA6. However, upon closer inspection, the bug was not in the original CVA6 FPU but was mistakenly introduced by the Yosys synthesizer. This led to the second critical observation: synthesizers also to some extent are unreliable.

Given these demonstrated unreliabilities, the research explores what a malicious actor can achieve. Two primary threat models are considered:

1. Malicious Contributor to an Open-Source Repository: In an era of collaborative hardware development (e.g., OpenTitan, PULP project, Chipyard project), a malicious contributor could commit seemingly innocuous RTL that exploits these bugs.
2. Malicious External IP Provider: An untrusted third-party IP vendor could supply IP that appears correct during verification but contains hidden malicious functionality.

These threat models lead to two distinct attack scenarios based on the type of EDA bug leveraged:

• Synthesizer Translation Bug: A malicious actor provides correct RTL containing a mistranslated construct – a specific code pattern that the synthesizer misunderstands. The verification tools correctly validate the input RTL as secure. However, the buggy synthesizer produces incorrect, malicious RTL in its output, injecting a backdoor into the final design.
• Simulator or Verifier Translation Bug: The malicious actor provides already bad RTL, but this RTL contains a mistranslated construct that causes simulators and verifiers to believe the design is correct and secure. The verification phase passes, giving the illusion of security. However, when this "verified" (but actually malicious) RTL is synthesized, it produces genuinely bad hardware, leading to a malicious outcome.

These attacks appear challenging, requiring both specific translation bugs and a reliable method to package them into hardware backdoors. However, Solt demonstrates that both aspects are surprisingly achievable.

Key Findings

▶ Watch: Second observation: Synthesizers also to some extent unreliable (5:00)

The research yielded significant findings that underscore the pervasive vulnerability of EDA tools. Through a systematic approach, Solt and his team discovered a total of 25 new vulnerabilities across all tested simulators and synthesizers. Crucially, 20 of these were identified as translation bugs, while the remaining 5 were more classical crash-style bugs. These translation bugs were not isolated to a single tool but were found in arguably the most popular open-source RTL simulators—Icarus Verilog, CXX-RTL, and Verilator—as well as the most popular open-source RTL synthesizer, Yosys. This widespread presence indicates that the issue of EDA tool unsoundness is not an anomaly but a systemic problem.

The most critical finding is the ease with which these translation bugs can be leveraged to inject highly potent and nearly undetectable hardware backdoors. Solt demonstrates that a single translation bug can be used to create a "mistranslation gadget" or "oracle" that provides different hardware semantics depending on whether the design is being simulated/verified or synthesized. For example, a construct that should produce a logical zero according to specification might be mistranslated by a specific buggy simulator (like Verilator) to produce a logical one. This creates a conditional behavior: a '1' if running under the buggy Verilator, and a '0' otherwise.

By combining such gadgets, attackers can construct sophisticated hardware backdoors that are effectively invisible to traditional white-box verification techniques. This capability bypasses the very mechanisms designed to ensure hardware integrity, forcing detection into later, much more difficult stages like post-synthesis netlist analysis or even post-silicon testing. The ability to reliably package these bugs into arbitrary backdoors represents a fundamental shift in the threat landscape for hardware security.

Technical Deep Dive

▶ Watch: Two threat models for malicious exploitation of EDA bugs (5:15)

The methodology for uncovering translation bugs relies on differential fuzzing. This technique involves providing randomized but deterministic circuit inputs to multiple EDA tools and comparing their outputs. For instance, the same circuit stimulus is fed to two different simulators (e.g., Verilator and Icarus Verilog) and their respective simulation models. The fuzzing process then checks for discrepancies in the output, indicating a bug in one or both tools' interpretation or execution. To generate these input circuits, abstract netlists are created and then passed to Yosys's Verilog back-end to produce inputs suitable for the simulators.

Ensuring determinism in the fuzzed inputs is critical for differential fuzzing to be effective. The research specifically addressed two key challenges in this regard:

1. X propagation: Unknown values (represented as 'X' in HDLs) can propagate differently across various simulators. For example, a division by zero might result in an 'X', but the exact rules for its propagation are not uniformly guaranteed across all tools. This variability can lead to false positives in differential fuzzing if not properly managed.
2. Ordering of events: Similar to the concurrency issues in hardware itself, simulators may not provide identical guarantees for the ordering of concurrent events. Differences in event scheduling can lead to divergent simulation results even for deterministic designs.

Once translation bugs are identified, the next step is to weaponize them into mistranslation gadgets or oracles. An example cited in the talk demonstrates a construct that, by Verilog specification, should always evaluate to zero. However, due to a bug in Verilator, this specific construct is mistranslated to produce a one. This effectively creates a "fingerprint" or "oracle" that can detect if the design is being processed by the buggy Verilator simulator versus any other tool. By logically combining such gadgets (e.g., using a large OR gate), an attacker can create a complex oracle that detects specific verification environments. This allows for the implementation of conditional hardware semantics: one set of behaviors when undergoing simulation/verification, and an entirely different, malicious set of behaviors when actually synthesized for deployment.

This approach fundamentally differs from classical RTL Trojans. In a classical RTL Trojan scenario, the malicious logic is embedded directly into the RTL code. While the attacker attempts to hide this logic (e.g., using magic values or activation only after specific instruction sequences), the backdoor is present in the RTL that is verified. White-box techniques like coverage-based fuzzing and formal verification are highly effective at discovering these types of backdoors because the malicious logic exists at the verification stage. However, with translation bugs, the situation changes drastically.

When leveraging a synthesizer bug, the malicious logic is not present in the original, verified RTL. It is only introduced by the buggy synthesizer during the translation process. The input RTL is clean, so white-box techniques find nothing.

When leveraging a simulator or verifier bug, the malicious logic is present in the input RTL, but it is rendered invisible or misinterpreted by the verification tools. The verification tools falsely report the design as secure, effectively "sanitizing" the view of the malicious RTL.

In both scenarios, the backdoor becomes undetectable at the RTL verification stage. This forces the victim to detect the backdoor only after synthesis or even after silicon manufacturing. At these later stages, detection becomes significantly more challenging and, in practice, often impossible. The complexity of synthesized netlists and the black-box nature of deployed silicon make it exceedingly difficult to uncover hidden conditional logic that might only activate under very specific, rare conditions. This makes these confused deputy attacks a particularly insidious threat to hardware integrity.

Demo / Proof of Concept

▶ Watch: Understanding attack scenarios: synthesizer vs. simulator translation bugs (6:00)

Flavien Solt presented two compelling proofs of concept (PoCs) to demonstrate the real-world applicability and potency of these confused deputy attacks:

1. Backdoor in the CVA6 CPU's Memory Management Unit (MMU):

• Context: This PoC simulates a scenario where a malicious contributor injects a backdoor into an open-source hardware repository. The target was the CVA6 core, a RISC-V CPU developed by ETH and maintained by the Open Hardware Group.
• Mechanism: A mistranslation gadget was integrated into the CVA6's MMU. The MMU is responsible for permission checks during memory access. The gadget was designed to interfere with these normal permission checks.
• Exploitation: By following a specific activation protocol, a user (operating at a lower privilege level) could exploit this backdoor to access supervisor pages—memory regions typically restricted to the operating system or higher-privileged software. This demonstrates a critical privilege escalation vulnerability. The general principle is that if an attacker can reliably flip a bit from '0' to '1' (or vice-versa) using a translation gadget, they can effectively control arbitrary logic, leading to outcomes like unauthorized access. The challenge for an attacker here is discretion, as overly intricate commits might raise suspicion during code review.

1. Malicious External IP in the OpenTitan Root of Trust:

• Context: This PoC addresses the threat model of a malicious external IP provider. The target was the OpenTitan root of trust, a critical security component, specifically leveraging a known vulnerability in the IBEX CPU (a 32-bit RISC-V core) which has previously been shown to be susceptible to bus-related issues.
• Mechanism: A malicious external IP was crafted to appear correct during simulation and verification. This IP contained a translation bug designed to trigger malicious behavior under specific conditions. When processed by a buggy synthesizer, or when the verifier itself was buggy, the IP would cause malicious bus transactions.
• Exploitation: These malicious bus transactions were specifically engineered to trigger the pre-existing, known vulnerability in the IBEX CPU. The result was that the OpenTitan root of trust, which is designed to be highly secure, would no longer be as safe as intended. The external IP, despite passing verification, would compromise the system's integrity by causing the IBEX CPU to misbehave on the bus, demonstrating how even a seemingly correct third-party component can undermine foundational security.

Both proofs of concept powerfully illustrate that these translation bugs are not merely theoretical curiosities but practical avenues for injecting sophisticated, stealthy, and highly impactful hardware backdoors that bypass conventional verification safeguards.

Defensive Implications

▶ Watch: How to find and package translation bugs for backdoors (8:00)

The findings presented by Flavien Solt have severe defensive implications for hardware security. The core challenge lies in the fact that these confused deputy attacks render traditional white-box verification techniques (such as formal verification, coverage-based fuzzing, and static analysis) ineffective at the RTL stage. Because the backdoor either doesn't exist in the verified RTL (synthesizer bug) or is rendered invisible to the verification tools (simulator/verifier bug), defenders are left in a precarious position.

The detection of these backdoors is forcibly shifted to post-synthesis or even post-silicon stages. At these later stages, the complexity of the hardware representation increases exponentially. A synthesized netlist is far more intricate and difficult to analyze than the original RTL. Furthermore, once a chip is fabricated (post-silicon), detection becomes a black-box problem, relying on runtime observations and extensive testing, which is often infeasible for complex, rare activation conditions. As Solt states, detecting such backdoors after synthesis or silicon is "much more difficult to detect it and impossible in practice."

This research necessitates a fundamental shift in how hardware security is approached. Defenders must consider the trustworthiness of their entire EDA toolchain, not just the RTL code itself. This could involve:

• Trusting the Toolchain: Developing methods to verify the correctness of EDA tools, perhaps through formal methods or extensive differential testing against a trusted reference.
• Enhanced Post-Synthesis Verification: Investing in more advanced techniques for analyzing synthesized netlists for anomalous behavior or discrepancies from the original RTL. This is a significantly harder problem than RTL analysis.
• Runtime Monitoring: Implementing robust hardware-level runtime monitoring capabilities that can detect unexpected behaviors or deviations from intended functionality, even if the underlying logic was injected maliciously.
• Supply Chain Security: Extending the concept of supply chain security to include the EDA tools themselves, ensuring they are not compromised.
• Redundant Verification: Potentially using multiple, diverse EDA toolchains for critical designs and comparing their outputs to detect inconsistencies, though this is costly and may not always catch subtle translation bugs.

The presenter indicated that they are "currently pursuing defense work as well to protect against such attacks," which suggests ongoing efforts to address this critical vulnerability. However, the current state highlights a significant blind spot in hardware security that needs urgent attention from both academia and industry.

Key Takeaways

• EDA Tools are Unreliable: RTL synthesizers and simulators, even widely used open-source ones like Yosys, Verilator, and Icarus Verilog, contain significant bugs, including 25 new vulnerabilities identified in this research.
• Pervasive Translation Bugs: A substantial portion of these vulnerabilities (20 out of 25) are translation bugs, where tools misinterpret hardware descriptions, leading to discrepancies between the intended and actual hardware.
• Confused Deputy Attacks: These translation bugs can be easily packaged into mistranslation gadgets or "oracles" that allow attackers to create conditional hardware semantics, effectively injecting backdoors that activate only under specific conditions (e.g., when synthesized, but not when simulated).
• Undetectable by White-Box Methods: Unlike classical RTL Trojans, these backdoors are nearly undetectable during the RTL verification stage because they are either introduced post-verification (synthesizer bugs) or rendered invisible to verification tools (simulator/verifier bugs).
• Forced Post-Silicon Detection: Detection is pushed to post-synthesis or post-silicon stages, where it becomes "impossible in practice" due to increased complexity and black-box conditions.
• Critical Impact on Hardware Security: This research exposes a fundamental flaw in the hardware design and verification toolchain, creating a novel and potent attack surface for injecting stealthy hardware backdoors into critical systems like CPUs and roots of trust.

About the Speaker(s)

Flavien Solt is a researcher whose work focuses on hardware security, particularly investigating vulnerabilities within the electronic design automation (EDA) toolchain. His presentation at USENIX Security on "Lost in Translation: Enabling Confused Deputy Attacks on EDA Software with TransFuzz" showcases his expertise in uncovering and demonstrating novel attack vectors against hardware integrity. This talk builds upon his previous research presented at USENIX conferences, which highlighted the unreliability of RTL simulators and synthesizers. While the provided metadata does not specify his institutional affiliation or formal title, his detailed technical presentation and contributions to the field underscore his role as a significant contributor to hardware security research.