Papers
Topics
Authors
Recent
Search
2000 character limit reached

RowHammer Vulnerability Counter (RVC): Redefining RowHammer Detection with Victim-Centric Tracking

Published 27 Apr 2026 in cs.CR and cs.AR | (2604.24287v1)

Abstract: The Rowhammer vulnerability poses an increasing challenge with newer generations of DRAM and aggressive technology scaling. Existing mitigation techniques, such as Graphene, Twice, and Hydra, primarily rely on tracking activation counts for each row and issuing refreshes when a row reaches a predefined tracking threshold. However, these methods have inherent limitations, including inefficiencies in identifying rows genuinely at risk of bit flips. In this paper, we propose a novel framework called Rowhammer Vulnerability Count (RVC), which shifts the focus from activation count tracking to evaluating a row's actual vulnerability to bit flips. By selectively issuing refreshes only to rows on the verge of experiencing bit flips, RVC drastically reduces unnecessary refresh operations. We also demonstrate that prior works have incorrectly set tracking thresholds, leading to security flaws. Our evaluation shows that RVC achieves 95 - 99.99% improvement in mitigation induced refreshes when compared to Graphene, with no additional space overhead. Furthermore, RVC improves energy efficiency and reduces average LLC latency by up to 76.91%, making it a highly efficient and scalable solution for addressing Rowhammer in modern DRAM systems. These findings establish RVC as a superior approach for preventing Rowhammer, outperforming existing methods in both accuracy and efficiency.

Summary

  • The paper introduces a victim-centric approach (RVC) that counters RowHammer by tracking vulnerability of victim rows rather than aggressor counts.
  • It significantly reduces redundant refreshes and mitigation commands, achieving over 91% improvement compared to traditional methods.
  • Experimental evaluations demonstrate substantial energy, latency, and throughput gains across varying DRAM configurations and blast radii.

Rowhammer Vulnerability Counter (RVC): A Victim-Centric Paradigm for RowHammer Mitigation

Motivation and Limitations of Aggressor-Based Tracking

Aggressive scaling of DRAM technology has resulted in decreased RowHammer thresholds (TrhT_{rh}), making memory increasingly susceptible to disturbance-induced bit-flips, even from benign activation patterns. Classical RowHammer mitigation schemes—including Graphene, Hydra, and RowHammerCache—utilize aggressor row activation-count tracking and trigger blanket Victim Row Refresh (VRR) commands when a row surpasses a fixed threshold. These approaches suffer from several critical drawbacks:

  • Redundant Refreshes and Security Flaws: Aggressor tracking can lead to refreshing rows that are either recently accessed (and thus inherently refreshed) or recently mitigated, incurring unnecessary overhead (Figure 1). This inefficiency is particularly acute when victim rows are shared among multiple aggressors or have been refreshed due to an unrelated previous trigger. Figure 1

    Figure 1: Problems in Aggressor Activation Count Tracking with VRR Rowhammer Mitigation: redundant refresh of recently refreshed and recently accessed rows.

  • Incorrect Threshold Calculation: Conventional tracking must conservatively lower TrhT_{rh} by $2n$ for a blast radius of nn, to account for cumulative disturbance on a common victim, resulting in overly frequent mitigations that degrade performance, especially for benign workloads (Figure 2). Figure 2

    Figure 2: Cumulative effect on a victim by accessing adjacent rows; critical in threshold determination for multi-aggressor scenarios.

These architectural inefficiencies reveal fundamental flaws in aggressor-centric designs, necessitating a paradigm shift toward victim-centric row vulnerability assessment.

RVC: The Victim-Centric RowHammer Vulnerability Counter

RVC proposes tracking the disturbance exposure of victim rows directly. Instead of solely monitoring aggressor row activations, RVC maintains vulnerability counters for each victim row, incremented whenever adjacent rows are activated within the blast radius. Upon direct access to any row, its vulnerability counter is reset, as such access equates to a local refresh.

RVC Operation

  • Initialization / Refresh Interval: All victim counters reset to zero.
  • Row Access: Counter for accessed row reset to zero; counters of adjacent rows within the blast radius incremented by one.
  • Selective Mitigation: When any row’s vulnerability counter meets threshold TT, a selective VRR is issued for that row only, mediated via a blast-radius-sized bit vector. This selective VRR avoids unnecessary refreshes on robust rows, minimizing both energy and performance penalties.

Through this targeted intervention, RVC provides robust protection against single-sided, double-sided, and multi-sided RowHammer attack scenarios while drastically reducing mitigation overhead.

Threshold Calculation: Eliminating Conservative Reductions

Unlike aggressor-based tracking, RVC’s cumulative accounting renders division by $2n$ redundant. The simplified threshold constraint, 2(T−1)<Trh2(T-1) < T_{rh}, directly bounds cumulative disturbance, allowing higher tracking thresholds and further reducing false positive mitigations. This accurate modeling ensures only truly vulnerable rows are targeted, optimizing efficiency and security.

Experimental Evaluation and Quantitative Results

RVC was evaluated using Ramulator2 with DDR5 configurations, supporting diverse workload mixes and varying blast radii. The experimental results demonstrate superior quantitative metrics across all axes when compared to the state-of-the-art Graphene tracker.

  • Mitigation Commands and DRAM Refreshes: Average reduction in mitigations issued exceeds 91.3%, with VRR-triggered refreshes reduced by 92.3% (Figures 3, 4, 6). Figure 3

Figure 3

Figure 3

Figure 3

Figure 3

Figure 3: Comparison of mitigation commands issued for Graphene and RVC across benchmarks.

Figure 4

Figure 4: Reduction in VRR commands issued under RVC.

Figure 5

Figure 5: Percentage reduction in overall refreshes with RVC.

  • Energy Consumption: VRR-induced energy drops by 91.3%, yielding a total DRAM energy reduction of 4% on average for typical thresholds; at Trh=5000T_{rh}=5000, VRR energy savings peak at 99.98%. Total energy improvement in DRAM is observable across workloads (Figures 8, 10). Figure 6

    Figure 6: Reduction in energy consumed due to selective, victim-centric VRR.

    Figure 7

    Figure 7: Percentage improvement in total DRAM energy.

  • Latency and Throughput: LLC latency improves by 5.5%–76.92% (blast radius-dependent), corroborating the performance gains of victim-centric selective refreshing (Figure 8). Figure 8

    Figure 8: Reduction in average LLC latency owing to minimized contention by RVC.

  • IPC Impacts: Weighted IPC and STP are significantly improved, with IPC ANTT and STP reductions shown in Figures 5 and 9. Figure 9

    Figure 9: Decrease in IPC ANTT, reflecting improved throughput.

    Figure 10

    Figure 10: Percentage reduction in IPC STP (lower is better).

Blast Radius Scaling

As blast radius increases, RVC’s efficiency advantage over Graphene and similar trackers is amplified, with up to 99.99% reductions in refreshes and mitigations for large blast radii. This scalability is crucial as future DRAM generations further lower disturbance thresholds and increase the vulnerability window.

Practical and Theoretical Implications

RVC fundamentally redefines RowHammer mitigation by targeting actual victim row vulnerability. This approach directly addresses the limitations of aggressor-based frameworks, eliminating threshold miscalculations and reducing unnecessary system interventions. RVC is intrinsically scalable, requires no additional area overhead, and adapts efficiently to DRAM technologies with larger blast radii or ultra-low thresholds.

From a practical standpoint, embedding RVC within DRAM modules—potentially leveraging DDR5’s Per Row Activation Counting (PRAC)—could facilitate hardware-native mitigation with minimal runtime overhead. Theoretically, RVC reframes RowHammer tracking as an optimization problem targeting actual risk exposure, not proxy event counts, opening avenues for more precise counter design and new architectural defense mechanisms.

Conclusions

The RowHammer Vulnerability Counter (RVC) provides a victim-centric mitigation paradigm that consistently outperforms aggressor-based tracking in both security and efficiency metrics (2604.24287). Rigorous evaluation across varying thresholds and blast radii demonstrates substantial reductions in mitigation overhead, energy consumption, and latency. RVC adapts seamlessly to future scaling trends, maintaining robust memory integrity with minimal performance impact. Future work may explore direct DRAM integration of RVC, further reducing latency and overhead and setting new standards for RowHammer defense.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.