CFGuide-Fuzz: Dynamic Fuzz Testing Framework Based on Control Flow Features

Abstract

RTL-level fuzz testing is critical for identifying vulnerabilities in hardware designs. However, existing hardware fuzz testing methods suffer from slow coverage improvement and blind exploration due to the lack of fine-grained control flow guidance. To address this gap, this article proposes the CFGuide-Fuzz framework, which includes control node extraction and compression techniques based on FIRRTL instrument and a hardware fuzz engine driven by feature feedback. This research introduces a fine-grained control flow feedback mechanism for hardware fuzz testing, enabling a pivotal shift from blind exploration to targeted testing. Experimental results demonstrate that compared to the DiFuzzRTL baseline, the proposed CFGuide-Fuzz framework enhances register state coverage by 9.4% under identical iteration counts and testing environments. Additionally, it doubles the number of effective inputs that trigger mismatched differential test results. These findings fully validate the framework’s dual advantages: deeper hardware control flow exploration and higher semantic vulnerability triggering efficiency.

1. Introduction

As the foundational layer of computing systems, hardware security vulnerabilities [1,2,3] propagate through the trust chain [4] to the upper layers, eroding the trust foundation of the entire system. Compared with software vulnerabilities, hardware vulnerabilities are more difficult to detect due to lower abstraction layers, which can only be identified by in-depth analysis paired with specialized hardware toolchains. More critically, once the vulnerable hardware is manufactured, it is hard to fix. Even if it is mitigated by software [5], it will result in performance overhead or reduced functionality.

As chip integration and microarchitecture complexity grow exponentially, traditional hardware verification methods [6,7,8] encounter substantial bottlenecks. Formal verification guarantees logical correctness but is prone to state explosion in large-scale designs (e.g., complex processors), making it challenging to achieve full scenario coverage. Functional simulation depends on hardware domain expertise and requires manual test case development, suffering from limitations like low efficiency and incomplete coverage. As a mature automated testing technique in software, fuzz testing [9] automatically generates numerous variant inputs, monitors target behavior, and explores the input space independently, without the need for complex design modeling. With only a small set of initial seeds, it efficiently identifies potential vulnerabilities.

While RTL-level fuzz testing [10,11,12,13,14] has become a core technique for hardware vulnerability discovery, existing approaches exhibit research gap areas in control flow awareness and utilization. This leads to inadequate coverage exploration of target code in fuzz testing, which fails to meet the verification requirements of complex hardware designs. Key limitations include insufficient control flow feedback granularity, overly simplistic coverage guidance mechanisms, and limited scenario adaptability. Mainstream tools and recent studies have attempted to address these issues via control flow modeling, coverage evaluation, and timing analysis, yet significant limitations remain.

RFuzz pioneered hardware fuzz testing by implementing multiplexer switching coverage. However, it simplifies multi-cycle tests into single-cycle inputs via concatenation, fails to distinguish cross-cycle state dependencies, and incurs instrumentation costs that scale exponentially with RTL complexity. DiFuzzRTL adopts control register coverage-guided fuzz testing with only 15% instrumentation overhead. However, its register-level coverage awareness cannot capture fine-grained nodes (e.g., branches and conditional judgments), resulting in missed path updates when register states remain unchanged, making it challenging to cover complex timing scenarios during guided fuzz testing. MPFuzz integrates syntactic fuzz testing with symbolic simulation, defining Full Multiplexer Toggle Coverage (FMTC) to enhance timing monitoring. However, its control flow modeling is limited to Mux switching and does not account for multi-level control structures (e.g., FSMs and conditional branches).

Existing research suffers from two core gaps. First, current tools focus on single-layer signals and lack methods that balance fine-grained extraction with low monitoring overhead. Second, existing dynamic adjustment mechanisms rely on register or multiplexer switching, lacking dynamically adaptive testing strategies based on control flow structures.

To address the limitations of existing research, this paper makes the following key contributions. First, it proposes a four-layer control node extraction and compression mechanism based on FIRRTL. Second, it designs a fuzz strategy based on coverage feature feedback to balance random exploration and directed mining. Third, it establishes a comprehensive fuzz testing framework, CFGuide-Fuzz. Comparative experiments on a typical CPU RTL design confirm the framework’s significant advantages in enhancing control flow coverage and improving vulnerability-detection efficiency.

This paper is structured as follows: Section 2 reviews related work and core technical background in hardware fuzz testing; Section 3 details the CFGuide-Fuzz framework’s methodology, including the control flow extraction optimization mechanism and dynamic fuzz strategy implementation; Section 4 presents the experimental environment, results, and performance analysis; and Section 5 summarizes the work and outlines future research directions.

2. Related Work

Hardware fuzz testing research focuses on three core areas: hardware fuzz testing techniques, control flow analysis and extraction, and test generation strategies. This section systematically reviews the technological evolution and limitations of each domain, drawing on the latest research to clarify CFGuide-Fuzz’s academic positioning.

2.1. Hardware Fuzz Testing Techniques

Hardware fuzz testing techniques have evolved through several stages, traditional random testing, formal guided testing, coverage-guided testing, directed fuzz testing, and input optimization testing. Random testing generates arbitrary instructions and is only suitable for simple combinational logic, with low coverage efficiency. While formal verification delivers high precision, it encounters state explosion when dealing with large-scale complex processors, making it unable to provide timely and effective feedback. As a compromise strategy, coverage-guided testing balances verification efficiency and vulnerability-detection capabilities, garnering substantial attention from researchers.

Table 1. Comparison of hardware fuzz testing research.

Fuzz Technology	Coverage Feedback	Fuzz Strategy	Limitations
RFuzz [15]	Multiplexer	Random mutation.	Low clock sensitivity.
DiFuzzRTL [16]	Register	Register states’ feedback and differential fuzz.	Insufficient feedback granularity.
DirectFuzz [17]	Register	Static priority orientation and dynamic mutation frequency allocation.	Insufficient advantages in complex design.
TheHuzz [18]	Statement, branch, FSM, etc.	Comparison of Golden Models and heuristic search.	Dependent on commercial tools.
HyPFuzz [19]	Statement, branch, FSM, etc.	Formal and dynamic fuzz testing scheduling.	Dependent on commercial tools.
WhisperFuzz [20]	MEG path	Timing path guidance and operand variation.	Limited universality.
INSTILLER [21]	Register	VACO input distillation and multi-interrupt simulation.	Insufficient feedback granularity.
MPFuzz [22]	FMTC	Grammar blurriness and symbol simulation.	State space explosion limits design scale.
CFGuide-Fuzz	Control flow	Control flow extraction and dynamic fuzz strategy.	Low simulation performance.

summarizes recent studies on hardware fuzz testing.

2.2. Control Flow Extraction

Control flow extraction serves as the foundation for guiding fuzz testing. CFG modeling techniques from the software domain are ill-suited for hardware’s parallelism and timing constraints. Existing approaches like RFuzz, DiFuzzRTL, and DirectFuzz employ FIRRTL instrumentation to monitor Mux signals and control registers. MPFuzz, based on PyRTL IR modeling, similarly focuses on Mux switching coverage. TheHuzz utilizes commercial tools to extract coverage metrics across six dimensions including statements, branches, and FSMs. However, its high overhead prevents real-time feedback. WhisperFuzz employs MEG modeling for microarchitecture state transitions to locate timing defects, yet fails to establish coverage metrics supporting test guidance. Existing control flow extraction and hierarchical techniques either focus on single-level control signals or achieve multi-dimensional coverage without real-time feedback. The extraction and optimization of hierarchical control flow at the RTL level is still a research gap area.

2.3. Test Generation Strategy

The core of test generation strategies lies in balancing exploration and utilization. RFuzz extracts the mux flip situation to guide fuzz and performs random bit mutation. DiFuzzRTL uses the state coverage of control registers as feedback to guide fuzz testing and perform instruction level mutation, which has strong universality but low reach rate for complex paths. DirectFuzz guides test generation through priority queues and module distance metrics, dynamically allocating mutation counts based on module distance. MPFuzz introduces ISA (Instruction Set Architecture) syntax constraints to reduce the proportion of illegal instructions, and generates seeds that satisfy FMTC (0-1-0 switching) through symbol simulation. However, symbolic solving incurs high computational cost and is only suitable for initial seed initialization. MMFuzz adjusts seed weights and mutation probabilities based on Markov chains, making it adaptable to non-processor designs. HyPFuzz significantly accelerates coverage by dynamically switching between fuzz testing and formal verification, yet it relies on commercial formal tools. WhisperFuzz’s operand variation focuses on data dependency paths, but is not associated with control flow structures. These test generation strategies optimize the randomness problem of fuzz testing from the perspective of constrained input and dynamic adjustment strategies, but cannot dynamically adjust the exploration direction and mutation intensity based on the hierarchical activation structure characteristics of hardware control flow.

2.4. Research Positioning

This work addresses two key technical gaps in hardware fuzz testing through two targeted innovations:

• FIRRTL-based fine-grained control flow extraction: Enabled by lightweight instrumentation, it achieves four-tier coverage (control ports, FSMs, control nodes, conditional nodes), breaking the limitations of single-layer signal/register coverage in existing methods.
• Feedback-driven dynamic fuzzing strategy: A two-stage mechanism (branch fuzzing for breadth exploration, leaf fuzzing for depth utilization) that automatically adjusts exploration weights via coverage features, eliminating the need for formal tools or manual intervention.

3. Methodology

3.1. Overall Framework

The CFGuide-Fuzz framework mainly consists of two parts. One is the control node extraction module, which uses FIRRTL—an intermediate abstraction layer between high-level hardware description languages and gate-level representations, characterized by flexibility and extensibility to support custom compilation strategies and optimizations—to extract control nodes from the design, then compresses the number of nodes and divides all control nodes into four layers. The second is a dynamic fuzz testing module based on feature feedback. This module obtains the activation information of control nodes from the output port of the instrumentation design code, extracts coverage features from the control flow activation information, and finally dynamically selects target seed and fuzz strategy based on the coverage features. The flowchart of the framework is shown in Figure 1.

3.2. Control Flow Extraction Module

Based on the hierarchical semantic features of FIRRTL, this paper designs a control flow extraction module that includes four processes, static recognition, dependency inference, compression optimization, and hierarchical extraction. Ultimately, it achieves accurate extraction of four layers of control nodes, CTRL_PORT layer (control port layer), FSM layer (finite state machine layer), CTRL layer (control node layer), and COND layer (condition layer).

3.2.1. Control Node Extraction

The control node extraction process takes Lowform FIRRTL as input, traverses all statements in the module body, and identifies the node set $S_0$ directly related to the control logic through statement type analysis and dependency construction. The formal proof of the correctness of the dependency inference is shown in Appendix A. The specific process is as follows.

3.

Traverse the Node statements and the Connect statements in Lowform to build the original node dependency graph $G_0=\left(V_0,E_0\right)$, where $V_0$ represents the node set and $E_0$ is the dependency edge between nodes, such as a Node statement $N_1=Mux\left(c,a,b\right)$, then build, $c\to N_1$, $b\to N_1$ and $a\to N_1$.

4.

Identify the condition node from Mux operator, such as $Mux\left(c,a,b\right)$, and mark $\mathrm{c}$ as condition node.

5.

Take the identified Mux condition node as the starting point, traverse backward along the dependency graph $G_0$, infer all nodes that drive the condition judgment, and form the initial control node set $S_0$.

3.2.2. Control Node Compression

The control node compression process achieves compression of the initial control node set $S_0$ and the dependency graph $G_0$, and further extract four control node layers from $S_0$ including CTRL_PORT layer, FSM layer, CTRL layer and COND layer. Algorithm 1 presents the pseudo-code for the control node compression process. Finally, for complex modules, the optimization effect of Algorithm 1 is not significant, and it is necessary to prioritize extracting the nodes with the highest control complexity for monitoring.

Algorithm 1 Control node compression algorithm
1:	$\mathbf{Input}: \mathrm{Origin} \mathrm{control} \mathrm{flow} \mathrm{graph} \mathrm{G} =\left(\mathrm{V}, \mathrm{E}\right)$
2:	$\mathbf{Output}: \mathrm{Optimized} \mathrm{control} \mathrm{flow} \mathrm{graph} \mathrm{G}\text{’} =\left(\mathrm{V}\text{’}, \mathrm{E}\text{’}\right)$
3:	$\mathrm{Initialize} \mathrm{V}\text{’}=\mathrm{V}, \mathrm{E}\text{’}=\mathrm{E}$$, \mathrm{and} \mathrm{the} \mathrm{set} \mathrm{of} \mathrm{chains} \mathrm{to} \mathrm{be} \mathrm{deleted} \mathrm{S}=\varnothing$
4:	$\mathbf{for} \mathrm{v} \mathbf{in} \mathrm{V}$:
5:	$\mathbf{If} \mathrm{the} \mathrm{in}\text{-}\mathrm{degree} \mathrm{of} \mathrm{v} > 0 \mathrm{and} \mathrm{the} \mathrm{outdegree} \mathrm{of} \mathrm{v}$ == 1:
6:	$\mathrm{Initialize} \mathrm{the} \mathrm{chain} \mathrm{s}, \mathrm{with} \mathrm{the} \mathrm{head} \mathrm{being} \mathrm{v}$;
7:	Track single chain until the outdegree > 1;
8:	$\mathrm{Add} \mathrm{chain} \mathrm{s} \mathrm{to} \mathrm{S}$.
9:	for s in S:
10:	$\mathrm{Delete} \mathrm{all} \mathrm{nodes} \mathrm{in} \mathrm{s} \mathrm{and} \mathrm{update} \mathrm{V}\text{’}$;
11:	$\mathrm{Remove} \mathrm{the} \mathrm{dependencies} \mathrm{of} \mathrm{s} \mathrm{from} \mathrm{E}\text{’}$;
12:	$\mathrm{Add} \mathrm{new} \mathrm{dependencies} \mathrm{and} \mathrm{update} \mathrm{E}\text{’}$;

• Select the nodes of port type from $S_0$ to form the control port set $S_{cp}$, and delete the dependencies and nodes of $G_0$ containing $S_{cp}$ to obtain $G_1=\left(V_1,E_1\right)$, where $V_1=S_1=S_0-S_{cp}$, $E_1$ is the dependency edge inside $S_1$.
• Implement Algorithm 1 on the trimmed control node set $S_1$ and dependency graph $G_1$ to compress redundant nodes, and generate $S_2$.
• Layer the compressed $S_2$. The FSM layer node set $S_{fsm}$ has no upstream dependency and belongs to the register type. The COND layer node set $S_{cond}$ has no downstream control nodes, which is used as the termination node for condition judgment. The remaining nodes belong to the CTRL layer $S_{ctrl}$, which is between the FSM layer and the COND layer, and is used as the intermediate forwarding node of the control flow.

Control node compression example is shown in Figure 2. The red nodes in the figure represent the head nodes of the chain to be deleted.

As illustrated in Figure 2, the circles denote the core control nodes in the hardware circuit, while the connecting arrows represent the transmission direction of control signals between nodes. The red-highlighted nodes are the head nodes of the compressible chains screened out in this compression round. These nodes and their corresponding control chains only undertake signal transmission and supplementary functions, and do not participate in the output of critical control flow decisions.

3.2.3. Instrument Monitoring Signal

For all control nodes ($S_{cp}\cup S_{fsm}\cup S_{ctrl}\cup S_{cond}$), this paper proposes a lightweight instrument scheme based on the FIRRTL PASS mechanism, which can achieve complete collection of control node activation states without compromising the original design functionality. The core process is as follows. Firstly, monitoring logic is inserted after the node allocation/connection statement, and the activation states are recorded without modifying the original functional logic. Secondly, according to the division of four types of control nodes, the activation state signals of all nodes at the same level are concatenated into independent hierarchical monitoring nodes, and finally summarized to generate an overall monitoring node. Finally, for complex designs containing sub module instances, connect the module monitoring nodes with the sub instance monitoring node suffixes to generate instance-level bit width mapping configuration files, providing accurate bit width mapping foundations for feedback analysis in subsequent fuzz testing.

3.3. Dynamic Fuzz Strategy

3.3.1. Coverage Feature Extraction

This article proposes coverage feature extractor for accurately collecting and quantifying the activation states of control flows, including mask calculation, multi-dimensional feature extraction and global coverage updates.

• Mask calculation. The initialization phase calculates masks for each instance and each control layer by parsing configuration files. All layer masks and instance masks are stored in cache to avoid duplicate calculations.
• Extract seed features. During the simulation phase, the output port’s activation states are monitored to generate a seed-specific activation bitmap. Multi-dimensional coverage features of the seed are then extracted from this bitmap, providing a decision-making basis for the dynamic hybrid fuzz strategy. The seed characteristics and calculation methods are shown in

  Table 2. Features of seed.

  Feature Name	Calculation Method	Significance
  Activated instances	Perform and operation on the instance mask and record instances with non-zero results.	Evaluate the diversity of seed
  Activation density of instances	Number of activated instances/total number of tracked instances.	Evaluate the coverage of seed on a single instance.
  Exploration depth of instances	Weighted sum of activation layers.	Evaluate the exploration depth of seed on a single instance.
  Coverage contribution	Activation bit increment/global total bit width.	Determine whether the seed is effective.
  Proportion of deep exploration instances of seeds	Number of deeply explored instances/total activated instances.	Evaluate the exploration depth of seed.

  .

3.

Extract global coverage features. After each seed simulation is completed, the latest global activity bitmap is obtained through the bit or seed activity bitmap. If the coverage increases, use the global activity bitmap to update the global coverage feature.

3.3.2. Fuzz Testing

According to the characteristics of modularization and timing control of hardware design, this paper designs two fuzz strategies, branch fuzz and leaf fuzz, and then combines the target instance selection and seed scoring screening mechanism to realize the adaptive switching between global exploration and local deep excavation. The fuzz testing process is shown in Figure 3.

The detailed process of target instance selection strategy is as follows.

• The selection of target instances is the core of fuzz strategy. It accurately locates the most valuable instances through hierarchical filtering and backtracking mechanisms to ensure that fuzz testing resources prioritize low coverage and high-value hardware instances.
• In the screening phase, first traverse the activation density data of all instances, select the instances with coverage within the range of (0, 0.9), and randomly select from the five instances with the lowest coverage. If the selection fails, directly select the instance with the lowest global coverage (including the instance with 0 coverage). For instances with coverage of 0, their parent instance is used as a substitute to avoid the test efficiency reduction caused by the absence of an effective execution path for instances with coverage of 0.
• In order to adapt to the dynamic changes in coverage, the target instance will be dynamically updated according to a fixed cycle, avoiding the stagnation of coverage growth caused by long-term focus on a single instance.

To quantify the effectiveness of seeds and optimize seed pool management, two scoring models are defined with unified notation explanations provided in

Table 3. Definitions of symbols in seed scoring models.

Symbol	Definition
$D_{inst}$	Activation density of a seed on the target instance.
$De{p}_{inst}$	Exploration depth of a seed on the target instance.
$C_{global}$	Global coverage contribution rate of a seed.
$F_{fresh}$	The freshness of the seeds is inversely proportional to the number of times it has been selected.
$S_{depth}$	Complex control flow mining capability of a seed.
$S_{div}$	Diversity of a seed, quantified by the number of distinct instances activated by the seed.
$S_{eff}$	Execution efficiency of a seed, calculated as the ratio of the number of effective instructions to the total simulation cycles.
$P_{fresh}$	Freshness penalty of a seed.
$P_{age}$	The time attenuation penalty, the longer the seed is created, the greater the penalty.

. All symbols adhere to consistent semantic definitions throughout the scoring process to ensure clarity.

Based on the selected target instance, filter out the seed set covering the current target instance, and calculate the comprehensive score for the filtered seed. The weight distribution is as shown in Equation (1).

$$Score=0.4\cdot D_{inst}+0.3\cdot De{p}_{inst}+0.2\cdot C_{global}+0.1\cdot F_{fresh}$$

(1)

Every 50 iterations, dynamically adjust the mutation strategy based on the increase in coverage. If the rate of coverage improvement decreases by more than 90%, it is determined that the coverage growth is stagnant: trigger the leaf fuzz mode, modify the mutation probability configuration, improve the probability of retaining the original instruction, reduce the invalid mutation, reduce the probability of deleting the instruction, and avoid damaging the effective path.

In order to avoid the performance degradation caused by the expansion of seed pool, the pruning mechanism of premium plus comprehensive score was designed. The optimal seed of each instance is retained to ensure that the effective path of each instance is not lost. The pruning score is calculated for the remaining seeds, and the high score seeds are retained in order of score. The calculation method of seed pool pruning score is represented by Equation (2).

$$Scor{e}_{prune}=0.4\cdot C_{global}+0.3\cdot S_{depth}+0.15\cdot S_{div}+0.1\cdot S_{eff}+0.05\cdot P_{fresh}-0.1\cdot P_{age}$$

(2)

The weight distribution in Equations (1) and (2) is determined based on domain expertise aligned with the core goal of CFGuide-Fuzz, prioritizing low-coverage and high-value hardware instances. For the seed comprehensive scoring (Equation (1)), higher weights are assigned to $D_{inst}$ (0.4) and $De{p}_{inst}$ (0.3) as they directly reflect a seed’s ability to supplement target instance coverage, while $C_{global}$ (0.2) and $F_{fresh}$ (0.1) serve as auxiliary constraints for global coverage balance and seed diversity.

For seed pool pruning (Equation (2)), $C_{global}$ (0.4), $S_{depth}$ (0.3), and $S_{div}$ (0.15) are prioritized to retain high-impact seeds, with $S_{eff}$, $P_{fresh}$, and $P_{age}$ as adjustment factors to avoid homogenization and performance degradation.

Moderate adjustments to individual weights (within a ±0.1 range) will only proportionally shift the scoring emphasis toward the corresponding metric, without fundamentally compromising the strategy’s effectiveness in prioritizing low-coverage, high-value instances or maintaining testing efficiency.

4. Experiments and Discussion

4.1. Experimental Environment

The hardware environment of this experiment is x86 architecture server, the processor is Intel (R) core (TM) i7-14700k, the memory is dual channel DDR5 DIMM (32GiB × 2), the graphics card is NVIDIA GeForce RTX 4090 (AD102 core), and the motherboard is ASUS PRIME Z790-V AX.

The experimental software environment is the RTL fuzz testing toolchain built based on Ubuntu 24.04 LTS operating system, including sbt1.8.2, python3.10, verifier-v4.106, and cocotb-1.5.2. The compilation toolchain is RISCV GNU toolchain 2021.04.23. All modules are built based on the open-source ecosystem to ensure the repeatability and scalability of the experiment.

4.1.1. Benchmark RTL Design

The experiment selected RocketTile, a mainstream and mature open-source processor core in the current RISC-V ecosystem, as the core validation benchmark. The control flow logic of this kernel conforms to real hardware application scenarios, and has a complete open-source ecosystem and detailed documentation, which can seamlessly integrate with mainstream simulation toolchains such as verilator and cocotb. At the same time, the complexity of the RocketTile kernel is moderate, which includes deep timing control paths that hardware fuzz testing needs to focus on mining, and avoids the simulation efficiency loss caused by large-scale out-of-order kernels.

4.1.2. Scale of Code Development

To implement the core functionality of the CFGuide-Fuzz framework, over 2200 lines of code have been developed, including 1600 lines of Scala code and 600 lines of Python code. Scala code is based on the Chisel/FIRRTL ecosystem, implementing hardware control flow extraction, RTL instrumentation, and instance-level parsing. Python code implements coverage feature extraction, dynamic fuzz strategy switching, and seed pool management functions. The code architecture follows a modular design principle, facilitating subsequent functional expansion and cross-hardware architecture adaptation.

4.2. Experimental Results

4.2.1. Comparison of Control Node Optimization

This part tests the effectiveness of the node optimization technique by comparing the number of control nodes before and after compression.

Table 4. Comparison of compression numbers for control nodes.

Module Name	Before	After	Compression Ratio
TLB	2742	2583	5.8%
Rocket	1911	1285	32.8%
DCache	1860	1689	9.2%
PTW	966	755	21.8%
FPU	720	627	13%
Frontend	696	446	35.9%
MulAddRecFNToRaw_postMul_1	458	18	96.1%
RoundAnyRawFNToRecFN_4	224	48	78.8%
TLXbar_7	177	84	52.5%
TLMonitor_36	105	74	29.5%

shows the compression effect.

From the table, it can be seen that different modules have achieved varying degrees of scale reduction after multiple compressions, with compression rates ranging from 5.8% to 96.1% for each module. The overall optimization effect is significant, with MulAddRecFNToRaw_postMul_1 showing the highest optimization amplitude (up to 96.1%). The initial size and optimization space of modules exhibit differentiation characteristics, and modules with larger initial sizes (such as TLB) have relatively lower compression rates. This is because the control flow of these modules is very complex, and the number of single links that can be optimized is small. Therefore, this article combines the sampling strategy of control nodes to reduce the size of control node extraction.

4.2.2. Comparative Experiment

In this part, DiFuzzRTL is selected as the benchmark tool for comparative analysis, with two core rationales underpinning this choice.

• Compatibility with the FIRRTL ecosystem: CFGuide-Fuzz is constructed based on FIRRTL instrumentation technology, and DiFuzzRTL is a mainstream, publicly available tool that operates natively within the FIRRTL ecosystem, and this ensures the comparison eliminates confounding variables arising from differences in underlying abstraction layers.
• Alignment with technical improvement objectives: The work presented in this manuscript constitutes an extension and optimization of DiFuzzRTL. DiFuzzRTL establishes a foundation for FIRRTL-based hardware fuzz testing, while CFGuide-Fuzz addresses its identified limitations (e.g., insufficient coverage efficiency, lack of adaptive strategies) through hierarchical control node extraction and dynamic adaptive mechanisms. DiFuzzRTL thus serves as the most appropriate baseline to quantify the incremental performance gains of the proposed framework.

To quantify the control flow exploration capability of different fuzz testing frameworks, this experiment uses register state coverage as the core evaluation metric. Within 6000 rounds of fuzz testing iterations, the system records and compares the coverage progress and final coverage level of each framework. In addition, to quantify the vulnerability triggering capability of differential testing, this experiment counts the number of simulation inputs with inconsistent execution results between RTL simulation and the ISA reference model under different fuzz testing frameworks. The experimental results are shown in Figure 4.

The experimental results show that under the same 6000 iterations, unified hardware simulation environment, and benchmark design (RocketTile kernel), the CFGuide-Fuzz framework proposed in this paper achieves a 9.4% improvement in register state coverage compared to DiFuzzRTL. This data intuitively verifies the effectiveness of the CFGuide-Fuzz core design. Compared with the register coverage feedback mechanism of DiFuzzRTL, CFGuide-Fuzz achieves fine-grained feedback through control flow extraction, and combines dynamic fuzz strategy to balance exploration and utilization. It can more accurately locate low-coverage, high-value hardware instances and control nodes, effectively reduce invalid mutations and coverage redundancy, and achieve better control flow exploration depth and breadth at the same iteration cost.

In terms of vulnerability-detection capability, experimental results show that the CFGuide-Fuzz framework generates approximately 13 mismatched inputs, while the DiFuzzRTL framework generates approximately 6 mismatched inputs. The number of mismatched inputs in CFGuide-Fuzz has doubled compared to DiFuzzRTL, reflecting the stronger triggering ability of the dynamic fuzz strategy and directional seed selection method proposed in this paper for hardware vulnerabilities.

Among all triggered mismatches, 70% are attributed to CSR access and state misalignment, and the remaining 30% stem from memory access boundary violations. For CSR access and state misalignment, the root cause lies in inconsistent updates of privilege-related CSR registers (e.g., ‘mepc’, ‘mcause’) during trap handling, leading to mismatched architectural states. For memory access boundary violations, the core issue is improper address translation and out-of-bounds data access in the memory subsystem, resulting in invalid memory read/write behaviors.

To further test the independent effects of fuzz strategy guidance and seed selection mechanism, we conducted two ablation experiments. One set only retained the basic fuzz process and turned off the dynamic switching of fuzz strategy. The other group retains the fuzz strategy but randomly selects seeds. By comparing the coverage curve and number of mismatched inputs with the complete framework, verify the necessity of the two modules in improving coverage efficiency and vulnerability triggering capability. Figure 5 shows the experimental results.

The ablation experiment results showed that the register state coverage of the group without fuzz strategy guidance and the group without seed selection decreased by 2.53% and 5%, respectively, and the number of mismatched inputs decreased by 69.2% and 64.5%, respectively. This fully demonstrates that the directional fuzz strategy and precise seed selection can effectively improve the efficiency of hardware control flow exploration and the ability to trigger semantic vulnerabilities, which are the core sources of the framework’s performance advantages.

In addition, it is not difficult to find through testing that the control group after ablation still retains strong register coverage exploration ability, indicating the advantages of the control flow extraction and control coverage feedback framework proposed in this paper in seed effectiveness judgment.

4.3. Performance Analysis

4.3.1. Resource Overhead Evaluation

In this part, the cost of the FIRRTL instrumentation method proposed in the paper is analyzed.

Table 5. Comparison of instrument overhead.

	Benchmark	Before	After	Instrument Overhead
DiFuzzRTL	RocketTile	50,588	81,887	61.87%
CFGuide_Fuzz	RocketTile	50,588	77,370	52.94%
DiFuzzRTL	SmallBoom	141,631	239,286	68.95%
CFGuide_Fuzz	SmallBoom	141,631	221,619	56.47%

shows the comparison of the number of code lines before and after instrumentation.

The table reflects that the proposed instrument technique has a lower cost. For RocketTile, the instrument code quantity of the method proposed in this paper is 26,780 and 97,655, which is approximately 14% to 18% less than DiFuzzRTL’s instrument method.

This reduced instrumentation cost stems from our deliberate design trade-off between control node extraction granularity and the simulation platform’s control flow processing efficiency. Extraction granularity dictates the detail of captured control flow information, with the platform’s processing efficiency inherently constrained by the volume of extracted nodes. We adopt fine-grained extraction for critical control nodes: aggressive node pruning for further efficiency gains would sacrifice granularity, obscuring key control flow details and impairing the accuracy of our control flow guided mutation and seed selection mechanisms. Post compression, our design retains the fine-grained visibility essential for effective fuzzing guidance while maintaining practical processing efficiency.

4.3.2. Complexity and Run Time Analysis

This part analyzes the performance of the proposed instrumentation tool and fuzz testing framework in terms of complexity.

Table 6. Complexity analysis table.

Module	Control Flow Extraction	Code Instrumentation	Feature Extraction	Fuzz Testing Strategy
Time Complexity	O(S + N2)	O(MNlogN)	O(W)	O(C + KlogK)

quantifies the time complexity of the control flow extraction module, the code instrumentation module, the feature extraction module, and the fuzz testing strategy module.

In Table 6, the notations are defined as follows: S and N denote the number of statements and the number of control nodes in a single module, respectively; M represents the number of all modules; W is the number of control nodes across all instances; and C and K indicate the size of the seed pool and the total number of instances, respectively.

The time complexity O(S + N²) for control flow extraction and O(MNlogN) for instrumentation aligns with the technical characteristics of FIRRTL-based control flow analysis and instrumentation, demonstrating solid theoretical validity. The linear complexities O(W) for feature extraction and O(C) for seed selection ensure these modules remain lightweight and efficient. Meanwhile, the O(KlogK) complexity of instance selection prevents it from becoming a performance bottleneck in the overall framework, as its execution frequency is inherently limited.

Table 7. Comparison of running time (s).

Iterations	1000	2000	3000	4000	5000	6000
DiFuzzRTL	630.16	1297.54	2035.77	2745.51	3503.24	4339.51
CFGuide_Fuzz	2160.51	4486.2075	6829.98	8858.17	10,958.73	13,211.86

shows the comparison of the running time of the two fuzz testing techniques after 6000 simulation iterations.

From the table, it can be seen that under the same number of iterations, the running time of the fuzz testing framework proposed in this paper is more than three times that of DiFuzzRTL. This is because the framework needs to monitor port signals and compare activation bits during the simulation cycle to achieve dynamic switching of fuzz strategies, resulting in a significant decrease in overall simulation performance. This issue can be alleviated by using multi-core parallel testing and a wider monitoring window.

5. Conclusions

As a core technology for RTL-level vulnerability mining, hardware fuzz testing has long faced the key problem of the lack of fine-grained control flow guidance. Traditional fuzz strategies rely heavily on random mutations or coarse-grained coverage guidance (such as Mux coverage), which cannot accurately mine deep timing control paths in hardware, and lack control flow extraction techniques and fuzz strategies open-source tool-based, resulting in low coverage efficiency and high vulnerability-detection rates.

In response to the above issues, this paper proposes the CFGuide-Fuzz framework. Firstly, it proposes a hardware control flow hierarchical extraction method to achieve precise extraction of control nodes at different layers. Secondly, the framework achieves a balance between exploration and utilization in hardware fuzz testing by analyzing global coverage features and dynamically switching between branch and leaf fuzz strategies, solving the problem of coverage stagnation or inefficient exploration caused by a single strategy. Experimental results demonstrate that CFGuide-Fuzz enhances register state by 9.4% and doubles potential error detection capability on mainstream RISC-V kernels compared to traditional methods in the same number of iterations, validating the effectiveness of the framework.