Overview
ProcessorFuzz: Processor Fuzzing with Control and Status Registers Guidance presents ProcessorFuzz, a processor fuzzer for Register-Transfer Level (RTL) processor verification. The paper is authored by Sadullah Canakci, Chathura Rajapaksha, Leila Delshadtehrani, Anoop Nataraja, Michael Bedford Taylor, Manuel Egele, and Ajay Joshi, with affiliations at Boston University and the University of Washington.[C1]
The work is motivated by the increasing complexity of processor designs and the difficulty of verifying large processor state spaces before manufacturing. The paper frames processor fuzzing as an adaptation of coverage-guided software fuzzing to hardware, while noting two important challenges: conventional software coverage metrics such as basic-block or branch coverage are not well suited to hardware, and processor bugs often do not manifest as obvious crashes or exceptions during testing.[C2]
Contributions
The paper introduces two main ideas:
- CSR-transition coverage. ProcessorFuzz guides fuzzing with a coverage metric based on transitions in Control and Status Registers (CSRs). The paper argues that CSRs control and hold processor state, so CSR transitions indicate new processor states. It also notes that some ISA-defined CSRs expose aspects of the processor finite-state-machine state, such as current privilege mode or the event that caused a floating-point-mode exception.[C3]
- ISA-simulation-based filtering of interesting inputs. ProcessorFuzz uses ISA simulation to determine whether a test input is interesting. The paper contrasts this with prior approaches that rely on RTL simulation for the same purpose, describing RTL simulation as time-consuming and ISA simulation as significantly faster. This is intended to reduce repeated execution of redundant tests and focus effort on qualitatively distinct input patterns.[C4]
Methodology
ProcessorFuzz follows the general coverage-guided fuzzing pattern: execute many generated test inputs, identify inputs that increase coverage, mutate those inputs, and feed the resulting tests into later fuzzing rounds. Unlike software fuzzers, where the program under test can usually run directly on the host, processor fuzzing must evaluate hardware designs through RTL simulation because hardware is not directly executable on the host machine.[C5]
The distinguishing design choice in ProcessorFuzz is to treat transitions in architecturally meaningful CSRs as feedback for whether an input reaches a new processor state. This differs from hardware coverage metrics that monitor lower-level design structures, such as register values associated with multiplexer selection signals.[C6]
Evaluation
The paper evaluates ProcessorFuzz on three real-world open-source RISC-V processors: Rocket, BOOM, and BlackParrot. The evaluated processors include designs written in Chisel and SystemVerilog and vary in microarchitectural features such as pipeline depth and execution style, including in-order and out-of-order execution.[C7]
Against the state-of-the-art register-coverage-guided fuzzer DIFUZZRTL, ProcessorFuzz triggered a set of ground-truth bugs 1.23× faster on average. The experiments also exposed 8 new bugs across the three RISC-V cores and one new bug in a reference model; the paper states that all nine bugs were confirmed by the developers of the corresponding projects.[C8]
Significance
The paper’s central claim is that CSR-transition coverage provides a more semantically meaningful processor-fuzzing signal by focusing on architectural state transitions rather than generic code coverage or lower-level RTL activity. Combined with faster ISA-simulation-based input triage, ProcessorFuzz is presented as a way to improve processor fuzzing efficiency and bug discovery for RTL designs.[C3][C4][C8]