Overview

Software fuzzing is a testing technique for discovering bugs by repeatedly running a Program Under Test (PUT) with a large number of random inputs. The provided evidence describes fuzzing as broadly adopted in the software community because of its effectiveness in bug discovery, scalability, and practicality.

Coverage-based greybox fuzzing

A widely used variant is coverage-based greybox fuzzing (CGF). CGF collects coverage feedback from the PUT at runtime. During each run, the fuzzer records coverage information such as basic-block coverage or edge coverage and uses that feedback to decide whether the input is interesting—that is, whether it increases coverage.

When an input is classified as interesting, CGF applies mutations to that input to generate new inputs for later fuzzing rounds. The motivating intuition is that inputs that increase coverage may lead, after mutation, to additional unexplored code. CGF typically instruments the program code, either statically or dynamically, with bookkeeping logic that records coverage during execution.

Relationship to hardware fuzzing

The evidence states that CGF, originally described in the software-testing context, has been adapted as a dynamic verification method for hardware, including processors. In software CGF, the target is a compiled program that can execute directly on a host machine. In processor fuzzing, the target hardware design is not directly executable on the host; it is usually represented at the RTL abstraction in a hardware description language such as Verilog or VHDL and evaluated with an RTL simulator.

Processor-fuzzing work also adapts differential testing ideas from software: in software, differential testing compares outputs of multiple programs with the same intended functional behavior and checks for inconsistencies. In the processor-fuzzing setting described by the evidence, the output of an RTL simulator is compared with an Instruction Set Architecture (ISA) simulator, and a difference indicates a potential processor bug.