Processor fuzzing

Overview

Processor fuzzing applies fuzzing to processor verification by generating instruction-sequence test cases, executing them on a design under test, and checking the resulting behavior for faults or vulnerabilities. In the provided sources, this is described as a form of hardware fuzzing for RTL processor designs, with a strong focus on open-source RISC-V cores. [Processor fuzzing as hardware fuzzing] [Execution and bug analysis] [RISC-V relevance]

Why it is used

The cited literature motivates processor fuzzing as a complement to more traditional hardware verification methods. Random regression can become slow when exploring intricate hardware behavior, especially in hard-to-reach critical components, while formal verification depends on manually specified properties and can become impractical because of state explosion. By contrast, fuzzing is described as highly automatable, cost-effective, scalable, and broadly applicable in hardware security. [Limits of random regression and formal verification] [Fuzzing advantages]

Common workflow

A typical processor-fuzzing loop in the provided evidence includes:

1. Seed creation or selection of instruction sequences.
2. Mutation or generation of new instruction sequences from promising seeds.
3. Execution on an RTL simulator, a software model derived from RTL, or alongside an ISA-level reference.
4. Bug detection by comparing traces, checking for mismatches, or analyzing microarchitectural effects. [Seed mutation in processor fuzzers] [Execution and bug analysis]

The evidence explicitly mentions common mutation operations such as bit or byte flipping, swapping, deleting, and cloning. [Seed mutation in processor fuzzers]

Guidance and feedback

Guidance signals are a central design choice in processor fuzzing. The provided sources state that traditional processor fuzzers such as DifuzzRTL and TheHuzz use code coverage and control register coverage to guide mutation. Other processor-behavior metrics mentioned in the evidence include mux toggle coverage and hardware behavior coverage. [Traditional coverage guidance] [Additional processor coverage metrics]

The same sources also describe important limits of coverage-driven fuzzing. ProcessorFuzz argues that existing approaches can rely on misleading coverage signals. SimFuzz argues that current coverage metrics can be biased and inefficient, and that they become less useful when coverage growth plateaus. In the transient-execution setting, DejaVuzz further argues that general processor-behavior coverage is not suitable because it does not track the propagation of sensitive data. [ProcessorFuzz motivation and method] [SimFuzz approach and limitations] [Transient-execution coverage limitation]

Representative approaches

CSR-guided processor fuzzing

ProcessorFuzz guides mutation using CSR-transition coverage. Its core idea is that Control and Status Registers reflect processor state, so transitions in CSRs can indicate exploration of new processor states. The cited abstract also says ProcessorFuzz is HDL-agnostic and does not require instrumentation of the processor design. [ProcessorFuzz motivation and method]

In the reported evaluation on Rocket, BOOM, and BlackParrot, ProcessorFuzz triggered ground-truth bugs 1.23× faster on average than DIFUZZRTL and exposed 8 new bugs across the three RISC-V cores plus 1 new bug in a reference model, all confirmed by developers. [ProcessorFuzz evaluation]

Formal-assisted processor fuzzing

HyPFuzz is presented as a hybrid or formal-assisted processor fuzzer for hard-to-reach processor design spaces. According to the provided public summary, it uses formal verification tools to help fuzz security-critical control-flow and data-flow logic, adds a scheduling strategy to balance formal and fuzzing resources, and uses heuristics to select design-space targets for the formal tool. [HyPFuzz method and results]

The summary reports evaluation on five open-source processors, detection of all vulnerabilities found by the most recent processor fuzzer, discovery of 3 additional vulnerabilities, creation of 2 CVE entries, and 11.68× faster coverage than the most recent processor fuzzer. [HyPFuzz method and results]

Similarity-guided processor fuzzing

SimFuzz reduces dependence on online coverage guidance by building a high-quality seed corpus from historical bug-triggering inputs and applying similarity-guided, block-level mutation. The cited summary says instruction similarity helps expand the search space around seeds while preserving control-flow structure, enabling deeper exploration without relying on coverage feedback. [SimFuzz approach and limitations]

In evaluation on Rocket, BOOM, and XiangShan, SimFuzz reportedly found 17 bugs in total, including 14 previously unknown issues and 7 CVE-assigned cases, and achieved up to 73.22% multiplexer coverage on its seed corpus. [SimFuzz results]

LLM-guided input generation

The provided ChatFuzz excerpts describe another direction: using a trained large language model on machine code to generate pseudo-random but interconnected instruction sequences that emphasize interdependent data flow and control flow. The same source positions this as an alternative to relying only on conventional random seed generation and mutation. [ChatFuzz method]

The excerpt reports 74.96% condition coverage in under one hour, about 34.6× faster than TheHuzz for that coverage point, 97.02% condition coverage on BOOM in 49 minutes, detection of approximately 6K mismatches, more than 100 unique mismatches, all bugs found by TheHuzz, and 2 new bugs. [ChatFuzz results]

Transient-execution-focused processor fuzzing

The evidence also includes a specialized form of processor fuzzing for transient execution bugs. DejaVuzz states that general processor-behavior coverage metrics are insufficient for this task because they do not capture sensitive-data propagation, and transient-execution vulnerabilities require more detailed microarchitectural analysis than ordinary functional bugs detected via co-simulation. [Transient-execution coverage limitation]

On BOOM, the cited evaluation says SpecDoctor covers only 4 transient-window types and needs about 125 training instructions, while DejaVuzz can trigger all transient-window types with minimal overhead. [DejaVuzz transient-window results]

Recurring challenges

Across the provided evidence, recurring challenges in processor fuzzing include:

• reaching deep or hard-to-explore control-flow and data-flow logic; [Limits of random regression and formal verification] [HyPFuzz method and results]
• avoiding weak, misleading, or plateauing feedback signals; [ProcessorFuzz motivation and method] [SimFuzz approach and limitations]
• generating instruction sequences that are not merely valid, but also meaningful enough to reach deep design regions; [ChatFuzz method]
• designing observability and feedback that match the target bug class, especially for transient execution. [Transient-execution coverage limitation]

Relationship to hardware fuzzing

In the provided sources, processor fuzzing is consistently framed as a processor-specific branch of hardware fuzzing. Its main distinguishing feature is that inputs are instruction sequences and that feedback, execution, and bug detection are tailored to processor state, ISA behavior, and microarchitectural effects. [Processor fuzzing as hardware fuzzing] [Traditional coverage guidance]