PaperlayerView exact revision on arXiv

Source-linked AI summary

TRRespass: Exploiting the Many Sides of Target Row Refresh

Pietro Frigo, Emanuele Vannacci, Hasan Hassan, Victor van der Veen, Onur Mutlu, Cristiano Giuffrida, Herbert Bos, Kaveh Razavi

arXiv:2004.01807v1cs.CR

TL;DR

RowHammer remained insufficiently understood on modern TRR-protected DDR4 systems, whose advertised mitigation was treated as definitive despite limited disclosure of its implementation and security. The paper analyzes TRR across hardware layers and develops TRRespass, a scalable black-box fuzzer. It finds that many-sided, TRR-aware RowHammer can still trigger bit flips on modern DDR4 and LPDDR4(X) devices, including 13 of 42 tested DDR4 modules and 5 of 13 tested phones.

  • Problem

    The paper addresses the limited evidence about the implementation and security of TRR, which vendors advertised as eliminating RowHammer on newer DDR4 systems.

  • Method

    The paper analyzes memory-controller and in-DRAM TRR mechanisms, then uses the resulting insights to build TRRespass, a scalable black-box RowHammer fuzzer.

  • Results

    TRRespass identifies TRR-bypassing patterns on 13 of 42 tested DDR4 modules and 5 of 13 tested mobile phones, with many-sided RowHammer triggering bit flips across modern devices.

  • Takeaways & Limitations

    Modern TRR implementations do not eliminate RowHammer: TRR-aware access patterns can expose vulnerable DDR4 and LPDDR4(X) substrates to state-of-the-art attacks.

Abstract

from arXiv · show

After a plethora of high-profile RowHammer attacks, CPU and DRAM vendors scrambled to deliver what was meant to be the definitive hardware solution against the RowHammer problem: Target Row Refresh (TRR). A common belief among practitioners is that, for the latest generation of DDR4 systems that are protected by TRR, RowHammer is no longer an issue in practice. However, in reality, very little is known about TRR. In this paper, we demystify the inner workings of TRR and debunk its security guarantees. We show that what is advertised as a single mitigation mechanism is actually a series of different solutions coalesced under the umbrella term TRR. We inspect and disclose, via a deep analysis, different existing TRR solutions and demonstrate that modern implementations operate entirely inside DRAM chips. Despite the difficulties of analyzing in-DRAM mitigations, we describe novel techniques for gaining insights into the operation of these mitigation mechanisms. These insights allow us to build TRRespass, a scalable black-box RowHammer fuzzer. TRRespass shows that even the latest generation DDR4 chips with in-DRAM TRR, immune to all known RowHammer attacks, are often still vulnerable to new TRR-aware variants of RowHammer that we develop. In particular, TRRespass finds that, on modern DDR4 modules, RowHammer is still possible when many aggressor rows are used (as many as 19 in some cases), with a method we generally refer to as Many-sided RowHammer. Overall, our analysis shows that 13 out of the 42 modules from all three major DRAM vendors are vulnerable to our TRR-aware RowHammer access patterns, and thus one can still mount existing state-of-the-art RowHammer attacks. In addition to DDR4, we also experiment with LPDDR4 chips and show that they are susceptible to RowHammer bit flips too. Our results provide concrete evidence that the pursuit of better RowHammer mitigations must continue.

I. INTRODUCTION

TRRespass challenges the claim that TRR has solved RowHammer by showing that TRR comprises diverse, poorly documented mechanisms that can be bypassed on modern systems. Its black-box fuzzing identifies many-sided access patterns that trigger bit flips across contemporary DDR4 and LPDDR4(X) devices.

  • Results: With mitigations bypassed, DDR4 and LPDDR4(X) chips show bit flips after as few as 45K row activations, versus approximately 139K tolerated by cited DDR3 predecessors.The paper presents this as evidence that newer chips can be more vulnerable once their mitigation is disabled.
  • The many sides of TRR: TRR is an umbrella term for mechanisms implemented in memory controllers or inside DRAM chips, rather than one mitigation design.In-DRAM variants are poorly documented, leaving their security guarantees embedded in the chips.
  • TRRespass: TRRespass is a black-box fuzzer that identifies TRR-bypassing RowHammer access patterns without relying on controller or DRAM implementation details.The approach builds on analysis of different TRR mechanisms and generates many-sided hammering patterns.
  • Results: Many-sided RowHammer uses many aggressor rows to bypass most TRR variations and expose vulnerable DDR4 devices to bit flips.The identified patterns enable state-of-the-art RowHammer attacks on TRR-protected DDR4 and LPDDR4(X) chips.
  • Results: 13 of 42 tested DDR4 modules from Samsung, Micron, and Hynix yield effective TRR-bypassing patterns, alongside 5 of 13 tested mobile phones.The tested DDR4 vendors represent over 95% of the DRAM market.

II. ROWHAMMER ON DDR4: STILL A PROBLEM?

RowHammer exploits repeated activations of DRAM rows, motivating continued study of DDR4 systems whose organization and refresh behavior support data retention but do not by themselves establish immunity.

  • RowHammer on DDR4: Prior work systematically characterized RowHammer on DDR3, while comparatively little was known about its extent on recent DDR4 systems.The section frames DDR4 evaluation as necessary because earlier DDR4 reports involved earlier chip generations.
  • DRAM Organization: A DRAM channel can host multiple modules, whose chips form ranks operating in lockstep while receiving commands for different data portions.The memory controller issues requests to the corresponding channel.
  • DRAM Organization: Within a bank, rows share wordlines; activating a row loads its data into a row buffer, where it can be read or modified.The row decoder selects the row, and the row buffer contains sense amplifiers connected to bitlines.
  • DRAM Organization: DRAM cells store bits as electrical charge in capacitors, whose gradual charge loss requires periodic refresh, usually every 64 ms.Refresh prevents data loss as capacitors lose charge over time.

B. RowHammer

RowHammer exploits charge leakage in neighboring DRAM rows caused by repeatedly activating aggressor rows. Although standard patterns no longer produced bit flips on tested recent DDR4 modules, the paper investigates newer TRR-aware patterns.

  • RowHammer: RowHammer repeatedly activates aggressor rows, accelerating charge leakage in neighboring victim rows and potentially causing bit flips.Rows being hammered are aggressors; their neighbors are victims.
  • Attacks: RowHammer attacks have compromised kernels, cloud isolation, mobile devices, browsers, and networked server applications.These attacks can trigger bit flips using memory accesses, native code, JavaScript, or remote clients.
  • Defenses: Existing software defenses are complex, expensive, or incomplete, while increased refresh rates and ECC have proven ineffective or costly.Higher refresh rates also consume energy and delay data transfers.
  • DDR4: Towards a RowHammer-less landscape: 42 recent DDR4 modules were tested against standard hammering patterns because prior research had focused primarily on DDR3 and earlier DDR4 generations.The study also compares the DDR4 results with a prior DDR3 dataset.
  • DDR4: Towards a RowHammer-less landscape: None of the tested recent DDR4 modules showed bit flips under standard hammering patterns, matching vendor claims for known attacks.The result motivates asking whether RowHammer is actually solved.
  • Target Row Refresh: TRR is an umbrella term for distinct mitigations implemented in memory controllers or inside DRAM chips.The paper analyzes both implementation levels and finds that recent in-DRAM mitigations can be bypassed with targeted access patterns.
  • The many sides of TRR: The paper introduces TRRespass, a black-box fuzzer that generates many-sided RowHammer patterns without relying on implementation details.Many-sided RowHammer uses many aggressor rows to bypass differing TRR implementations.

A. TRR-compliant Memory

TRR-compliant memory exposes a Maximum Activate Count that memory controllers can use to select RowHammer defenses. Experiments show pTRR’s behavior on one supported system but limited deployment across tested Intel CPUs.

  • A. TRR-compliant Memory: The memory controller uses the module’s Maximum Activate Count to determine how many row activations neighboring rows can tolerate.The MAC is stored on the SPD chip and read during boot; modules exposing it are called TRR-compliant.
  • A. TRR-compliant Memory: JEDEC defines MAC as unlimited, untested, or a discrete activation limit such as 300K.Unlimited indicates a module claims to be RowHammer-free; untested indicates it was not inspected after production.
  • B. Intel pTRR Explained: Intel pTRR refreshes victim rows when DRAM activations exceed the MAC value, but it does not apply to modules with no usable MAC.The mechanism was introduced in the Ivy Bridge EP server family.
  • B. Intel pTRR Explained: With MAC set to untested, the Xeon E5-2620 v2 resorts to double refresh, visible as twice as many latency peaks.The peaks represent delays introduced by REFRESH commands.
  • B. Intel pTRR Explained: With MAC set to 400K, pTRR drastically reduces observed bit flips compared with MAC set to unlimited.The experiment varies discrete MAC values while hammering the same memory chunk.
  • B. Intel pTRR Explained: Six additional descendant Ivy Bridge Intel CPUs did not double refresh when MAC was untested, indicating no memory-controller RowHammer mitigation.The experiments covered both server and consumer lines; consumer systems also did not show pTRR behavior when MAC values varied.

C. Discussion

TRR implementations vary across platforms and vendors, with protections deployed in memory controllers or inside DRAM. The analysis models TRR through a sampler and inhibitor and tests how each operates.

  • Deployment: TRR mitigations appear only in specific Intel processor families, with server systems using memory-controller defenses while consumer systems generally rely on undocumented in-DRAM TRR.This deployment pattern is reported for both DDR3 and DDR4 platforms.
  • Implementation: TRR is a family of mechanisms implemented either in the CPU memory controller or directly in DRAM chips, rather than one uniform solution.Intel pTRR is an example of memory-controller-based protection, while newer DDR4 systems also use in-DRAM mechanisms.
  • Building blocks: The analysis abstracts TRR into two building blocks: a sampler that tracks hammered aggressor rows and an inhibitor that applies the mitigation.These abstractions support hypotheses about how different vendor implementations operate.
  • Hypotheses: The sampler may use fixed-frequency or per-row tracking, while the inhibitor may refresh victim rows or use row remapping.The proposed studies examine sampler size, tracking behavior, and inhibitor operation.
  • Research questions: The experiments ask how many aggressor rows the sampler can track, how it records activations, and how the inhibitor prevents bit flips.The inhibitor hypothesis places its operation at refresh time under DRAM timing constraints.

B. Case I: Module C12

Module C12 reveals that TRR acts on refresh commands but has limited ability to track and refresh multiple victim rows. Many-sided hammering can therefore overwhelm the mitigation.

  • Baseline vulnerability: 50K activations trigger bit flips on module C12 when refresh is disabled, establishing the module’s unmitigated activation threshold.The test uses double-sided RowHammer on a single DRAM bank.
  • Refresh behavior: 2,866 bit flips fall to one after one extra refresh and to zero after at least two, showing that TRR responds to every refresh command.This is the first case-study observation.
  • Sampler and inhibitor: TRR can sample more than one aggressor per refresh interval but refreshes only one victim within the tRFC operation.The mismatch leaves residual bit flips when multiple aggressors are hammered.
  • Many-sided RowHammer: More than 4 aggressor rows should bypass C12’s mitigation, and Figure 10 confirms that hammering 5 rows overwhelms it.Beyond 5 aggressors, bit flips decrease drastically, suggesting sampler-selection effects.

C. Case II: Module A15

Module A15 exposes additional TRR dependencies: sampling can depend on command order and row addresses. These dependencies complicate reproducing FPGA-discovered patterns on CPUs.

  • Refresh behavior: A15’s mitigation acts at every refresh command, corroborating the refresh-time behavior observed for module C12.The module is then evaluated as aggressor count varies under the default refresh rate.
  • Command order: The A15 sampler appears to record the first α activations after refresh, where α ≤6, indicating command-order dependence.Sampling is therefore tied to the position of activations within the refresh interval.
  • Address dependency: Particular dummy-row addresses produce more bit flips than random choices, suggesting address conflicts in the sampler’s activation-tracking design.The effect is observed when hammering two aggressor rows.
  • CPU reproduction: CPU execution yields far fewer bit flips than SoftMC because synchronizing activations with refresh commands is difficult under memory-controller request reordering.The comparison concerns the A15 access patterns derived from the controlled FPGA analysis.

E. Observations

The observations motivate TRRespass, a guided black-box fuzzer that varies aggressor count and location to discover TRR-aware access patterns without implementation details.

  • Motivation: CPU reproduction of controlled FPGA results is difficult, motivating a black-box test suite for generating effective access patterns on TRR-protected DDR4.The difficulty arises when translating simplified, controlled experiments to modern CPUs.
  • Design insights: TRRespass exploits the possibility that TRR samplers track only a limited number of aggressor rows, allowing sampler-table overflow.It also accounts for command-order, frequency, and row-address dependencies.
  • TRRespass: TRRespass is a guided black-box fuzzer that searches for RowHammer patterns without relying on memory-controller or DRAM implementation details.Its CPU-based approach evaluates patterns through software rather than requiring an FPGA memory controller.
  • Fuzzing strategy: The fuzzing strategy randomizes cardinality and location, representing the number and placement of hammered aggressor rows.These are the two explicit parameters used to generate access patterns.
  • Cardinality: At least 7 aggressor rows are required to observe bit flips in module A15, while excessive cardinality can become counterproductive.The fuzzer balances sampler overflow against the module’s activation limits.
  • Location: Randomizing aggressor locations increases the chance of bypassing address-dependent TRR and implicitly avoids fixed time-domain sampling features.The strategy varies distances between rows and access patterns.

B. TRRespass-ing over DDR4

TRRespass evaluates 42 DDR4 modules and discovers that many-sided hammering patterns can bypass TRR on a subset of them. The identified patterns vary across vendors and modules, while testing limitations prevent treating untriggered modules as immune.

  • Evaluation: 42 DDR4 modules were evaluated individually using TRRespass and related experiments.The set included modules from three major DRAM manufacturers, and each module was tested separately.
  • Many-sided RowHammer: Many-sided RowHammer generalizes assisted double-sided hammering by repeatedly accessing many aggressor rows in patterns named by their cardinality.Assisted double-sided hammering uses x −1, x + 1, and an additional row x + n; the broader class includes patterns such as 19-sided RowHammer.
  • Results: 13 of 42 TRR-protected modules yielded effective access patterns, with vulnerable modules exposing at least two patterns.Vendor B had vulnerable patterns on 4 of 12 modules, while vendor C had patterns on 2 of 14 modules, including 9-sided and 10-sided patterns.
  • Scalability: TRRespass automatically discovers successful patterns that can generate significant numbers of bit flips without requiring implementation details.The black-box approach is presented as especially useful where reproducing an optimal pattern manually is complex.
  • Caveat: The 13-of-42 result does not establish that the remaining modules are immune or that one vendor is more vulnerable than another.The testing was not exhaustive because of limited time and resources, and better strategies might find additional effective patterns.

C. TRRespass on LPDDR4(X)

The study extends TRRespass to LPDDR4(X) mobile devices and evaluates RowHammer bit flips across DDR4 modules. It finds vulnerability patterns on some mobile phones and substantial vendor- and generation-specific variation in DDR4 results.

  • LPDDR4(X) evaluation: A simplified ARMv8 version of TRRespass tested LPDDR4 and LPDDR4X chips in mobile phones under constrained privileges and resources.The mobile design drops the location parameter and instead maps a large memory region to find addresses in the same bank.
  • DDR4 evaluation: The DDR4 evaluation tests each module with its most bit-flip-inducing discovered pattern across a 256 MB contiguous physical-memory sweep.Bit flips are checked in both true and anti cells, covering 1 →0 and 0 →1 transitions.
  • LPDDR4(X) results: 5 of 13 tested mobile phones exhibited bit-flip-inducing RowHammer patterns.The LPDDR4(X) results are summarized for phones ordered by production date.
  • Vendor A: Vendor A had vulnerable patterns on 7 of 16 modules, averaging more than 16K bit flips across those modules.Modules A8 and A9 supported 19-sided RowHammer with approximately 45K activations per effective aggressor row within 64 ms, compared with approximately 139K or more on older DDR3.
  • Vendor B: Vendor B showed low bit-flip counts and iteration-dependent results, while multi-DIMM configurations often produced more flips.These observations suggest an additional parameter that TRRespass does not yet bypass.
  • Vendor C: Vendor C had effective patterns on 2 of 14 modules, with newer generations showing fewer flips and C13 performing multiple targeted refreshes per regular refresh.The authors state that recent chips remain vulnerable, but further research is needed to understand newer TRR mitigations and improve fuzzing strategies.

B. Increasing the Refresh Rate

The paper examines whether increasing the refresh rate strengthens in-DRAM TRR and whether many-sided patterns remain practically exploitable. New patterns still trigger bit flips, and the resulting exploits retain the overall structure of prior RowHammer attacks.

  • Increasing the refresh rate: Doubling or quadrupling refresh frequency was evaluated because in-DRAM TRR acts mainly at refresh time.More frequent refreshes could enforce TRR operations more often, but prior work found that double-refresh does not fully eliminate RowHammer.
  • Results: New hammering patterns triggered bit flips in three modules despite increased refresh operations.This result further undermines double refresh as a stopgap even when in-DRAM TRR is deployed.
  • Repeatability: Repeatability tests on modules A14, B1, and C13 found reliable repetition of many-sided bit flips, although multiple attempts and spurious flips can occur.The same bit flip may require repeated attempts before reappearing.
  • Exploitation workflow: Many-sided exploitation follows memory templating, memory massaging, and final triggering of the templated bit flips.Templating may require huge pages or side channels, memory massaging remains pattern-agnostic, and exploitation requires repeatable flips without spurious victim-page flips.
  • Practical exploitability: Once effective many-sided patterns are available, the authors report that real-world RowHammer attacks can be mounted on modern DDR4 systems in minutes.The framework is described as similar in spirit to existing state-of-the-art RowHammer attacks.

A. Exploitation on DDR4

The paper evaluates whether many-sided RowHammer patterns can support practical attacks on modern DDR4 systems. It applies established exploitation workflows and measures the time needed to find exploitable templates.

  • Example attacks: Three example attacks target page-table entries, RSA public keys, and the sudo binary using templated many-sided bit flips.The attacks respectively seek kernel privileges, access to a co-hosted virtual machine, and opcode modification.
  • Assumptions and evaluation: The exploitation workflow assumes that an attacker can use established memory-massaging techniques to place target data on vulnerable pages.Table IV reports results for the most and least vulnerable modules sampled from each vendor.
  • Timing: The study records τ as the time to template a single row, including row filling, hammering, and scanning.Many-sided RowHammer requires more templating time than previous RowHammer approaches.
  • Relation to prior work: Prior RowHammer patterns such as single-sided, double-sided, and one-location techniques are ineffective against modern DDR4 modules with in-DRAM mitigations.TRRespass instead uses many-sided patterns to bypass these mitigations.

APPENDIX A TRR-COMPLIANT MEMORY

TRR-compliant memory is characterized through SPD metadata and differs from pTRR compliance, which additionally requires a reserved-bit setting. The appendix also defines n-sided hammering patterns and shows that aggressor-pair distance affects effectiveness.

  • TRR-compliant memory: The SPD MAC field records a module’s RowHammer resiliency limits using MAC and tMAW values in its six least significant bits.MAC denotes Maximum Activate Count, while tMAW denotes Maximum Activate Window.
  • TRR-compliant memory: MAC values can indicate an untested module, unlimited limits, or discrete limits from 200K to 700K in 100K increments.The corresponding encodings are 0b0000, 0b1000, and 0b0001–0b0110, respectively.
  • TRR-compliant memory: pTRR requires SPD bit 7 to be set; otherwise the system treats the module as non-compliant regardless of its MAC and tMAW values.This requirement differs from the paper’s definition of TRR-compliant memory.
  • TRRespass-ing patterns: TRRespass defines ⟨n-sided | dist=d⟩ RowHammer by randomizing cardinality and distance across pairs of aggressor rows.Each pair is separated by one victim row, while d specifies the number of rows between aggressor-row pairs.
  • TRRespass-ing patterns: For module A10, ⟨10-sided | dist=D⟩ produces a varying number of bit flips as D changes, with the maximum at D = 12.The result indicates that distance between aggressor-row pairs plays a primary role in assembling an effective hammering pattern.
Loading 2004.01807v1…