Skip to content
STIMSMITH

Assembly-Level Instruction Generation

Concept

Assembly-level instruction generation is a fuzzing technique that produces sequences of assembly instructions to drive coverage-guided testing of processor designs. In the TheHuzz hardware fuzzer, this technique is used to generate test instructions (TIs) that maximize coverage metrics and uncover software-exploitable hardware vulnerabilities.

First seen 6/14/2026
Last seen 6/14/2026
Evidence 4 chunks
Wiki v1

WIKI

Assembly-Level Instruction Generation

Overview

Assembly-level instruction generation is a technique used in hardware fuzzing to produce sequences of assembly instructions as inputs to a processor design under test (DUT). TheHuzz employs this technique to generate instructions that increase desired coverage values, thereby finding hardware bugs exploitable from software. The generated instructions are executed directly on the processor RTL simulation without requiring an operating system.

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

1 connections
TheHuzz ← uses 100% 2e
TheHuzz generates assembly-level instructions as inputs to the DUT.

CITATIONS

16 sources
16 citations — click to expand
[1] TheHuzz generates assembly-level instructions to increase the desired coverage values, thereby finding many hardware bugs exploitable from software. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[2] Each input consists of two types of instructions: configuration instructions (CIs) and test instructions (TIs). TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[3] CIs are needed to setup the baremetal environment, e.g., setting up the stack, exception handler table, and clearing the general-purpose registers. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[4] Each seed input has 20 TIs; this number is selected based on empirical observations before a random TI leads to a deadlock. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[5] Events like exceptions or instructions like branch, jump, system calls, and atomic instructions can cause the control flow of the processor to jump to a different location or even freeze for a large number of clock cycles. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[6] The first half of the TIs are generated uniformly from the instructions that are less likely to trigger such events (e.g., arithmetic and logical instructions). The other half of the TIs are generated uniformly from all the instructions returned by the optimizer. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[7] The processor is reset after the execution of every 20 instructions and is simulated with new input. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[8] The GCC toolchain compiles these C programs to generate the executable files which are loaded onto the processor RAM and used as seeds. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[9] We mutate the instructions directly as binary data instead of at a higher abstraction level such as assembly. This allows us to mutate all the bits of the instruction based on the mutation technique used. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[10] This allows us to test the processor with out-of-spec inputs like illegal instructions (i.e., instructions not specified in the ISA) generated through mutation of the opcode bits of the instruction. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[11] We mutate only the TIs since these are the instructions used to fuzz the processor. The CIs are not mutated to ensure the correct initialization of the processor for fuzzing. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[12] The mutation techniques used by our fuzzer can be classified into two types. The first type only mutates the data bits keeping the opcode unchanged. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[13] The Profiler characterizes the control and data flow paths explored by each IM pair. The Optimizer aims to minimize the number of IM pairs while achieving the same amount of coverage as using all the IM pairs. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[14] The seed generator uses the weights, wI, to select instructions, and the stimulus generator uses the weights, wM, to select the mutation techniques for each instruction and thereby, eliminating underperforming instructions. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[15] Bugs detected include incorrect implementation of FENCE.I logic (Branch coverage, CWE-440), incorrect propagation of exception type (Toggle coverage, CWE-1202), illegal instruction execution (Condition coverage, CWE-1242), cache coherency violation (FSM coverage, CWE-1202), and incorrect ALU logic (Expression coverage, CWE-1201). TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models
[16] TheHuzz achieves 1.98× and 3.33× the speed compared to the industry-standard random regression approach and the state-of-the-art hardware fuzzer, DifuzzRTL, respectively, and detected 11 bugs including 8 new bugs. TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models