PaperlayerView exact revision on arXiv

Source-linked AI summary

RowPress: Amplifying Read Disturbance in Modern DRAM Chips

Haocong Luo, Ataberk Olgun, A. Giray Yağlıkçı, Yahya Can Tuğrul, Steve Rhyner, Meryem Banu Cavlak, Joël Lindegger, Mohammad Sadrosadati, Onur Mutlu

arXiv:2306.17061v5cs.CRcs.AR

TL;DR

Read disturbance in DRAM can break memory isolation, but the effects of keeping a row open for a long time require characterization. The paper experimentally studies RowPress in 164 DDR4 chips and evaluates its implications and mitigations. RowPress sharply reduces the activations needed for bitflips, and the authors report a mitigation approach with low additional performance overhead.

  • Problem

    Read disturbance can break memory isolation, and the effects of increased aggressor-row on-time require rigorous characterization.

    Source: §1 · p. 1, §2.4 · p. 3

  • Method

    The authors characterize RowPress in real DRAM chips, demonstrate it on a DDR4 system, and evaluate adaptations of existing read-disturb mitigations.

    Source: §1 · p. 2, §9 · p. 16

  • Results

    At tAggON = 7.8 µs, RowPress reduces ACmin by 17.6× on average (up to 40.7×); at 70.2 µs, it reduces ACmin by 159.4× on average (up to 363.8×).

    Source: §1 · p. 2

  • Takeaways & Limitations

    The authors conclude that existing read-disturb mitigations can be adapted to protect against RowPress with low additional performance overhead.

    Source: §9 · p. 16

    Existing device-level studies do not fully explain RowPress, motivating further device-level research.

    Source: §5.4 · p. 11

Abstract

from arXiv · show

Memory isolation is critical for system reliability, security, and safety. Unfortunately, read disturbance can break memory isolation in modern DRAM chips. For example, RowHammer is a well-studied read-disturb phenomenon where repeatedly opening and closing (i.e., hammering) a DRAM row many times causes bitflips in physically nearby rows. This paper experimentally demonstrates and analyzes another widespread read-disturb phenomenon, RowPress, in real DDR4 DRAM chips. RowPress breaks memory isolation by keeping a DRAM row open for a long period of time, which disturbs physically nearby rows enough to cause bitflips. We show that RowPress amplifies DRAM's vulnerability to read-disturb attacks by significantly reducing the number of row activations needed to induce a bitflip by one to two orders of magnitude under realistic conditions. In extreme cases, RowPress induces bitflips in a DRAM row when an adjacent row is activated only once. Our detailed characterization of 164 real DDR4 DRAM chips shows that RowPress 1) affects chips from all three major DRAM manufacturers, 2) gets worse as DRAM technology scales down to smaller node sizes, and 3) affects a different set of DRAM cells from RowHammer and behaves differently from RowHammer as temperature and access pattern changes. We demonstrate in a real DDR4-based system with RowHammer protection that 1) a user-level program induces bitflips by leveraging RowPress while conventional RowHammer cannot do so, and 2) a memory controller that adaptively keeps the DRAM row open for a longer period of time based on access pattern can facilitate RowPress-based attacks. To prevent bitflips due to RowPress, we describe and evaluate a new methodology that adapts existing RowHammer mitigation techniques to also mitigate RowPress with low additional performance overhead. We open source all our code and data to facilitate future research on RowPress.

1 Introduction

Read disturbance threatens memory isolation, and RowPress adds a distinct mode: keeping an aggressor row open for a long time can disturb nearby rows. Across 164 DDR4 chips, it sharply reduces the activations needed for bitflips, differs from RowHammer, and can be triggered by a user-level program despite RowHammer protection.

1 Introduction

  • RowPress is a widespread read-disturb phenomenon in real DDR4 chips that occurs when a row stays open long enough to disturb nearby rows.The characterization covers 164 chips from all three major manufacturers.Source: §1 · pp. 1–2
  • At tAggON = 7.8 µs, RowPress reduces ACmin by 17.6× on average (up to 40.7×); at 70.2 µs, it reduces ACmin by 159.4× on average (up to 363.8×).At an extreme tAggON of 30 ms, a bitflip occurs with only one activation.Source: §1 · p. 2, Figure 1 · p. 2
  • RowPress bitflips affect a distinct cell population: fewer than 0.013% of affected cells also exhibit RowHammer bitflips, and fewer than 0.34% overlap retention-failure cells.RowPress also behaves differently from RowHammer as temperature and access pattern change.Source: §1 · p. 2
  • A user-level program induces RowPress bitflips on a real DDR4 system with in-DRAM RowHammer mitigation, while conventional RowHammer cannot induce bitflips there.The program accesses multiple columns so the memory controller keeps the aggressor row open longer.Source: §1 · p. 2
  • The authors propose adapting RowHammer mitigations to limit maximum row-open time and account for RowPress-induced ACmin reduction, with low additional performance overhead.Applied to PARA and Graphene, the methodology yields average additional slowdowns of 3.6% and −0.63%, respectively.Source: §1 · p. 2

2 Background & Motivation

This section introduces DRAM organization and operations, the timing parameters governing row access and refresh, and the read-disturb problem motivating the study.

2.1 DRAM Organization

  • A DRAM module contains ranks of lock-step chips, and each chip contains independently accessible banks holding rows and columns of cells.Cells connect capacitors to bitlines through access transistors controlled by wordlines; row-buffer sense amplifiers support reads and writes.Source: §2.1 · pp. 2–3, Figure 2 · p. 2

2.2 Major DRAM Operations

  • DRAM access opens a row with ACT, reads or writes through RD/WR while it is open, then closes it with PRE; REF commands periodically restore cell charge.A PRE is required before refresh to close any open row.Source: §2.2 · p. 3

2.3 Key DRAM Timing Parameters

  • tRAS and tRP set minimum intervals around row close and reopen, while tREFI is the default interval between refreshes and tREFW bounds the refresh window.Controllers may keep a row open beyond tRAS to serve further requests; without postponed refreshes, the row can remain open for tREFI, or up to 9×tREFI when postponement is allowed.Source: §2.3 · p. 3, Figure 3 · p. 3

2.4 Motivation

  • Read disturbance arises from undesirable interactions between circuit components and, like retention failures, worsens as DRAM technology scales to smaller nodes.The study aims to characterize disturbance caused by increased aggressor-row on-time and understand its implications for secure, reliable, and safe DRAM operation.Source: §2.4 · p. 3

3 Methodology

The methodology uses an FPGA-based infrastructure to test commodity DDR4 chips while controlling temperature and minimizing interference from refresh, ECC, and existing RowHammer defenses. The tested chips span manufacturers, die densities, and revisions.

3.1 DRAM Testing Infrastructure

  • An FPGA board running DRAM Bender executes tests, while heaters, a thermocouple, and a PID controller maintain the target chip temperature.A host generates test programs and collects results.Source: §3.1 · p. 3, Figure 4 · p. 3
  • Periodic refresh is disabled, tests stay within a refresh window, and modules without rank-level or on-die ECC are used to observe circuit-level bitflips.Disabling refresh also disables existing on-die RowHammer defenses such as TRR.Source: §3.1 · p. 4

3.2 Commodity DDR4 DRAM Chips Tested

  • The study tests 164 DDR4 chips from all three major manufacturers, spanning die densities and die revisions.The authors reverse-engineer physical row address layout to account for in-DRAM row address mapping.Source: §3.2 · p. 4

4 Major RowPress Characterization

The characterization measures how RowPress vulnerability changes with aggressor-row on-time and compares RowPress bitflips with RowHammer and retention failures. Longer on-time substantially reduces the activations needed for bitflips, and RowPress-vulnerable cells largely differ from those affected by the other phenomena.

4.1 Experiment Methodology

  • The study sweeps single-sided tAggON from 36 ns to 30 ms and measures the minimum activation count needed to induce bitflips.For each tested tAggON, it uses a modified bisection search and reports the minimum across five repetitions per row.Source: §4.1 · p. 4, §4 · p. 4

4.2 Vulnerability to Read Disturbance

  • 21× and 190× average reductions in mean AC_min occur as tAggON rises from 36 ns to 7.8 µs and 70.2 µs, respectively, across almost all die revisions.The respective maximum reductions are 59× and 537×; 7.8 µs and 70.2 µs are potential bounds dependent on controller refresh postponement.Source: §4.2 · p. 5, Figure 6 · p. 5
  • At 30 ms and 50°C, 13.1% of tested rows with RowPress bitflips need only one aggressor-row activation.In three dies, bitflips were observed with one activation at tAggONmin values of 9.2 ms, 9.8 ms, and 9.0 ms.Source: §4.2 · pp. 5–6
  • The AC_min reduction rate slows as tAggON increases, so AC_min does not decline linearly with tAggON.For the three manufacturers, average reductions per microsecond are about −0.37 to −0.41 from 7.8 to 15 µs, versus −0.021 to −0.023 from 30 to 70.2 µs.Source: §4.2 · p. 5
  • RowPress vulnerability worsens as DRAM technology scales down, with almost 100% of tested 8Gb S D-Die rows showing bitflips versus below 80% for C-Dies and below 60% for B-Dies.The paper reports this pattern across chips from all three major manufacturers.Source: §4.2 · pp. 5–6

4.3 Distinguishing Characteristics of RowPress

  • At tAggON ≥7.8 µs, less than 0.013% of RowPress-vulnerable cells overlap RowHammer-vulnerable cells, and less than 0.34% overlap retention failures.The authors infer that RowPress and RowHammer bitflips arise from different failure mechanisms.Source: §4.3 · p. 6, Figure 10 · p. 6
  • With the tested checkerboard pattern, RowHammer bitflips are predominantly 0-to-1 while RowPress shifts toward 1-to-0 as tAggON increases.The opposite trend is not observed in Mfr. M 16Gb E-Die chips, where the 1-to-0 fraction decreases as tAggON increases.Source: §4.3 · pp. 6–7, Figure 12 · p. 7

5 RowPress Sensitivity Study

RowPress sensitivity varies with temperature, access pattern, data pattern, and the balance of aggressor-row on and off time. These results distinguish its behavior from RowHammer and show that existing device-level studies do not fully explain it.

5.1 Temperature

  • At 80°C, increasing tAggON from 36 ns to 7.8 µs reduced ACmin by 48× on average, and from 36 ns to 70.2 µs by 438× on average.At 30 ms, 82.8% of rows with bitflips had ACmin of one at 80°C, versus 13.1% at 50°C.Source: §5.1 · p. 7
  • As temperature rose from 50°C to 80°C, tAggONmin decreased across manufacturers, and the fraction of rows with bitflips approached 100% in almost all vulnerable die revisions.For Mfr. H 4Gb A-Die, bitflips appeared at AC=1 at temperatures ≥65°C, despite none at AC=10000 at 50°C.Source: §5.1 · pp. 7–8

5.2 Access Pattern

  • At larger tAggON values, single-sided RowPress required fewer activations than double-sided RowPress, reversing the initial advantage of double-sided access.The reversal appeared beyond 1536 ns for some die revisions at 50°C and was consistent across almost all revisions above 7.8 µs at 80°C.Source: §5.2 · pp. 8–9

5.3 Data Pattern

  • CheckerBoard was the most effective tested data pattern in most cases, while RowStripe’s short-tAggON advantage did not persist at longer tAggON values.For two revisions, RowStripe could not induce bitflips above 636 ns; in the double-sided case, Column-Stripe patterns instead gained effectiveness as tAggON increased, the only major single-/double-sided difference observed.Source: §5.3 · pp. 9–10

5.4 tAggON vs tAggOFF

  • With single-sided access, increasing tAggON mitigated read disturbance for ΔtA2A ≤1200 ns but exacerbated it at larger ΔtA2A; with double-sided access, disturbance consistently worsened as tAggON increased and tAggOFF decreased.The opposing single-sided trends and double-sided behavior show that access pattern matters to RowPress’s device-level failure mechanisms, which existing device-level studies do not fully explain.Source: §5.4 · pp. 10–11

6 Real System Demonstration of RowPress

A simple user-level program induced RowPress bitflips on a real DDR4 system with TRR, including cases where RowHammer induced none. The test also verified that consecutive cache-block accesses can keep a row open, a controller behavior that can facilitate RowPress attacks.

6.1 Experimental Setup

  • The real-system demonstration used an Intel DDR4 platform with TRR and a program designed to access adjacent aggressor rows while using dummy rows to avoid TRR detection.The program accessed multiple cache blocks per aggressor-row activation to increase row-open time.Source: §6.1 · p. 11, §6.2 · p. 11

6.2 RowPress on Real Systems

  • A user-level program leveraging RowPress induced bitflips when RowHammer could not, and induced many more bitflips than RowHammer at the same aggressor-row activation count.With NUM_AGGR_ACTS=2 and NUM_READS=64, it induced up to 83 bitflips in 79 rows; with NUM_AGGR_ACTS=3 and NUM_READS=32, up to 436 bitflips in 285 rows.Source: §6.2 · p. 12
  • Bitflips did not rise monotonically with cache blocks read per activation: for four activations, counts rose from 8 to 258 and then fell to 18 and 2 as reads increased from 1 to 16, 32, and 48.The authors attribute the rise partly to longer row-open time and reduced real-aggressor detection; they hypothesize that overly long patterns and lower activation frequency explain the subsequent decline.Source: §6.2 · pp. 12–13

6.3 Verifying tAggON Increase

  • The first cache-block access had a median latency 30 cycles longer than subsequent accesses, consistent with the first access activating the row and later accesses using the already-open row.The authors conclude that the tested controller keeps a row open during consecutive cache-block accesses; controllers behaving similarly can facilitate RowPress attacks.Source: §6.3 · p. 13

7 Mitigating RowPress

The paper evaluates four approaches to RowPress mitigation, finding that adapting existing RowHammer defenses can mitigate both phenomena with low additional performance overhead. ECC alone may require costly storage overhead, while row-buffer decoupling and simple row-open-time limits have practical drawbacks.

7.1 Error Correcting Codes (ECC)

  • Up to 25 RowPress bitflips can occur in one 64-bit word, beyond the correction or detection guarantees of widely used ECC schemes.The analysis also reports that at tAggON = 7.8 µs, at least three bitflips occur in up to 0.99%, 35.77%, and 10.08% of words for manufacturers A, B, and C, respectively.Source: §7.1 · pp. 13–14
  • ECC-only mitigation is costly because schemes that correct all observed bitflips require prohibitively large storage overheads.Page retirement can also render up to 35.77% of storage capacity useless in the reported analysis.Source: §7.1 · pp. 13–14

7.2 Decoupling the Row Buffer from the Row

  • Row-buffer decoupling can limit tAggON to tRAS, but requires DRAM-chip changes, complicates write scheduling, and does not mitigate RowHammer.The authors leave its detailed RowPress evaluation to future work.Source: §7.2 · p. 14

7.3 Limiting the Maximum Row-Open Time

  • A row-open-time cap above tRAS does not undo disturbance already caused by a longer activation, while closing every row after tRAS can increase latency and slowdown.Reducing row-buffer hit rate can cause up to 34.1% single-core performance degradation; forced closes can also increase repeated activations of the same row.Source: §7.3 · p. 14

7.4 Adapting Existing RowHammer Mitigations

  • The adaptation reduces the RowHammer threshold according to characterized RowPress disturbance and also limits maximum row-open time.For a characterized tAggON of X ns and maximum A C_min reduction of Y%, the method sets T′_RH = (1 − Y%)T_RH and closes the row after X ns.Source: §7.4 · p. 14
  • Graphene-RP and PARA-RP mitigate RowPress with low additional performance overhead compared with Graphene and PARA.Graphene-RP averages −0.63% slowdown at t_mro = 96 ns and reaches a 4.6% maximum at 636 ns; PARA-RP averages 3.2% at 36 ns and reaches a 13.1% maximum at 96 ns.Source: Table 3 · p. 15, §7.4 · p. 15

8 Related Work

The paper distinguishes its experimentally characterized RowPress phenomenon from prior work on increased row-open time, patents, and one-location hammering. It also notes that existing RowHammer mitigations generally do not account for RowPress.

RowHammer with Increased tAggON

  • Prior increased-tAggON studies examined narrower ranges and did not assess temperature, access-pattern sensitivity, or induced-bitflip properties together.The authors report that their characterization finds almost no overlap between RowPress and RowHammer bitflips.Source: §8 · p. 15

RAS Clobber

  • Micron patents mention similar RAS Clobber effects but provide no evaluation or clear distinction from RowHammer, unlike this work's DRAM characterization and real-system demonstration.The patents also do not evaluate their proposed mitigations at system level.Source: §8 · p. 15

One-Location RowHammer

  • One-Location Hammering leaves unclear whether bitflips arise from increased tAggON or conventional RowHammer, while prior RowHammer mitigations do not account for RowPress.The cited access pattern also does not consider on-die RowHammer mitigations.Source: §8 · p. 15

9 Conclusion

RowPress keeps a DRAM row open long enough to disturb nearby rows, and its bitflips arise from a mechanism distinct from RowHammer. The authors demonstrate RowPress on real systems and describe adaptations to existing mitigations, while releasing artifacts for reproducing their work.

9 Conclusion

  • Characterization of 164 real DRAM chips shows RowPress has a different underlying mechanism from RowHammer and can reduce the activations needed for a bitflip by one to two orders of magnitude.In extreme cases, a single activation can induce a bitflip, and vulnerability worsens as DRAM technology node size decreases.Source: §9 · pp. 15–16
  • A user-level program induces RowPress bitflips in a real system, and the authors adapt existing read-disturb mitigations to protect against RowPress with low additional performance overhead.The reported demonstration works even in the presence of in-DRAM read-disturb mitigation mechanisms.Source: §9 · p. 16

A.1 Abstract

  • The artifact provides characterization data and code, the real-system demonstration source, and a Ramulator implementation of the proposed mitigation.It also includes scripts and notebooks to analyze and plot results for all three components.Source: §A.1 · p. 19

A.6 Evaluation and Expected Results

The artifact experiments reproduce the paper’s real-chip characterization, real-system demonstration, and mitigation simulations. Replicating characterization on a DRAM module requires a specialized test setup and several weeks.

A.6 Evaluation and Expected Results

  • Running the artifact experiments reproduces the real-chip characterization, real-system RowPress demonstration, and simulation results for the proposed mitigation.The expected results include figures from characterization and demonstration, plus Table 3 for mitigation.Source: §A.6 · p. 20

A.7.1 Characterization

  • Replicating characterization on one DRAM module takes about three to four weeks and requires temperature control supplied by the reader’s testing infrastructure.The characterization program can vary DRAM modules, data and access patterns, activation counts, and tAggON/tAggOFF values.Source: §A.7.1 · p. 20

A.7.2 Demonstration

  • The real-system demonstration is documented for an Intel Core i5 10400 system with a Samsung DDR4 module containing 8Gb C-Dies from manufacturer S.The instructions describe adapting the program for different processors or DRAM modules.Source: §A.7.2 · p. 20

A.7.3 Mitigation

  • Mitigation simulations use Ramulator configurations and can be run with user-provided traces.The artifact includes scripts for generating configurations and jobs.Source: §A.7.3 · p. 20

C.1 Extended Characterization Results of the RowPress-ONOFF Pattern

The extended characterization plots RowPress-ONOFF bit error rates across die revisions, access-pattern timing, and two temperatures. The minimally-open-row policy increases row activations substantially, while reducing performance for workloads with high row-buffer locality.

C.1 Extended Characterization Results of the RowPress-ONOFF Pattern

  • The RowPress-ONOFF characterization sweeps ΔtA2A and the fraction contributing to tAggON across die revisions at 50°C and 80°C.Plots show bit error rates for single-sided and double-sided patterns, with error bands marking standard deviation.Source: §C.1 · p. 23

D.1 Limiting the Maximum Row-Open Time

  • 21 of 58 workloads see at least a 50× increase in activations to a row within tREFW under the minimally-open-row policy, with a maximum increase of 372× for 483.xalancbmk.For 510.parest, the most-activated row rises from 497 to 3808 activations within tREFW.Source: §D.1 · p. 25, Figure 38 · p. 25
  • The minimally-open-row policy can potentially turn benign workloads into RowHammer attacks, while some access-pattern-adaptive row policies leave t_mro attacker-controllable above tRAS.The authors argue secure mitigation requires combining existing RowHammer mitigations with a row policy that enforces t_mro.Source: §D.1 · p. 25
  • The minimally-open-row policy reduces IPC for workloads with high row-buffer locality, including a 34.1% reduction for 462.libquantum.Its RBMPKI rises 110%, from 0.91 to 1.90.Source: §D.1 · p. 25, Figure 39 · p. 25

D.2 Adapting Existing RowHammer Mitigations

The paper evaluates adaptations of Graphene and PARA for RowPress mitigation across single-core and multiprogrammed workloads. Both adaptations show low additional performance overhead in the reported evaluation, with outcomes depending on configuration and workload.

D.2 Adapting Existing RowHammer Mitigations

  • For single-core workloads, Graphene-RP slightly outperforms Graphene for all t_mro ≥ 66 ns, by up to 0.46% on average at t_mro = 336 ns.Performance varies with row-buffer locality: shorter t_mro can help low-hit-rate workloads but hurt high-hit-rate workloads.Source: §D.2 · p. 26, Figure 40 · p. 26
  • PARA-RP’s best single-core configuration has an average slowdown of 7.3% over PARA at t_mro = 186 ns.The passage attributes PARA-RP’s consistent slowdown to extra activations increasing preventive refreshes.Source: §D.2 · p. 26
  • Across heterogeneous four-core workloads, Graphene-RP outperforms Graphene by 2.3% at t_mro = 66 ns, while PARA-RP performs PARA by 0.03% at t_mro = 36 ns.For homogeneous workloads, Graphene-RP outperforms Graphene by 0.67% at 96 ns, and PARA-RP’s best result is a 3.8% slowdown at 36 ns.Source: Figure 41 · p. 26, §D.2 · p. 27
  • For PARA-RP, performance overhead always decreases as t_mro increases beyond 36 ns because preventive-refresh overhead can outweigh the benefits of longer row-open time.This finding concerns single-core workloads, in contrast to the reported multicore results.Source: §D.2 · p. 27
  • Graphene-RP and PARA-RP adapt existing RowHammer mitigations to mitigate RowPress with low additional performance overhead.The evaluation summarizes overheads for single-core and multicore workloads.Source: §D.2 · p. 27, Table 9 · p. 27

E Repeatability of RowPress Bitflips

RowPress bitflips are repeatable across experimental iterations, including across different access patterns and temperatures. Most bitflips recur in all five iterations, and this holds across tested tAggON values and nearly all die revisions from all three manufacturers.

E Repeatability of RowPress Bitflips

F Extended Results on the Effect of Temperature on RowPress Bitflips

Additional experiments test RowPress at 65°C and compare single- and double-sided access across three temperatures. The results confirm that higher temperature consistently lowers the activation threshold and that single-sided access needs fewer activations at 65°C.

F Extended Results on the Effect of Temperature on RowPress Bitflips

  • The experiments extend the temperature characterization to 65°C using the same methodology as the earlier study.The reported comparisons also test whether the temperature and access-pattern observations persist across 50°C, 65°C, and 80°C.Source: F Extended Results on the Effect of… · p. 30
  • As temperature rose from 50°C to 65°C and then 80°C, ACmin consistently fell at the same tAggON for every die revision vulnerable to RowPress.Figures 46 and 47 show mean ACmin at 65°C normalized to 50°C and at 80°C normalized to 65°C, respectively.Source: F Extended Results on the Effect of… · p. 30, Figure 46 · p. 30, Figure 47 · p. 30
  • At 65°C, single-sided RowPress still required fewer total aggressor-row activations to induce a bitflip than double-sided RowPress.Figure 48 shows single-sided ACmin minus double-sided ACmin at 50°C, 65°C, and 80°C; values below zero indicate fewer activations for single-sided access.Source: F Extended Results on the Effect of… · p. 30, Figure 48 · p. 30

G Inducing Even More Bitflips on the Real System

On a real system, Algorithm 2's access and flush ordering produces substantially more RowPress bitflips than Algorithm 1 in the reported settings. The results suggest that row-open time and memory-controller handling merit further investigation.

G Inducing Even More Bitflips on the Real System

  • Algorithm 2 immediately flushes each cache block after accessing it, unlike Algorithm 1, which flushes after accessing blocks from both aggressor rows.The variant changes the program order of cache-block accesses and clflushopt instructions.Source: G Inducing Even More Bitflips on the… · p. 31
  • Algorithm 2 is described as inducing significantly more bitflips than Algorithm 1 in the real-system test.The figure compares bitflip counts and affected-row counts across programs and activation counts.Source: G Inducing Even More Bitflips on the… · p. 31, Figure 49 · p. 31
  • The reported counts vary slightly between runs because of operating-system scheduling and synchronization with DRAM refresh.These low-level events are transparent to the test program.Source: G Inducing Even More Bitflips on the… · p. 31
  • With four activations and 32 reads per aggressor row, Algorithm 2 produced 2,371 bitflips in 429 rows, versus Algorithm 1's 24 bitflips in 20 rows.With three activations and 32 reads, Algorithm 2 produced 4,190 bitflips in 542 rows, versus Algorithm 1's 1,065 bitflips in 450 rows.Source: G Inducing Even More Bitflips on the… · p. 31, Figure 49 · p. 31
  • The authors hypothesize that Algorithm 2's access pattern keeps aggressor rows open longer, leading to more bitflips in more rows.They call for more investigation into how modern memory controllers handle row-open time.Source: G Inducing Even More Bitflips on the… · p. 31

Related papers

Loading 2306.17061v5…