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

1. Problem Statement

The RowHammer vulnerability in modern DRAM allows frequent accesses to an "aggressor" row to induce bit-flips in adjacent "victim" rows. As DRAM technology scales (e.g., DDR5), the RowHammer threshold ($T_{rh}$)—the number of activations required to cause a flip—has dropped drastically (from ~140K to ~500).

Existing mitigation techniques (e.g., Graphene, Twice, Hydra) rely on aggressor-centric tracking. They monitor the activation counts of aggressor rows and issue a Victim Row Refresh (VRR) when an aggressor hits a predefined tracking threshold ($T$). This approach suffers from three critical flaws:

1. Redundant Refreshes: They fail to account for the fact that a victim row might have been recently accessed (and thus refreshed) by other operations, or refreshed by a previous mitigation, leading to unnecessary VRR commands.
2. Inaccurate Thresholds: To prevent cumulative bit-flips from multiple aggressors affecting a single victim, existing methods drastically lower the tracking threshold ($T$) by a factor of $2^n$ (where $n$ is the blast radius). This conservative approach triggers mitigations far too frequently for benign workloads, causing significant performance degradation.
3. Inefficiency: Tracking only aggressors ignores the actual state of the victim, leading to high energy consumption and increased memory latency due to excessive refresh operations.

2. Methodology: RowHammer Vulnerability Counter (RVC)

The authors propose RVC, a paradigm shift from tracking aggressor activations to tracking victim vulnerability.

Core Mechanism

• Victim-Centric Counters: Instead of counting activations of the aggressor, RVC maintains a counter for every row representing its vulnerability.
• Access Logic:
  • When a row is accessed, its own counter is reset to 0 (simulating a refresh).
  • Simultaneously, the counters of all rows within the blast radius (adjacent rows) are incremented by 1.
• Mitigation Trigger: If a row's counter reaches the tracking threshold $T$, a refresh is issued only for that specific row.
• Selective VRR Command: To handle cases where multiple adjacent rows reach the threshold simultaneously, RVC introduces a new Selective VRR command. This command uses a bit-vector to instruct the DRAM to refresh only the specific rows indicated as vulnerable, rather than refreshing a fixed set of neighbors.

Threshold Determination

In traditional methods, the tracking threshold is calculated as $T < \frac{T_{rh}}{2(T-1) \cdot 2^n}$ to account for cumulative effects across refresh windows and blast radius.
In RVC, because the mechanism inherently tracks the cumulative effect on the victim (by incrementing victim counters directly), the division by $2^n$ becomes redundant. The formula simplifies to:
$$2(T - 1) < T_{rh}$$
This allows RVC to operate with a significantly higher tracking threshold (e.g., 2500 vs. 1250 for $T_{rh}=5000$), drastically reducing false positives.

Implementation Overhead

• Space: RVC uses the Misra-Gries algorithm for tracking. Due to the proportional scaling of the threshold and window size, the number of required tracker entries remains constant compared to existing methods.
• No Additional Overhead: The paper claims zero additional space overhead compared to state-of-the-art solutions like Graphene.

3. Key Contributions

1. Victim-Centric Tracking: A novel framework that evaluates a row's actual risk of bit-flips rather than inferring risk from aggressor activity.
2. Optimized Thresholding: Proving that prior works incorrectly set tracking thresholds, leading to security flaws or inefficiency. RVC derives a mathematically sound, higher threshold that maintains security without over-mitigating.
3. Selective VRR Command: A hardware mechanism to refresh only the specific rows at risk, eliminating the "blast radius" refresh waste.
4. Comprehensive Evaluation: Demonstrating that RVC outperforms Graphene (a state-of-the-art tracker) across energy, latency, and refresh metrics.

4. Evaluation Results

The authors evaluated RVC using Ramulator2 with a DDR5-16Gb configuration, comparing it against Graphene across various workloads (SPEC CPU2017 mixes) and blast radii ($n=1, 2, 4, 8$).

• Refresh Reduction: RVC achieved a 95–99.99% reduction in mitigation-induced refreshes compared to Graphene.
• Mitigation Commands: Reduced the number of VRR commands issued by 91.9% on average.
• Energy Efficiency:
  • VRR Energy: Reduced by >91.6%.
  • Total DRAM Energy: Reduced by an average of 8.5%.
• Performance (Latency):
  • LLC Latency: Improved by up to 76.91% (specifically at high blast radii and lower thresholds).
  • Throughput: Reduced contention in the DRAM bank, allowing faster servicing of memory requests.
• Scalability: As the blast radius increased (simulating future technology scaling), RVC's advantages became more pronounced, maintaining high efficiency where Graphene performance degraded significantly.

5. Significance

The RVC framework represents a fundamental rethinking of RowHammer mitigation. By shifting the focus from aggressor activity to victim vulnerability, it solves the inherent inefficiency of "refreshing rows that don't need it."

• Security: It provides robust protection against single-sided, double-sided, and multi-sided attacks without the security flaws caused by incorrect threshold settings in prior works.
• Efficiency: It addresses the critical trade-off between security and performance. As DRAM cells shrink and $T_{rh}$ drops, the cost of traditional mitigation (excessive refreshes) becomes prohibitive. RVC offers a scalable solution that ensures data integrity while minimizing the performance penalty, making it a superior candidate for future DDR5 and beyond memory systems.
• Future Potential: The paper suggests that RVC logic could eventually be embedded directly into DRAM (leveraging features like Per Row Activation Counting in DDR5) to further reduce latency and controller overhead.