Overview

MorFuzz is a processor-fuzzing tool described by the paper MorFuzz: Fuzzing Processor via Runtime Instruction Morphing enhanced Synchronizable Co-simulation. The paper situates processor fuzzing as a dynamic verification approach in which fuzzers generate instruction streams, mutate them based on coverage from prior runs, simulate the hardware, collect coverage, and verify architectural state against expected behavior. ^[1]

MorFuzz's distinguishing mechanisms in the provided evidence are its binary-level field-aware mutation and its use of runtime DUT state to dynamically morph instructions and randomize operands. These mechanisms are presented as ways to explore corner-case instruction formats and to construct complex execution environments that earlier methods may miss. ^{[2] [3]}

Verification context

The evidence frames processors as finite state machines with both microarchitectural state and architectural state. Microarchitectural state is implementation-related internal state, while architectural state represents program-visible state such as memory and general-purpose registers and is expected to be consistent for the same ISA. ^[4]

Processor verification is described as checking whether a processor design under test conforms to the implementation function defined by the specification. The evidence also states that simulation-based verification is prevalent in practice because formal verification has scaling limits for complex designs. ^[5]

Processor-fuzzing workflow

The cited paper describes a general processor-fuzzing workflow with three phases:

1. Input generation: the fuzzer generates instruction streams from seeds and mutates them using coverage from the previous round.
2. Hardware simulation: RTL code of the design under test is translated into a host executable binary, and hardware instrumentation collects coverage during simulation.
3. State verification: the fuzzer extracts the architectural state of the design under test for checking. ^[1]

The evidence notes that existing processor fuzzers have used coverage metrics including mux coverage, control-register coverage, and hardware-behavior coverage. ^[6]

Mutation and runtime morphing

MorFuzz is reported to perform binary-level field-aware mutation, which allows it to explore unexpected or rare instruction formats more efficiently than fuzzers that mutate only at the instruction level and generate only valid assembly instruction formats. ^[2]

For complex logic bugs, the evidence states that MorFuzz monitors internal runtime states of the DUT, dynamically morphs instructions, and randomizes operands. This is presented as a way to enhance instruction semantics when preparing the specific execution environments needed to expose complex hardware logic bugs. ^[3]

Reported bug findings

The paper groups bugs found by MorFuzz into three categories: instruction-decoder-related bugs, CSR-state-related bugs, and complex logic bugs. The evidence says the bugs were identified using the latest RISC-V ISA specification referenced by the paper. ^[7]

Examples reported in the evidence include:

• Rocket: treating an aes64ks1i instruction with an rcon field greater than 0xA as valid, reported as CVE-2022-34632. ^[8]
• BOOM: executing floating-point instructions with illegal rm fields without raising exceptions, and crafted or incorrectly formatted sfence.vma and dret instructions being executed. ^[9]
• CVA6: delayed update of mstatus.sd when mstatus.fs is set to dirty, and writing the binary instruction of ebreak to mtval/stval when executing ebreak. ^[10]
• Spike: an incorrect mask in mcontrol.action, described as 0x3f even though the field is four bits wide, which could save an illegal action and crash simulation. ^[11]

The evidence also states that MorFuzz's inclusion of binary-level mutations may trigger bugs previous methods did not cover, with B8 given as an example. ^[12]

Comparison points in the evidence

The paper excerpt mentions earlier or related tools and generators, including DifuzzRTL, TheHuzz, and riscv-torture. DifuzzRTL is described as using static analysis to generate instructions with required operands, while TheHuzz is described as optimizing mutations according to optimal weights. ^[13]

References

^[1]: Processor-fuzzing workflow. ^[4]: Processor architectural and microarchitectural state model. ^[5]: Processor verification and simulation-based verification context. ^[6]: Existing processor-fuzzing coverage metrics. ^[2]: MorFuzz binary-level field-aware mutation. ^[3]: MorFuzz runtime state monitoring and instruction morphing. ^[7]: MorFuzz bug categories. ^[8]: Rocket bug B1 reported by MorFuzz. ^[9]: BOOM bugs reported by MorFuzz. ^[10]: CVA6 bugs reported by MorFuzz. ^[11]: Spike bug B18 reported by MorFuzz. ^[12]: Binary-level mutations triggering previously missed bugs. ^[13]: Related processor-fuzzing tools mentioned in the paper.