Skip to main content
QUICK REVIEW

[Paper Review] ABACuS: All-Bank Activation Counters for Scalable and Low Overhead RowHammer Mitigation

Ataberk Olgun|arXiv (Cornell University)|Oct 15, 2023
Security and Verification in Computing4 citations
TL;DR

ABACuS is a scalable, low-overhead RowHammer mitigation technique that uses a single shared activation counter per row ID across all DRAM banks to track row activations, significantly reducing area, performance, and energy overhead. It achieves 0.58% performance overhead and 1.66% energy overhead at a RowHammer threshold of 1000, while requiring 2.5× less chip area than the best prior low-area solution and 22.72× less area than the best performance-efficient alternative at a threshold of 125.

ABSTRACT

We introduce ABACuS, a new low-cost hardware-counter-based RowHammer mitigation technique that performance-, energy-, and area-efficiently scales with worsening RowHammer vulnerability. We observe that both benign workloads and RowHammer attacks tend to access DRAM rows with the same row address in multiple DRAM banks at around the same time. Based on this observation, ABACuS's key idea is to use a single shared row activation counter to track activations to the rows with the same row address in all DRAM banks. Unlike state-of-the-art RowHammer mitigation mechanisms that implement a separate row activation counter for each DRAM bank, ABACuS implements fewer counters (e.g., only one) to track an equal number of aggressor rows. Our evaluations show that ABACuS securely prevents RowHammer bitflips at low performance/energy overhead and low area cost. We compare ABACuS to four state-of-the-art mitigation mechanisms. At a near-future RowHammer threshold of 1000, ABACuS incurs only 0.58% (0.77%) performance and 1.66% (2.12%) DRAM energy overheads, averaged across 62 single-core (8-core) workloads, requiring only 9.47 KiB of storage per DRAM rank. At the RowHammer threshold of 1000, the best prior low-area-cost mitigation mechanism incurs 1.80% higher average performance overhead than ABACuS, while ABACuS requires 2.50X smaller chip area to implement. At a future RowHammer threshold of 125, ABACuS performs very similarly to (within 0.38% of the performance of) the best prior performance- and energy-efficient RowHammer mitigation mechanism while requiring 22.72X smaller chip area. ABACuS is freely and openly available at https://github.com/CMU-SAFARI/ABACuS.

Motivation & Objective

  • Address the growing challenge of RowHammer vulnerability in modern and future DRAM chips, where the RowHammer threshold (N_RH) has dropped to as low as 125, increasing the risk of bitflips.
  • Overcome the scalability limitations of existing counter-based RowHammer mitigation techniques, which incur high area and performance overheads as N_RH decreases and the number of DRAM banks increases.
  • Design a hardware mitigation that maintains low performance, energy, and area overheads even as DRAM becomes more vulnerable to RowHammer attacks.
  • Enable secure, scalable, and efficient RowHammer protection without relying on software or complex device-level modifications.

Proposed method

  • Propose a novel counter-based mechanism that uses a single shared activation counter per row ID to track activations across all DRAM banks, rather than maintaining separate counters per bank.
  • Leverage the observation that both benign workloads and RowHammer attacks frequently access the same row address across multiple banks simultaneously due to memory interleaving and spatial locality.
  • Use the shared counter to detect when a row with a given row ID approaches the RowHammer threshold, triggering preventive refresh or access blocking.
  • Integrate the counter logic into the DRAM controller or memory controller, minimizing changes to existing memory subsystems.
  • Ensure the mechanism scales efficiently with increasing DRAM bank counts and decreasing RowHammer thresholds.
  • Design the system to minimize area cost by drastically reducing the number of required counters—only one per unique row ID, regardless of the number of banks.
Figure 1 : DRAM organization (a), timing parameters (b), and RowHammer (c)
Figure 1 : DRAM organization (a), timing parameters (b), and RowHammer (c)

Experimental results

Research questions

  • RQ1Can a shared activation counter across all DRAM banks effectively detect RowHammer aggressor rows without sacrificing security or performance?
  • RQ2How does the performance, energy, and area overhead of ABACuS compare to existing counter-based RowHammer mitigation techniques at low RowHammer thresholds?
  • RQ3To what extent does ABACuS scale with increasing DRAM bank counts and worsening RowHammer vulnerability (i.e., lower N_RH)?
  • RQ4Can ABACuS achieve comparable or better security and efficiency to state-of-the-art mechanisms while using significantly less chip area?

Key findings

  • At a RowHammer threshold of 1000, ABACuS incurs only 0.58% (single-core) and 0.77% (8-core) performance overhead, with 1.66% and 2.12% DRAM energy overhead, respectively.
  • ABACuS requires only 9.47 KiB of storage per DRAM rank, achieving 2.5× smaller chip area than the best prior low-area mitigation mechanism at the same threshold.
  • At a future RowHammer threshold of 125, ABACuS performs within 0.38% of the best prior performance- and energy-efficient mechanism while requiring 22.72× less chip area.
  • For 16-, 32-, and 64-bank systems at N_RH = 125, ABACuS incurs 1.58%, 1.50%, and 2.60% performance overhead across all 62 single-core workloads, respectively, demonstrating strong scalability.
  • ABACuS maintains low overhead across diverse workloads and scales efficiently with increasing bank counts, making it suitable for future high-bandwidth, high-capacity DRAM systems.
  • The technique is freely available on GitHub and can be combined with integrity-based mechanisms for enhanced system reliability.
Figure 2 : Number of sibling rows activated before one sibling row is activated again, averaged across all DRAM row activations for each simulated workload and RowHammer attack (x-axis).
Figure 2 : Number of sibling rows activated before one sibling row is activated again, averaged across all DRAM row activations for each simulated workload and RowHammer attack (x-axis).

Better researchstarts right now

From reading papers to final review, dramatically reduce your research time.

No credit card · Free plan available

This review was created by AI and reviewed by human editors.