💻 computer science

HammerSim: A System-Level Tool to Model RowHammer

This paper presents HammerSim, a gem5-based full-system simulation framework that integrates probability-driven bitflip modeling to realistically evaluate RowHammer vulnerabilities and assess hardware and software mitigations across modern computing platforms.

Original authors: Kaustav Goswami, Ayaz Akram, Hari Venugopalan, Jason Lowe-Power

Published 2026-05-28

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Kaustav Goswami, Ayaz Akram, Hari Venugopalan, Jason Lowe-Power

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine your computer's memory (RAM) is like a massive, crowded apartment building. Each apartment is a tiny storage cell holding a single piece of data (a 0 or a 1). In a perfect world, these apartments are sturdy and independent. But in the real world, as technology shrinks to fit more apartments into the same space, the walls between them get paper-thin.

This is where RowHammer comes in.

The Problem: The "RowHammer" Effect

Imagine a noisy tenant in Apartment 404 who starts jumping up and down on their floor repeatedly. Because the walls are so thin, the vibrations eventually shake the furniture in the neighboring apartments (403 and 405), causing things to fall over or change. In computer terms, repeatedly accessing (or "hammering") a specific row of memory causes electrical interference that flips the bits in the neighboring rows.

This isn't just a glitch; it's a security nightmare. Hackers can use this "vibration" to flip bits in a way that lets them break into the building's management office (the operating system) or steal secrets.

The Current Dilemma: Two Flawed Tools

Researchers have been trying to study this problem with two main tools, but both have holes:

The Hardware Lab (FPGAs): This is like building a real, physical model of the apartment building. It's very accurate for seeing how the walls vibrate, but it's too small to see how the building manager (the Operating System) reacts to the noise. You can't see the whole building's dynamics.
The Software Exploit: This is like writing a script to pretend to be the noisy tenant. It's great for seeing how the manager reacts, but it's a guess. You can't actually see the physical walls shaking or the electrical interference happening inside the chips.

Most computer simulations today are like a cartoon version of the building. They assume all walls are equally strong and all vibrations are the same. But in reality, some walls are weak, some are strong, and the vibrations are chaotic.

The Solution: HammerSim

The authors of this paper built a new tool called HammerSim. Think of it as a super-realistic video game simulator that combines the best of both worlds.

It runs the whole building: Unlike the small hardware models, HammerSim runs inside a full computer simulator (called gem5). This means it can watch the "building manager" (the OS) and the "tenants" (applications) while the noise happens.
It knows the weak spots: Instead of assuming all walls are the same, HammerSim uses a "map" of real-world memory chips. It knows exactly which specific cells are weak and likely to break, just like a real building inspector would know which apartments have thin walls.
It's a "What-If" machine: Researchers can use HammerSim to test different scenarios:
- The Attack: Can a hacker jump on the floor enough to break in?
- The Defense: What if we install soundproofing (a hardware fix called TRR) or a security guard who checks the furniture (software/ECC)?
- The Accidents: What happens if a normal, innocent tenant (a benign app) accidentally causes a bit to flip? Does the building collapse, or does it just have a small mess?

How It Works (The Magic Behind the Scenes)

The paper explains that HammerSim uses two modes to study these problems:

Online Mode (Live Action): The simulator runs a real program. As the program runs, HammerSim secretly injects "bit flips" (the furniture falling over) into the memory. It watches to see if the program crashes, if the OS panics, or if the hacker succeeds. It's like watching a movie where the special effects (the bit flips) happen in real-time.
Offline Mode (The Replay): Sometimes, running the whole movie takes too long. In this mode, HammerSim records the "footsteps" (memory access patterns) of the program. Later, a computer can replay those footsteps against thousands of different "weak wall" maps to see what would have happened without waiting for the whole simulation to finish.

The Results

The team tested HammerSim against real computer chips. They found that their simulator was very good at predicting exactly where the "bit flips" would happen, matching the real hardware almost perfectly.

They also showed that:

ECC (Error Correcting Code): This is like a security guard who fixes a fallen chair before anyone notices. HammerSim showed that while this helps, it's not a magic bullet; if too many things fall at once, the guard can't fix them all.
Silent Errors: Sometimes, a bit flips, but the program doesn't crash. It just gives you the wrong answer. HammerSim can catch these "silent" mistakes, which is crucial for safety.

The Bottom Line

HammerSim is a bridge. It connects the messy, unpredictable reality of physical computer chips with the clean, controlled world of computer simulations. It allows researchers to safely test how to protect our computers from these "vibrating" attacks without needing to build a new physical chip for every single test. It's a tool to make our digital apartment buildings safer before the walls start shaking.

Technical Summary: HammerSim

Problem Statement

Modern architecture research relies heavily on simulators to evaluate system security, yet analyzing emerging hardware vulnerabilities like RowHammer presents a significant challenge. Existing tools suffer from a "fidelity gap":

Hardware-based methods (FPGAs, software exploits) provide high physical accuracy or OS-level visibility but lack the other. FPGAs cannot model OS abstractions or full-system dynamics, while software exploits lack the hardware visibility needed to prototype co-design mitigations.
Cycle-accurate simulators (e.g., standard gem5 configurations) often assume idealistic settings, using nominal timing and voltage values from datasheets. They typically treat faults as uniform or binary events, failing to capture the highly non-uniform, localized nature of RowHammer bitflips caused by manufacturing process variations.
System-level impact: As DRAM technology scales, RowHammer thresholds decrease, making full-system visibility crucial. Without the ability to simulate how hardware faults dynamically interact with OS scheduling, cache hierarchies, and memory controllers, researchers cannot reliably estimate security boundaries or system reliability.

Methodology

The authors present HammerSim, a full-system RowHammer modeling framework built upon the gem5 architectural simulator. The methodology bridges the gap between hardware characterization and architectural simulation through the following components:

1. Hardware Characterization and Modeling

To ground the simulation in physical reality, the authors conducted extensive experiments on real DDR4 DIMMs from multiple manufacturers using the Blacksmith profiling infrastructure. Key empirical observations drove the modeling:

Spatial Localization: Bitflips are intensely localized; specific regions are vulnerable while adjacent structures remain resilient.
Temporal Saturation: The pool of vulnerable cells is finite; once a cell fails, it has a bounded probability of failing again.
Non-Linearity: Multi-sided (double-sided) attacks amplify bitflip probabilities significantly compared to single-sided attacks.

2. Architectural Implementation in gem5

HammerSim integrates these insights directly into the gem5 memory interface, avoiding the need for external trace-driven backends. It introduces two primary execution modes:

Online Mode (Runtime Fault Injection):
- Probability-Driven Bitflips: Uses probability distributions (either file-based device maps from real hardware or statistical models based on VARIUS) to identify "Weak Cells" (WC).
- Spatial Tracking: Maintains optimized counter-pairs within the memory controller to track activation rates of aggressor rows and their neighbors (supporting single-sided, double-sided, and Half-Double attacks).
- Silent Corruption: Injects bit-level data corruption into active memory arrays without triggering hardware interrupts, mimicking real soft errors. This allows the OS and applications to remain unaware until they access the corrupted data.
- Functional ECC: Implements a software abstraction of Error Correcting Code (SECDED) that intercepts requests, evaluates parity, and corrects single-bit errors or flags multi-bit errors, all while maintaining simulation wall-clock time.
Offline Mode (Trace Analysis):
- Logs row-level activation traces at refresh boundaries ( $t_{REFW}$ ).
- Allows external tools to overlay these traces with different process variation distributions, device maps, or mitigation thresholds without re-running the full-system simulation. This enables rapid sensitivity sweeps for hardware designers.

3. Mitigation Support

The framework supports the evaluation of hardware-software co-designs, including:

Target Row Refresh (TRR): Modeled with timing correctness, sending targeted REF or ACT commands to victim rows during refresh windows.
Probabilistic Refresh: Implementation of strategies like PARA and TWICE.

Key Contributions

System-Level RowHammer Model: A gem5-based framework incorporating multiple probability distributions for realistic bitflip estimation, enabling studies on real workloads and future DRAM technologies.
Dual Analysis Modes:
- Online: Enables in-situ data corruption to study system-level effects (OS reactions, kernel panics, silent errors).
- Offline: Provides post-processing for accurate probability estimation and rapid design space exploration.
Hardware-Informed Validation: Extensive validation against real DDR4 DIMMs using Jensen-Shannon (JS) divergence to demonstrate that the simulation accurately captures real-world bitflip patterns and spatial localization.

Results and Evaluation

The authors validated HammerSim through three case studies:

Validation (Case Study I):
- Compared simulated bitflip maps against hardware-generated maps from 9 different rows across multiple DIMMs.
- Result: The simulation showed low JS divergence values, indicating a high degree of similarity to real hardware behavior, even when modeling complex TRR interactions.
Full-System Applications and ECC (Case Study II):
- Executed Google's rowhammer-test workload within the simulator.
- Result: Successfully demonstrated data corruption and the ability to bypass OS protections.
- ECC Evaluation: Tested SECDED ECC functionality. The simulator correctly corrected single-bit errors and detected double-bit errors, reporting statistics on uncorrectable errors and kernel panics.
Benign Applications (Case Study III):
- Analyzed memory traces from NAS Parallel Benchmarks and GAPBS.
- Result: Under standard parameters, no RowHammer patterns were detected. However, by lowering the threshold and increasing probability, the tool successfully identified "silent errors" that propagated to the end of program execution in some workloads (e.g., mg, ft), while others failed (Seg. Fault).
- Overhead: HammerSim incurred an average 10.9% to 29.2% increase in wall-clock time and 50.6% to 65% increase in host memory usage compared to baseline gem5, a trade-off for the added fidelity.

Significance and Claims

The paper claims that HammerSim provides an extensible platform to bridge the gap between hardware experiments and architectural simulation. Its primary significance lies in:

Realism: Moving beyond idealistic assumptions to model the non-uniform, spatially localized nature of RowHammer using real device maps.
System Visibility: Allowing researchers to study the interaction of hardware faults with OS scheduling, cache hierarchies, and memory controllers, which was previously impossible with FPGA-only or trace-only approaches.
Versatility: Supporting the evaluation of both attacks (e.g., privilege escalation, fingerprinting) and defenses (TRR, ECC, row-swapping) in a unified environment.
Future-Proofing: Providing a foundation to study how decreasing RowHammer thresholds in future DRAM generations will impact the reliability of benign workloads and system security.

The authors conclude that while the current mitigations demonstrated are intentionally simple, HammerSim establishes a rigorous foundation for prototyping and benchmarking advanced, system-level defenses against RowHammer.