Fuzzing

Definition

Fuzzing (also called fuzz testing) is a testing technique that consists of repeatedly running a target with random or mutated inputs in order to find bugs, crashes, or security vulnerabilities. A typical coverage-guided fuzzing loop comprises:

1. A seed corpus of initial inputs.
2. A mutation engine that produces new test cases by mutating existing seeds.
3. The target under test (software, a parser, or a hardware design).
4. A coverage/feedback monitor that records how the new input exercised the target.
5. A decision step that keeps inputs which yield new coverage, and a bug/crash detector that flags inputs that trigger failures.

The general formulation is preserved across domains: fuzzing is an automated testing method that repeatedly generates inputs, often randomly or through guided mutation, to expose bugs, crashes, or unexpected behaviors [PROFUZZ].

Software Fuzzing

In the software domain, fuzzing has been widely used to discover vulnerabilities in input-parsing code. A representative example is Learn&Fuzz, which automates the construction of an input grammar suitable for input fuzzing using sample inputs and neural-network-based statistical machine-learning techniques, applied to the PDF parser embedded in Microsoft Edge [Learn&Fuzz].

Another software direction is fuzz driver generation for libraries: PromptFuzz is a coverage-guided fuzzer that iteratively generates fuzz drivers to explore undiscovered library code. On 14 real-world libraries, PromptFuzz achieved 1.61× and 1.63× higher branch coverage than OSS-Fuzz and Hopper respectively, and detected 33 genuine, new bugs out of 49 crashes, with 30 confirmed by their communities [PromptFuzz].

Hardware / Processor Fuzzing

Fuzzing has more recently been adapted for hardware verification. Inspired by well-established software fuzzing techniques, hardware fuzzing emerged as a complementary approach to functional and formal verification, which struggle to scale with the growing complexity of modern hardware designs [PROFUZZ]. When adapting fuzzing to hardware, three key questions arise:

• Input format and mutation: e.g., driving RTL signals versus generating assembly test programs, and how to mutate them.
• Coverage feedback metric: standard RTL coverage metrics versus new, HDL-agnostic metrics designed for fuzzing.
• Bug detection: golden models versus a hardware equivalent of a "software crash," often implemented via differential comparison between an ISA simulation trace and an RTL simulation trace.

A general hardware-fuzzing pipeline therefore uses both RTL simulation (to produce an RTL trace) and ISA simulation (to produce an architectural trace), comparing the two to detect mismatches indicative of bugs.

Coverage-Guided vs. Directed Graybox Fuzzing

Within hardware fuzzing, two principal paradigms are distinguished [PROFUZZ]:

• Coverage-Guided Graybox Fuzzing (CGF) is the foundational technique. Input generation is directed by feedback from real-time code coverage, allowing the fuzzer to prioritize input mutations that reveal unexplored paths and improve functional coverage of RTL designs. RTL-level fuzzing frameworks built around CGF have demonstrated effectiveness in achieving broad coverage, particularly across designs with complex datapaths.
• Directed Graybox Fuzzing (DGF) was proposed as an alternative for the practical realities of hardware design workflows. Unlike software, hardware is typically developed incrementally, with new modules added or existing ones modified across design iterations, so verification efforts must focus on specific changes rather than re-testing the entire system. DGF steers test generation toward specific regions of interest, which is particularly useful in scenarios such as patch validation, bug localization, or module-specific testing.

DirectFuzz is a representative DGF-based implementation that aimed to bring directionality into the fuzzing process to improve targeted coverage. It nevertheless exhibits several key limitations: (i) inability to capture hardware-specific semantics and structure, (ii) misaligned coverage metrics that do not align well with established verification practices, (iii) limited scalability when targeting multiple design regions, and (iv) inability to perform targeted verification across multiple modules [PROFUZZ].

PROFUZZ

PROFUZZ is a hardware fuzzing framework based on DGF that is specifically designed to overcome the limitations of prior work, including abstraction mismatches, limited coverage precision, and poor scalability. Unlike earlier DGF-based methods, PROFUZZ operates directly at the hardware's native abstraction level, allowing it to accurately model inherent hardware behaviors and utilize coverage metrics that reflect hardware-specific characteristics. Additionally, PROFUZZ is designed to integrate seamlessly with industry-standard Electronic Design Automation (EDA) tools, facilitating adoption within established design and verification workflows [PROFUZZ].

ProcessorFuzz

ProcessorFuzz introduces a new coverage metric for processor fuzzing based on Control and Status Register (CSR) transitions: a new transition in CSR values signals a coverage increase. Because it is collected via an ISA simulator, the coverage collection is HDL-agnostic and more efficient. In evaluation on Rocket, BOOM, and BlackParrot RISC-V processors, ProcessorFuzz detected known bugs 23% faster than DifuzzRTL and discovered 9 new bugs (6 in BlackParrot, 2 in Rocket and BOOM, and 1 in the Dromajo ISA simulator).

SIGFuzz

SIGFuzz is a framework for discovering microarchitectural timing side channels. It runs a reference test and a mutated test on RTL simulation, then extracts signatures and evaluates trace properties on cycle-accurate commit traces; divergence between the two trace-property values flags potential side channels. Evaluated on Rocket and BOOM, SIGFuzz discovered 3 new side channels (and 2 known ones), including one that was exploited to mount a Spectre-style attack on BOOM.

Cascade

Cascade is a CPU fuzzer that operates via intricate program generation, targeting CPU designs. It is presented in a USENIX Security 2024 paper, with an artifacts repository providing a Docker image to reproduce results, and the main fuzzing code hosted in a companion meta repository.

Summary

Across domains, fuzzing combines (1) random or grammar-informed input generation, (2) a coverage feedback signal, and (3) an oracle for failures (crashes, trace mismatches, or property violations). Software fuzzing targets include parsers and libraries, while hardware/processor fuzzing targets RTL designs and uses HDL-agnostic coverage metrics and trace-based bug oracles. Within hardware fuzzing, CGF drives broad exploration across complex datapaths, while DGF (as exemplified by DirectFuzz and PROFUZZ) targets specific regions of interest for incremental, module-level, or patch-driven verification, with PROFUZZ addressing prior DGF limitations through native-abstraction operation and EDA-tool integration.