PaperlayerView exact revision on arXiv

Source-linked AI summary

BlockHammer: Preventing RowHammer at Low Cost by Blacklisting Rapidly-Accessed DRAM Rows

Abdullah Giray Yağlıkçı, Minesh Patel, Jeremie S. Kim, Roknoddin Azizi, Ataberk Olgun, Lois Orosa, Hasan Hassan, Jisung Park, Konstantinos Kanellopoulos, Taha Shahroodi, Saugata Ghose, Onur Mutlu

arXiv:2102.05981v2cs.CRcs.AR

TL;DR

RowHammer is an increasingly serious DRAM reliability and security problem, while existing mitigations face rising overheads and compatibility constraints. BlockHammer uses Bloom-filter tracking and proactive throttling within the memory controller to prevent risky activation rates without modifying DRAM internals. It provides low overhead for benign workloads, identifies attackers accurately, and improves co-running benign-application performance under attack.

  • Problem

    Increasing DRAM vulnerability makes RowHammer bit-flips and related privilege-escalation or data-leak attacks harder to mitigate without rising performance, area, or compatibility costs.

  • Method

    BlockHammer uses area-efficient Bloom filters to track row activation rates and proactively throttle accesses that could induce RowHammer bit-flips, entirely within the memory controller.

  • Results

    BlockHammer guarantees RowHammer-safe operation with 0.06% area, 0.7% performance, and 0.6% DRAM energy overheads for benign workloads, while achieving 99.98% attacker-identification accuracy and 45.0% average improvement for co-running benign applications under attack.

  • Takeaways & Limitations

    BlockHammer is the only one of 14 examined mechanisms satisfying comprehensive threat coverage, commodity compatibility, efficient scaling, and deterministic prevention.

  • Takeaways & Limitations

    Supporting worst-case observed DRAM characteristics requires configuring NRH* to 0.2539×NRH, while double-sided attacks use NRH* equal to half of NRH.

Abstract

from arXiv · show

Aggressive memory density scaling causes modern DRAM devices to suffer from RowHammer, a phenomenon where rapidly activating a DRAM row can cause bit-flips in physically-nearby rows. Recent studies demonstrate that modern DRAM chips, including chips previously marketed as RowHammer-safe, are even more vulnerable to RowHammer than older chips. Many works show that attackers can exploit RowHammer bit-flips to reliably mount system-level attacks to escalate privilege and leak private data. Therefore, it is critical to ensure RowHammer-safe operation on all DRAM-based systems. Unfortunately, state-of-the-art RowHammer mitigation mechanisms face two major challenges. First, they incur increasingly higher performance and/or area overheads when applied to more vulnerable DRAM chips. Second, they require either proprietary information about or modifications to the DRAM chip design. In this paper, we show that it is possible to efficiently and scalably prevent RowHammer bit-flips without knowledge of or modification to DRAM internals. We introduce BlockHammer, a low-cost, effective, and easy-to-adopt RowHammer mitigation mechanism that overcomes the two key challenges by selectively throttling memory accesses that could otherwise cause RowHammer bit-flips. The key idea of BlockHammer is to (1) track row activation rates using area-efficient Bloom filters and (2) use the tracking data to ensure that no row is ever activated rapidly enough to induce RowHammer bit-flips. By doing so, BlockHammer (1) makes it impossible for a RowHammer bit-flip to occur and (2) greatly reduces a RowHammer attack's impact on the performance of co-running benign applications. Compared to state-of-the-art RowHammer mitigation mechanisms, BlockHammer provides competitive performance and energy when the system is not under a RowHammer attack and significantly better performance and energy when the system is under attack.

1. Introduction

RowHammer is worsening as denser DRAM becomes less reliable, while existing mitigations face rising overheads and compatibility barriers. BlockHammer addresses these challenges by tracking activation rates and selectively throttling risky accesses.

  • Motivation: Denser DRAM cells and spacing improve cost-per-bit but reduce reliability, making RowHammer increasingly serious for current and future chips.Rapidly activating an aggressor row can flip bits in nearby victim rows, enabling privilege escalation and private-data leaks.
  • Motivation: Commodity DDR3, DDR4, and LPDDR4 chips remain vulnerable despite in-DRAM mitigations, including target row refresh.TR-Resspass demonstrated reliable bit-flips by circumventing existing in-DRAM mechanisms.
  • Challenges: Existing mitigation approaches face increasing performance or area costs as RowHammer vulnerability worsens and may require proprietary DRAM mappings or chip modifications.The main approaches include increased refresh, physical isolation, reactive refresh, and proactive throttling.
  • BlockHammer: BlockHammer tracks row activation rates with area-efficient Bloom filters and selectively throttles accesses within the memory controller, requiring no DRAM-internal knowledge or modification.Its design goal is to scale with worsening vulnerability while remaining compatible with commodity DRAM chips.
  • Evaluation: 0.06% area, 0.7% performance, and 0.6% DRAM energy overheads were measured for benign workloads under a realistic 32K-activation threshold.Under attack, BlockHammer identified and throttled attacker activations with 99.98% accuracy, improving concurrently running benign-application performance by 45.0% on average.
  • Evaluation: Among 14 examined mitigation mechanisms, BlockHammer was the only one satisfying comprehensive threat coverage, commodity compatibility, efficient scaling, and deterministic prevention.The comparison evaluates four properties identified as necessary for a low-cost, effective, and easy-to-adopt mechanism.

2. Background

This section introduces DRAM organization and RowHammer, then explains BlockHammer’s RowBlocker and AttackThrottler components for preventing unsafe activation rates and reducing attack impact.

  • DRAM Organization: DRAM stores bits in capacitor-based cells arranged into banks, which are accessed through rows, columns, row buffers, ranks, channels, and a memory controller.Cells require periodic refresh because their charge leaks over time; only one row per bank can be accessed at a time.
  • RowHammer: RowHammer repeatedly activates an aggressor row until disturbance induces bit-flips in nearby victim rows after a threshold within a refresh window.The threshold is denoted NRH and is also called MAC or HCfirst in prior work.
  • BlockHammer Overview: BlockHammer combines RowBlocker, which proactively throttles unsafe row activations, with AttackThrottler, which limits bandwidth consumed by suspicious threads.The design targets efficient scaling and compatibility with commodity DRAM chips.
  • RowBlocker: RowBlocker blacklists rows exceeding NBL and delays consecutive activations only for blacklisted, recently activated rows to reduce benign-app throttling.It uses per-bank RowBlocker-BL and a per-rank RowBlocker-HB history buffer.
  • RowBlocker: Counting Bloom filters track row activation rates with lower area cost, while two time-interleaved filters cover large windows without losing rows that should be blacklisted.A Bloom filter tests set membership using hash functions and a bit array; RowBlocker-BL uses two filters to avoid stale blacklists.
  • AttackThrottler: AttackThrottler uses RHLI, the normalized count of blacklisted-row activations for each thread-bank pair, to identify attack-like access patterns.RHLI is bounded by 1 in a BlockHammer-protected system and supports throttling attacker bandwidth.

4. Many-Sided RowHammer Attacks

Many-sided attacks exploit cumulative disturbance from multiple aggressor rows, so BlockHammer conservatively lowers its activation threshold using distance-dependent effects.

  • Attack Model: Many-sided attacks can induce bit-flips by cumulatively hammering multiple rows whose disturbance reaches beyond immediately adjacent rows.Prior characterization reports that impact decreases with physical distance and can disappear after about six rows.
  • Threshold Adjustment: BlockHammer reduces NRH to NRH* so simultaneous hammering of multiple rows remains no more harmful than hammering one immediately adjacent row NRH times.The adjustment sums each aggressor’s distance-weighted effect on the victim row.
  • Threshold Adjustment: For worst-case modern-chip characteristics, rblast = 6 and ck = 0.5k–1 yield NRH* = 0.2539×NRH.These values are based on characterization studies of more than 1500 real DRAM chips from 2010 to 2020.
  • Configuration: For double-sided attacks, BlockHammer sets NRH* to half of NRH by using rblast = 1 and ck = 1.Table 1 gives example parameters for commodity DDR4 and a 32K RowHammer threshold.

5. Security Analysis

BlockHammer’s security analysis bounds aggressor-row activations across dependent epoch types and proves that no access pattern can exceed the RowHammer threshold within a refresh window.

  • Proof strategy: The proof by contradiction assumes an access pattern exceeds NRH, models all row-activation distributions, and shows the resulting constraints are impossible.The analysis represents a successful attack as a permutation of epoch types and derives necessary constraints on their counts.
  • Epoch analysis: Five epoch types span possible access patterns using previous- and current-epoch activation counts, with Nepmax bounding current-epoch activations.Epoch types are defined by Nep–1 and Nep; Nepmax is the maximum possible Nep.
  • Epoch analysis: T0, T1, and T3 epochs bound activation counts below their blacklisting thresholds, while T4 remains blacklisted across consecutive epochs.T4 permits at most one activation per tDelay window, whereas T3 is blacklisted only in the current epoch.
  • Attack constraints: Consecutive epoch types are dependent, restricting which epoch types can precede one another in a hypothetical attack sequence.The dependency follows because epoch types use activation counts from both the previous and current epochs.
  • Security guarantee: No combination of epoch counts satisfies the necessary attack constraints, so no access pattern can activate an aggressor row more than NRH times within a refresh window.An analytical solver finds no feasible set of ni values for the BlockHammer configuration.

6. Hardware Complexity Analysis

The hardware analysis evaluates BlockHammer’s physical costs and latency against prior mitigations, including how area overhead scales as RowHammer thresholds decrease.

  • Evaluation setup: BlockHammer’s area, static power, access energy, and latency are evaluated using circuit models, CACTI, and Synopsys DC against state-of-the-art mechanisms.The comparison includes six prior RowHammer mitigation mechanisms and considers thresholds of 32K and 1K.
  • Design components: BlockHammer combines RowBlocker and AttackThrottler, with RowBlocker using dual counting Bloom filters and supporting hardware for row tracking.The mechanisms are organized per DRAM bank in the hardware design.
  • Area comparison: Graphene has larger area overhead per metadata byte because it is fully implemented with CAM logic, whereas probabilistic mechanisms avoid kilobytes of activation-rate metadata.The probabilistic mechanisms identified are PARA, PRoHIT, and MRLoc.
  • Scaling analysis: At a 1K RowHammer threshold, BlockHammer consumes 1.57 mm2, while TWiCe’s and CBT’s area overheads reach 3.3x and 2.5x BlockHammer’s, respectively.The analysis concludes that BlockHammer scales better in area overhead than TWiCe and CBT as the threshold decreases.
  • Latency: BlockHammer answers an RowHammer-safety query in 0.97 ns, far below the 45–50 ns row-access latency of representative DRAM standards.The RTL model indicates that this latency can be hidden because it is one-to-two orders of magnitude smaller.

7. Experimental Methodology

The experiments compare BlockHammer with six prior safe mechanisms using cycle-level DDR4 simulations across benign and double-sided RowHammer workloads.

  • Evaluation framework: The evaluation uses Ramulator for performance and DRAMPower for DRAM energy, with an open-source infrastructure implementing BlockHammer and six prior mechanisms.The simulated system is a typical DDR4-based memory subsystem.
  • Attack model: The attack model uses double-sided RowHammer attacks, with BlockHammer’s threshold set to NRH* = NRH/2 to account for cumulative disturbance from both aggressor rows.The study uses NRH* = 16K when NRH = 32K and scales NRH across thresholds above 1K in a later study.
  • Baselines: Comparisons include a no-mitigation baseline, three probabilistic mechanisms, and three deterministic mechanisms that provide RowHammer-safe operation.The mechanisms are evaluated under the same attack model used by prior work.
  • Workloads: The workload suite contains SPEC CPU2006, YCSB disk-I/O, commercial network-I/O, and synthetic non-temporal-copy applications categorized by row-buffer conflicts per kilo instruction.Applications are grouped into L, M, and H categories according to RBCPKI.
  • Workloads: The study simulates 125 eight-benign-thread workloads and 125 workloads with one RowHammer attack plus seven benign threads.Each workload runs until every benign thread executes at least 200 million instructions after a 100-million-instruction cache warmup.

8. Performance and Energy Evaluation

BlockHammer incurs minimal overhead on benign workloads and improves performance and DRAM energy consumption under RowHammer attacks. Its benefits persist as DRAM becomes more vulnerable, while its low false-positive rate limits latency impact.

  • Single-Core Applications: BlockHammer introduces no performance or DRAM energy overheads for benign single-core applications.Benign applications do not exceed BlockHammer’s blacklisting threshold.
  • Multiprogrammed Workloads: Less than 0.5%, 0.6%, and 1.2% overhead occurs in weighted speedup, harmonic speedup, and maximum slowdown, respectively, for multiprogrammed workloads without attacks.These values are measured against a baseline without RowHammer mitigation.
  • Multiprogrammed Workloads: 45.0% and 56.2% average increases in weighted and harmonic speedups accompany a 22.7% decrease in maximum slowdown under attack.Maximum improvements reach 61.9%, 73.4%, and 45.4%, respectively.
  • Multiprogrammed Workloads: 28.9% average DRAM energy reduction under attack contrasts with increases of up to 0.4% for other state-of-the-art mechanisms.Throttling raises row-buffer hit rate by 177% on average and converts 23% of row-buffer conflicts to misses.
  • Worsening RowHammer Vulnerability: At NRH=1024, BlockHammer’s average performance and DRAM energy overheads remain below 0.6% without attack, while PARA incurs 21.2% and 22.3% weighted and harmonic speedup overheads and 5.1% energy overhead.Under attack, BlockHammer improves average weighted and harmonic speedups by 71.0% and 83.9%, while reducing maximum slowdown and DRAM energy by 30.4% and 32.4%.
  • Overhead Analysis: BlockHammer has a 0.012% false-positive rate and microsecond-scale worst-case latency, at least two orders of magnitude below typical millisecond-scale quality-of-service targets.Its impact depends on Bloom-filter false positives and the penalty for delaying activations.

9. Comparison of Mitigation Mechanisms

The paper compares RowHammer mitigations across four architectural approaches and four evaluation dimensions. Table 6 summarizes this qualitative comparison.

  • Approaches: The mechanisms are classified as increased refresh rate, physical isolation, reactive refresh, and proactive throttling.These are the paper’s four high-level mitigation approaches.
  • Evaluation Dimensions: The comparison evaluates comprehensive protection, compatibility with commodity DRAM chips, scaling with RowHammer vulnerability, and deterministic protection.These dimensions frame the qualitative assessment.
  • Qualitative Comparison: Table 6 summarizes the qualitative evaluation of RowHammer mitigation mechanisms.The table covers the four approaches and evaluation dimensions described in the text.

1. Comprehensive Protection.

Comprehensive protection requires preventing all potential RowHammer bit-flips regardless of how an attacker hammers DRAM rows. Several existing mechanisms are effective only against limited threat models and have been defeated by recent attacks.

  • Comprehensive Protection: A comprehensive RowHammer mitigation mechanism should prevent all potential bit-flips regardless of the attacker’s hammering method.This requirement defines the paper’s comprehensive-protection criterion.
  • Limitations: Four key mitigation mechanisms are effective only against a limited threat model.The passage identifies this as a deficiency in comprehensive protection.
  • Limitations: Recent attacks have already defeated four key mitigation mechanisms.The cited reasons include trusting system components that can be used to perform RowHammer attacks.

2. Compatibility with Commodity DRAM Chips.

Compatibility with commodity DRAM is important because recent experiments observe RowHammer bit-flips in cutting-edge chips, including chips marketed as RowHammer-free. Compatible mechanisms must avoid vendor-proprietary information and chip-design modifications.

  • Motivation: Recent experiments observe RowHammer bit-flips in cutting-edge commodity DRAM chips, including chips marketed as RowHammer-free.This motivates compatibility with current and future commodity DRAM chips.
  • Requirements: A compatible mitigation mechanism should not rely on proprietary information that DRAM vendors do not share.The requirement applies to compatibility with commodity DRAM chips.
  • Requirements: A compatible mitigation mechanism should not require modifications to DRAM chip design.This is the second compatibility requirement stated in the passage.

3. Scaling with Increasing RowHammer Vulnerability.

As RowHammer vulnerability worsens, existing mitigations become increasingly costly because they require more aggressive throttling, more tracking, or greater memory reservation. BlockHammer is presented as an efficient and scalable proactive-throttling alternative.

  • Scaling Challenge: More vulnerable DRAM requires more aggressive throttling, which can impose prohibitive performance or area overheads when benign accesses are also throttled or all rows are tracked.These costs motivate mechanisms that scale efficiently with worsening vulnerability.
  • Existing Mitigation Costs: 78% average performance overhead makes increased refresh rate prohibitively expensive for DRAM with a 32K RowHammer threshold.The overhead results from refreshing rows frequently enough to prevent bit-flips.
  • Existing Mitigation Costs: Physical isolation can reserve up to 12 rows, reducing secure memory capacity as the blast radius increases.The required reservation is twice the blast radius, which increased by 33% from 2014 to 2020.
  • Existing Mitigation Costs: Reactive refresh mechanisms incur increasing performance, energy, and/or area overheads at lower RowHammer thresholds.For example, ANVIL’s millisecond-scale sampling must become much faster when attacks induce bit-flips in under 50 µs at a 1K threshold.
  • Proactive Throttling: Naïve proactive throttling either needs a counter for every DRAM row or prohibitively increases tRC by 42.2x/1350.4x for NRH=32K/1K.BlockHammer is identified as the first efficient and scalable proactive throttling-based prevention technique.

4. Deterministic Prevention.

Deterministic mitigation must guarantee RowHammer-safe operation at all times, rather than merely reducing attack probability. BlockHammer provides this guarantee by preventing any row from being activated at an unsafe rate.

  • Deterministic Guarantee: Deterministic mitigation ensures RowHammer-safe operation at all times and eliminates the probability of a successful RowHammer attack.This property is important for critical systems where security failures can have severe consequences.
  • BlockHammer: BlockHammer guarantees that no row can be activated at a RowHammer-unsafe rate.The paper contrasts this zero-probability capability with probabilistic mechanisms such as PARA, ProHIT, and MRLoc.

10. Related Work

Related work places BlockHammer among RowHammer mitigations that aim to prevent bit-flips without proprietary DRAM knowledge or modification. The paper claims BlockHammer uniquely combines these properties with improved performance and energy under attack.

  • Comparison with Prior Work: BlockHammer is claimed to prevent RowHammer bit-flips efficiently and scalably without proprietary DRAM knowledge or modifications.The paper presents this as a distinguishing property among examined mitigation mechanisms.
  • Comparison with Prior Work: BlockHammer is claimed to satisfy all four desired characteristics for a RowHammer mitigation mechanism.Those characteristics are discussed elsewhere in the paper’s comparison of prior mechanisms.
  • In-DRAM Reactive Refresh: Target row refresh refreshes rows physically near an aggressor without exposing in-DRAM row-address mapping outside the DRAM chip.TRRespass is cited as demonstrating that existing proprietary in-DRAM mitigation can be circumvented.
  • Under-Attack Behavior: BlockHammer improves benign application performance and system energy when the system is under a RowHammer attack.Its source code is made freely and openly available for further research and development.
  • BlockHammer Approach: BlockHammer uses area-efficient Bloom filters to track row activations and proactively throttle accesses that could induce bit-flips.The mechanism operates entirely within the memory controller.

A. Appendix Tables

The appendix tables document BlockHammer configuration parameters for different RowHammer thresholds and list the benign applications used in cycle-level simulations.

  • Configuration Parameters: Table 7 lists BlockHammer’s configuration parameters for different NRH values.The parameters are used in the paper’s area and simulation evaluations.
  • Simulation Workloads: Table 8 lists the benign applications used in cycle-level simulations.
Loading 2102.05981v2…