Skip to content
STIMSMITH

Interrupt

Concept

In computing, an interrupt is an event that alters the normal flow of program execution, whether delivered as external hardware stimulus, an internal exception, or a software-triggered instruction. This article covers the general concept and its varied uses: x86 software interrupts (notably int3 / opcode 0xCC) repurposed by binary-instrumentation and coverage-guided fuzzing tools, modular static verification of interrupt-driven software, automatic interrupt modeling for MCU firmware analysis, hardware-core verification of interrupt handling in designs such as the Ibex RISC-V core, and corner-case issues (such as race conditions during status-register clear) that arise when interrupt service routines interact with status registers.

First seen 6/6/2026
Last seen 7/26/2026
Evidence 5 chunks
Wiki v3

WIKI

Definition

In computing, an interrupt is an event that causes the processor or execution environment to suspend the current flow of instruction execution and transfer control to a dedicated handler. Interrupts may originate from external hardware stimulus (devices, timers, debug requests), internal exceptions, or explicit software instructions. They are a principal class of asynchronous, externally-driven events whose complete semantics — including nested invocations of interrupt handlers — are notoriously difficult to model and reason about [arxiv:1709.10078].

x86 Software Interrupts and the int3 Opcode

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

6 connections
external stimulus ← part of 1e
Interrupts are a form of external stimulus in the co-simulation flow.
core_ibex_test_lib.sv ← uses 1e
core_ibex_test_lib.sv handles interrupt assertion verification.
int3 ← implements 90% 1e
The paper notes that byte 0xCC decodes to the int3 instruction, which triggers an interrupt.
Firmware Fuzzing ← uses 90% 1e
Firmware fuzzing delivers inputs via interrupts.
JUMBO Packet ← mentions 1e
A JUMBO Packet triggers an Interrupt when observed on a port.
Interrupt Service Routine mentions → 1e
An Interrupt Service Routine is performed after receiving an Interrupt.

CITATIONS

12 sources
12 citations — click to expand
[1] Interrupts originate from external hardware stimulus, internal exceptions, or explicit software instructions, and their complete semantics (including nested handler invocations) are difficult to model. Modular Verification of Interrupt-Driven Software
[2] On x86/x86-64, 0xCC is the single-byte opcode for int3, and the byte sequence [00 CC] at address 0x405500 normally decodes as [add %cl,%ah] but the trailing 0xCC is itself a valid int3 opcode that can be redirected into. Same Coverage, Less Bloat: Accelerating Binary-only Fuzzing with Coverage-preserving Coverage-guided Tracing
[3] Coverage-Guided Tracing (CGT) instruments binaries by inserting int3 interrupts rather than new basic blocks, providing lightweight native-speed coverage. Same Coverage, Less Bloat: Accelerating Binary-only Fuzzing with Coverage-preserving Coverage-guided Tracing
[4] Jump mistargeting redirects a conditional jump's critical edge so execution lands on a 0xCC opcode, with embedded-int and zero-address-int variants; scanning the displacement range for candidate 0xCC bytes is a key bottleneck. Same Coverage, Less Bloat: Accelerating Binary-only Fuzzing with Coverage-preserving Coverage-guided Tracing
[5] AFL-style bucketed hit-count tracking is incompatible with CGT's binarized interrupt-driven coverage, motivating the bucketed-unrolling transformation. Same Coverage, Less Bloat: Accelerating Binary-only Fuzzing with Coverage-preserving Coverage-guided Tracing
[6] A 2017 abstract-interpretation framework analyzes each interrupt handler in isolation, propagates results to other handlers, and iterates to a fixed point; evaluated on 35 applications (22,541 LOC). Modular Verification of Interrupt-Driven Software
[7] AIM provides a generic, scalable, hardware-independent dynamic firmware-analysis framework on angr with firmware-guided Just-in-Time Interrupt Firing, covering up to 11.2× more interrupt-dependent code than prior approaches on eight real-world MCU firmwares. AIM: Automatic Interrupt Modeling for Dynamic Firmware Analysis
[8] Fuzzware combines lightweight program analysis, firmware re-hosting, and coverage-guided fuzzing with precise MMIO modeling that focuses only on meaningful hardware-generated values; inputs to embedded/MCU firmware are delivered via MMIO registers, interrupts, and DMA. Low Power, High Risk: Fuzzing the Chips Behind IoT
[9] A common interrupt corner case is when a new triggering event (e.g., a JUMBO packet) coincides with the software write of 1 to clear the interrupt status register; the expected behavior is that the interrupt status is retained at 1 so the new event is not lost. ASIC Design and Verification: corner cases
[10] In the Ibex RISC-V core, interrupts are an external stimulus that triggers a trap and, with debug requests and memory faults, form the principal class of asynchronous events the testbench must cover. Same Coverage, Less Bloat: Accelerating Binary-only Fuzzing with Coverage-preserving Coverage-guided Tracing
[11] ISS models can simulate traps due to exceptions but not traps due to external stimulus such as interrupts, so Ibex uses the RISCV-DV handshaking mechanism with signature address 0x8ffffffc, integrated in core_ibex_base_test.sv and used in core_ibex_test_lib.sv for interrupt assertions, debug, and fault runtime verification. Same Coverage, Less Bloat: Accelerating Binary-only Fuzzing with Coverage-preserving Coverage-guided Tracing
[12] Ibex compares only final register values (not every write) against the ISS trace log because the ISS log lacks execution info for debug ROM and interrupt-handler code, on the assumption those handlers preserve register state. Same Coverage, Less Bloat: Accelerating Binary-only Fuzzing with Coverage-preserving Coverage-guided Tracing