Overview

ProcessorFuzz is a processor fuzzing tool introduced in the paper “ProcessorFuzz: Processor Fuzzing with Control and Status Registers Guidance.” The paper positions processor fuzzing as a pre-silicon dynamic verification approach for complex processors, where exhaustive verification is considered unrealistic because processor state spaces are very large and verification resources are limited.

Verification model

The available evidence describes the broader hardware-fuzzing workflow used by recent processor fuzzers as an adaptation of coverage-based greybox fuzzing and differential testing. In this setting, a test input is simulated on a processor design under test and the resulting behavior is analyzed for bugs.

For processor differential testing, the evidence states that outputs from a Register Transfer Level (RTL) simulator are compared with outputs from an Instruction Set Architecture (ISA) simulator. The RTL simulator models execution on the detailed microarchitectural implementation, while the ISA simulator models the functional behavior of the processor as a reference. A difference between RTL-simulation and ISA-simulation outputs is treated as a potential processor bug.

Coverage motivation

The paper contrasts ProcessorFuzz with DIFUZZRTL, which uses a register coverage metric that monitors value changes in registers controlling multiplexer selection signals. The evidence reports the paper’s observation that such register coverage can be misleading when it monitors datapath registers with minimal control over the processor finite-state-machine state. Inputs that only affect those datapath registers may be misclassified as interesting, wasting fuzzing time.

CSR focus and exclusions

The paper title and CSR table indicate that ProcessorFuzz is guided by Control and Status Registers (CSRs). The available table specifically lists CSRs that are not monitored by ProcessorFuzz and gives reasons for exclusion. Examples include:

• CSRs that hold constant values during testing, such as misa, mhartid, {m,s}tvec, satp, PMP configuration/address CSRs, interrupt-pending and interrupt-enable CSRs, and mideleg.
• Debug-extension and vector-extension CSRs that are excluded because the testing infrastructure does not support the relevant functionality.
• Hardware performance counter CSRs such as cycle, instret, hpmevent, and hpmcounter, which the table characterizes as more useful for designer analysis of a hardware bug than for revealing the fundamental issue.
• Trap/context CSRs such as {m,s}tval, mscratch, {m,s}epc, and sscratch, which are also grouped under the table’s rationale about assisting analysis rather than exposing the core issue.

Reported bug-finding result

The provided excerpt states that ProcessorFuzz identified eight new bugs across three processor designs and one new bug in a reference model. The excerpt does not identify the three processor designs by name.