High-level synthesis (HLS) is gaining popularity because it allows hardware accelerators to be specified at a higher level of abstraction, such as C or C++, rather than at the Register Transfer Level (RTL). While constant-time (CT) programming is heavily used to mitigate timing side channels in programs executed on CPUs, it is unclear if these software rules provide adequate protection when an HLS compiler turns CT software into hardware. To address this, we introduce TurboTurtle, the first fuzzer capable of testing HLS flows against timing side channels, alongside CTurtle, the first C program generator that creates random programs adhering to known and customizable CT rules.
Check out our paper (presented at CCS’26) and open source implementation. This paper was written in collaboration with DYNAMO.
Main Findings
Our systematic evaluation of four state-of-the-art HLS compilers revealed that applying standard CT software rules is not always sufficient to guarantee secure hardware. The key findings include:
- We discovered 12 new vulnerabilities where HLS flows converted CT software into non-CT hardware.
- Our research resulted in the assignment of two CVEs (CVE-2026-23894 and CVE-2026-23895).
- Eight of the discovered vulnerabilities establish unsafe C operators for specific HLS flows.
- Three vulnerabilities persist even after applying our newly discovered CT rules.
- HLS compilers can unpredictably insert data-dependent decisions at any stage of the HLS flow, breaking CT programming expectations.
Motivation
In traditional software development, CT programming rules explicitly forbid secret-dependent control flow, secret-dependent memory accesses, and passing secrets to instructions with data-dependent timing. CPU vendors frequently provide data-independent timing (DIT) specifications so developers know which instructions are safe.
However, HLS compilers lack DIT specifications, leaving users completely unaware of which high-level programming constructs are safe to synthesize. Because HLS compilers do not compile code into CPU assembly instructions, developers cannot hard-code assembly to guarantee security, creating a critical gap in HLS security.
Methodology: TurboTurtle and CTurtle
We introduce CTurtle, the first program generator that constructs random programs that follow CT rules. These rules are customizable, allowing HLS tool-specific rules. To assess whether programs generated with CTurtle are synthesized into vulnerable RTL code, we introduce TurboTurtle, which runs a fuzzing and verification pipeline.
CTurtle
To systematically find side channels introduced by HLS flows, we require high-level programs that are free from timing side channels. No prior program generator could produce random C programs that strictly follow custom CT rules. Thus, we would have had to generate random C programs and check them against CT with existing CT verification tools. However, such tools do not allow the customization of CT rules, required for HLS. Moreover, they often work at CPU assembly level and HLS does not compile programs to CPU instructions.
For these reasons, we built CTurtle. CTurtle maintains a secret and a public data flow during program construction, generating valid code that is CT with respect to specified secret inputs and customized rules. CTurtle may be configured to consider HLS-specific configurations, pragmas and directives as CT rules.
TurboTurtle
TurboTurtle takes C programs as inputs, synthesizes them using random HLS configurations, and automatically generates a miter testbench. Miters track information flows as difference between two copies of the same RTL (see Pathfinder). TurboTurtle simulates the testbench with several thousand random inputs and detects timing side channels by assessing whether secret inputs are able to influence the ‘done’ signal of the HLS-generated circuit, which indicates the completion of the accelerated operation.
Once a program is found to be vulnerable, it can be time consuming to find the root cause within thousands of HLS generated lines of RTL code. TurboTurtle also employs an automated C statement and HLS configuration reduction algorithm to pinpoint the C code snippet or compiler flag responsible for the vulnerability.
Discovered Vulnerabilities
We evaluated two open-source HLS tools (Dynamatic and Bambu) alongside two commercial tools.
Some of the most notable vulnerabilities discovered include:
- Unsafe Bambu Operators: We found that several operations, including integer division, modulo operators, and various floating-point operations and conversions, are insecure in Bambu under specific configurations.
- Short-Circuit Evaluation (Dynamatic CVE-2026-23895): Short-circuit evaluation in C allows that the right-hand side of a logical AND/OR operation is not evaluated, if the left-hand side determines the output already. For example, in the snippet below, function() does not need to be called, if SECRET is 0:
GCC and Clang emit SECRET-dependent branches for this statement. This statement can also be vulnerable when compiled for a CPU (e.g., for x86). Interestingly though, we did not observe a timing side channel in the closed-source tools with this snippet.
- Dynamatic Backend Vulnerability (CVE-2026-23894): The following code snippet is suggested by state of the art methods (Constantine) that linearize control flow and thus render programs constant time:
LLVM compiles this multiplication with a secret-dependent binary value (the condition result) into a select statement that can be lowered into constant-time conditional moves when targeting CPUs. This requires the division result to be available when the conditional move is executed. Dynamatic’s backend realizes the optimization potential and implements RTL code that only performs the division when the secret-dependent condition is true, thus leaking the secret via a timing side channel.
Real-World Impact
These vulnerabilities can compromise actual cryptographic and machine-learning workloads. For example, the Dynamatic backend vulnerability affects state-of-the-art constant-time lookup patterns used in cryptographic libraries, as well as (somewhat ironically) the fallback solution for a CT select in LLVM that is used when compiling for a non-supported CPU (or in our case HLS). Furthermore, floating-point to integer conversions, which cause timing side channels in Bambu, are utilized in dynamic range quantization and neural network inference operators such as Google’s XNNPACK.
Paper and Code
Our fuzzer, TurboTurtle, is readily available and open-source. You can find the code, generated programs, scripts, and documentation on our GitHub repository. The paper will be presented at the ACM CCS 2026 conference.
Acknowledgements
This work has been supported by a Qualcomm Innovation Fellowship, the Swiss State Secretariat for Education, Research and Innovation under contract number MB22.00057 (ERC-StG PROMISE), and by the Swiss National Science Foundation (grant number 215747).
Frequently Asked Questions
Can you use CTurtle to fuzz C compilers targeting CPUs?
Yes, CTurtle emits generic C programs and you may customize the CT rules according to your CPU’s DIT specification. CTurtle optionally adds HLS-specific pragmas or directives.
Can you test whether a given C program is synthesized into a vulnerable RTL code?
Yes, absolutely, see our case studies. You can pass an arbitrary C program to TurboTurtle, mark some program input as ‘secret’ and check with TurboTurtle, whether the generated RTL code completes in constant time.
Note, that if your C program is vulnerable at C code level (e.g., executes different amounts of statements depending on the secret’s value), and TurboTurtle detects a timing side channel, the vulnerability was not inserted by the HLS compiler. We also found that some vulnerable C programs seem to be converted into CT RTL (you would need to prove your RTL to be sure, see next question).
When TurboTurtle does not find a timing side channel, can you be sure that the program is secure?
No, because TurboTurtle fuzzes the generated RTL via random simulation of miter testbenches (see Pathfinder for an explanation). You would need to use formal verification to be sure.
Why do you not formally prove the absence of timing side channels in the generated RTL?
TurboTurtle’s goal is to detect timing side channels. While formal RTL verification would guarantee that we did not miss timing side channels in our generated designs, we could still not provide formal guarantees about the HLS flow, because we fuzz the HLS compiler inputs and are thus not exhaustively exploring the input space of the compiler. In the paper, we show that with simulation we are able to find more side-channel vulnerabilities in less time.
Is TurboTurtle automated?
Yes, TurboTurtle automatically invokes CTurtle to generate programs, automatically synthesizes the program, automatically generates a test bench and automatically simulates the testbench.
Can I use TurboTurtle with open-source tools only?
Yes, you can fuzz Dynamatic and Bambu (or your own HLS tool) and simulate with Verilator.