2024 Design, Automation & Test in Europe Conference (DATE 2024)

Beyond Random Inputs: A Novel ML-Based Hardware Fuzzing

Mohamadreza Rostami‡∗, Marco Chilese‡∗, Shaza Zeitouni∗ Rahul Kande†, Jeyavijayan Rajendran†, Ahmad-Reza Sadeghi∗ ∗Technical University of Darmstadt, †Texas A&M University

Abstract—Modern computing systems heavily rely on hardware DUT comprehensively [5]. Hardware fuzzing has emerged as as the root of trust. However, their increasing complexity has a promising approach for not only broadening the exploration given rise to security-critical vulnerabilities that cross-layer at- of design space but also for revealing security vulnerabilities tacks can exploit. Traditional hardware vulnerability detection methods, such as random regression and formal verification, have within intricate designs, including complex processors [3], limitations. Random regression, while scalable, is slow in exploring [8], [9], [13]. To bolster their effectiveness, hardware fuzzers hardware, and formal verification techniques are often concerned harness coverage data, such as branch conditions, statements, with manual effort and state explosions. and multiplexers’ control registers or signals, for generating test Hardware fuzzing has emerged as an effective approach to explor- cases and probing diverse hardware behaviors [8]–[11]. When ing and detecting security vulnerabilities in large-scale designs compared to traditional hardware verification techniques, hard- like modern processors. They outperform traditional methods regarding coverage, scalability, and efficiency. However, state-of- ware fuzzers have demonstrated broader coverage, enhanced the-art fuzzers struggle to achieve comprehensive coverage of intri- scalability, and efficiency in identifying real-world vulnerabil- cate hardware designs within a practical timeframe, often falling ities that have been associated with privilege escalation and short of a 70% coverage threshold. To address this challenge, arbitrary code execution attacks [3], [8], [9]. Nonetheless, state- we propose a novel ML-based hardware fuzzer, ChatFuzz. Our of-the-art fuzzers struggle to achieve comprehensive coverage approach leverages large language models (LLMs) to understand processor language and generate data/control flow entangled yet of intricate hardware designs within a practical timeframe, often random machine code sequences. Reinforcement learning (RL) is falling short of a 70% coverage threshold in complex hardware integrated to guide the input generation process by rewarding the such as a RISC-V RocketCore processor [1]. inputs using code coverage metrics. Our Contributions. In this paper, we introduce ChatFuzz, the Utilizing the open-source RISC-V-based RocketCore and BOOM cores as our testbed, ChatFuzz achieves 75% condition coverage first processor fuzzer that leverages machine learning for input in RocketCore in just 52 minutes. This contrasts with state-of-the- generation and improvement with the help of coverage metrics, art fuzzers, which demand a 30-hour timeframe for comparable addressing a critical challenge in the field of processor fuzzing, condition coverage. Notably, our fuzzer can reach a 79.14% con- namely, generating interdependent data/control flow entangled dition coverage rate in RocketCore by conducting approximately yet random instructions. 199k test cases. In the case of BOOM, ChatFuzz accomplishes a remarkable 97.02% condition coverage in 49 minutes. Our Three-Step ML-Based Input Generation. We present a three- analysis identified all detected bugs by TheHuzz, including two step training process, including unsupervised learning to un- new bugs in the RocketCore and discrepancies from the RISC-V derstand machine language structures, reinforcement learning ISA Simulator. with a disassembler for valid instruction generation, and further I. INTRODUCTION reinforcement learning using RTL simulation as a reward agent Traditional hardware verification techniques are crucial for to improve the coverage. ensuring the reliability and correctness of a hardware design, Significant Speed Enhancement. ChatFuzz demonstrably ex- the design under test (DUT), before fabrication. Among these pedites enhancing condition coverage, attaining a coverage techniques, random regression and formal verification methods level of 74.96% within less than one hour. In contrast, the are commonly employed. Despite its capacity to accommo- current leading hardware fuzzer, TheHuzz [9], requires a much date extensive hardware designs, random regression presents longer period of roughly 30 hours to achieve the same coverage, a notable efficiency problem as it tends to slow down when i.e., 34.6× faster. In the case of BOOM, ChatFuzz accomplishes exploring the intricacies of a hardware design. Consequently, it a remarkable 97.02% condition coverage in 49 minutes. It is encounters difficulties uncovering vulnerabilities within hard- worth noting that TheHuzz exhibits greater efficiency compared to-reach critical components [6]. On the other hand, formal to random regression techniques and is approximately 3.33× verification, which aims to ascertain whether a DUT complies swifter than DifuzzRTL [8]. with specified/predefined properties [14], is often regarded as Findings. During fuzzing, ChatFuzz detects approximately 6K an efficient approach for verifying the correctness of hard- mismatches and identifies more than 100 unique mismatches to-reach hardware components. However, formal techniques after automated analysis. These findings include all bugs that rely heavily on manual effort from domain experts to define were detected by TheHuzz [9] and two new bugs, namely the required properties, which can be error-prone and time- the cache coherency management issue (CWE-1202) and the consuming. Furthermore, formal verification frequently results execution tracing (CWE-440). Moreover, ChatFuzz exposes in state explosion, rendering it impractical to verify the entire deviations in the behavior of the RocketCore compared to the specifications in the RISC-V ISA. This showcases ChatFuzz’s ‡These authors contributed equally to this work. efficiency in delving into the processor search space, thoroughly

979-8-3503-4859-0/DATE24/© 2024 EDAA

investigating even the most detailed corner cases specified in   stability and efficiency. PPO algorithms have been successfully
the RISC-V ISA specification.                                    applied to various domains, e.g., natural language generation.
    II. BACKGROUND & RELATED WORK                                2) Large Language Models (LLMs): LLMs are large ML mod-
                                                                 els for processing and generating natural language text. They
A. Fuzzing                                                       leverage neural networks (NN), often using the transformer

Fuzzing provisions a large number of inputs to the program un- architecture, to learn from sequential data and capture long de- der test to uncover faults, bugs, or vulnerabilities that traditional pendencies. LLMs can contain billions of parameters (weights), testing methods may miss [7]. The fuzzer may generate random, dictating how the model handles input and generates output. malformed, or unusual inputs to test how the program handles LLMs are trained using different learning paradigms, from self- them. The initial set of test inputs, also known as seeds, can supervised to reinforcement learning, which means that they be automatically generated or manually crafted by verification do not require labeled data or explicit rules but learn from engineers. During each fuzzing round, the fuzzer manipulates the patterns and structures inherent in the text corpus. LLMs the best test inputs from the preceding round using mutation can perform various natural language processing (NLP) tasks, operations like bit/byte flipping, swapping, deleting, or cloning such as recognition, summarization, translation, prediction, and to generate new inputs. In recent years, fuzzing has gained generation. LLMs are general-purpose models that can adapt to significant attention from the hardware security community due different domains and applications with minimal fine-tuning or to its numerous advantages over existing verification methods. prompt engineering. In a concurrent work, LLMs have been In particular, fuzzing is highly automatable, cost-effective, scal- utilized in software fuzzing [12]. The proposed method creates able to real-world applications, and comprehensively covers the test cases, particularly for fuzzing compilers, by training a tested application. These factors have contributed to its growing large language model on a task that relies on human-defined popularity and adoption among researchers and practitioners in prompts to generate and modify test cases. In contrast, our the field of software as well as hardware security [2], [8]–[10]. approach does not rely on human interaction during training

1. Processor Fuzzers: Traditional processor fuzzers such as and is additionally steered by coverage metrics. DifuzzRTL [8] and TheHuzz [9] use code coverage and control III. ChatFuzz register coverage as feedback to guide the mutation process. Utilizing recent advancements in LLMs, we propose ChatFuzz These fuzzers generate seeds through random generation of as an innovative approach for enhancing hardware security. instructions and mutate the instructions in the current input ChatFuzz involves training LLMs using machine language to generate new inputs. Recent research also led to hybrid (specifically, machine codes) and employing the trained model hardware fuzzers such as HyPFuzz [3] and PSOFuzz [4] that to generate sequences of pseudo-random yet interconnected combine the capabilities of fuzzers with formal tools and instructions for hardware fuzzing. Unlike existing methods, our optimization algorithms to improve the coverage achieved. approach prioritizes creating interdependent data/control flow However, these hybrid fuzzers also use the seed generation and entangled instruction sequences. mutation engines inherited from traditional processor fuzzers ChatFuzz, illustrated in Figure 1a, comprises several compo- such as TheHuzz [9]. While the seed generator and mutation nents. The LLM-based Input Generator generates instruction engine in these fuzzers can identify valid instructions from sequences for fuzzing the targeted CPU. Details about this com- the ISA, they do not have well-defined feedback to determine ponent are discussed in subsection III-A and subsection III-B. a meaningful sequence of instructions that will lead to deep The RTL and ISA Simulators execute the given inputs on design regions. the targeted CPU and its golden model, respectively, while B. Machine Learning recording execution traces. For each test input the RTL Sim-

2. Reinforcement Learning (RL): RL is a branch of machine ulator reports coverage information, which is utilized by the learning that studies how agents can learn from their actions and LLM-based Input Generator to optimize the input generation environment feedback to achieve a goal. RL differs from other process. The Mismatch Detector compares execution traces forms of machine learning, such as supervised and unsuper- to identify mismatches or potential bugs, which are manually vised learning, in that the agent does not have access to labeled inspected for confirmation as elaborated in subsection III-C. In data or explicit rules but must discover the optimal behavior the following, we elucidate the fundamental components of our through trial and error. The agent’s objective is to find a policy, approach, encompassing A) the acquisition of a training dataset a function that maps each state to an action that maximizes for instructing the LLM model, B) the training process of the the expected cumulative reward over time. This is achieved LLM model to grasp machine language intricacies, and C) the using various algorithms, such as policy-based or actor-critic execution of hardware fuzzing and bug detection procedures. methods. Proximal Policy Optimization (PPO) is a family of A. Machine Language Dataset model-free RL algorithms. PPO updates policy parameters for A major challenge in training LLMs is the need for an extensive higher expected rewards based on policy gradient methods. training dataset. While collecting data for natural languages like Unlike traditional policy gradient methods, PPO employs a English is relatively easy, it becomes much more complicated clipped surrogate objective function to control policy updates for machine languages. To explore this issue, we will investi- and prevent large deviations from the previous policy, ensuring gate two key questions: How do we collect a machine language

                                                              (1) Initial Training   (2) Model Cleanup Training  (3) Model Optimization
                                           Trace.ISA
                                                                      4118,419c, …
               1cc0
               3a7f 0e19
               5aa0 c401
               5bbf 6e70
               aa8b 00d8  ISA Simulator        Mismatch.list     Tokenizer
                                                                [32,53,524, …]      Generator* Generator     Generator*       Generator
   LLM-based                              Mismatch
   

   Input Generator DUT Detector GPT2 Model

   Feedback RTL Simulator Trace.DUT PPO ISA Disassembler PPO RTL Simulator Coverage C Manual Bug [32,53,524, …, Reward Computation Reward Computation Calculator overage Report Detection 272,28,293, …] (a) Overview of ChatFuzz (b) ChatFuzz’s training steps Fig. 1: ChatFuzz’s final model results from three consequent training steps: (1) Unsupervised training based on the GPT2 model to learn the inner structure of the machine language; (2) Utilizing a disassembler as a scoring agent during PPO-based RL training, the initial model is refined by cleaning up the learned language and removing bad combinations of instructions; (3) Improving the coverage with a PPO-based RL process where the refined generator is trained through a reward function based on coverage information attained through RTL simulation. dataset? And how do we represent the machine language data training dataset designed for our LLM model. This approach set for LLMs? ensures that each function, being associated with a distinct

3. Training Data Collection: We have two options for col- responsibility and meaning, contributes to the creation of a lecting a machine language dataset. i) Dynamic data collec- training set characterized by a high degree of inter-dependency tion. Recording instructions as a program runs is convenient; among the instructions and their sequencing. however, it faces challenges that disrupt data inter-dependency, such as context switches and kernel-related instructions. Rarely B. Training of LLM Model executed code sections may also be missing due to conditional Figure 1b depicts the ML subsystem. Our approach involves a constraints, affecting data completeness and interdependence. structured three-step pipeline, each phase dedicated to training These issues are more pronounced when collecting data from the language model, advancing steadily towards our ultimate complex programs, e.g., the Linux kernel, where repetitive objective. instructions and infrequent execution of critical sections add 1) Initial Training: In this step, the model is initialized and complexity to data collection and interdependence. ii) Static trained using the collected dataset. This step aims to learn the data collection directly gathers training data from fixed sources language utilized by the CPU. For this purpose, we train a like GUI-compiled code, avoiding dynamic program execution tokenizer on the full ISA. The tokenizer then prepares the inputs complexities such as context switches and kernel-related in- for the model as shown in Figure 1b(1). structions. This approach keeps the collected data isolated from 2) Model Language Cleanup: Once the initial training is OS concurrent tasks’ interference, preserving intrinsic data completed, the model can commit numerous errors in the text relationships as coded in the source. Static data collection also generation (e.g., wrong/illegal combinations of instructions). comprehensively captures all code segments, including rarely Therefore, a refinement phase is crucial. Hence, at this stage executed blocks, without relying on their activation during of the pipeline, Figure 1b(2), our goal is to clean up the gen- program runtime. erations of the trained model, enforcing the correct instruction In this work, we opted for static data collection as it effec- associations to minimize the number of ineffective generations. tively overcomes the challenges posed by instruction inter- For this purpose, we designed an RL process that leverages, as dependency and code block rarity encountered in dynamic data a reward agent, the ISA disassembler (cf., subsection III-A). We collection. avoid using, as commonly done, a probabilistic scorer, such as

4. Training Data Representation: This step is challenging due a neural network, for the rewarding task to prevent uncertainty to several factors, including the presence of metadata (such and reduce errors. Employing a deterministic reward agent, as headers and linking information) within machine codes we can provide the model with more precise guidance during resulting from program compilation. Metadata can introduce the training, leading to better optimization policies and more complexity and ambiguity, potentially hindering the LLM precise model updates. This step helps avoid unnecessary CPU model’s ability to learn the language effectively and maintain simulation of bad/malformed data and thus improves the overall the meaningfulness and interdependence of the training dataset. performance of our fuzzer. To address this challenge, as illustrated in subsection III-B, 3) Model Optimization: Finally, we aim to improve the training we disassemble the binaries generated from program compila- of our LLM to achieve our goal, which is generating sequences tion and automatically identify the start and end locations of of pseudo-random yet interconnected instructions that lead to functions within the disassembled files. We then include the better CPU coverage. To do so, we employed another RL-based machine code of each function as an individual entry in the training step, utilizing a deterministic reward agent similar to

Optimization

Optimization

the previous step. In this case, the reward function embeds the coverage points recorded in the previous batch. Meanwhile, scores provided as fuzzing loop feedback comprising hardware total coverage encapsulates the cumulative tally of coverage coverage information collected during the simulation of the points attained thus far, incorporating the contributions of generated data on the targeted CPU as shown in Figure 1b(3). all inputs generated by the LLM model. These values are We performed the previous steps for RISC-V ISA. However, it deployed in the calculation of scores assigned to each test is worth noting that the approach described above is general- input generated by the LLM-based input generator, thereby izable to any CPU architecture. facilitating a comprehensive evaluation of the generated inputs, C. Hardware Fuzzing and Bug Detection i.e., test inputs, with respect to their coverage effectiveness. After training the LLM model (cf., subsection III-B), we initiate C. LLM-based Input Generation the fuzzing loop. As delineated in Figure 1a, the LLM model The ML part of ChatFuzz was fully implemented in Python generates a batch of test inputs, where each entry represents with the use of the frameworks Pytorch (www.pytorch.org) and a list of instructions. These entries are then executed on the Huggingface (www.huggingface.co). The use of Huggingface golden model and the targeted CPU using the ISA and RTL is considered the standard for NLP-related tasks. Specifically, Simulators, respectively. The resulting two execution traces of we leveraged its implementations of the tokenizer, the large each entry are analyzed by the Mismatch Detector to identify language model (more precisely, of GPT2 family), and the traces’ discrepancies, which are documented for subsequent PPO algorithm for the RL pipeline. All the experiments were manual inspection as part of the bug detection process. conducted on a high-performance server. In the following, Additionally, the RTL Simulator reports hardware coverage we describe the main steps designed for achieving our goal, metrics to the Coverage Calculator, which computes standalone, principally depicted in Figure 1b. overall, and incremental coverage values for each entry as 1) Initial Training: The initial step in designing an NLP described in section IV. These values are then used to score pipeline is defining the dictionary and its corresponding tok- each entry generated by the LLM model, leading to a precise enizer. The tokenizer translates words (i.e., instructions) into evaluation of the entries and guiding the LLM model to tokens by encoding input text into an array of dictionary word generate further inputs that have the potential to enhance the indices, always serving as an intermediary step between the coverage. dataset and the language model. Decoding, on the other hand, translates an array of tokens back into text (i.e., sequence of IV. IMPLEMENTATION instructions). In this section, we will provide details on the implementation Next, we trained the selected model to understand the inner of ChatFuzz components. We deployed Synopsys VCS and the workings of the machine language, including grammar and Spike simulator for RTL and RISC-V ISA, i.e., the golden instructions relationships. During the training, the model re- model, simulations. Additionally, we developed custom com- ceives an input fragment of valid test vectors from our collected ponents for Mismatch Detection and Coverage Calculation. dataset, resembling ∼ 500K test vectors extracted by compiling the Linux Kernel, and learns how to complete it. A. Mismatch Detection 2) Model Language Cleanup: After the initial training, the This component uses differential testing to flag potential vul- model is able to utilize the CPU’s language. However, having nerabilities in the targeted CPU. It compares the architectural the full ISA available as a dictionary, the model will easily state changes between the targeted CPU and its golden model commit errors, generating illegal associations of instructions when both run the same input and compiles a report with that a disassembler can easily detect. To overcome this limita- uniquely identified discrepancies. Thus, effectively reducing the tion, which would significantly impact the quality of the end manual workload for verification engineers. This is particularly generations, we decided to perform training through a PPO- advantageous when multiple instances of the same bug generate based RL, where the scoring agent is the RISC-V disassembler. numerous mismatches. Further, verification engineers can add The reward function is designed in such a way that correct filters to the Mismatch Detector in the form of architectural generations are incentivized, and generations with illegal in- state values that will allow filtering out most of the false structions are as penalized as many invalid instructions are positive mismatches and accelerate vulnerability detection. present in the generated test vector: B. Coverage Calculation where Ni f (GenTexti) = Ni − 5 ∗ Invalidi (1) is the number of instructions generated at time i This component is responsible for receiving the coverage for GenTexti, and Invalidi is the number of invalid instructions reports from the RTL simulator, i.e., Synopsys VCS in our present in GenTexti. implementation. Subsequently, the coverage reports undergo For the training, we utilized a dataset of 51.2K samples parsing, facilitating the calculation of three key values: stand- extracted from the larger main dataset. For each sample, we alone coverage, incremental coverage, and total coverage, for randomly selected the initial 2 to 5 instructions as input for each coverage metric. Stand-alone coverage indicates the num- the LLM. The model then completes the test vectors using its ber of coverage points attained by the input under consideration. learned logic. Incremental coverage gauges the quantity of newly achieved The training consists of 30 epochs. We monitored the PPO coverage points by the current input compared to the total algorithm’s loss, the Kullback-Leibler divergence between op-

timization policies, and the mean rewards assigned at each step     85
to assess the training progress.                                    80
3) Model Optimization:       Once the model went through two
steps of training and the number of errors in the generations was   75
sensibly reduced, we proceeded with the final training, where       70
we wanted to carefully drive the model towards the exploration      65
of the targeted CPU (i.e., increasing the reference coverage)
through a PPO-based RL process. In this case, the reward            60
function, based on the values reported by the Coverage Calcu-       55     TheHuzz ChatFuzz
lator, takes into account the overall knowledge of architecture     500    10      20
until the i-th step, the incremental coverage (i.e., whether
there was an improvement), and stand-alone coverage (i.e.,              Time (hrs)

coverage of the i-th sample). In practice, the reward function Fig. 2: Coverage analysis of TheHuzz [9] and ChatFuzz over guides the search direction toward generations that increase the time for RocketCore. coverage by giving a bonus and penalizing (i.e., assigning a visual representation of the condition coverage for ChatFuzz negative reward) those that do not produce any improvement. and TheHuzz during 24 hours of RocketCore fuzzing. This reward function, ultimately, pushes the model to explore B. Findings more in the direction of interesting generations. Moreover, analogously to the previous step, this training takes place with In the initial stage of our mismatch detection process ChatFuzz the same strategy. We utilize the same sampled dataset of 51.2K effectively identified 5,866 instances of disparities within the samples as input. In this case, the training is designed to last execution traces originating from the RISC-V ISA simulator at most 15 epochs, during which the values reported by the and the RocketCore. Subsequently, these identified mismatches coverage calculator are used for the reward computation. underwent a secondary filtration process, separating more than 100 unique mismatches. This filtration process was executed V. EVALUATION in an automated fashion. Following this, we embarked on We used ten instances of Synopsys VCS as a simulator and a detailed manual analysis of these unique mismatches, the measured the effectiveness of our solution using the condition summaries of which are presented below. coverage metric provided by Synopsys VCS. It is imperative 1) Bug1: According to the RISC-V specification [15], when that this feedback captures new hardware behavior and func- there are modifications made to the instruction memory, it is tionalities during fuzzing. Condition coverage aligns with this imperative for the software to manage cache coherency through goal, correlating the satisfaction of hardware design conditions the utilization of the FENCE.I instruction. Neglecting this with realizing new functional behaviors. An exemplary instance cache coherency management can lead to unforeseeable con- is fulfilling conditions leading to privilege-level transitions, sequences, wherein processors may rely on outdated data and such as shifting from the user to the supervisory level. We execute instructions incorrectly. During testing with a generated have chosen the widely utilized RISC-V RocketCore and Boom input program by our fuzzing tool that modified the instruction processors, renowned as preeminent open-source processors memory but did not incorporate the FENCE.I instruction, an within the RISC-V ecosystem. In evaluating RISC-V proces- inconsistency was identified in the trace logs of the RocketCore sors, we employed the Chipyard simulation environment, which processor and Spike. This disparity could have been prevented facilitates the assessment of diverse processors and ensures a if the RISC-V specification or the RocketCore processor could uniform testing arena. Each experiment was executed over 24 detect violations of cache coherency at the hardware level. This hours and repeated three times to underscore the robustness and bug has the potential to introduce cache coherency problems in consistency of our findings. software executed on the RocketCore processor, which might A. Design Coverage go unnoticed if the FENCE.I instruction is misused, ultimately resulting in a memory and storage vulnerability identified as Our analysis revealed that both ChatFuzz and TheHuzz incur CWE-1202. similar runtime overhead. Nevertheless, when considering an 2) Bug2: RISC-V specification consists of arithmetic instruc- equivalent number of generated tests (1.8K) with same number tions such as multiply and divide [15] that compute a value of instructions, ChatFuzz achieved a condition coverage of using the operand registers and update the result in the desti- 74.96%, while TheHuzz reached 67.4%. Remarkably, TheHuzz nation register. The RocketCore processor and ISA simulator required around 30 hours to reach a 75% coverage rate, i.e., behave accordingly when executing the multiply and divide ChatFuzz achieved the same amount of coverage 34.6× faster. instructions. However, the tracer module in RocketCore is not Ultimately, ChatFuzz achieved a condition coverage rate of outputting the write to the destination register in RocketCore’s 79.14% by generating 199k test cases, while TheHuzz [9] trace output, resulting in Bug2. This bug may not have security attained a condition coverage rate of 76.7% for the same consequences as it is present in the debug components of number of test cases. Furthermore, ChatFuzz accomplishes a RocketCore. However, bugs like this can mask other security remarkable 97.02% condition coverage in 49 minutes while vulnerabilities that can otherwise be detected with the correct running experiments on the Boom processor. Figure 2 provides trace output information (CWE-440).

% Cond points covered

3. Other Findings: In conjunction with its capacity for vul- compared to the 30 hours required by leading hardware fuzzers, nerability detection, our tool has brought to light compelling i.e., ChatFuzz achieved the same amount of coverage 34.6× disparities between the target processor and Spike. While these faster. Also, in the case of Boom, ChatFuzz accomplishes a re- disparities do not signify security vulnerabilities, they highlight markable 97.02% condition coverage in 49 minutes. ChatFuzz the tool’s capabilities in comprehensively examining the tar- has successfully identified more than 100 unique mismatches, get processor. These discrepancies represent exceptional cases revealed two novel bugs, and exposed deviations in RocketCore within the RISC-V specification and highlight the effectiveness behavior compared to the golden model, even in intricate corner of our approach in exploring the DUT search space. This is cases specified in the RISC-V ISA specification. These results achieved by generating interdependent and data/control flow highlight ChatFuzz’s effectiveness in exploring processor vul- entangled instructions, as opposed to the conventional use nerabilities, offering a faster and more comprehensive approach of random instructions employed by state-of-the-art hardware to hardware security and testing. fuzzers. We will elucidate the three most significant ones below. A Finding1. In line with the RISC-V specification [15], when CKNOWLEDGEMENT an instruction triggers multiple synchronous exceptions, the Our research work was partially funded by the Intel’s Scal- higher-priority exception is logged in the mcause regis- able Assurance Program, Deutsche Forschungsgemeinschaft ter. The priority hierarchy established in the RISC-V privi- (DFG) – SFB 1119 – 236615297, the European Union under lege specification places the Load/store/AMO address Horizon Europe Programme – Grant Agreement 101070537 misaligned exception above the Load/store/AMO – CrossCon, the European Research Council under the ERC access fault exception. In our fuzz testing using Chat- Programme - Grant 101055025 - HYDRANOS, and the US Fuzz, two test cases emerged. In the first, both Load access Office of Naval Research (ONR Award #N00014-18-1-2058). fault and Load address misaligned exceptions were simultane- This work does not in any way constitute an Intel endorsement ously raised. In contrast, the second test case triggered both of a product or supplier. Any opinions, findings, conclusions, or Store access fault and Store address misaligned exceptions recommendations expressed herein are those of the authors and concurrently. Notably, Spike responded with the Load/Store do not necessarily reflect those of Intel, the European Union, address misaligned exception, while RocketCore issued the European Research Council, or the US Government. the Load/Store address fault exception. R EFERENCES Finding2. In another example, ChatFuzz generated a pair of atomic instructions, such as AMOOR.D, in which it employed [1] Asanovi´c et al. The Rocket Chip Generator. (UCB/EECS-2016-17), 2016. R0 as a temporary location for loading data from memory, [2] Canakci et al. DirectFuzz: Automated test generation for RTL designs using directed graybox fuzzing. In Design Automation Conference (DAC). designated as rd. Interestingly, our tool observed that this IEEE Computer Society, 2021. atomic instruction appeared to function as expected, with R0 [3] Chen et al. HyPFuzz: Formal-assisted processor fuzzing. arXiv preprint receiving data—a behavior seemingly at odds with the RISC- [4] arXiv:2304.02485, 2023. Chen et al. Psofuzz: Fuzzing processors with particle swarm optimization. V specification [15]. Upon further investigation, we realized arXiv preprint arXiv:2307.14480, 2023. that this behavior represents a corner case within the RISC-V [5] Clarke et al. Progress on the State Explosion Problem in Model Checking. specification [15]. It is conceivable that developers, in pursuit of [6] Informatics, 2001. Dessouky et al. HardFails: Insights into Software-Exploitable Hardware optimization, could implement the AMOOR.D operation within Bugs. In USENIX Security Symposium. USENIX Association, 2019. the memory controller. Consequently, if a user specifies R0 as [7] Fioraldi et al. Afl++: Combining incremental steps of fuzzing research. the destination register (rd) for this instruction, the memory In USENIX Workshop on Offensive Technologies (WOOT). USENIX Association, 2020. controller may perform the atomic operation as intended. [8] Hur et al. DifuzzRTL: Differential fuzz testing to find cpu bugs. In IEEE Finding3. Another notable scenario relates to the behavior of Symposium on Security and Privacy (S&P). IEEE Computer Society, the RocketCore processor, particularly in its treatment of the 2021. R0 register, compared to the Spike ISA simulator. According to [9] Kande et al. TheHuzz: Instruction fuzzing of processors using Golden- Reference models for finding Software-Exploitable vulnerabilities. In the RISC-V ISA specifications, the R0 register is expected to USENIX Security Symposium. USENIX Association, 2022. maintain a constant value of zero, implying immunity to write [10] Laeufer et al. Rfuzz: coverage-directed fuzz testing of rtl on fpgas. operations. However, our analysis unveiled that in the execution In IEEE/ACM International Conference on Computer-Aided Design (IC- CAD). IEEE Computer Society, 2018.

traces generated by the RocketCore, there are occurrences of [11] Trippel et al. Fuzzing hardware like software. In USENIX Security attempted writes to the R0 register within specific sequences Symposium. USENIX Association, 2022. of instructions. It is important to note that this discrepancy is [12] Xia et al. Universal fuzzing via large language models. arXiv preprint arXiv:2308.04748, 2023. solely observed in the output traces and does not affect the [13] Xu et al. MorFuzz: Fuzzing processor via runtime instruction morphing functionality of RocketCore. enhanced synchronizable co-simulation. In USENIX Security Symposium. USENIX Association, 2023. VI. C ONCLUSION [14] Yuji Kukimoto. Introduction to Formal Verification, 2011. [15] RISC-V. The risc-v instruction set manual volume i: Unprivileged isa, We introduced ChatFuzz, a novel hardware fuzzer that utilizes 2019. large language models to learn machine language and gener- ate complex, interdependent, data/control flow entangled and pseudo-random test cases. Our approach significantly improves condition coverage, reaching 74.96% in less than an hour,