SOURCE ARCHIVE
EXTRACTED CONTENT
129,603 charsReFuzz: Reusing Tests for Processor Fuzzing with Contextual Bandits
Chen Chen†, Zaiyan Xu†, Mohamadreza Rostami‡, David Liu†,
Dileep Kalathil†, Ahmad-Reza Sadeghi‡, and Jeyavijayan (JV) Rajendran†
†Texas A&M University, USA, ‡Technische Universitat Darmstadt, Germany¨
†{chenc, zxu43, david_liu, jv.rajendran}@tamu.edu,
‡{mohamadreza.rostami, ahmad.sadeghi}@trust.tu-darmstadt.de
Abstract—Processor designs rely on iterative modifications as Tiger Lake into subsequent generations like Alder Lake and reuse well-established designs. However, this reuse of prior and Raptor Lake [2], [3]. Moreover, the design reuse strat- designs also leads to similar vulnerabilities across multiple pro- egy is typical in hardware. According to a 2023 worldwide cessors. As processors grow increasingly complex with iterative modifications, efficiently detecting vulnerabilities from modern semiconductor survey, over two-thirds of non-memory system- processors is critical. Inspired by software fuzzing, hardware on-chips (SoCs) and integrated circuits (ICs) reuse existing fuzzing has recently demonstrated its effectiveness in detecting designs [4]. Supporting this trend, hardware programming processor vulnerabilities. Yet, to our best knowledge, existing pro- languages like Chisel have been developed to facilitate design cessor fuzzers fuzz each design individually, lacking the capability reuse [5]. For example, BOOMV3 [6] reuses large portions of to understand known vulnerabilities in prior processors to fine- tune fuzzing to identify similar or new variants of vulnerabilities. codebase from another processor, Rocket Core [7]. To address this gap, we present ReFuzz, an adaptive fuzzing While abstraction of functionalities and design reuse re- framework that leverages contextual bandit to reuse highly duce workload, they allow vulnerabilities to propagate across effective tests from prior processors to fuzz a processor-under- processors. For example, RISC-V processors, CVA6 [8], test (PUT) within a given ISA. By intelligently mutating tests that PicoRV32 [9], and Kronos [10], incorrectly raise excep- trigger vulnerabilities in prior processors, ReFuzz detects similar tions for valid FENCE and FENCE.I instructions due to and new variants of vulnerabilities in PUTs. ReFuzz uncovered three new security vulnerabilities and two new functional bugs. faulty decoding logic [11]–[13]. Similarly, CVA6 and BOOMV3 ReFuzz detected one vulnerability by reusing a test that triggers incorrectly raise exceptions when accessing page table entries a known vulnerability in a prior processor. One functional bug that violate physical memory attribute checks [13]. exists across three processors that share design modules. The As processor designs continue to grow more complex, second bug has two variants. Additionally, ReFuzz reuses highly efficiently verifying their integrity and security becomes in- effective tests to enhance efficiency in coverage, achieving an average 511.23× coverage speedup and up to 9.33% more total creasingly challenging. Patching these vulnerabilities post- coverage, compared to existing fuzzers. silicon is costly, as the flaws exist physically within the hardware [14], often requiring kernel and microcode up- I. INTRODUCTION dates [15], [16], disabling microarchitectures [17], or even Processors, as the core of computing systems, are crucial recalling products [18]. Such mitigation degrades performance not only for performance but also for system security. Over and significantly impacts vendors’ finances and reputation. the past 60 years, instruction set architectures (ISAs) have ab- Detecting vulnerabilities during the pre-silicon stage (i.e., stracted the functionality of processors independently of their before fabricating the processors) is therefore critical. designs. This abstraction makes the main goal of processor Industrial verification flow. Industry applies both direct and designs enhance performance, dependability, energy efficiency, random testing to verify processors before fabrication [19]. and fast real-time responses through the introduction of new Direct testing uses the internals of processor designs and microarchitectures, rather than adding new functionalities or known vulnerabilities, such as common vulnerabilities and ex- altering input and output spaces [1]. posures (CVEs) and common weakness enumerations (CWEs), Consequently, processor designs rely on iterative modifi- to manually create directed tests [20]. These tests are usually cations and extensive reuse of well-established designs. For reused across different designs for vulnerability detection example, Intel extends successful processor generations such and coverage achievement [21]. Random testing generates instruction sequences to verify processor behaviors. However, direct testing requires deep domain knowledge, while random testing struggles to effectively verify large-scale designs [11]. Processor fuzzing at pre-silicon. Inspired by software Network and Distributed System Security (NDSS) Symposium 2026 fuzzing, processor fuzzing has emerged as an effective ap- 23-27 February 2026, San Diego, CA, USA proach for detecting vulnerabilities in modern processors [11]– ISBN 979-8-9919276-8-0 [13], [22]–[26]. Processor fuzzers have proven effective for https://dx.doi.org/10.14722/ndss.2026.240118 www.ndss-symposium.org
Traditional Strategy vulnerabilities that exist in prior processors, making PP-tests
Direct Testing valuable starting points for uncovering related flaws.
ADD R1 However, we observe that directly executing PP-tests on
ADD R1……
SUB R2
SUB R2…...... … PUTs fails to detect variants of known vulnerabilities or to
IFIF ID explore the new microarchitectures. While hardware fuzzing
ID EX
EX M
M W
W Direct Tests Known addresses these limitations, it introduces its own challenges: (i)
Known
Fuzzing Prior Vuls.
Vuls. A fuzzer can over- or under-mutate a PP-test, reducing both the
ADD R1
ADD R1…… Processors fuzzer’s efficiency and effectiveness. The fuzzer must carefully
ISA SUB R2
Spec. SUB R2…...... … balance between the time to mutate a given test and the need
Fuzzing Tests to proceed to the next. (ii) The test effectiveness varies during
ReFuzz PP-Tests New fuzzing, requiring dynamic evaluation and prioritization.
New ReFuzz. To overcome the challenges, we introduce ReFuzz,
Vuls.
Vuls. the first fuzzing framework that leverages contextual ban-
ADD R1
ADD R1…… dit (CB) algorithms to adaptively reuse PP-tests as seeds.
SUB R2
Coverage SUB R2…… Processor- ReFuzz uses the exploration-exploitation trade-off inherent to
Coverage ...... Under-Test Coverage CB algorithms to balance between reusing the current test and
switching to the next. ReFuzz evaluates coverage increment
Figure 1. ReFuzz, a novel fuzzing framework that leverages effective tests of a PP-test at different total coverage to precisely prioritize from prior processors to enhance fuzzing efficiency on processor-under-tests seeds, enhancing both coverage and vulnerability detection. (PUTs). Vuls. means Vulnerabilities. Overall, the main contributions of this paper are: • We develop the first framework, ReFuzz, that leverages CB identifying a wide range of vulnerabilities during the pre- algorithms to guide test reuse from prior processors as seeds silicon stage, including functional incorrectness [13], time for fine-tuning fuzzers on PUTs. Unlike existing approaches side-channels [27], and speculative vulnerabilities [28]–[31]. that fuzz each PUT independently, ReFuzz exploits ISA Processor fuzzers use a set of seeds to initiate fuzzing, with abstraction and common design reuse to provide effective the effectiveness of a seed directly influencing the efficiency tests across processors following the same ISA. of vulnerability detection and coverage achievement [32]. • ReFuzz is agnostic to any processor fuzzers and random Existing research treats processor fuzzing as an advanced testing that require seeds to initiate processes. alternative to random testing, fuzzing each processor individ- • We evaluate ReFuzz on five widely-used and open-sourced ually, generating seeds from scratch, and improving efficiency RISC-V processors with diverse microarchitectures and through advanced seed generation [12], [13], [33]–[37]. achieve an average 511.23× coverage speedup over baseline To our best knowledge, no hardware fuzzer leverages in- fuzzers. ReFuzz also outperforms baseline fuzzers and sights from direct testing by reusing tests1 from prior pro- achieves up to 9.33% more total coverage (see Section VI). cessors (PP-tests) to guide fuzzing of a processor-under-test • ReFuzz detected three new vulnerabilities and two new (PUT) and enhance coverage and vulnerability detection2, as functional bugs. ReFuzz detected one vulnerability by shown in Figure 1. Developing such a method is the core reusing a PP-test that triggers a known vulnerability in a contribution of this work and aligns hardware fuzzing with prior processor, resulting in a memory deadlock exploitable the reuse trend in the hardware development cycle. for denial-of-service attacks. Rocket Core [7], BOOMV3, Reusing PP-tests. The PP-tests can enhance fuzzing efficiency and BOOMV4 [6] have the same bug due to reusing the same on PUTs for three reasons: (i) Processors within the same module. BOOMV3 and BOOMV4 share another, and BOOMV4 ISA mostly share input and output spaces and functionalities, has more variants due to its new microarchitectures. enabling effective reuse of PP-tests. (ii) Complex functionali- ties often remain vulnerable across generations. For example, II. BACKGROUND despite the FDIV bug being discovered in Intel Pentium A. Verification of Processor Design processors in 1994 [18], AMD still reports bugs of floating point units in its Zen family processors in 2023 due to the To manage design complexity, verification of modern pro- complexity of floating-point arithmetic [38]. Similarly, proces- cessors is conducted at multiple levels. At the unit level, sor fuzzers like Cascade [12] report multiple vulnerabilities verification targets individual components like decoders or related to the memory synchronization function in RISC-V adders. The subsystem level targets integrated groups of mod- processors. This function is challenging to implement while ules that perform specific functions like cache coherence. At maintaining both memory consistency and pipeline efficiency. the architecture level, verification ensures that the processor (iii) New microarchitectures can introduce variants of known is compliant with its ISA specifications, which is the primary focus of most hardware fuzzers [39]. 1A processor test is a binary executable with a sequence of instructions. To support multi-level verification, both industry and 2For brevity, we call processors that share the ISA with PUTs as “prior” academia employ a comprehensive toolbox of formal and processors and the tests executed on them as “prior-processor” tests (PP-tests). dynamic techniques [40]. Formal verification, primarily used
2
at the unit and subsystem levels, relies on predefined assertions Contextual bandit (CB) is a type of bandit problem that to validate functional correctness and security properties. At includes contextual information. Before taking an action, the the architecture level, dynamic verification is more common learner observes the context of the environment. The learner and includes random testing, which generates instruction then selects an action and receives a reward only for that sequences to explore design behaviors, and direct testing, action, without feedback on the unchosen alternatives. This which applies curated test suites or handcrafted tests based feature makes CB algorithms particularly suited for real-world on known vulnerabilities (e.g., CVEs, CWEs) [41]. Because scenarios, where environments are dynamic and involve a large many processors share similar verification goals, such as number of actions (e.g., thousands) [45]. covering corner cases and detecting variants of vulnerabilities, In general, CB consists of six core components: (i) agent: directed tests from prior processors are commonly reused the decision maker selecting actions; (ii) environment: the across processor generations to reduce verification effort [21]. source of context and reward feedback; (iii) set of arms B. Hardware Processor Fuzzers (A): the set of available actions; (iv) context (c): informa- tion observed before making a decision; (v) policy (π): the Fuzzing is a dynamic technique that verifies designs through mapping from context to actions; (vi) reward (r): feedback iterative test generation and execution [32]. Processor fuzzers from environment for the chosen action. At each time step t, typically produce instruction sequences based on the instruc- the agent observes a context ct from the environment, selects tion set architecture (ISA) of the processor-under-test (PUT). an action a ∈ A according to policy π(·|ct), and receives a A processor fuzzer includes four core components: seed gen- reward rt = f (ct, a) from the environment. erator, mutation engine, feedback engine, and vulnerability detector [22]. The seed generator generates an initial set of III. OBSERVATIONS ON REUSING AND MUTATING TESTS tests as seeds, by randomly selecting instruction opcodes and Directly reusing prior-processor tests (PP-tests) often falls operands [24]. A fuzzer then simulates or emulates these seeds short when detecting variants of vulnerabilities or achiev- on the PUT and collects feedback data and output used by ing comprehensive coverage on processor-under-tests (PUTs). the feedback engine to guide mutations and the vulnerability While PP-tests remain valuable for their original verification detector to identify bugs. purposes, they exhibit inherent limitations in identifying vari- The feedback engine often employs code coverage as ants of vulnerabilities that manifest uniquely within evolved feedback [11], which monitors the amount of hardware microarchitectures. In this section, we analyze the limitations logic explored, such as branch statements, finite-state ma- of directly using PP-tests to detect variants of vulnerabilities chines (FSMs), and toggled bits. Additionally, hardware or enhance coverage on PUTs and show how processor fuzzers fuzzers use customized metrics as feedback, such as control- can overcome these limitations by mutating tests intelligently. register coverage [24], which tracks the states of multiplexer signals, and control and status register (CSRs) coverage [23], A. Case Study: Detecting Variants of Vulnerabilities which monitors the values of CSRs in the PUT. The vulnera- bility detector identifies vulnerabilities using either assertions, ReFuzz detects a new bug affecting both BOOMV3 and which check if certain conditions hold true at runtime [42], BOOMV4 [6], where improper updates to the CSRs cause or differential testing, which compares the PUT’s outputs certain instructions observed to increment the committed in- against a golden-reference model (GRM) [11]–[13], [24], [36]; struction counter (minstret) by two. This behavior vio- mismatches represent potential vulnerabilities in the PUT. lates the RISC-V specification, which mandates that each After executing the initial tests, the feedback engine iden- committed instruction increments minstret by one [46]. tifies “interesting tests” that reach new coverage points for Accurate accounting of committed instructions is essential further exploration of design spaces. These tests guide the for performance profiling [47], bug reproduction [48], and mutation engine to generate new tests. The mutation engine anomaly detection [49]. performs data manipulation, such as bit flips and swaps [11], Shared root cause lies in the interaction between the reorder [43], similar to the strategies used in the most popular software buffer (ROB) and the CSR modules. The ROB module man- fuzzer, American Fuzzy Lop (AFL) [44]. Mutation operators ages instruction commit logic, while the CSR module tracks may mutate instruction operands or alter entire instructions. architectural states, including privilege levels and the number The seed generator and mutation engine automate test gener- of committed instructions (i.e., minstret). In both BOOMV3 ation, and the effectiveness of seeds is crucial for determining and BOOMV4, committing an instruction by the ROB module the efficiency and effectiveness of a fuzzing campaign [32]. triggers a two-cycle delay to update the minstret register C. Bandit Problems in the CSR module, as shown by the waveforms in Figure 2. However, the processors are configured to expose architectural Bandit problems are a class of reinforcement learning states to the software level when an instruction is committed problems focused on action selection without modeling future without counting this delay. This makes the CSRs, such as state transitions. The objective is to learn a policy that max- minstret, inaccurately represent the processor’s architecture imizes expected cumulative reward by balancing exploration states, leading to some instructions failing to increment the and exploitation [45]. minstret register, while others increment the register by
3
BOOMV3 exe Table I
queue exe clock COVERAGE RESULTS OF DIFFERENT TEST REUSE STRATEGIES ON
alu
alu
alu
issue alu
mul rob minstret
mul
mul
mul 0 0 1 2 3 BOOMV4 [6]. “PP” REFERS TO CVA6, Rocket Core, AND BOOMV3.
exe CSR commit0 NOP Strategy Ave. Total
exe Coverage (
queue issue alu Speedup
alu
alu
alu commit1 NOP
div rob Fuzzing from Scratch (baseline) 66.66 %) 1.00×
div
div
div commit2 MUL Same Sequence of BOOMV3-Tests 66.47 0.76×
BOOMV4 clock Random Sequence of PP-Tests 66.40 0.74×
Ranked Sequence of BOOMV3-Tests 66.64 1.00×
alu rob minstret 0 0 1 2 2 Ranked Sequence of PP-Tests 66.76 2.30×
queue issue alu
unq. exe ReFuzz 70.58 5.40×
mul
mul
mul CSR commit0 NOP
div
div
queue issue divalu commit1 NOP B. Can Reusing PP-tests Enhance Coverage?
alu rob commit2 MUL
Since improving coverage achieved by a fuzzer is criti-
Figure 2. BOOMV3 and BOOMV4 have the same bug due to reusing modules cal for detecting vulnerabilities, we evaluate whether simply that update the minstret register two cycles after an instruction is commit- reusing PP-tests can improve coverage on PUTs. ted. BOOMV4 has more variants of the bug due to its new microarchitectures. For example, the MUL instruction will trigger the bug in BOOMV4 but not in Evaluation setup. We evaluate coverage achieved by a fuzzer BOOMV3. Red lines highlight the clock cycles when minstret is accessed to in terms of total coverage3 and coverage speed. We use an represent architectural states, while dashed arrows point to the actual commit existing fuzzer [11] to fuzz BOOMV3 (the prior processor) and number for each instruction. BOOMV4 (the PUT) [6] by generating 21K tests. The 21K tests from BOOMV3 serve as PP-tests. We define coverage speed as two, BOOMV3 and BOOMV4 reuse both modules, thereby the number of tests required to reach a given total coverage. sharing the same bug. For example, the baseline fuzzer reaches 66% total coverage Variants in BOOMV4. However, BOOMV4 includes 10 addi- after generating 8,548 tests, whereas directly reusing tests tional instructions that can trigger this bug due to different mi- from BOOMV3 requires 11, 246 tests to reach the same total croarchitectures. Both BOOMV3 and BOOMV4 are superscalar coverage, resulting in a 0.76× slowdown. Also, executing all processors, capable of executing multiple instructions in paral- PP-tests from BOOMV3 on BOOMV4 resulted in 0.19% less lel via multiple issues [1]. In Figure 2, they are configured with total coverage. Table I summarizes the coverage results of all two issue slots. In BOOMV3, each issue slot is equipped with an strategies, with ReFuzz performing the best (see Section V execution unit, including a multiplier for the MUL instruction. for the details of the evaluation setup). In contrast, BOOMV4 uses a unique execution unit across Inadequate diversity. Directly reusing tests from BOOMV3 issue slots. To avoid data races, the shared unit implements a does not achieve higher total coverage than baseline on static arbiter to serialize access, introducing extra latency when BOOMV4 because the PP-tests cannot explore unique design BOOMV4 accesses the multiplier. Consequently, executing the features of BOOMV4. To address the issue, we collect 21K same test (an instruction sequence with two NOP and one MUL) tests each from two RISC-V processors Rocket Core [7] results in MUL incrementing minstret by two on BOOMV4, and CVA6 [8] (totally 63K tests), which are widely used as but by one on BOOMV3. Figure 2 illustrates this discrepancy, benchmarks by processor fuzzers [12], [13], [24], [33], [36]. and Appendix C lists all instructions observed to trigger this We randomly pick 21K tests from all three processors (i.e., bug. This case highlights that (i) the design reuse strategy Random tests from procs). The strategy achieves 0.26% less can propagate vulnerabilities across processor generations, and total coverage than the baseline. (ii) directly reusing tests from prior processors may fail to In contrast, using the same PP-tests, ReFuzz achieves detect variants of vulnerabilities. For example, BOOMV4 has 3.92% more total coverage compared to the baseline. This 10 additional variants of the vulnerability. Properly mutating highlights that simply reusing PP-tests achieves similar total PP-tests (e.g., by altering instruction opcodes [11]) increases coverage as fuzzing the PUT directly. However, mutating the probability of detecting such variants. PP-tests, as ReFuzz does, can help explore unique design However, effective mutation is non-trivial. Over- or under- features of the PUT, leading to higher total coverage. mutating a test can reduce a fuzzer’s efficiency and effective- Observation #2: Simply reusing PP-tests achieves similar ness. Fuzzers must carefully balance how long to mutate a total coverage as fuzzing the PUT directly. Mutating PP- given test versus when to proceed to the next. tests achieves more coverage.
Observation #1: Mutating PP-tests is essential for un- Inefficient order of execution. The naive approach for reusing
covering variants of vulnerabilities in PUTs. However, PP-tests is to execute them on the PUT in the identical
the effectiveness and efficiency of fuzzing depend on sequence (as they were executed during the PP fuzzing cam-
balancing how long to mutate a test before switching to
the next one. 3Total coverage refers to the cumulative percentage of coverage points
reached after executing a given number of tests.
4
paign). However, this method proves insufficient for enhancing characteristics of fuzzing (we call it adaptive CB), and we the coverage speed, as it degrades the coverage speed by a further optimize the training tests to enhance the effectiveness factor of 0.76× compared to fuzzing the PUT from scratch, of the CB model. Finally, we integrate the trained CB model evidenced by our experimental results (see second row in with two distinct fuzzers to test its effectiveness, demonstrating Table I). As expected, results from other PPs with this method that the approach is agnostic to any hardware fuzzers. demonstrate even worse performance. A more advanced approach would be to randomly select A. Why Contextual Bandit (CB)? tests from the PP-tests and execute them on the PUT. However, As shown in III, a naive, greedy approach that prioritizes this method encounters the same inefficiency problem of historically high-performing tests risks converging on local coverage speed, as demonstrated by our experiments (see third optima. Conversely, an exhaustive evaluation of all prior test row in Table I). This approach, on average, further degrades cases is computationally prohibitive and lacks the dynamic and the coverage speed by a factor of 0.74×. This shows that the adaptive nature. This problem of choosing an action (a test) order of execution impacts the coverage speed. based on the current state (coverage context6) to maximize To advance the method, we ranked the tests based on their cumulative reward (total coverage) is precisely a contextual standalone coverage4, while executing on their related PP. decision-making problem. For instance, if a PP-test originated from Rocket Core, The CB algorithms are suited to this challenge due to three we ranked it based on its standalone coverage from Rocket key properties. First, CBs incorporate context into their policy. Core. In the fourth row of Table I, we present results for the The effectiveness of a test changes as fuzzing progresses; tests most closely related PP, BOOMV3, to our PUT, BOOMV4, which for broad exploration at low total coverage (e.g., 50%) are demonstrates that while ranking provides better coverage different from those needed for deep, corner-case exploration speed compared to identical sequence and random selection, at high total coverage (e.g., 70%). CBs learn a policy that it still delivers the same performance as the baseline. To adapts to the evolving coverage context, enabling adaptive further advance this method, we ranked the PP-tests based on decision-making for ReFuzz to select the most effective their average standalone coverage across all three processors, tests at any coverage context. Second, CBs are designed to achieving a 2.30× improvement in coverage speed (see fifth balance leveraging known effective tests (exploitation) with row in Table I). These results suggest that leveraging a broader investigating new ones (exploration). This balance is critical set of PPs helps identify highly effective tests. for fuzzing efficiency. ReFuzz uses this capability to dy- While the aforementioned strategies improve coverage namically adjust its strategy (exploration-exploitation trade- speed, their static nature prevents them from improving total off), ensuring it efficiently uses highly effective tests. Third, coverage. This observation motivates that a dynamic strategy, CBs are computationally lightweight and can handle a large while benefiting from effective test reuse and improving cov- action space list PP-test corpora without the overhead of erage speed, could also increase total coverage. We propose more complex reinforcement learning models. Their anytime the ReFuzz framework to address this lack of dynamic learning [45] property means they continuously refine their strategy. ReFuzz improves the coverage speed by 5.40×, policy and retain a useful solution even if the training process outperforming all evaluated strategies. The key insight is that is interrupted (scalability and anytime learning). a test’s effectiveness in increasing coverage varies during the fuzzing process. For instance, a test achieves an average 4.99% B. Modeling Fuzzing as a Contextual Bandit (CB) Problem incremental coverage5 across all three processors when the To apply CB to fuzzing, we model the interaction between total coverage is 55%, but the same test achieves only 0.06% ReFuzz and the PUT as a contextual bandit problem. During incremental coverage when the total coverage is 70%. training, ReFuzz learns a CB policy by iteratively exploring Observation #3: The effectiveness of tests varies during PP-tests and observing their effectiveness. The goal is to the fuzzing process. The fuzzer needs to dynamically identify and prioritize tests that maximize total coverage. evaluate the effectiveness of tests and determine which Preliminary formulation. The primary components of a test to mutate. bandit problem are: agent, environment, set of arms, context, policy, and reward, as mentioned in Section II-C. ReFuzz is IV. METHODOLOGY the agent that learns the policy (i.e., which test to select first) In this section, we first discuss why CB is suitable for through interacting with the environment. We let the training reusing prior-processor test (PP-tests) with hardware fuzzing environment be the PUT and its verification environment, and how we model hardware fuzzing as a CB problem. such as software simulators [50], which provides coverage We then describe how we build and train the CB model. feedback. We then let n be the total number of training steps. We improve the efficiency of the CB model based on the Definition 1. A is the finite set of arms. It contains all PP- 4Standalone coverage refers to the percentage of coverage points achieved tests. at denotes the test selected by ReFuzz at time t. by executing a single test. 5Incremental coverage refers to the percentage of newly reached coverage 6Coverage context refers to the point in the fuzzing process when total points compared to total coverage by a test. coverage reaches specific thresholds, such as 55%, 60%, or 65%.
5
Definition 2. C ⊆ [0, 1] is the finite set of coverage context this, we first use a test minimizer to preprocess PP-Tests which contains all possible total coverage of a PUT achievable and remove redundant ones that reach the same coverage by the fuzzer. We use ct ∈ C to denote the coverage context at points. The minimized tests are then used by the adaptive time t, where ct ranges from 0 (covers no point) to 1 (covers CB algorithm, which drops ineffective tests and learns which 100% coverage points). tests are most effective at achieving coverage increment under Definition 3. rt(ct, at) denotes the reward at time t after exe- different coverage contexts. cuting the test at selected under context ct. To maximize total coverage, we let the reward represent coverage increment Training the CB Model PP1 Prior Processors 30% at Different c C after receiving coverage feedback for the selected test from the Vulnerability Adaptive CB Algorithm environment as rt(ct, at) = ∆covt(at), where ∆covt(at) = Tests Vul Vulₜ₁ₜ₁ Δcov=5 PP1 PP1 PP2 {∆covt | ∆covt is covered by at at t but not ct}. In training, Vul Δcov=5 30% 80% 60% Vulₜ₂ₜ₂ Δcov=4 cov=4 the coverage increment is the incremental coverage of the ...... ...... Vulnerability List selected test at. Coverage Cov Vul , q1 Vult2, q2 Covₜ₁ₜ₁ Δcov=6 Tests Cov cov=6 t1 Cov Δcov=3 t2t2 cov=3 At each time step, ReFuzz observes the current coverage c₁=30% ...... ...... Coverage List of C 1 context. It chooses a test, runs the test, and checks how much coverage increment is achieved (reward). It then updates ... Test Covt1, q1 Minimizer Dropped Covt2, q2 its policy about which tests are most effective at increasing Tests Covt3, q3 coverage under which coverage context. Thus, the goal is to learn the optimal CB policy that maximizes the sum of Figure 3. ReFuzz’s training stage. C is the set of different coverage contexts. collected rewards, i.e., total coverage. Let g : C × A → C V ult is a test in the vulnerability list, and Covt is a test in the coverage list. denote the deterministic function that represents the PUT and Figure 4 shows the coverage achievement of the original CB its verification environment. In particular, given the coverage algorithm, the adaptive CB algorithm, and the baseline fuzzer. context of a PUT ct and the test at selected by ReFuzz, The original CB algorithm achieves 2.43% more coverage and t+1 = g(ct, at) is the next coverage context of the PUT. 4.35× Formally, the mathematical objective of ReFuzz is achievespeedup than the baseline. The adaptive CB algorithm maxπ E Xn rt(ct, at) | at ∼ π(· | ct), ct+1 = g(ct, at). 3.92% more coverage and 5.40× speedup7. 70.0 t=1 C. Training a Contextual Bandit (CB) Model 67.5 Figure 3 shows how ReFuzz applies CB to identify effec- tive tests and takes two inputs: PP-tests and various coverage 65.0 Baseline Fuzzer contexts collected during fuzzing PPs. Following industry Original CB practices in creating directed tests for different verification Adaptive CB purposes [21], we categorize PP-tests into either vulnerability 62.5 0 5 10 15 20 tests that trigger known vulnerabilities or coverage tests that Program Count (xK) improve coverage achieved on one or multiple PPs. During training, ReFuzz generates two types of test lists: Figure 4. The total coverage achieved by the baseline fuzzer, original CB, vulnerability list and multiple coverage lists. A test list con- and adaptive CB on BOOMV4 [6]. tains optimal PP-tests identified by the CB model associated with a probability distribution, in which θ1 corresponds to D. Challenges and Solutions the probability of T est1 being selected by the CB model The original CB algorithm achieves limited improvement for a given coverage context c1. Each coverage list is tuned on the baseline fuzzer due to two major challenges. to a specific coverage context. Multiple coverage lists help Challenge 1. Ineffective tests remain in the lists. The orig- ReFuzz to prioritize tests precisely based on the current inal CB algorithm assumes that all actions remain available coverage context and prevent ReFuzz from selecting the forever [45]. However, in fuzzing, some tests consistently same test across different coverage contexts. For example, the achieve zero coverage increment and should not remain in coverage list trained for 50% coverage context contains more consideration. Moreover, since training a CB model is an tests that explore major design spaces in a PUT. While the iterative process, newly selected tests may outperform existing coverage list for 70% coverage context contains more tests ones by achieving higher coverage increments. Without a that explore corner cases (see Section VI-D). The number of mechanism to eliminate ineffective tests, they remain in the coverage list depends on the granularity of coverage context test list, degrading ReFuzz’s overall performance. configured during ReFuzz’s setup. 7To make a fair comparison, the results only use PP-tests from the same However, using PP-tests to train a CB model is non-trivial due to the limitations in the original CB algorithms. To address baseline fuzzer. We collect PP-tests from multiple baseline fuzzers, which achieves substantial improvement (see Section VI-C).
6
Coverage Points (%)
Solution 1. We develop an adaptive CB algorithm with an Algorithm 1 Adaptive CB algorithm. elimination function. Unlike conventional elimination strate- gies [45] that only eliminate suboptimal arms, our approach 1: Inputs: Acorpus, c, k, γ, θ, n also aims to explore a broad range of effective tests to 2: Outputs: A, π enhance fuzzing efficiency. The algorithm trains the model by 3: Initialize: A ← ∅; Atmp ⊂ Acorpus with |Atmp| = k; iteratively identifying and retaining highly effective tests under πtmp(a|c) = |A1 ∀a ∈ A ; π(a|c) ← 0 ∀a; a tmp| tmp different coverage contexts. It monitors their effectiveness rˆ(a) ← 0 ∀ ∈ Atmp; #(a) ← 0 ∀a ∈ Atmp through moving-average coverage increments and dynamically 4: ∀a ∈ Atmp: update rˆ(a) and #(a) once. eliminates ineffective ones. Tests that consistently achieve high 5: for t = 1, 2, . . . , n do coverage increments are promoted to the final model. 6: at ∼ πtmp(· | c); rt ← r(c, at) Algorithm 1 outlines the adaptive CB algorithm, with the 7: πtmp ← UpdatePolicy(πtmp, c, at, rt) elimination function highlighted in gray. The inputs are the 8: rˆ(at) ← rˆ(aᵗ)×#(aᵗ)+r(c,aᵗ) ; #(a ) ← #(a ) + 1 then PP-test corpus Acorpus, a coverage context c, the number 9: if #(at) ≥ γ #(at)+1 t t of arms k, the check window γ, the pre-defined adaptive 10: if rˆ(at) = 0 then threshold θ, and the training step n. The outputs are the 11: Atmp ← Atmp \ {at} coverage list A and the policy π. Since the number of tests 12: a′ ← random sample(Acorpus) (arms) is changing during training, the algorithm uses an 13: Atmp ← Atmp ∪ {a′} auxiliary policy πtmp and a temporary arm set Atmp that 14: else if πtmp(at | c) ≥ θ then always contains k arms. For each coverage context c, the 15: A ← A ∪ {at} algorithm calculates the average coverage increments a test 16: π(at | c) ← πtmp(at | c) can achieve (Line 8). 17: Atmp ← Atmp \ {at} Once the test has been selected at least γ times (Line 9), 18: a′ ← random sample(Acorpus) the algorithm evaluates its effectiveness. If the test achieves no 19: Atmp ← Atmp ∪ {a′} coverage increment, it is dropped from Atmp with its relevant 20: π(a | c) ← Pₐ′π(a|c) ; return A, π variables (Line 11), and a new test from the PP-test corpus ∈A π(a′|c) Acorpus is added to maintain the number of arms (Lines 12– 13). However, if the probability to select the test exceeds the pre-defined adaptive threshold θ (Line 14), it is promoted to a single test and shows which coverage points it reaches. The the ultimate arm set A (i.e., the test list) and the final policy number of columns represents the total number of coverage π (Lines 15–16). Since the number of the ultimate arms will points defined by a target coverage metric in a PUT. vary depending on the coverage context and the effectiveness Constructing the coverage matrix for our test minimizer of PP-tests, the final policy needs to be normalized to ensure involves two key requirements. First, we must understand it remains a valid probability distribution (Line 20). the hierarchical structure of the PUT. This is essential for Challenge 2. Tests may achieve the same coverage points. correctly attributing coverage points to their corresponding The CB algorithm evaluates the effectiveness of tests indepen- register-transfer level (RTL) modules, enabling fine-grained dently, without accounting for overlap in coverage. As a result, analysis of where each test explores within the design. Second, it may prioritize multiple tests that reach the same coverage we need to monitor which coverage points within each RTL points, even if each individually achieves a high coverage module are reached by individual tests. This enables us to com- increment. This redundancy reduces exploration diversity and pile a row vector for each test in the coverage matrix, where leads to inefficient use of fuzzing resources. each entry reflects whether a coverage point was covered. Solution 2. We develop the test minimizer to remove redundant To address these requirements, we leverage the coverage tests before training, ensuring computational efficiency while databases generated by Synopsys VCS [50], an industry- preserving the total coverage achieved by the original test set. standard simulator. While VCS does not provide APIs for Specifically, the test minimizer selects the smallest possible directly accessing the hierarchical structure of the PUT or the subset of PP-tests that together reach the same total coverage status of coverage points, we can extract this information by as all PP-tests. For example, if test a covers all the coverage parsing the internal files of the databases. We then use the points covered by tests b and c, then tests b and c are removed. information to concatenate row vectors for tests and construct However, identifying such redundancies is computationally the coverage matrix. The approach ensures stability and re- challenging. Comparing tests pairwise or exhaustively evalu- mains compatible with a broad range of processor designs. ating all subsets quickly becomes intractable, as the number As a result, it facilitates the training of our CB model and of combinations grows exponentially with the number of tests. ReFuzz’s integration with industrial verification flows. The Therefore, inspired by MINTS [51], we formulate the task of result shows that test minimizer successfully identifies the selecting a minimal subset of tests as an optimization problem minimal subset by removing 98.76% redundant tests, reducing and solve it using integer programming. The model of test the number of tests from 126K to 1.5K (See Section VI-D). minimizer is discussed in Appendix A. The model requires a No elimination is performed on vulnerability tests. Note coverage matrix as the input, where each row corresponds to that the elimination function and the test minimizer are applied
7
only to coverage tests, which are numerous and highly redun- Training the Training PUTs Testing
dant. In contrast, we assume that vulnerability tests trigger CB Model Training PUTs Trained Results Select PUT
with different
distinct vulnerabilities and explore diverse design spaces. with different Trained Results
coverage
coverage Vulnerability Seeds
Vulnerability
Vulnerability List
Therefore, no vulnerability tests are dropped during training. Vulnerability
Tests List Current
E. Integrating the Trained CB Model with Processor Fuzzers Tests Adaptive CB Cov. HW
Adaptive CB Coverage Fuzzer
Algorithm Coverage
Algorithm Lists
Environment for testing. To evaluate the generalizability of Test Minimizer Lists Empty add r1...
our CB model, we test it in an environment that differs from Coverage add r1...
Coverage add r1...
sub r2...
Tests sub r2...
the training stage. Given that fuzzers may employ different Tests Dropped sub r2...
Tests New seeds
mutation strategies [11]–[13], the testing environment includes
both the baseline fuzzer and the PUT. Unlike the training Figure 5. The framework of ReFuzz.
stage, where the model uses only the incremental coverage of
each PP-test as the reward, ReFuzz evaluates the cumulative
incremental coverage of the PP-test and its mutated variants. ReFuzz begins by preprocessing a large corpus of tests from
Based on the cumulated incremental coverage, the CB model prior fuzzing campaigns. To address test redundancy, a test
automatically decides whether to continue mutating the current minimizer removes 98.76% of redundant tests, resulting in a
test or proceed to the next one. lean and effective test corpus for training. Next, 1 the adaptive
Altering the testing environment is standard practice for CB algorithm analyzes the performance of minimized tests assessing the generalizability of a CB model. This is analogous across prior processors and coverage contexts. This allows to sim-to-real generalization in reinforcement learning [52], ReFuzz to learn which tests are most likely to increase where models trained in simulation are tested under altered coverage under specific coverage contexts. 2 The output is dynamics, such as changes in gravity or actuator noise. a set of carefully curated test lists: a vulnerability list for Similarly, testing ReFuzz in an environment with different known vulnerabilities, and several coverage lists, each tuned to fuzzing mechanisms provides a more robust assessment of its a coverage context. In 3 the testing stage, ReFuzz integrates effectiveness. Empirical results show that ReFuzz is agnostic with an existing processor fuzzer to guide its test selection. to fuzzers with distinct mechanisms and outperforms them in The result is a unified framework that combines the speed and both total coverage and coverage speed (see Section VI-C). targeted nature of directed testing with the explorative power Resuming seed generation. Unlike the training stage, of processor fuzzers. ReFuzz does not add new tests to the curated test lists V. BENCHMARKS, TRAINING, AND IMPLEMENTATION during testing. Thus, when a coverage list becomes empty due to the unique design features of the PUT, ReFuzz allows Fuzzer selection. We select fuzzers to generate tests the fuzzer to resume its native seed generation to continue for training based on two criteria: (i) Do fuzzers implement exploring the design spaces. Additionally, if the total coverage distinct algorithms that increase the probability of verifying is too low (no match with any coverage context) for the CB diverse processor functionalities? This diversity helps ReFuzz algorithm to select tests from the next coverage list, and the identify tests that explore a broad range of design spaces. current coverage list is empty, ReFuzz will skip directly to (ii) Are fuzzers’ strategies generalizable, allowing them to be the next list, avoiding stalling fuzzing progress. In summary, applied across different processor designs? This generalizabil- ReFuzz resumes the fuzzer’s own seed generation strategies ity enables ReFuzz to evaluate the effectiveness of a test only after all curated test lists have been exhausted, ensuring on a variety of processors following the same ISA. Based on efficient reuse of PP-tests while maintaining flexibility to these criteria, we select TheHuzz and Cascade [12] as our explore unique design features of the PUT. baseline fuzzers. Appendix F includes detailed justifications. ReFuzz begins by selecting tests from the vulnerability Benchmark selection. While ISAs define the functionalities list and monitors their coverage increment. If a test and its and interfaces of processors, hardware vulnerabilities often mutated variants fail to improve coverage, it is dropped. Once arise from microarchitectures. Therefore, we select processors all tests in the vulnerability list are dropped, ReFuzz switches with diverse microarchitectures as benchmarks. to coverage lists. ReFuzz tracks the total coverage achieved Table II by vulnerability tests and uses this information to determine the current coverage context and decide the starting coverage MICROARCHITECTURAL FEATURES IN BENCHMARK PROCESSORS. list. ReFuzz periodically evaluates each test, removing those Processor OoO SIMD Ld/St Speculative Mem. Dep. that show no further coverage increment, and continues this CVA6 [8] Forwarding Scheduling Predictor process until all coverage lists are empty. Appendix H shows Rocket Core [7] the detailed integration process. BOOMV3 [6] BOOMV4 [6] F. Putting it all Together RSD [53] The ReFuzz framework consists of the training and the Given that most commercial processors are protected in- testing stages, as shown in Figure 5. In the training stage, tellectual property (IP) and closed-source, we select bench-
8
marks from open-source RISC-V processors. Table II sum- 65% across the three training processors. Based on this obser-
marizes the microarchitectures of each processor. To capture a vation, we define coverage context at {55%, 60%, 65%, 70%}.
broad range of microarchitectures, we select three widely-used These coverage contexts are also applied during testing to
RISC-V processors by existing processor fuzzers [11]–[13], determine appropriate coverage lists.
[33], [36] for training: Rocket Core [7], BOOMV3 [6], and To maximize effectiveness and avoid test overlap between
CVA6 [8]. We also include BOOMV4 and RSD [53] to evaluate coverage lists, we begin training ReFuzz from the highest the effectiveness of ReFuzz. BOOMV4 is the next generation coverage context (e.g., 70%) and use the remaining tests to of BOOMV3, enabling assessment of ReFuzz’s adaptability to train the lower contexts. During training, ReFuzz randomly different generations of processors. selects one of the training processors to compute the reward Simulation and vulnerability detection. We use Chipyard of each test for a given coverage context. (version 1.13.0, commit 69eba86) [54] as the simulation Configuring the CB model. According to Algorithm 1, we environment for CVA6 [8], Rocket Core [7], BOOMV3, heuristically configure the number of arms k to 100 and check and BOOMV4 [6], while RSD (commit 7b65f6b) [53] is window γ to 3. ReFuzz is trained at 10000 steps to identify simulated using VCS [50]. We employ differential testing, a effective tests for each coverage context. A critical parameter commonly used approach in the processor fuzzers, to detect in the adaptive CB algorithm is the adaptive threshold θ, which vulnerabilities and bugs, as mentioned in Section II-B. We determines test effectiveness. Setting θ too high may result in use Spike (commit de5094a) [55] as the golden-reference too few tests being identified (fewer than 10), while setting it model, widely used by existing fuzzers [11], [24], [33], [56]. too low may include too many, diluting the selection of optimal All experiments are conducted on a 48-core AMD EPYC 7443 tests. To balance this tradeoff, we configure θ separately for processor at 2.6 GHz with 256GB RAM. each coverage context: θ = {55% : 1.90, 60% : 1.50, 65% : Building the PP-test corpus. For vulnerability tests, we 0.90,70% : 1.26}. The threshold ensures that, by the end of collect tests that trigger vulnerabilities detected by two fuzzers training, each coverage list includes approximately 100 effec- on the training processors. TheHuzz detects four vulnera- tive tests, aligning with the number of arms k. Appendix B bilities in CVA6, while Cascade detects ten vulnerabilities details how we fine-tune the threshold automatically. in CVA6 and two in BOOMV3. For coverage tests, we run Manual efforts and automation. Manual efforts are required both TheHuzz and Cascade to generate 21K tests per to set up existing fuzzers for processors and collect coverage training processor, resulting in a total of 126K tests. For a results because fuzzers may not support all benchmarks. This fair comparison in Section III, we use TheHuzz [11] and its is a general step for all fuzzers. For vulnerability tests, we coverage tests as the baseline. obtain them directly from artifacts or documented GitHub A. Training issues. Once the PP-test corpora and fuzzers are configured, the training and testing processes are fully automatic. Preprocessing the PP-test corpus. As mentioned in Sec- tion IV-C, we develop a test minimizer to remove redundant VI. EVALUATION tests and implement it using DOcplex [57] from IBM. To We evaluate ReFuzz comprehensively to answer the fol- construct the coverage matrix, we developed a parser to parse lowing questions: VCS coverage databases (i.e., .vdb). After executing each Q1. Can ReFuzz effectively reuse prior-processor tests (PP- test, the parser identifies the RTL modules and their associated tests) to detect variants of known vulnerabilities on coverage points, determines whether each point was reached, processor-under-tests (PUTs)? and encodes this as a binary vector, with the ordering aligned Q2. Is ReFuzz agnostic to existing fuzzers, and can it to the traversal sequence of the module hierarchy. This binary outperform them on total coverage and coverage speed? vector serves as a row in the coverage matrix. The parser Q3. What are the individual contributions of various ReFuzz repeats this process for all PP-tests. optimizations and parameters? Sampling coverage contexts. We sample coverage contexts We first discuss the new vulnerabilities and bugs detected from the training processors during fuzzing with TheHuzz by ReFuzz, highlighting their connection to the design reuse and Cascade. We obtain coverage feedback using Synopsys strategy. To show the generalization of ReFuzz across dif- VCS [50]. Starting at 55% total coverage, we sample a new ferent fuzzers, we integrate ReFuzz with TheHuzz [11] and coverage context at every 5% increment. Cascade [12] and evaluate the improvement on total cover- Training stage. We implement both the original and adaptive age and coverage speed. Each fuzzer generates 21K tests per CB algorithms using the MABWiser Python library [58]. To processor, and we repeat the experiment three times to evaluate encourage exploration of diverse, high-effective tests, we adopt the average results. Finally, we analyze how the optimization the ϵ-greedy algorithm for the CB algorithm with an explo- and configuration impact the efficiency of ReFuzz. ration probability (ϵ) of 0.2. We use branch coverage as the target metric due to its importance in uncovering vulnerabili- A. New Vulnerabilities and Bugs ties [33]. ReFuzz can also be configured for other coverage ReFuzz detected three new security vulnerabilities and two metrics. We observe that branch coverage often starts above new functional bugs across multiple processors. Affected com- 50% and can quickly exceed 60%, but growth slows around mits are mentioned in Section V. B1 and B2 lead to incorrect
9
outputs of performance counters. Bug B1 exists in Rocket two new bugs, as shown in Table IV (See Appendix C), their Core [7], BOOMV3, and BOOMV4 [6], all of which share a time-to-bug numbers are not informative for speed comparison hardware module. The bug exists across three processors due and were excluded. But they still demonstrate how IP reuse can to design reuse and characteristics of the Chisel hardware propagate vulnerabilities and how different microarchitectures programming language [5]. Bug B2 affects both BOOMV3 and can introduce vulnerability variants. BOOMV4, with BOOMV4 exhibiting additional variants due to ReFuzz takes an average 6.29× less real time and 5.98× its new microarchitectures, as discussed in Section III. Precise less tests to detect new vulnerabilities. ReFuzz detects V1 implementation of performance counters is critical for perfor- faster than TheHuzz [11] because the seed that triggers mance analysis, profiling, and debugging [47]. In addition, another FENCE.I-related vulnerability in CVA6 is in the performance counters are used for malware detection [49]. vulnerability list of ReFuzz. As a result, ReFuzz does not Therefore, instructions that produce incorrect counter values need to generate such seeds from scratch. ReFuzz’s test speed can reduce detection accuracy and may also serve as side is similar to Cascade for V1 because Cascade aims to channels for information leakage. A detailed analysis of these generate long inputs with diverse instructions, increasing the two bugs is provided in Appendix C. probability of containing the instructions that can trigger V1. The vulnerabilities are severe, with CVSS scores ranging However, the time-to-bug is 14.76× faster because the PP- from 7.1 to 8.5 (out of 10) [59], and enable exploit scenarios, test only contains the instructions that can trigger the V1, such as denial of service (DoS) or unauthorized access. leading to less simulation time. While users have to identify The vendors either acknowledge the new vulnerabilities and the instructions that trigger V1 from Cascade’s long inputs. bugs, or we have identified their root causes. To answer This also shows that reusing effective PP-tests can further Q1, ReFuzz effectively reuses PP-tests to detect variants of enhance the following debugging process. known vulnerabilities on PUTs. However, ReFuzz detected V2 and V3 that are not on Vulnerability V1 (CVSS score: 7.1). A memory deadlock the vulnerability list slower than TheHuzz. This is because occurs on the RSD processor when executing the FENCE.I ReFuzz prioritizes the PP-tests of known vulnerability as instruction. ReFuzz reuses the vulnerability test that triggers mentioned in Section IV-F, which delays the identification of a FENCE.I-based vulnerability in CVA6 [8] to detect this V2 and V3. Adding the corresponding tests for V2 and V3 vulnerability. V1 presents a denial-of-service vector. Any user- will improve the speed of vulnerability detection. Moreover, mode program capable of executing arbitrary instructions can integrating ReFuzz with Cascade can not detect these two invoke FENCE.I to cause the memory deadlock of the proces- vulnerabilities because Cascade constrains the values of the sor. A potential exploitability context is shown in Appendix D. “funct3” field of LOAD and STORE instructions to always be Vulnerability V2 (CVSS score: 8.5). RSD executes illegal in the valid range. This shows the need to include PP-tests LOAD instructions, leading to DoS attacks or unauthorized from fuzzers with distinct mechanisms and include mutation access attacks. A malicious attacker can execute instructions processes to enhance design space exploration. to compromise the system’s security. This vulnerability is an C. Coverage Evaluation undocumented hardware feature, CWE-1242 [60]. To answer Q2, we compare the capability of ReFuzz in Vulnerability V3 (CVSS score: 8.5). This vulnerability is achieving coverage with the baseline fuzzers: TheHuzz [11] similar to V2 except that the opcode corresponds to the and Cascade [12]. Unlike the evaluations in Sections III-B STORE instruction. Both vulnerabilities V2 and V3 stem from and IV-C, we use the PP-tests from both fuzzers to train the same root cause in RSD’s instruction decoding logic, as ReFuzz for comprehensive evaluation. Across two testing discussed in Appendix E. V2 can allow malicious programs processors, BOOMV4 and RSD, ReFuzz achieves a 511.23× to probe memory in ways not anticipated by the software coverage speedup on average than the baseline fuzzers. Specif- stack, potentially enabling information disclosure. V3 can ically, ReFuzz generates 511.23× fewer tests to achieve the compromise data integrity in user-mode or shared-memory same total coverage as the baseline fuzzers. For total coverage, scenarios, weaken isolation boundaries, and overwrite control ReFuzz achieves an average of 1.89% more total coverage.. data structures managed by higher-privileged components. Though using CVA6, Rocket Core, and BOOMV3 for Appendix D shows their potential exploitability context. training, ReFuzz outperforms both baseline fuzzers in total B. Vulnerability Detection Speed coverage. On average, ReFuzz achieves 3.48% more total coverage across all five processors, highlighting ReFuzz’s We compared ReFuzz’s efficiency against TheHuzz and ability to reuse highly effective tests to help fuzzers explore Cascade on vulnerability detection. Since ReFuzz reuses more design spaces. Figure 6 shows coverage results. inputs that trigger known bugs in training processors, we Comparison with TheHuzz. For testing processors, ReFuzz evaluate time-to-bug and required tests to detect new vul- achieves 5.94% more total coverage and a 1818.27× speedup nerabilities in testing processors (RSD and BOOMV4), which compared to TheHuzz on BOOMV4 and achieves similar prevents overfitting. To measure time-to-bug, we use VCS as total coverage (68.45%) as TheHuzz (68.54%) on RSD. On the simulation tool for all fuzzers. Table III summarizes the the training processors, ReFuzz achieves 6.11% more total results. Because a wide range of instructions can trigger the coverage on CVA6 and 9.33% more total coverage on Rocket
10
Table III
SUMMARY OF VULNERABILITY DETECTION SPEED OF TH EHU Z Z [11], CA S C A D E [12], AND REFU Z Z . N.D. REFERS “NOT DETECTED.”
Vulnerability Processor CWE TheHuzz ReFuzz+ Time (sec) ReFuzz+ Speedup TheHuzz ReFuzz+ Tests ReFuzz+
TheHuzz Speedup Cascade Cascade TheHuzz Speedup Cascade Cascade Speedup
V1: FENCE.I causes RSD 833 137.44 15.73 8.74× 202.78 13.74 14.76× 83.33 4.00 20.83× 4.67 4.00 1.17×
memory deadlock
V2: Illegal LOAD RSD 1242 478.43 853.65 0.56× N.D. N.D. — 302.33 478.33 0.63× N.D. N.D. —
can be executed
V3: Illegal STORE RSD 1242 596.06 545.18 1.09× N.D. N.D. — 375.00 296.00 1.27× N.D. N.D. —
can be executed
TheHuzz Cascade ReFuzz+TheHuzz ReFuzz+Cascade
85
70
55
CVA6 RC BoomV3 BoomV4 RSD
40
85
70
55
CVA6 RC BoomV3 BoomV4 RSD
40 0 4 8 12 16 20 0 4 8 12 16 20 0 4 8 12 16 20 0 4 8 12 16 20 0 4 8 12 16 20
Program Count (xK)
Figure 6. Branch coverage results of TheHuzz [11], Cascade [12], and ReFuzz.
Core. This is because ReFuzz leverages the mutation en- future iterations of ReFuzz could be trained using a set of gines of TheHuzz to mutate tests with complex data- and 32-bit RISC-V processors. control-flow logic from Cascade, which helps explore more Evaluating condition coverage. To evaluate the comprehen- design spaces than randomly generated seeds. siveness of ReFuzz, we also use condition coverage as the Comparison with Cascade. For testing processors, ReFuzz target metric. Compared to branch coverage, condition cover- achieves 0.63% more total coverage and a 10.90× speedup age is a finer coverage metric that monitors the possible signal compared to Cascade on BOOMV4. On RSD, ReFuzz combinations in branch statements [33]. The coverage context achieves similar total coverage (67.88%) as Cascade does and the adaptive threshold θ are configured as θ = {45% : (66.91%) but still achieves a 215.06× coverage speed than 14.84,50% : 11.82, 55% : 7.81, 60% : 4.69, 65% : 2.86}. Cascade. On the training processors, ReFuzz achieves Across two testing processors, BOOMV4 and RSD, ReFuzz 1.30% more coverage on Rocket Core. This is because achieves an average of 223.57× coverage speed and 2.2% ReFuzz incorporates tests generated by TheHuzz, which more total coverage. On average, ReFuzz achieves a 279.44× helps explore corner cases. ReFuzz achieves limited im- coverage speed and 3.05% more total coverage across all five provement on total coverage when integrating with Cascade, processors. Appendix G includes more details. primarily because Cascade lacks a mutation engine and Overall, to answer Q2, ReFuzz is agnostic to existing depends only on the existing tests. fuzzers and outperforms them in both total coverage and Yet, ReFuzz achieves 5.48% more total coverage and a coverage speed. These improvements highlight its ability to 1086.98× speedup over Cascade on CVA6, because the generate more effective tests and accelerate the exploration FENCE.I will cause CVA6 to hang using Cascade’s setup. of processor design spaces, making it a robust and scalable Since most of Cascade’s tests include this instruction, they solution for enhancing vulnerability detection across a wide hang early in execution, preventing subsequent instructions range of processors. from running and limiting their ability to explore the design spaces of CVA6. ReFuzz eliminates most of these tests during D. Evaluating ReFuzz’s Optimizations and Parameters training, highlighting the importance of dropping ineffective To answer Q3, in Sections III-B and IV-C, we have tests and evaluating the effectiveness of tests across processors. analyzed how ReFuzz leverages the mutation engines of Coverage improvement on RSD is limited compared to both baseline fuzzers to achieve higher total coverage, and how the baseline fuzzers because RSD is a 32-bit RISC-V processor, adaptive CB algorithm helps ReFuzz identify effective tests whereas all training processors are 64-bit. As a result, many compared to the original CB algorithm. instructions of PP-tests identified during training are illegal In this section, we further examine how different optimiza- or invalid on RSD, reducing the effectiveness of tests and tions and parameters affect ReFuzz’s efficiency. Specifically, hindering design space exploration. To address this limitation, we focus on the impact of the PP-test corpus and the number
11
Cascade vs TheHuzz vs ReFuzz+Cascade Coverage Points (%) ReFuzz+TheHuzz
of training steps on the efficiency and effectiveness of the 100 All Interesting Minimized
trained CB model. Unlike other parameters such as the number 75
of arms, which make minor adjustments to the configuration
of ReFuzz’s CB model, the PP-test corpus determines the 50
effectiveness of tests, while the training steps decide whether 25
the model has sufficient time to identify optimal tests. 0
To make a comprehensive analysis, we prepared three PP- 0.5 1 2 5 8 10
test corpora of different sizes. The all corpus includes all Steps (K)
PP-tests generated by both fuzzers. The interesting corpus Figure 8. Training ReFuzz’s CB model with different training steps.
includes only interesting PP-tests that achieve incremental
coverage during fuzzing the prior processors. The minimized
corpus consists of PP-tests identified by our test minimizer. of 89 effective tests from the minimized corpus, compared to
Test minimizer. Figure 7 shows the results of applying the test 77 from the interesting corpus and 51 from the all corpus. This minimizer to the all corpus to generate the minimized corpus. result underscores the impact of the test minimizer in improv- Compared to the original 21K tests generated by each fuzzer, ing the training efficiency and the CB model’s effectiveness. it significantly reduces the corpus size. For example, it reduces Compared to other coverage contexts, identifying the effec- the number of TheHuzz tests for Rocket Core from 21K tive tests for the 70% coverage context requires longer training to 174, achieving a 99.17% reduction rate. On average, the steps, as the remaining uncovered points tend to be corner test minimizer takes 944.28 seconds and achieves a 98.76% cases. ReFuzz requires fewer training steps to find effective reduction rate compared to the number of PP-tests in the all tests for other coverage contexts. corpus and a 65.89% reduction rate compared to the interesting To answer Q3, the test minimizer effectively reduces the corpus. This substantial reduction highlights the high degree size of the PP-test corpus while preserving total coverage, of redundancy among tests and underscores the importance of demonstrating its value in eliminating redundant tests. Analy- reusing highly effective tests to improve fuzzing efficiency. sis of different training steps confirms the anytime property of CB algorithms and indicates that highly effective tests TheHuzz All Int. Min. identified by the test minimizer can enhance the efficiency 2 × 10⁴ Cascade of the training process. 10⁴ 10³ VII. RELATED WORK 10² Seed generation. Traditional approaches, such as those used in DIFUZZRTL [24] and ProcessorFuzz [23], rely on ran- 10¹ domly generating instruction sequences [11], [24], [26], [42]. 10⁰ MorFuzz [13] and Cascade [12] increase input diversity by CVA6 Rocket Core BOOMV3 enforcing control- and data-flow constraints during generation. Processors HyPFuzz [33] uses formal verification to synthesize inputs Figure 7. The number of tests the test minimizer reduces from TheHuzz [11] that reach hard-to-reach design spaces but scale poorly with and Cascade [12]. “Int.” represents the interesting corpus, and “Min.” complex designs. Machine learning-based approaches [35], represents the minimized corpus. [61], such as HFL [37] and GenHuzz [36], explore the use of Different training steps and PP-test corpora. CB algorithms large language models or reinforcement learning to generate support anytime learning, meaning that longer training gener- instruction streams with semantic and structural dependencies. ally yields better results. To study this effect, we vary the Despite promising early results, these methods often suffer number of training steps, 0.5K, 1K, 2K, 5K, 8K , and 10K , from hallucinations or invalid tests, limiting their practicality. and test each setting across three PP-test corpora. For every Seed schedule. MABFuzz [56] leverages multi-armed bandit setting, we measure how many effective tests the adaptive CB approaches and coverage feedback to identify an optimal algorithm identifies and repeat the experiment three times to schedule of seeds for each PUT. However, it is incompatible report average results. with non-feedback-based fuzzers like Cascade and relies on Figure 8 presents the average number of effective tests on the baseline fuzzer’s seed-generation strategy. ReFuzz dis- the coverage list when the coverage context is 70%. Using the cards fuzzers’ internal strategies and intelligently uses effective all corpus as an example, we observe that as training steps PP-tests to enhance fuzzing efficiency. increase from 0.5K to 10K , the average number of effective Coverage metrics. Existing processor fuzzers either rely on tests rises from 4 to 51, demonstrating the anytime property industry-standard code coverage metrics [11], [33], [35]–[37] of CB algorithms. Because the minimized corpus contains or define custom hardware-specific metrics [13], [23], [24], the smallest subset of PP-tests that achieves equivalent total [43]. Standard coverages are broadly compatible with existing coverage as the all corpus, ReFuzz is able to identify more design flows and simulation environments widely used in effective tests from it under the same training steps. For industry [62], [63], making them the most practical option example, at 10K training steps, ReFuzz identifies an average for testing production-grade designs. Custom coverage metrics
12
Number of Tests
Number of Tests (#)
attempt to capture more internal behaviors, such as multiplexer could identify the relevant features and their interactions and activity [43], register toggling [24], or instruction seman- then generate appropriate inputs. Finally, ReFuzz can adapt tics [13] but face integration barriers to industry verification to verification platforms with different observability levels flows. ReFuzz adopts industry-standard code coverage and by using any quantitative metric that defines 0% and 100% ensures simple integration with industry verification flows. coverage. As long as coverage increments can be computed Vulnerability detection. Most processor fuzzers are designed (Definition 3), ReFuzz can operate on that platform. to detect functional bugs through differential tests [11], [23], For sparsity, when historical design data are limited, ven- [24], [33], [35], [36], [61]. Orthogonal efforts target microar- dors can enrich their test suites by incorporating tests from chitectural vulnerabilities, including speculative execution at- other ISAs and translate them to the target ISA. For designs tacks [28]–[31] and timing side-channels [25], [27], lever- with highly customized or sparse architectures, integrating aging techniques like information flow tracking (IFT) [64], additional mutation engines into ReFuzz can help explore [65]. These works differ in their threat models and detection architecture-specific features. methods but share the same underlying need for effective test Finally, for scalability, combining integer linear program- generation. Since ReFuzz focuses on optimizing test reuse, ming (ILP), clustering, and approximation algorithms can it is agnostic to the target vulnerability and can be integrated tackle the challenge. One strategy is to partition the overall with a wide range of detection strategies. suite into smaller subsets and build a hierarchical approach. Overall, ReFuzz fills a key gap in prior work, which The approaches perform ILP on each subset, merge the re- treats each processor independently and generates seeds from sulting minimal suites, and then run ILP again to obtain a scratch, ignoring useful information from earlier testing ef- global minimal set. This approach, coupled with paralleliza- forts. ReFuzz introduces a CB-based test reuse framework tion, can substantially improve efficiency. If scalability issues that adaptively selects and mutates tests from prior proces- persist even after clustering, approximation algorithms, such sors for the current PUT. This approach improves coverage as greedy heuristics, can provide near-optimal solutions with and increases the likelihood of uncovering cross-generational significantly lower overhead. vulnerabilities and their variants. IX. CONCLUSION VIII. DISCUSSION Design reuse leads to vulnerabilities that propagate across processor generations. ReFuzz proposes the first test reuse Integrating ReFuzz with industry verification pipelines. hardware fuzzing framework that reuse and mutate effective ReFuzz naturally fits into the continuous integration and tests from prior processors to enhance fuzzing on processors- regression testing pipeline for IP vendors due to its anytime under-test, leveraging contextual bandit algorithms. ReFuzz learning property, allowing ReFuzz to continuously iden- is also agnostic to processor fuzzers or any dynamic techniques tify and reuse effective PP-tests while keeping the trained that require seeds to initiate their processes. ReFuzz uncov- model within a reasonable size. Moreover, besides Synopsys ered three new vulnerabilities. One was triggered by the same VCS [50], ReFuzz is compatible with coverage metrics from test that triggered vulnerabilities in a prior processor. It detects other industrial simulators, such as Cadence Xcelium [66] two functional bugs across three processors due to shared and Siemens Questa One Sim [67], which also generate designs. Evaluations show that ReFuzz achieves an average coverage files similar to VCS’s coverage database. 511.23× coverage speed and 1.89% more total coverage over Future challenges. To further strengthen ReFuzz’s impact on baseline fuzzers. These results establish ReFuzz as a practical the semiconductor development cycle, we identify three key solution for processor security, especially for companies like challenges: (i) Generalizability. In practice, hardware designs Intel and AMD, which have effective tests from a broad range vary in ISA extensions (e.g., 32-bit vs. 64-bit RISC-V, or of prior processors. cross-ISA settings such as RISC-V and ARM) and verifica- tion platforms (e.g., FPGA-prototyping, black-box, and hybrid ACKNOWLEDGMENT flows). (ii) Sparsity. Reuse may be constrained when vendors We thank Stephen Muttathil for his contribution to have limited historical designs or employ heavily customized Cascade implementation. Our research work was partially architectures. And (iii) Scalability. The reliance on integer funded by Intel’s Scalable Assurance Program, ONR Award programming to build the test minimizer may raise scalability #N00014-18-1-2058, the Lockheed Martin Corporation, NSF- concerns when applied to large industrial test suites. Grant 2344914, SRC-3308.001, the SCALE Fellowship Pro- Future directions. For generalizability, ReFuzz can evolve in gram (M2402515), DFG-SFB 1119-236615297, the European two directions. First, it can support more contexts, such as ISA Union under Horizon Europe Programme-Grant Agreement extensions or even cross-ISA scenarios, so that it can reuse 101070537-CrossCon, NSF-DFG-Grant 538883423, and the more precise tests, similar to selecting ISA extensions when European Research Council under the ERC Programme-Grant compiling binaries. Second, an abstract CB model could use 101055025-HYDRANOS. This work does not in any way microarchitectural features, functionalities, and ISA extensions constitute an Intel endorsement of a product or supplier. Any as context, along with mappings between instructions and opinions, findings, conclusions, or recommendations expressed the features they exercise. Under a given context, the model herein are those of the authors.
13
X. ETHICS CONSIDERATIONS [12] F. Solt, K. Ceesay-Seitz, and K. Razavi, “Cascade: CPU Fuzzing via
We consider the paper without potentially negative out- Intricate Program Generation,” USENIX Security Symposium, 2024.
comes from tangible harms and violations of human rights. [13] J. Xu, Y. Liu, S. He, H. Lin, Y. Zhou, and C. Wang, “Morfuzz: Fuzzing processor via runtime instruction morphing enhanced synchronizable co- We consider the full spectrum of stakeholders and the pa- simulation,” USENIX Security Symposium, 2023. per, including no harms related to exposing the identity of [14] M. Ender, A. Moradi, and C. Paar, “The Unpatchable Silicon: a Full research subjects, such as the individual identities, groups, Break of the Bitstream Encryption of Xilinx 7-Series FPGAs,” USENIX Security Symposium, 2020. and organizations, and the behaviors, communications, or [15] “USN-3597-2: Linux kernel (HWE) vulnerabilities,” https://ubuntu.com relationships associated with such identification. Respect for /security/notices/USN-3597-2, last accessed on 11/05/2025. Persons. The research targets open-sourced hardware designs [16] “USN-3531-3: intel-microcode update,” https://ubuntu.com/security/no and does not involve natural persons, live systems, or certain [17] tices/USN-3531-3, last accessed on 11/05/2025. “KB4457951: Windows guidance to protect against speculative execu- data that identifies them. Thus, no harm is caused to human tion side-channel vulnerabilities,” https://support.microsoft.com/en-us/ subjects, non-subjects, and information and communication topic/kb4457951-windows-guidance-to-protect-against-speculative-exe technology users, such as disruption of access, loss of privacy, cution-side-channel-vulnerabilities-ae9b7bcd-e8e9-7304-2c40-f047a0a b3385, last accessed on 11/05/2025. or unreasonable constraints on protected speech or activities. [18] “Intel Annual Report, 1994,” https://www.intel.com/content/www/us/e Beneficence. To minimize the relevant harmful impacts, we n/history/history-1994-annual-report.html, last accessed on 11/05/2025. contacted the vendors of open-sourced benchmarks as soon as [19] B. Bailey, “Practical Processor Verification,” https://semiengineering.co our strategy detected the vulnerabilities. Moreover, based on [20] m/practical-processor-verification/, 2020, Last accessed on 07/14/2025. “User Stories,” https://cwe.mitre.org/about/user stories.html, Last our current knowledge, the vulnerabilities exist in an open- accessed on 07/14/2025. source benchmark, which has not been used for any commer- [21] S. Ye, “Best Practices for a Reusable Verification Environment,” https: cial purposes. We discuss the root causes of vulnerabilities //www.eetimes.com/best-practices-for-a-reusable-verification-environ in the paper to help vendors and potential users mitigate [22] ment, 2004, Last accessed on 07/08/2025. M. Rostami, C. Chen, R. Kande, H. Li, J. Rajendran, and A.-R. Sadeghi, the vulnerabilities. Justice: Fairness and Equity. We select “Fuzzerfly Effect: Hardware Fuzzing for Memory Safety,” IEEE Security benchmarks that are widely used in existing papers. We select [23] & Privacy, 2024. existing techniques as baselines based on their distinct and S. Canakci, C. Rajapaksha, L. Delshadtehrani, A. Nataraja, M. B. Taylor, M. Egele, and A. Joshi, “ProcessorFuzz: Processor Fuzzing with unique features. We evaluate the performance of our technique Control and Status Registers Guidance,” IEEE International Symposium and baselines on the same platform for a fair comparison. [24] on Hardware Oriented Security and Trust, 2023. J. Hur, S. Song, D. Kwon, E. Baek, J. Kim, and B. Lee, “DIFUZZRTL: REFERENCES Differential Fuzz Testing to Find CPU Bugs,” IEEE Symposium on Security and Privacy, 2021. [1] D. A. Patterson and J. L. Hennessy, “Computer Organization and Design [25] C. Rajapaksha, L. Delshadtehrani, M. Egele, and A. Joshi, “SIGFuzz: A ARM edition: the Hardware Software Interface,” Morgan Kaufmann, Framework for Discovering Microarchitectural Timing Side Channels,” 2016. Design, Automation & Test in Europe Conference & Exhibition, 2023. [2] “Intel® 64 and IA-32 Architectures Software Developer Manuals,” https: [26] Y. Sugiyama, R. Matsuo, and R. Shioya, “SurgeFuzz: Surge-Aware Di- //www.intel.com/content/www/us/en/developer/articles/technical/intel-s rected Fuzzing for CPU Designs,” IEEE/ACM International Conference dm.html, last accessed on 11/05/2025. on Computer Aided Design, 2023. [3] “Intel® Core™ Processor Family,” https://www.intel.com/content/ww [27] P. Borkar, C. Chen, M. Rostami, N. Singh, R. Kande, A.-R. Sadeghi, [4] w/us/en/products/details/processors.html, last accessed on 11/05/2025. C. Rebeiro, and J. Rajendran, “Whisperfuzz: White-box Fuzzing for I. Manage, “Design Data Management Worldwide Trends – Survey Detecting and Locating Timing Vulnerabilities in Processors,” USENIX Report,” https://www.icmanage.com/design- data- management- wor Security Symposium, 2024. [5] ldwide-trends-survey-report/, 2013, last accessed on 11/20/2025. [28] J. Hur, S. Song, S. Kim, and B. Lee, “SpecDoctor: Differential Fuzz J. Bachrach, H. Vo, B. Richards, Y. Lee, A. Waterman, R. Aviˇzienis, Testing to Find Transient Execution Vulnerabilities,” ACM SIGSAC J. Wawrzynek, and K. Asanovi´c, “Chisel: Constructing Hardware in a Conference on Computer and Communications Security, 2022. [6] Scala Embedded Language,” Design Automation Conference, 2012. [29] M. Rostami, S. Zeitouni, R. Kande, C. Chen, P. Mahmoody, J. R. J. Zhao, B. Korpan, A. Gonzalez, and K. Asanovic, “SonicBOOM: The Rajendran, and A.-R. Sadeghi, “Lost and Found in Speculation: Hybrid 3rd Generation Berkeley Out-of-Order Machine,” Fourth Workshop on Speculative Vulnerability Detection,” ACM/IEEE Design Automation [7] Computer Architecture Research with RISC-V, May 2020. Conference, 2024. K. Asanovi´c, R. Avizienis, J. Bachrach, S. Beamer, D. Biancolin, [30] A. de Faveri Tron, R. Isemann, H. Ragab, C. Giuffrida, K. von Gleis- C. Celio, H. Cook, D. Dabbelt, J. Hauser, A. Izraelevitz, S. Karandikar, senthall, and H. Bos, “Phantom Trails: Practical Pre-Silicon Discovery B. Keller, D. Kim, J. Koenig, Y. Lee, E. Love, M. Maas, of Transient Data Leaks,” USENIX Security Symposium, 2025. A. Magyar, H. Mao, M. Moreto, A. Ou, D. A. Patterson, B. Richards, C. Schmidt, S. Twigg, H. Vo, and A. Waterman, “The Rocket Chip [31] M. Ghaniyoun, K. Barber, Y. Zhang, and R. Teodorescu, “IntroSpectre: Generator,” EECS Department, University of California, Berkeley, A Pre-Silicon Framework for Discovery and Analysis of Transient Tech. Rep. UCB/EECS-2016-17, Apr 2016. [Online]. Available: http: Execution Vulnerabilities,” International Symposium on Computer Ar- //www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-17.html chitecture, 2021. [8] F. Zaruba and L. Benini, “The Cost of Application-Class Processing: [32] X. Zhu, S. Wen, S. Camtepe, and Y. Xiang, “Fuzzing: A Survey For Energy and Performance Analysis of a Linux-Ready 1.7-GHz 64-Bit Roadmap,” ACM Computing Surveys, 2022. RISC-V Core in 22-nm FDSOI Technology,” IEEE Transactions on Very [33] C. Chen, R. Kande, N. Nguyen, F. Andersen, A. Tyagi, A.-R. Sadeghi, Large Scale Integration Systems, 2019. and J. Rajendran, “HyPFuzz: Formal-Assisted Processor Fuzzing,” [9] YosysHQ, “PicoRV32 - A Size-Optimized RISC-V CPU,” https://gith USENIX Security Symposium, 2023. ub.com/YosysHQ/picorv32, 2019, Last accessed on 07/07/2025. [34] C. Chen, V. Gohil, R. Kande, A.-R. Sadeghi, and J. Rajendran, [10] SonalPinto and F. Solt, “Kronos RISC-V,” https://github.com/YosysHQ “PSOFuzz: Fuzzing Processors with Particle Swarm Optimization,” /picorv32, 2019, Last accessed on 07/07/2025. IEEE/ACM International Conference on Computer Aided Design, 2023. [11] R. Kande, A. Crump, G. Persyn, P. Jauernig, A.-R. Sadeghi, A. Tyagi, [35] M. Rostami, M. Chilese, S. Zeitouni, R. Kande, J. Rajendran, and A.- and J. Rajendran, “TheHuzz: Instruction Fuzzing of Processors Using R. Sadeghi, “Beyond Random Inputs: A Novel ML-Based Hardware Golden-Reference Models for Finding Software-Exploitable Vulnerabil- Fuzzing,” Design, Automation & Test in Europe Conference & Exhibi- ities,” USENIX Security Symposium, 2022. tion, 2024.
14
[36] L. Wu, M. Rostami, H. Li, J. Rajendran, and A.-R. Sadeghi, “GenHuzz: Reinforcement Learning,” IEEE International Symposium on Hardware
An Efficient Generative Hardware Fuzzer,” USENIX Security Sympo- Oriented Security and Trust, 2025.
sium, 2025. [62] “Companies using Synopsys VCS,” https://enlyft.com/tech/products/syn
[37] L. Wu, M. Rostami, H. Li, and A.-R. Sadeghi, “HFL: Hardware Fuzzing opsys-vcs, 2025.
Loop with Reinforcement Learning,” Design, Automation & Test in [63] “List of companies using Synopsys VCS,” https://theirstack.com/en/te
Europe Conference, 2025. chnology/synopsys-vcs, 2025.
[38] A. M. Inc., “Revision Guide for AMD Family 17h Models 00h-0Fh [64] W. Hu, A. Ardeshiricham, and R. Kastner, “Hardware Information Flow Processors,” https://www.amd.com/content/dam/amd/en/documents Tracking,” ACM Computing Surveys, 2021. /processor- tech- docs/revision- guides/55449.pdf, Last accessed on [65] F. Solt, B. Gras, and K. Razavi, “CellIF T : Leveraging Cells for 01/21/2025. Scalable and Precise Dynamic Information Flow Tracking in RT L,” [39] “Verification Stages,” https://www.chipverify.com/verification/verificat USENIX Security Symposium, 2022. ion-stages, Last accessed on 07/14/2025. [66] “Xcelium Logic Simulator,” https://www.cadence.com/en US/home/too [40] S. Davidmann, “RISC-V Processor Verification Requires the Full Tool- ls/system-design-and-verification/simulation-and-testbench-verificatio box,” https://www.tessolve.com/wp-content/uploads/2025/07/Simon-D n/xcelium-simulator.html, 2025, Last accessed on 11/19/2025. avidmann-2.pdf, 2025, Last accessed on 07/17/2025. [67] “Questa One Sim,” https://eda.sw.siemens.com/en-US/ic/questa-one/s [41] K. McDermott, “Getting Started with RISC-V Verification,” https://risc imulation/questa-one-sim/, 2025, Last accessed on 11/19/2025. v.org/blog/2020/05/getting-started-with-risc-v-verification/, 2020, Last [68] J. Hong, B. Kveton, M. Zaheer, and M. Ghavamzadeh, “Hierarchical accessed on 07/14/2025. Bayesian Bandits,” International Conference on Artificial Intelligence [42] T. Trippel, K. G. Shin, A. Chernyakhovsky, G. Kelly, D. Rizzo, and and Statistics, 2022. M. Hicks, “Fuzzing Hardware Like Software,” USENIX Security Sym- [69] A. Piziali, “Functional Verification Coverage Measurement and Analy- posium, 2022. sis,” Springer, 2008. [43] K. Laeufer, J. Koenig, D. Kim, J. Bachrach, and K. Sen, “RFUZZ: [70] H. Foster, “FPGA Language and Library Trends,” https://blogs.sw.sie Coverage-Directed Fuzz Testing of RTL on FPGAs,” IEEE/ACM Inter- mens.com/verificationhorizons/2022/11/21/part-6-the-2022-wilson-res national Conference on Computer-Aided Design, 2018. earch-group-functional-verification-study/, 2022. [44] lcamtuf, “American Fuzzy Lop Fuzzer.” 2014, Last accessed on 11/18/2025. [Online]. Available: {https://github.com/google/AFL} APPENDIX [45] T. Lattimore and C. Szepesv´ari, “Bandit algorithms,” Cambridge Uni- A Optimization Model versity Press, 2020. [46] RISC-V, “RISC-V Specifications,” https://riscv.org/technical/specificat This section shows the optimization model for the test [47] ions/, 2025, last accessed on 11/19/2025. minimizer as mentioned in Section IV-C. J. Demme and S. Sethumadhavan, “Rapid identification of architectural bottlenecks via precise event counting,” 2011 38th Annual International Consider the following notations: ij ], where tij is a binary [48] Symposium on Computer Architecture (ISCA), 2011. 1) T: coverage matrix T := [t V. Weaver and S. McKee, “Can hardware performance counters be trusted?” Proceedings of the IEEE International Symposium on Work- indicator that represents whether the coverage point j has load Characterization, 2008. been covered (1) or not (0) in test i. [49] X. Wang, C. Konstantinou, M. Maniatakos, and R. Karri, “Confirm: 2) L Detecting firmware modifications in embedded systems using hard- j: minimum coverage constraint for coverage point j. ware performance counters,” IEEE/ACM International Conference on 3) Uj: maximum coverage constraint for coverage point j. Computer-Aided Design (ICCAD), 2015. 4) xi: xi ∈ 0, 1, ∀i, a decision variable indicating if test i is [50] “VCS,” https://www.synopsys.com/verification/simulation/vcs.html, in the minimal subset. 2025, Last accessed on 11/19/2025. [51] H.-Y. Hsu and A. Orso, “MINTS: A General Framework and Tool The model is then formulated as: for Supporting Test-Suite Minimization,” International Conference on 1) Objective Function: Identify the minimal subset Software Engineering, 2009. of tests that [52] K. Panaganti, Z. Xu, D. Kalathil, and M. Ghavamzadeh, “Robust Rein- P maintains the coverage equivalent: forcement Learning using Offline Data,” Advances in Neural Information minimize i xi. [53] Processing Systems (NeurIPS), 2022. 2) Constraint 1: Ignore coverage point S. Mashimo, A. Fujita, R. Matsuo, S. Akaki, A. Fukuda, T. Koizumi, covered in all tests: P t x . j if it is always J. Kadomoto, H. Irie, M. Goshima, K. Inoue et al., “An Open Source i ij i = 0 FPGA-Optimized Out-of-Order RISC-V Soft Processor,” International 3) Constraint 2: The constraint for the rest of the coverage Conference on Field-Programmable Technology, 2019. points to identify the minimal subset of tests: [54] A. Amid, D. Biancolin, A. Gonzalez, D. Grubb, S. Karandikar, H. Liew, P t ≤ U Lj ≤ A. Magyar, H. Mao, A. Ou, N. Pemberton, P. Rigge, C. Schmidt, i ij xi j , where If at least one test cover point J. Wright, J. Zhao, Y. S. Shao, K. Asanovi´c, and B. Nikoli´c, “Chip- j, we let Lj = 1 and Uj = ∞. If no tests cover point j, yard: Integrated Design, Simulation, and Implementation Framework for we let Lj = Uj = 0. Custom SoCs,” IEEE Micro, 2020. [55] RISC-V, “SPIKE Source Code,” https://github.com/riscv-software-src/r B Fine-Tune Adaptive Thresholds Automatically iscv-isa-sim, 2023, last accessed on 11/22/2025. [56] V. Gohil, R. Kande, C. Chen, A.-R. Sadeghi, and J. Rajendran, “MAB- The configuration of the adaptive threshold θ is automated, fuzz: Multi-Armed Bandit Algorithms for Fuzzing Processors,” Design, as shown in Algorithm 2. The goal is to identify approximately [57] Automation & Test in Europe Conference & Exhibition, 2024. the same number of tests, defined by the number of arms k, for IBM, “IBM Decision Optimization for Watson Studio,” https://www.ib m.com/products/decision-optimization-for-watson-studio, Last accessed each coverage list. The inputs are the PP-test corpus Acorpus, [58] on 01/05/2025. coverage contexts C, the number of arms k, the check window E. Strong, B. Kleynhans, and S. Kadioglu, “MABWiser: Parallelizable γ, the training step n, and the tolerance factor f . The output Contextual Multi-armed Bandits,” Int. J. Artif. Intell. Tools, 2021. [59] “Common Vulnerability Scoring System Calculator,” https://nvd.nist.g is the fine-tuned adaptive thresholds θ. ov/vuln-metrics/cvss/v3-calculator, 2019, Last accessed on 08/02/2025. The algorithm first calculates the acceptable interval for the [60] MITRE, “Hardware Design CWEs,” https://cwe.mitre.org/data/definitio number of tests (Line 3). Then, for each coverage context, ns/1194.html, 2019, Last accessed on 11/08/2025. [61] R. G¨otz, C. Sendner, N. Ruck, M. Rostami, A. Dmitrienko, and it starts the binary search from 0.00, assuming all tests are A.-R. Sadeghi, “RLFuzz: Accelerating Hardware Fuzzing with Deep effective, and 100.00 means a test can cover all points of a
15
Algorithm 2 Fine-Tune Adaptive Thresholds. reuse strategy in hardware design can potentially propagate
1: Inputs: Acorpus, C, k, γ, n, f vulnerabilities to multiple processors.
2: Outputs: θ Bug B2. In BOOMV3, and BOOMV4 [6], multiple instructions
3: θ ← ∅, kupper = (1 + f ) ∗ k, klower = (1 − f ) ∗ k fail to correctly increase the value of minstret register. For
4: for all c ∈ C in reverse order do example, when executing the MUL instruction in BOOMV4,
5: ℓ ← 0.00, h ← 100.00, tc ← 0.00 minstret register increments twice instead of once as
6: for i = 1 to 14 do ▷ Binary search expected. However, the same bug does not exist in BOOMV3
7: m ← (ℓ + h)/2 and Rocket Core, as discussed in Section III. Though three
8: A ← ADAPCB(Acorpus, c, k, γ, m, n) processors use the same CSR module, they can include bug
9: if A > kupper then ℓ ← m variants due to different microarchitectures. Table IV shows
10: else if A < klower then h ← m the common instructions that can trigger this bug in BOOMV3
11: else tc ← m; break and BOOMV4 and the additional instructions that can trigger
12: θ ← θ ∪ {tc} this bug only in BOOMV4.
13: A ← ADAPCB(c, tc, Acorpus, n)
14: Acorpus ← Acorpus \ A Table IV
15: return θ INSTRUCTIONS OBSERVED TO INCREMENT THE M I N S T R E T TWICE.
On Both BOOMV3 and BOOMV4
training processor (Lines 6 to 11). Given the threshold range CSR Instructions CSRRC, CSRRCI, CSRRS, CSRRSI,
with a precision of 0.01, the binary search requires at most 14 CSRRW, CSRRWI
iterations. To avoid duplicate tests across coverage lists, the Memory FENCE, FENCE.I
algorithm runs our adaptive CB algorithm once, removes the Synchronization
chosen tests from the PP-test corpus (Lines 13 and 14), and Load & Store LB, LBU, LH, LHU, LW, LWU, LD,
then fine-tunes the threshold for the next coverage context. SB, SH, SW, SD
Note that some tests may not have coverage results during Load-Reserved & LR.W, LR.D, SC.W, SC.D
fine-tuning. To avoid repeated simulations, we simulate the test Store-Conditional
once and reuse its coverage result. For experimental purposes, On BOOMV4 Only
we simulate all 1557 tests in parallel after test minimization Branch JALR, BGE, BLT, BLTU, BNE
using 10 threads. The same number of threads is used during Multiplication MUL, MULH, MULHSU, MULHU,
evaluation. The total simulation time is approximately 1.14 MULW
hours in real time. Algorithm 2 then took around 1.30 hours to identify the thresholds. This fine-tuning stage illustrates the necessity of test minimization and can be further accelerated D Potential Exploitability Contexts of RSD Vulnerabilities with additional threads or more advanced parallelization. V1 presents a denial-of-service vector. Any user-mode To automatically fine-tune more parameters, such as cover- program capable of executing arbitrary instructions can in- age contexts and check window γ, future work can consider tentionally invoke FENCE.I to cause the memory deadlock involving more advanced algorithms, such as hierarchical of the processor. This makes the vulnerability practically contextual bandits [68]. exploitable on systems where untrusted or partially trusted C Details on Detected Bugs code is allowed, which interrupts critical tasks, disrupts real- time workloads, and forces a hardware reset. A potential Bug B1. in Rocket Core [7], BOOMV3, and BOOMV4 [6], exploitability context is shown in Appendix D. Attackers can the ECALL and EBREAK instructions incorrectly increase exploit V1 as shown in Listing 1. This exploit demonstrates the value of the minstret register, violating the RISC-V that issuing a program with FENCE.I instruction on the specification. According to the RISC-V ISA, these exception- vulnerable RSD processor can trigger internal deadlock. The generating instructions should not contribute to the instruction program executes FENCE.I directly in user mode without retirement count, and should leave minstret unchanged. requiring any privileged operations, allowing an attacker to This bug misinterprets performance counter values and con- reliably induce a denial-of-service attack on the system. stitutes a violation of expected behavior (CWE-440) [60]. Listing 1. FENCE.I causes memory deadlock on RSD [53]. The bug exists across three processors due to design 1 int main(void) { reuse and characteristics of the Chisel hardware program- 2 // Execute FENCE.I instruction 3 asm volatile ("fence.i" :::"memory"); ming language [5]. Specifically, Rocket Core has a module 4 return 0; called CSR, responsible for updating the values of control 5 } 6 // RSD outputs on the debug console: and status registers (CSRs), including minstret. BOOMV3 7 // Deadlock detected and BOOMV4 use the same module, thereby propagating the 8 // ... 9 // Deadlock detected same bug. This bug also shows that the widely applied IP 10 // MSHR deadlock detected
16
V2 can allow malicious programs to probe memory in ways F Fuzzer Selection not anticipated by the software stack, potentially enabling Existing hardware fuzzers fall into two categories: information disclosure. While this behavior alone does not feedback-based and non-feedback-based fuzzers [22]. inherently grant privilege escalation, it can weaken memory- Feedback-based fuzzers typically use code coverage [11], safety assumptions in system software, including bounds- [33], [36], [37] or customized metrics [13], [23], [24], checking frameworks that rely on predictable exception se- [43] to guide exploration of design spaces. In contrast, mantics. V3 can compromise data integrity in user-mode non-feedback-based fuzzers [12] constrain input spaces based or shared-memory scenarios, weaken isolation boundaries, on ISA and processor design routines, introducing random and potentially overwrite control data structures managed by behaviors, such as the random selection of operands and higher-privileged components. opcodes, to explore a broad range of design spaces. Attackers can exploit V2 and V3 as shown in Listing 2. Feedback-based fuzzers have demonstrated effectiveness The attacker uses the same illegal load/store encoding (funct3 in detecting vulnerabilities, but they face compatibility is- = 111) to perform unintended sign-extended byte operations. sues with processor designs. For example, RFUZZ [43] and While the expected behavior is for the processor to throw DIFUZZRTL [24] customize coverage metrics for the tog- exceptions, RSD internally sign-extends the accessed byte and gling of multiplexer signals and control registers, respectively. completes the operation as though it were a legal instruc- However, the instrumentation requires designs to be written in tion. Because the extension semantics differ from the ISA Chisel [5], while over 80% of hardware designs in industry specification, the resulting value in the destination register or use Verilog or SystemVerilog, which are not supported by memory location may deviate significantly from the expected these fuzzers [69], [70]. ProcessorFuzz monitors control result. This behavior enables data corruption during program and status registers (CSRs) as coverage feedback, but such execution and breaks data integrity. registers are outputs and do not directly reflect the explored Listing 2. RSD [53] executes illegal LOAD or STORE instructions. design spaces. As a result, deploying feedback-based fuzzers 12 volatile uint32_t victim_mem = 0x12345678; with customized coverage metrics is incompatible with most 3 int main(void) { processor designs. Nonetheless, since software simulators with uint32_t tmp = 0; 45 // Execute STORE instruction with illegal funct3 code coverage metrics are widely used in semiconductor 6 asm volatile ( companies [62], [63], fuzzers using code coverage metrics ".word 0x01DE7023 // illegal STORE (funct3 = 7 : ,→ 111), rs2 = x29 (t4), rs1 = x28 (t3)" are compatible with a broader range of processor designs that 8 :"r"(tmp), "m"(victim_mem) share the same ISA [11], [13], [36]. 109 ); Finally, we select the feedback-based fuzzer, TheHuzz [11] 11 // Execute LOAD instruction with illegal funct3 and the non-feedback-based fuzzer Cascade [12] as the asm volatile ( 12 ".word,→0x000E7E83 // illegal LOAD (funct3 = 111 baseline fuzzers due to their distinct mechanisms and gener- 13 ), rd = x29 (t4), rs1 = x28 (t3)" alizability. TheHuzz uses industrial standard code coverage :"=r"(tmp) 14 :"0"(tmp), "m"(victim_mem) metrics [50] and deploys AFL-like mutators, similar to those 15 ); used in software fuzzers [44], which mutate seeds with limited 16 return 0;} or no knowledge of ISAs. It generates tests that contain 20 E Root Cause of Illegal LOAD&STORE Instructions in RSD instructions, which may limit its ability to detect vulnerabili- ties that require longer instructions, but enables it to explore Listing 3 shows the root cause of vulnerabilities V2 and V3 corner cases due to its randomness. In contrast, Cascade [12] in RSD’s decoding logic [53]. The case statement decides constrains the instruction space based on ISA and generates the data width based on the value of “funct3”. However, since tests of long instruction sequences with complex data- and RSD has a default statement, it identifies any unrecognized control-flows. However, Cascade may over-constrain the funct3 values as the byte data width with sign-extended (Lines randomness of instruction generation, missing corner cases. 725–727). The mitigation can add illegal instruction exception G Evaluation on Condition Coverage Metric for invalid values. We evaluated ReFuzz’s generalized improvement using 704 Listing 3. The root cause of illegal load and store instructions. condition coverage, including both coverage speed and total case(funct3) 705 MEM_FUNCT3_SIGNED_BYTE :begin //LB, SB coverage improvement based on the number of tests (Program 706 memAccessMode.isSigned = TRUE; Count). Figure 9 shows condition coverage results similar to 707 memAccessMode.size = MEM_ACCESS_SIZE_BYTE; 708 end Figure 6 for branch coverage. The coverage context and the 709 MEM_FUNCT3_SIGNED_HALF_WORD :begin //LH, SH adaptive threshold are configured as θ = {45% : 14.84, 50% : 710 memAccessMode.isSigned = TRUE; 11.82,55% : 7.81, 60% : 4.69, 65% : 2.86}. ReFuzz 711 memAccessMode.size = MEM_ACCESS_SIZE_HALF_WORD; 712 end outperforms both TheHuzz and Cascade on the condition . . . ... 725 default :begin coverage, showing its comprehensiveness. Across two testing 726 memAccessMode.isSigned = TRUE; processors, BOOMV4 and RSD, ReFuzz achieves an average 727 memAccessMode.size = MEM_ACCESS_SIZE_BYTE; . . . ... of 223.57× coverage speed and 2.2% more total coverage. On average, ReFuzz achieves a 279.44× coverage speed
17
TheHuzz Cascade ReFuzz+TheHuzz ReFuzz+Cascade
85
70
55
CVA6 RC BoomV3 BoomV4 RSD
40
85
70
55
CVA6 RC BoomV3 BoomV4 RSD
40 0 4 8 12 16 20 0 4 8 12 16 20 0 4 8 12 16 20 0 4 8 12 16 20 0 4 8 12 16 20
Program Count (xK)
Figure 9. Condition coverage results of TheHuzz [11], Cascade [12], and ReFuzz.
and 3.05% more total coverage across all five processors. 26). After completing at most m iterations, FuzzCovList The result demonstrates the comprehensiveness of ReFuzz returns the final total coverage tot cov (Line 29). on different coverage metrics. Algorithm 3 Integrating the CB Model with Processor Fuzzers H Integrating the CB Model with Processor Fuzzers 1: Inputs: Av, πv, Ac, πc, C, γ, m Algorithm 3 shows the integration process of ReFuzz’s 2: Outputs: tot cov trained contextual bandit (CB) model with processor fuzzers. 3: function MAIN The inputs are the trained vulnerability list Av and cover- 4: tot cov ← FUZZVULLIST(Av, πv, γ) age lists Ac with their learned policies πv and πc. it also 5: tot cov ← FUZZCOVLIST(Ac, πc, C, γ, tot cov, m) uses coverage contexts C, the check window γ, and the 6: return tot cov maximal fuzzing iteration m. The outputs are the achieved 7: function FUZZVULLIST(Av, πv, γ) total coverage tot cov. ReFuzz starts from the vulnerability 8: while true do list Av (Line 4). In FuzzVulList, it samples a test ai 9: ai ∼ πv(·) from Av according to the policy πv (Line 9). To ensure 10: A , π DROPTEST(ai, #(ai), r(tot cov, ai), fcov (ai), effectiveness of tests, ReFuzz evaluates each selected test 11: v v, γ) ai every γ fuzzing iterations, checking whether it yields a 12: tot cov ← tot cov + fcov (ai) coverage increment ri(tot cov, ai) (Line 31) by measuring 13: if |Av| = 0 then the cumulative incremental coverage from its mutated variants 14: return break fcov (ai). If no coverage increment, the test is dropped (Lines 15: function F tot cov 32–33). Otherwise, ReFuzz resets the tracking record # and 16: for i UZZCOVLIST(Ac, πc, C, γ, tot cov, m) continues to monitor the coverage increment (Line 35). Once 17: if = 1, 2, . . . , m do the list is exhausted (Lines 12–13), FuzzVulList returns 18: tot cov < ca 1 then the current total coverage tot cov (Line 14). 19: else ifi ∼c1π≤c(· | c1), ai ∈ A1c ReFuzz then swtiches to coverage lists through 20: ai ∼ πc tot cov < c2 then FuzzCovList (Line 5). ReFuzz selects tests based ... (· | c2), ai ∈ A2c on the cumulative total coverage from the coverage lists 25: else if no arm a i for tot cov then A = {A1 C c c, . . . , Ac }, where C represents the configured 26: Let fuzzer generate seed ai coverage contexts (Line 5). ReFuzz continuously monitors 27: tot cov ← tot cov + f the total coverage tot cov achieved by a processor fuzzer and 28: DROPTEST(ai, #(a cov (ai) selects tests according to the policy π · | ) to different intervals of coverage contexts( c , corresponding Ac, πc, γ) i), r(tot cov, ai), fcov (ai), (Lines 16-23). For example, if tot cov < c 1, it samples a test ai from 29: return tot cov the coverage list A1c using the policy πc(· | c1) (Lines 30: function DROPTEST(a, #, r, fcov , A, π, γ) 17–18); if c ≤ tot cov < c , it samples from A2c 31: # ← # + 1; r ← r + fcov 1 2 using the policy πc(· | c2) (Lines 19–20), and so on for the remaining 32: if # ≥ γ and r = 0 then intervals. This allows ReFuzz to adapt its selection of tests 33: A ← A \ {a} to the current total coverage. If all curated tests are exhausted, 34: else ReFuzz selects new tests generated by the processor fuzzer 35: r ← 0; # ← 0 to explore the unique design features of the PUT (Line 36: return #, r, A, π
18
Cascade vs TheHuzz vs ReFuzz+Cascade Coverage Points (%) ReFuzz+TheHuzz