- 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 (Trh​), 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: 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 Trh​ by $2n$ for a blast radius of n, 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: 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 T, 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)<Trh​, 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: Comparison of mitigation commands issued for Graphene and RVC across benchmarks.
Figure 4: Reduction in VRR commands issued under RVC.
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​=5000, VRR energy savings peak at 99.98%. Total energy improvement in DRAM is observable across workloads (Figures 8, 10).
Figure 6: Reduction in energy consumed due to selective, victim-centric VRR.
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: 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: Decrease in IPC ANTT, reflecting improved throughput.
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.