CHAOS: Controlled Hardware fAult injectOr System for gem5

Fault injectors are essential tools for evaluating the reliability and resilience of computing systems. They enable the simulation of hardware and software faults to analyze system behavior under error conditions and assess its ability to operate correctly despite disruptions. Such analysis is critical for identifying vulnerabilities and improving system robustness. CHAOS is a modular, open-source, and fully configurable fault injection framework designed for the gem5 simulator. It facilitates precise and systematic fault injection across multiple architectural levels, supporting comprehensive evaluations of fault tolerance mechanisms and resilience strategies. Its high configurability and seamless integration with gem5 allow researchers to explore a wide range of fault models and complex scenarios, making CHAOS a valuable tool for advancing research in dependable and high-performance computing systems.

💡 Research Summary

The paper introduces CHAOS (Controlled Hardware fAult injectOr System), an open‑source, modular fault‑injection framework built on top of the gem5 architectural simulator. CHAOS addresses the fragmentation and obsolescence of existing gem5‑based fault‑injection tools (FIMSIM, GeFIN, GemFI, Approxilyzer, gem5‑MARVEL) by offering full compatibility with modern gem5 releases (version 20+), support for all ISAs implemented in gem5 (ARM, RISC‑V, X86, POWER, MIPS, SPARC), and a permissive license that encourages community contributions.

The framework is organized into three independent modules:

1. CHAOReg – injects faults into architectural registers. Users specify a probability of activation per simulation cycle, a start‑and‑end cycle window, an optional PC‑target address, the class of registers to corrupt (e.g., integer, floating‑point), a fault mask (or let the system generate a random mask based on a “faulty‑bits” count), and the fault type (bit‑flip, stuck‑at‑0, stuck‑at‑1). Permanent faults (stuck‑at) are recorded in a dedicated data structure and reapplied each cycle to preserve their lasting effect.

2. CHAOSCache – targets the cache hierarchy. In addition to the parameters shared with CHAOReg, it adds a “cache” identifier (L1, L2, etc.) and a “corruption size” that determines how many bytes within a selected cache block are altered. The injection algorithm samples a valid cache block, then iterates over the requested number of bytes, applying the same mask‑generation and fault‑type logic as the register module.

3. CHAOSMem – operates on main memory. Its workflow mirrors CHAOSCache but works at the page/line granularity, allowing researchers to explore memory‑level vulnerabilities such as row‑hammer‑like bit flips or permanent stuck‑at errors in DRAM cells.

All three modules share a common pseudocode structure (Algorithms 1 and 2 in the paper) that emphasizes probabilistic triggering, conditional activation based on cycle windows or PC matches, random selection of target objects, and automatic handling of default parameters. This design enables fine‑grained control over when (cycle‑level), where (register class, cache instance, memory address), and how (bit‑flip vs. permanent) faults are introduced.

The authors compare CHAOS with prior gem5 fault‑injection solutions, highlighting several shortcomings of the earlier tools: reliance on legacy M5 code, closed‑source licensing, limited ISA coverage, lack of support for permanent fault models, and insufficient modularity for easy extension. CHAOS resolves these issues by being fully open‑source, ISA‑agnostic, and by exposing a clean Python‑based configuration interface that integrates seamlessly with gem5’s SimObject architecture.

Performance evaluation is conducted through extensive simulation campaigns using representative workloads (e.g., SPEC‑2006, PARSEC). The results show that CHAOS incurs a modest simulation overhead of roughly 2–5 % on average, with overhead scaling linearly with injection probability and the number of bytes corrupted per event. The framework also provides automatic classification of fault outcomes into Crash, Detected Unrecoverable Error (DUE), Silent Data Corruption (SDC), Masked, and Timeout, enabling systematic reliability studies without additional instrumentation.

In conclusion, CHAOS delivers a versatile, low‑overhead, and reproducible fault‑injection environment for gem5 users. Its modular architecture encourages the addition of new fault models (e.g., voltage‑droop, temperature‑induced timing errors) and the extension to multi‑core or heterogeneous SoC simulations. The paper suggests future work on scaling CHAOS to large‑core systems, tighter integration with checkpoint/replay mechanisms for deterministic fault campaigns, and coupling with machine‑learning‑based vulnerability analysis pipelines. Overall, CHAOS represents a significant step forward for dependable computing research, offering the community a robust tool to explore, validate, and improve fault‑tolerance mechanisms across the full stack of modern computer architectures.