Overview
AFL is described in the evidence as a coverage-guided fuzzer and as a notable representative of coverage-guided fuzzing alongside LLVM-based libFuzzer. The cited ISS-verification paper characterizes mutation-based fuzzing as a technique that mutates randomly created data and is guided by code coverage, avoiding the need to create an input model. [AFL as coverage-guided fuzzer]
A later cross-level processor-verification study refers to AFL as a state-of-the-art coverage-guided fuzzer and uses the unmodified AFL 2.56b release as its baseline, calling it Vanilla AFL. [AFL 2.56b baseline]
Use in processor-verification research
In Efficient Cross-Level Processor Verification using Coverage-guided Fuzzing, AFL was used in a case study comparing Vanilla AFL with an optimized Enhanced AFL variant. The study configured VexRiscv for the RV32IM instruction subset, used random seeds, started from a 32-bit corpus value of 0x0000, and imposed a 24-hour runtime limit. [AFL in cross-level processor verification]
The same study reported that experiments ran on a Linux machine with an Intel Xeon Gold 5122 CPU at 3.60 GHz, and that results were compared using fuzzer-run metrics such as queue size and unique crashes. In that context, #Queue counted test vectors that increased coverage without causing a co-simulation execution mismatch, while #Unique-Crash counted unique test vectors causing an execution mismatch. [Fuzzer-run metrics]
Enhanced AFL mutations in the evidence
The cross-level verification study enhanced AFL with problem-specific mutations named Fast Exploration and Enhanced Havoc. Fast Exploration is described as a deterministic mutation that adds a preliminary exploration phase before normal mutation. In the RISC-V setting, it begins by inserting each RISC-V instruction at the beginning of every test vector, with instruction arguments fixed to source/destination register x0 and immediate 0; the paper gives addi x0, x0, 0 as an example. [Enhanced AFL mutations]
Execution-controller setting in the AFL-based study
The AFL-based cross-level verification setup used an execution controller with two stated purposes: preventing infinite loops and detecting mismatches between processor cores. Infinite loops were conservatively detected when a new program-counter address equaled an already executed address and register values were unchanged, and the setup also imposed a hard limit of 10,000 ISS instruction executions to handle the halting problem. [Execution controller]
For mismatch detection, the study synchronized and compared when register values changed. In the example described in the paper, the execution controller detected a register-value mismatch between an ISS and an RTL core, threw an error, and stopped the simulation. [Mismatch detection]
Reported comparison of Vanilla AFL and Enhanced AFL
The study compared unmodified AFL 2.56b with Enhanced AFL. It reported that Enhanced AFL generated fewer queue test vectors on average, but a one-tailed Mann–Whitney U test on the #Queue values produced a U-value of 60, z-score of 0, and p-value of 0.5 against a 95% confidence critical threshold of 34. The paper therefore concluded that the apparent improvement was not statistically significant and was negligible in practice. [Vanilla AFL versus Enhanced AFL results]
AFL++ context
The provided public repository context describes AFL++ as “afl with community patches” and lists additions such as a QEMU 5.1 upgrade, collision-free coverage, enhanced laf-intel and redqueen, AFLfast++ power schedules, MOpt mutators, and unicorn_mode. [AFL++ public context]