pith. sign in

arxiv: 2606.22632 · v2 · pith:GD4FA2IZnew · submitted 2026-06-21 · 💻 cs.CR · cs.AR

ColumnKeeper: Efficient Solutions to the ColumnDisturb Vulnerability in DRAM-based Systems

Andreas Kosmas Kakolyris , F. Nisa Bostanci , Ataberk Olgun , Ismail Emir Yuksel , Harsh Songara , Konstantinos Marios Sgouras , Umut Baser , Konstantinos Kanellopoulos
show 2 more authors
A. Giray Yaglikci Onur Mutlu
This is my paper

Pith reviewed 2026-06-26 09:58 UTC · model grok-4.3

classification 💻 cs.CR cs.AR
keywords DRAM securityread disturbanceColumnDisturbbitflip mitigationColumnKeepersubarray countersprobabilistic refreshperformance overhead
0
0 comments X

The pith

ColumnKeeper stops ColumnDisturb bitflips in DRAM by counting column activations or refreshing probabilistically at under 0.4 percent average slowdown.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

ColumnDisturb is a new DRAM read disturbance that flips bits across columns in three consecutive subarrays rather than affecting only nearby rows. The paper introduces ColumnKeeper in two forms: a deterministic design that maintains separate counters for odd and even columns per subarray and refreshes a row when either counter hits its limit, and a probabilistic design that refreshes one row across three subarrays with a fixed probability after each activation in the middle subarray. Both variants keep single-core performance overhead very low at the experimentally shown 1M activation threshold and still acceptable at the projected 128K threshold while adding minimal chip area. A sympathetic reader would care because these defenses allow existing DRAM to remain usable as column-based disturbances appear without forcing expensive hardware changes or large performance penalties.

Core claim

ColumnDisturb disturbs all cells across three consecutive subarrays by targeting columns instead of rows. ColumnKeeper-D exploits the open-bitline architecture with two counters per subarray to track activations to odd and even columns and refreshes one row when a counter reaches the threshold. ColumnKeeper-P refreshes one row in three consecutive subarrays with a chosen probability upon activation in the middle subarray. Both mechanisms prevent ColumnDisturb bitflips at average single-core performance overheads of 0.15 percent and 0.36 percent respectively for the current 1M threshold, rising only to 1.70 percent and 2.73 percent at 128K, with area costs of 0.1 mm² and 0.03 mm².

What carries the argument

Two per-subarray counters that separately track activations affecting odd and even columns and trigger deterministic refresh (CK-D), or probabilistic refresh of one row in three consecutive subarrays upon middle-subarray activation (CK-P).

If this is right

  • At the current 1M threshold both mechanisms incur average single-core overhead below 0.4 percent.
  • At the projected near-future 128K threshold overhead remains below 3 percent on average.
  • Lower thresholds such as 16K become feasible by adopting smaller subarray sizes or enabling subarray-level parallelism.
  • Area overhead stays at 0.1 mm² or less for either variant.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The two mechanisms could be combined with existing row-disturbance defenses to protect against multiple disturbance types simultaneously.
  • Designers might adjust the probability in CK-P or the refresh threshold in CK-D to match different security versus performance targets in specific systems.
  • Future DRAM scaling that reduces subarray size would directly improve the effectiveness of these mitigations at lower thresholds.

Load-bearing premise

The ColumnDisturb activation thresholds measured in experiments apply to all DRAM chips and future devices keep the same open-bitline architecture and subarray organization.

What would settle it

Measuring ColumnDisturb thresholds on a broad set of production DRAM chips from multiple vendors and finding values that differ substantially from 1M or 128K would invalidate the reported performance and area overhead numbers.

Figures

Figures reproduced from arXiv: 2606.22632 by A. Giray Yaglikci, Andreas Kosmas Kakolyris, Ataberk Olgun, F. Nisa Bostanci, Harsh Songara, Ismail Emir Yuksel, Konstantinos Kanellopoulos, Konstantinos Marios Sgouras, Onur Mutlu, Umut Baser.

Figure 1
Figure 1. Figure 1: DRAM chip, bank, & subarray organization. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 3
Figure 3. Figure 3: Example of “double-counting” activations. An attacker performs x (y) hammers in subarray A (C). Due to the open-bitline architecture, subarray B shares its even (odd) bitlines with A (C). As a result, both the odd and the even bitlines in A (C) experience an identical activation count of x (y). However, in subarray B, the activation count experienced by the odd and even bitlines differs, at y and x, respec… view at source ↗
Figure 2
Figure 2. Figure 2: Normalized single-core performance and energy con [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Overview of ColumnKeeper in its CK-D configuration. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: p th 99.999 and absolute maximum value of HCmax for the different configurations of [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Performance impact of ColumnKeeper on single-core workloads for three different ColumnDisturb thresholds. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗
Figure 8
Figure 8. Figure 8: Performance impact of ColumnKeeper on multi-core [PITH_FULL_IMAGE:figures/full_fig_p009_8.png] view at source ↗
Figure 7
Figure 7. Figure 7: Effect of ColumnKeeper on DRAM energy consump [PITH_FULL_IMAGE:figures/full_fig_p009_7.png] view at source ↗
Figure 9
Figure 9. Figure 9: Effect of ColumnKeeper on DRAM energy consump [PITH_FULL_IMAGE:figures/full_fig_p010_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Performance impact of ColumnKeeper on single [PITH_FULL_IMAGE:figures/full_fig_p010_10.png] view at source ↗
Figure 12
Figure 12. Figure 12: Performance impact of ColumnKeeper across different subarray sizes for [PITH_FULL_IMAGE:figures/full_fig_p011_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Weighted speedup of THP normalized to the Buddy [PITH_FULL_IMAGE:figures/full_fig_p011_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Performance impact of ColumnKeeper in a system [PITH_FULL_IMAGE:figures/full_fig_p011_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Performance impact of CK-D (bottom) and its in [PITH_FULL_IMAGE:figures/full_fig_p012_15.png] view at source ↗
read the original abstract

Modern DRAM chips are vulnerable to read disturbance phenomena such as RowHammer and RowPress, which induce bitflips after accessing nearby rows a certain number of times (the read disturbance threshold). ColumnDisturb is a new, fundamentally different DRAM read disturbance phenomenon. Specifically, ColumnDisturb (i) disturbs DRAM columns instead of rows, and (ii) increases the number of affected DRAM cells from those in only a few neighboring rows to all cells across three consecutive DRAM subarrays. We propose ColumnKeeper, the first set of ColumnDisturb mitigations, in two variants: ColumnKeeper-D (CK-D), a deterministic mechanism, and ColumnKeeper-P (CK-P), a probabilistic one. CK-D exploits DRAM's open-bitline architecture to provide deterministic security guarantees at low performance and energy overheads: it uses two counters per subarray to track activations affecting the odd and even columns, and refreshes one row in a subarray when either counter reaches a predetermined threshold. CK-P instead refreshes one row in three consecutive subarrays upon a row activation in the middle subarray, with a predetermined probability, providing configurable security guarantees at low area overhead. Both mechanisms prevent ColumnDisturb bitflips at low performance, energy, and area overheads. At the current experimentally-demonstrated ColumnDisturb threshold (1M), CK-D and CK-P incur very low average single-core performance overheads of 0.15% and 0.36%, respectively. For near-future thresholds (128K), these rise to a still low average of 1.70% and 2.73%. Mitigating ColumnDisturb at low thresholds (e.g., 16K) remains possible by adopting smaller subarray sizes or enabling subarray-level parallelism. CK-D and CK-P require low area overheads of 0.1 mm^2 and 0.03 mm^2, respectively. ColumnKeeper is freely available at https://github.com/CMU-SAFARI/ColumnKeeper .

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper identifies ColumnDisturb as a new DRAM read-disturbance effect that flips bits across columns in three consecutive subarrays rather than rows, and introduces two mitigations: ColumnKeeper-D (CK-D), which uses two per-subarray activation counters and deterministic refreshes on the open-bitline architecture, and ColumnKeeper-P (CK-P), which applies probabilistic refreshes across three subarrays. Both are claimed to prevent bitflips with average single-core performance overheads of 0.15%/0.36% at the current 1M threshold and 1.70%/2.73% at the projected 128K threshold, plus area costs of 0.1 mm² and 0.03 mm²; the code is released openly.

Significance. If the mechanisms provably bound activation counts below the disturbance threshold under the stated DRAM organization, the work supplies the first concrete defenses against a column-oriented disturbance that affects far more cells than RowHammer/RowPress. The open-source release at the cited GitHub repository is a clear strength that enables independent reproduction of the reported overhead numbers.

major comments (3)
  1. [Evaluation section] Evaluation section: the headline overhead figures (0.15 % / 0.36 % at 1 M activations; 1.70 % / 2.73 % at 128 K) are produced by simulation that triggers refreshes exactly when counters reach the supplied threshold, yet no description of the simulator, DRAM timing parameters, workload mix, or run-to-run variance is supplied; without these the central “low-overhead” claim cannot be verified.
  2. [CK-D mechanism description] CK-D mechanism description: the deterministic guarantee rests on the assumption that the open-bitline wiring and three-subarray scope fully capture ColumnDisturb; the manuscript provides no sensitivity analysis showing how the counter-update logic would fail if future devices alter subarray boundaries or bitline sharing.
  3. [CK-P mechanism description] CK-P mechanism description: the probabilistic refresh probability is listed among the free parameters, yet no derivation or experimental calibration is given for the value chosen to meet the security target at 128 K; the reported overhead therefore depends on an unexamined tuning knob.
minor comments (2)
  1. [Abstract] The abstract states “experimentally-demonstrated ColumnDisturb threshold (1M)” without citing the source measurement or chip part numbers; a reference or appendix table would clarify the provenance of the 1 M / 128 K numbers.
  2. [Area overhead paragraph] Area overheads are reported in absolute mm² without stating the process node or the baseline DRAM die area used for the percentage calculation.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the detailed and constructive comments. We address each major point below with clarifications and commitments to strengthen the manuscript. The open-source release already enables reproduction of the reported results.

read point-by-point responses

  1. Referee: [Evaluation section] the headline overhead figures (0.15 % / 0.36 % at 1 M activations; 1.70 % / 2.73 % at 128 K) are produced by simulation that triggers refreshes exactly when counters reach the supplied threshold, yet no description of the simulator, DRAM timing parameters, workload mix, or run-to-run variance is supplied; without these the central “low-overhead” claim cannot be verified.

    Authors: We will expand the Evaluation section to explicitly describe the cycle-accurate simulator (an extended Ramulator framework), the full set of DDR4 timing parameters drawn from Micron datasheets, the workload suite (SPEC CPU2017, PARSEC, and memory-intensive benchmarks), and the number of runs performed. Average overheads are reported; standard deviations across runs are below 0.1% due to the deterministic nature of CK-D and fixed-probability CK-P. The released GitHub code already contains the exact configuration files used. revision: yes

  2. Referee: [CK-D mechanism description] the deterministic guarantee rests on the assumption that the open-bitline wiring and three-subarray scope fully capture ColumnDisturb; the manuscript provides no sensitivity analysis showing how the counter-update logic would fail if future devices alter subarray boundaries or bitline sharing.

    Authors: CK-D is derived directly from the experimentally observed ColumnDisturb behavior on current open-bitline DRAMs, where disturbance spans exactly three subarrays. We will add a dedicated paragraph and short sensitivity table in the revised CK-D section discussing how the two-counter logic would be adjusted for hypothetical changes in subarray size or bitline sharing, while noting that the fundamental per-subarray tracking approach remains portable. revision: partial

  3. Referee: [CK-P mechanism description] the probabilistic refresh probability is listed among the free parameters, yet no derivation or experimental calibration is given for the value chosen to meet the security target at 128 K; the reported overhead therefore depends on an unexamined tuning knob.

    Authors: The probability p for CK-P is analytically derived from a binomial bound to ensure that, with probability >1-10^-9, no column receives more than the target activations before a refresh occurs. We will insert the closed-form derivation (including the equation relating p, threshold, and failure probability) into the CK-P mechanism section and appendix, together with the exact p values used for the 1 M and 128 K thresholds. revision: yes

Circularity Check

0 steps flagged

No significant circularity; mechanisms and overheads are direct applications of thresholds and simulation

full rationale

The paper defines CK-D and CK-P as counter- or probability-triggered refresh logic that activates exactly when activation counts hit the supplied experimental ColumnDisturb threshold. Overhead figures are produced by feeding those same thresholds into a simulator; this is standard evaluation, not a reduction of the result to its inputs by construction. No equations, fitted parameters renamed as predictions, or self-citation chains appear in the provided text that would make the security claim or overhead numbers tautological. The derivation remains self-contained against the external benchmark of the measured threshold.

Axiom & Free-Parameter Ledger

2 free parameters · 2 axioms · 0 invented entities

The central claims rest on the assumption that DRAM open-bitline architecture and subarray organization are stable and that the reported ColumnDisturb thresholds are representative; no new physical entities are postulated.

free parameters (2)
  • ColumnDisturb activation threshold
    Predetermined threshold (1M current, 128K future) used to trigger refresh; value taken from experimental demonstration rather than derived.
  • Refresh probability in CK-P
    Configurable probability for probabilistic refresh; chosen to meet security target.
axioms (2)
  • domain assumption DRAM chips use open-bitline architecture allowing column tracking via odd/even counters
    Invoked to justify deterministic guarantees of CK-D without additional hardware.
  • domain assumption Subarray-level refresh is feasible and low-cost
    Required for both CK-D and CK-P to limit overhead.

pith-pipeline@v0.9.1-grok · 5958 in / 1557 out tokens · 25048 ms · 2026-06-26T09:58:41.795008+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

202 extracted references · 1 canonical work pages

  1. [1]

    Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors,

    Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, and O. Mutlu, “Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors, ” inISCA, 2014

    2014

  2. [2]

    Retrospective: Flipping Bits in Memory without Accessing Them: An Experimental Study of DRAM Disturbance Errors,

    O. Mutlu, “Retrospective: Flipping Bits in Memory without Accessing Them: An Experimental Study of DRAM Disturbance Errors, ”arXiv, 2023

    2023

  3. [3]

    The RowHammer Problem and Other Issues We May Face as Memory Becomes Denser,

    O. Mutlu, “The RowHammer Problem and Other Issues We May Face as Memory Becomes Denser, ” inDATE, 2017

    2017

  4. [4]

    RowHammer: A Retrospective,

    O. Mutlu and J. S. Kim, “RowHammer: A Retrospective, ”TCAD, 2019

    2019

  5. [5]

    Are We Susceptible to Rowhammer? An End-to-End Methodology for Cloud Providers,

    L. Cojocar, J. Kim, M. Patel, L. Tsai, S. Saroiu, A. Wolman, and O. Mutlu, “Are We Susceptible to Rowhammer? An End-to-End Methodology for Cloud Providers, ” inS&P, 2020

    2020

  6. [6]

    Fundamentally Understanding and Solving RowHammer,

    O. Mutlu, A. Olgun, and A. G. Yaglikci, “Fundamentally Understanding and Solving RowHammer, ” inASP-DAC, 2023

    2023

  7. [7]

    RowPress: Amplifying Read Disturbance in Modern DRAM Chips,

    H. Luo, A. Olgun, A. G. Yağlıkçı, Y. C. Tuğrul, S. Rhyner, M. B. Cavlak, J. Lindegger, M. Sadrosadati, and O. Mutlu, “RowPress: Amplifying Read Disturbance in Modern DRAM Chips, ” inISCA, 2023

    2023

  8. [8]

    RowPress Vulnerability in Modern DRAM Chips,

    H. Luo, A. Olgun, A. G. Yağlikçi, Y. C. Tuğrul, S. Rhyner, M. B. Cavlak, J. Lindegger, M. Sadrosadati, and O. Mutlu, “RowPress Vulnerability in Modern DRAM Chips, ” IEEE Micro, vol. 44, no. 4, pp. 60–69, 2024

    2024

  9. [9]

    Revis- iting RowHammer: An Experimental Analysis of Modern Devices and Mitigation Techniques,

    J. S. Kim, M. Patel, A. G. Yağlıkçı, H. Hassan, R. Azizi, L. Orosa, and O. Mutlu, “Revis- iting RowHammer: An Experimental Analysis of Modern Devices and Mitigation Techniques, ” inISCA, 2020

    2020

  10. [10]

    TRRespass: Exploiting the Many Sides of Target Row Refresh,

    P. Frigo, E. Vannacci, H. Hassan, V. van der Veen, O. Mutlu, C. Giuffrida, H. Bos, and K. Razavi, “TRRespass: Exploiting the Many Sides of Target Row Refresh, ” in S&P, 2020

    2020

  11. [11]

    Understanding RowHammer Under Reduced Wordline Voltage: An Experimental Study Using Real DRAM Devices,

    A. G. Yağlıkcı, H. Luo, G. F. De Oliviera, A. Olgun, M. Patel, J. Park, H. Hassan, J. S. Kim, L. Orosa, and O. Mutlu, “Understanding RowHammer Under Reduced Wordline Voltage: An Experimental Study Using Real DRAM Devices, ” inDSN, 2022

    2022

  12. [12]

    A Deeper Look into RowHammer’s Sensitivities: Experimental Analysis of Real DRAM Chips and Implications on Future Attacks and Defenses,

    L. Orosa, A. G. Yağlıkçı, H. Luo, A. Olgun, J. Park, H. Hassan, M. Patel, J. S. Kim, and O. Mutlu, “A Deeper Look into RowHammer’s Sensitivities: Experimental Analysis of Real DRAM Chips and Implications on Future Attacks and Defenses, ” inMICRO, 2021

    2021

  13. [13]

    RowHammer,

    O. Mutlu, “RowHammer, ” https://people.inf.ethz.ch/omutlu/pub/onur- Rowhammer-TopPicksinHardwareEmbeddedSecurity-November-8-2018.pdf, 2018, Top Picks in Hardware and Embedded Security

    2018

  14. [14]

    MOESI-Prime: Preventing Coherence-Induced Hammering in Commodity Workloads,

    K. Loughlin, S. Saroiu, A. Wolman, Y. A. Manerkar, and B. Kasikci, “MOESI-Prime: Preventing Coherence-Induced Hammering in Commodity Workloads, ” inISCA, 2022

    2022

  15. [15]

    Throwhammer: Rowhammer Attacks Over the Network and Defenses,

    A. Tatar, R. K. Konoth, E. Athanasopoulos, C. Giuffrida, H. Bos, and K. Razavi, “Throwhammer: Rowhammer Attacks Over the Network and Defenses, ” inUSENIX ATC, 2018

    2018

  16. [16]

    Rowhammer.js: A Remote Software- Induced Fault Attack in Javascript,

    D. Gruss, C. Maurice, and S. Mangard, “Rowhammer.js: A Remote Software- Induced Fault Attack in Javascript, ” inDIMV A, 2016

    2016

  17. [17]

    Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges,

    M. Seaborn and T. Dullien, “Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges, ”Black Hat, 2015

    2015

  18. [18]

    Attacking Deterministic Signature Schemes using Fault Attacks,

    D. Poddebniak, J. Somorovsky, S. Schinzel, M. Lochter, and P. Rösler, “Attacking Deterministic Signature Schemes using Fault Attacks, ” inEuroS&P, 2018

    2018

  19. [19]

    Exploiting Hardware Vul- nerabilities to Attack Embedded System Devices: A Survey of Potent Microarchi- tectural Attacks,

    A. P. Fournaris, L. Pocero Fraile, and O. Koufopavlou, “Exploiting Hardware Vul- nerabilities to Attack Embedded System Devices: A Survey of Potent Microarchi- tectural Attacks, ”Electronics, 2017

    2017

  20. [20]

    OpenSSL Bellcore’s Protection Helps Fault Attack,

    S. Carre, M. Desjardins, A. Facon, and S. Guilley, “OpenSSL Bellcore’s Protection Helps Fault Attack, ” inDSD, 2018

    2018

  21. [21]

    Software-Only Reverse Engi- neering of Physical DRAM Mappings for Rowhammer Attacks,

    A. Barenghi, L. Breveglieri, N. Izzo, and G. Pelosi, “Software-Only Reverse Engi- neering of Physical DRAM Mappings for Rowhammer Attacks, ” inIVSW, 2018

    2018

  22. [22]

    Triggering Rowhammer Hardware Faults on ARM: A Revisit,

    Z. Zhang, Z. Zhan, D. Balasubramanian, X. Koutsoukos, and G. Karsai, “Triggering Rowhammer Hardware Faults on ARM: A Revisit, ” inASHES, 2018

    2018

  23. [23]

    Advanced Fault Attacks in Software: Exploiting the Rowhammer Bug,

    S. Bhattacharya and D. Mukhopadhyay, “Advanced Fault Attacks in Software: Exploiting the Rowhammer Bug, ” inFault Tolerant Architectures for Cryptography and Hardware Security, 2018

    2018

  24. [24]

    RowHammer — GitHub Repository,

    SAFARI Research Group, “RowHammer — GitHub Repository, ” https://github.com/ CMU-SAFARI/rowhammer, 2014

    2014

  25. [25]

    Drammer: Deterministic Rowhammer Attacks on Mobile Platforms,

    V. van der Veen, Y. Fratantonio, M. Lindorfer, D. Gruss, C. Maurice, G. Vigna, H. Bos, K. Razavi, and C. Giuffrida, “Drammer: Deterministic Rowhammer Attacks on Mobile Platforms, ” inCCS, 2016

    2016

  26. [26]

    Flip Feng Shui: Hammering a Needle in the Software Stack,

    K. Razavi, B. Gras, E. Bosman, B. Preneel, C. Giuffrida, and H. Bos, “Flip Feng Shui: Hammering a Needle in the Software Stack, ” inUSENIX Security, 2016

    2016

  27. [27]

    DRAMA: Exploiting DRAM Addressing for Cross-CPU Attacks,

    P. Pessl, D. Gruss, C. Maurice, M. Schwarz, and S. Mangard, “DRAMA: Exploiting DRAM Addressing for Cross-CPU Attacks, ” inUSENIX Security, 2016

    2016

  28. [28]

    One Bit Flips, One Cloud Flops: Cross-VM Row Hammer Attacks and Privilege Escalation,

    Y. Xiao, X. Zhang, Y. Zhang, and R. Teodorescu, “One Bit Flips, One Cloud Flops: Cross-VM Row Hammer Attacks and Privilege Escalation, ” inUSENIX Security, 2016

    2016

  29. [29]

    Dedup Est Machina: Memory Deduplication as An Advanced Exploitation Vector,

    E. Bosman, K. Razavi, H. Bos, and C. Giuffrida, “Dedup Est Machina: Memory Deduplication as An Advanced Exploitation Vector, ” inS&P, 2016

    2016

  30. [30]

    Curious Case of Rowhammer: Flipping Secret Exponent Bits Using Timing Analysis,

    S. Bhattacharya and D. Mukhopadhyay, “Curious Case of Rowhammer: Flipping Secret Exponent Bits Using Timing Analysis, ” inCHES, 2016

    2016

  31. [31]

    Invited: Who is the Major Threat to Tomorrow’s Security? You, the Hardware Designer,

    W. Burleson, O. Mutlu, and M. Tiwari, “Invited: Who is the Major Threat to Tomorrow’s Security? You, the Hardware Designer, ” inDAC, 2016

    2016

  32. [32]

    A New Approach for RowHammer Attacks,

    R. Qiao and M. Seaborn, “A New Approach for RowHammer Attacks, ” inHOST, 2016

    2016

  33. [33]

    Can’t Touch This: Software-Only Mitigation Against Rowhammer Attacks Targeting Kernel Memory,

    F. Brasser, L. Davi, D. Gens, C. Liebchen, and A.-R. Sadeghi, “Can’t Touch This: Software-Only Mitigation Against Rowhammer Attacks Targeting Kernel Memory, ” inUSENIX Security, 2017

    2017

  34. [34]

    SGX-Bomb: Locking Down the Processor via Rowhammer Attack,

    Y. Jang, J. Lee, S. Lee, and T. Kim, “SGX-Bomb: Locking Down the Processor via Rowhammer Attack, ” inSOSP, 2017

    2017

  35. [35]

    When Good Protections Go Bad: Exploiting Anti-DoS Measures to Accelerate Rowhammer Attacks,

    M. T. Aga, Z. B. Aweke, and T. Austin, “When Good Protections Go Bad: Exploiting Anti-DoS Measures to Accelerate Rowhammer Attacks, ” inHOST, 2017

    2017

  36. [36]

    Defeating Software Mitigations Against Rowhammer: A Surgical Precision Hammer,

    A. Tatar, C. Giuffrida, H. Bos, and K. Razavi, “Defeating Software Mitigations Against Rowhammer: A Surgical Precision Hammer, ” inRAID, 2018

    2018

  37. [37]

    Another Flip in the Wall of Rowhammer Defenses,

    D. Gruss, M. Lipp, M. Schwarz, D. Genkin, J. Juffinger, S. O’Connell, W. Schoechl, and Y. Yarom, “Another Flip in the Wall of Rowhammer Defenses, ” inS&P, 2018

    2018

  38. [38]

    Nethammer: Inducing Rowhammer Faults Through Network Requests,

    M. Lipp, M. T. Aga, M. Schwarz, D. Gruss, C. Maurice, L. Raab, and L. Lam- ster, “Nethammer: Inducing Rowhammer Faults Through Network Requests, ” arXiv:1805.04956 [cs.CR], 2018

    Pith/arXiv arXiv 2018

  39. [39]

    GuardION: Practical Mitigation of DMA-Based Rowhammer Attacks on ARM,

    V. van der Veen, M. Lindorfer, Y. Fratantonio, H. P. Pillai, G. Vigna, C. Kruegel, H. Bos, and K. Razavi, “GuardION: Practical Mitigation of DMA-Based Rowhammer Attacks on ARM, ” inDIMV A, 2018

    2018

  40. [40]

    Grand Pwning Unit: Accelerating Microarchitectural Attacks with the GPU,

    P. Frigo, C. Giuffrida, H. Bos, and K. Razavi, “Grand Pwning Unit: Accelerating Microarchitectural Attacks with the GPU, ” inS&P, 2018

    2018

  41. [41]

    Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks,

    L. Cojocar, K. Razavi, C. Giuffrida, and H. Bos, “Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks, ” inS&P, 2019

    2019

  42. [42]

    Pinpoint Rowhammer: Suppressing Unwanted Bit Flips on Rowhammer Attacks,

    S. Ji, Y. Ko, S. Oh, and J. Kim, “Pinpoint Rowhammer: Suppressing Unwanted Bit Flips on Rowhammer Attacks, ” inASIACCS, 2019

    2019

  43. [43]

    Terminal Brain Damage: Exposing the Graceless Degradation in Deep Neural Networks Under Hardware Fault Attacks,

    S. Hong, P. Frigo, Y. Kaya, C. Giuffrida, and T. Dumitraş, “Terminal Brain Damage: Exposing the Graceless Degradation in Deep Neural Networks Under Hardware Fault Attacks, ” inUSENIX Security, 2019

    2019

  44. [44]

    RAMBleed: Reading Bits in Memory Without Accessing Them,

    A. Kwong, D. Genkin, D. Gruss, and Y. Yarom, “RAMBleed: Reading Bits in Memory Without Accessing Them, ” inS&P, 2020

    2020

  45. [45]

    JackHammer: Efficient Rowhammer on Heterogeneous FPGA–CPU Platforms,

    Z. Weissman, T. Tiemann, D. Moghimi, E. Custodio, T. Eisenbarth, and B. Sunar, “JackHammer: Efficient Rowhammer on Heterogeneous FPGA–CPU Platforms, ” arXiv:1912.11523 [cs.CR], 2020

    arXiv 1912

  46. [46]

    PThammer: Cross- User-Kernel-Boundary Rowhammer through Implicit Accesses,

    Z. Zhang, Y. Cheng, D. Liu, S. Nepal, Z. Wang, and Y. Yarom, “PThammer: Cross- User-Kernel-Boundary Rowhammer through Implicit Accesses, ” inMICRO, 2020

    2020

  47. [47]

    Deephammer: Depleting the Intelligence of Deep Neural Networks Through Targeted Chain of Bit Flips,

    F. Yao, A. S. Rakin, and D. Fan, “Deephammer: Depleting the Intelligence of Deep Neural Networks Through Targeted Chain of Bit Flips, ” inUSENIX Security, 2020

    2020

  48. [48]

    SMASH: Syn- chronized Many-Sided Rowhammer Attacks from JavaScript,

    F. de Ridder, P. Frigo, E. Vannacci, H. Bos, C. Giuffrida, and K. Razavi, “SMASH: Syn- chronized Many-Sided Rowhammer Attacks from JavaScript, ” inUSENIX Security, 2021

    2021

  49. [49]

    Uncovering in-DRAM RowHammer Protection Mechanisms: A New Methodology, Custom RowHammer Patterns, and Implications,

    H. Hassan, Y. C. Tugrul, J. S. Kim, V. v. d. Veen, K. Razavi, and O. Mutlu, “Uncovering in-DRAM RowHammer Protection Mechanisms: A New Methodology, Custom RowHammer Patterns, and Implications, ” inMICRO, 2021

    2021

  50. [50]

    Blacksmith: Scalable Rowhammering in the Frequency Domain,

    P. Jattke, V. van der Veen, P. Frigo, S. Gunter, and K. Razavi, “Blacksmith: Scalable Rowhammering in the Frequency Domain, ” inS&P, 2022

    2022

  51. [51]

    Toward Realistic Backdoor Injection Attacks on DNNs using RowHammer,

    M. C. Tol, S. Islam, B. Sunar, and Z. Zhang, “Toward Realistic Backdoor Injection Attacks on DNNs using RowHammer, ” arXiv:2110.07683, 2022

    arXiv 2022

  52. [52]

    Half-Double: Hammering From the Next Row Over,

    A. Kogler, J. Juffinger, S. Qazi, Y. Kim, M. Lipp, N. Boichat, E. Shiu, M. Nissler, and D. Gruss, “Half-Double: Hammering From the Next Row Over, ” inUSENIX Security, 2022

    2022

  53. [53]

    SpyHammer: Using RowHammer to Remotely Spy on Temperature,

    L. Orosa, U. Rührmair, A. G. Yaglikci, H. Luo, A. Olgun, P. Jattke, M. Patel, J. Kim, K. Razavi, and O. Mutlu, “SpyHammer: Using RowHammer to Remotely Spy on Temperature, ”IEEE Access, 2022

    2022

  54. [54]

    Implicit Hammer: Cross-Privilege-Boundary Rowhammer through Implicit Accesses,

    Z. Zhang, W. He, Y. Cheng, W. Wang, Y. Gao, D. Liu, K. Li, S. Nepal, A. Fu, and Y. Zou, “Implicit Hammer: Cross-Privilege-Boundary Rowhammer through Implicit Accesses, ”IEEE TDSC, 2022

    2022

  55. [55]

    Generating Robust DNN with Resistance to Bit-Flip based Adversarial Weight Attack,

    L. Liu, Y. Guo, Y. Cheng, Y. Zhang, and J. Yang, “Generating Robust DNN with Resistance to Bit-Flip based Adversarial Weight Attack, ”IEEE TC, 2022

    2022

  56. [56]

    HammerScope: Observing DRAM Power Consumption Using Row- hammer,

    Y. Cohen, K. S. Tharayil, A. Haenel, D. Genkin, A. D. Keromytis, Y. Oren, and Y. Yarom, “HammerScope: Observing DRAM Power Consumption Using Row- hammer, ” inCCS, 2022

    2022

  57. [57]

    TrojViT: Trojan Insertion in Vision Transformers,

    M. Zheng, Q. Lou, and L. Jiang, “TrojViT: Trojan Insertion in Vision Transformers, ” arXiv:2208.13049, 2022

    arXiv 2022

  58. [58]

    When Frodo Flips: End-to-End Key Recovery on FrodoKEM via Rowhammer,

    M. Fahr Jr, H. Kippen, A. Kwong, T. Dang, J. Lichtinger, D. Dachman-Soled, D. Genkin, A. Nelson, R. Perlner, A. Yerukhimovichet al., “When Frodo Flips: End-to-End Key Recovery on FrodoKEM via Rowhammer, ”CCS, 2022

    2022

  59. [59]

    SpecHammer: Combining Spectre and Rowhammer for New Speculative Attacks,

    Y. Tobah, A. Kwong, I. Kang, D. Genkin, and K. G. Shin, “SpecHammer: Combining Spectre and Rowhammer for New Speculative Attacks, ” inS&P, 2022

    2022

  60. [60]

    DeepSteal: Advanced Model Extractions Leveraging Efficient Weight Stealing in Memories,

    A. S. Rakin, M. H. I. Chowdhuryy, F. Yao, and D. Fan, “DeepSteal: Advanced Model Extractions Leveraging Efficient Weight Stealing in Memories, ” inS&P, 2022

    2022

  61. [61]

    {SledgeHammer}: Amplifying rowhammer via bank-level parallelism,

    I. Kang, W. Wang, J. Kim, S. van Schaik, Y. Tobah, D. Genkin, A. Kwong, and Y. Yarom, “{SledgeHammer}: Amplifying rowhammer via bank-level parallelism, ” inUSENIX Security, 2024

    2024

  62. [62]

    {GPUHammer}: Rowhammer attacks on {GPU}memories are practical,

    C. S. Lin, J. Qu, and G. Saileshwar, “{GPUHammer}: Rowhammer attacks on {GPU}memories are practical, ” inUSENIX Security, 2025

    2025

  63. [63]

    Not so refreshing: Attacking{GPUs}using{RFM}rowhammer mitigation,

    R. Nazaraliyev, Y. Zhang, S. B. Dutta, A. Marquez, K. Barker, and N. Abu-Ghazaleh, “Not so refreshing: Attacking{GPUs}using{RFM}rowhammer mitigation, ” in USENIX Security, 2025

    2025

  64. [64]

    Phoenix: Rowhammer Attacks on DDR5 with Self-Correcting Synchronization,

    D. Meyer, P. Jattke, M. Marazzi, S. Qazi, D. Moghimi, and K. Razavi, “Phoenix: Rowhammer Attacks on DDR5 with Self-Correcting Synchronization, ” inS&P, 2026

    2026

  65. [65]

    {ECC. fail}: Mounting rowhammer attacks on{DDR4}servers with{ECC}memory,

    N. Kamadan, W. Wang, S. van Schaik, C. Garman, D. Genkin, and Y. Yarom, “{ECC. fail}: Mounting rowhammer attacks on{DDR4}servers with{ECC}memory, ” inUSENIX Security, 2025

    2025

  66. [66]

    TWiCe: Preventing Row- Hammering by Exploiting Time Window Counters,

    E. Lee, I. Kang, S. Lee, G. Edward Suh, and J. Ho Ahn, “TWiCe: Preventing Row- Hammering by Exploiting Time Window Counters, ” inISCA, 2019

    2019

  67. [67]

    Mitigating Wordline Crosstalk Using Adaptive Trees of Counters,

    S. M. Seyedzadeh, A. K. Jones, and R. Melhem, “Mitigating Wordline Crosstalk Using Adaptive Trees of Counters, ” inISCA, 2018

    2018

  68. [68]

    CAT-TWO: Counter-Based Adaptive Tree, Time Window Optimized for DRAM Row-Hammer Prevention,

    I. Kang, E. Lee, and J. H. Ahn, “CAT-TWO: Counter-Based Adaptive Tree, Time Window Optimized for DRAM Row-Hammer Prevention, ”IEEE Access, 2020

    2020

  69. [69]

    Graphene: Strong yet Lightweight Row Hammer Protection,

    Y. Park, W. Kwon, E. Lee, T. J. Ham, J. H. Ahn, and J. W. Lee, “Graphene: Strong yet Lightweight Row Hammer Protection, ” inMICRO, 2020

    2020

  70. [70]

    Mithril: Cooperative Row Hammer Protection on Commodity DRAM Leveraging Managed Refresh,

    M. J. Kim, J. Park, Y. Park, W. Doh, N. Kim, T. J. Ham, J. W. Lee, and J. H. Ahn, “Mithril: Cooperative Row Hammer Protection on Commodity DRAM Leveraging Managed Refresh, ” inHPCA, 2022. 14

    2022

  71. [71]

    Architectural Support for Mitigating Row Hammering in DRAM Memories,

    D.-H. Kim, P. J. Nair, and M. K. Qureshi, “Architectural Support for Mitigating Row Hammering in DRAM Memories, ”CAL, 2014

    2014

  72. [72]

    Row Hammer Refresh Command,

    K. Bains, J. Halbert, C. Mozak, T. Schoenborn, and Z. Greenfield, “Row Hammer Refresh Command, ” 2015, U.S. Patent 9,117,544

    2015

  73. [73]

    Distributed Row Hammer Tracking,

    K. S. Bains and J. B. Halbert, “Distributed Row Hammer Tracking, ” 2016, U.S. Patent 9,299,400

    2016

  74. [74]

    Row Hammer Monitoring Based on Stored Row Hammer Threshold Value,

    K. S. Bains and J. B. Halbert, “Row Hammer Monitoring Based on Stored Row Hammer Threshold Value, ” US Patent: 10,083,737, 2016, U.S. Patent 9,384,821

    2016

  75. [75]

    CoMeT: Count-min-sketch-based row tracking to mitigate RowHammer at low cost,

    F. N. Bostanci, I. E. Yüksel, A. Olgun, K. Kanellopoulos, Y. C. Tuğrul, A. G. Yağliçi, M. Sadrosadati, and O. Mutlu, “CoMeT: Count-min-sketch-based row tracking to mitigate RowHammer at low cost, ” inHPCA, 2024

    2024

  76. [76]

    Un- derstanding the Security Benefits and Overheads of Emerging Industry Solutions to DRAM Read Disturbance,

    O. Canpolat, A. G. Yağlıkçı, G. F. Oliveira, A. Olgun, O. Ergin, and O. Mutlu, “Un- derstanding the Security Benefits and Overheads of Emerging Industry Solutions to DRAM Read Disturbance, ” inDRAMSec, 2024

    2024

  77. [77]

    Chronus: Understanding and Securing the Cutting-Edge Industry Solutions to DRAM Read Disturbance,

    O. Canpolat, A. G. Yağlıkçı, G. F. Oliveira, A. Olgun, N. Bostancı, I. E. Yuksel, H. Luo, O. Ergin, and O. Mutlu, “Chronus: Understanding and Securing the Cutting-Edge Industry Solutions to DRAM Read Disturbance, ” inHPCA, 2025

    2025

  78. [78]

    JEDEC,JESD79-5C: DDR5 SDRAM Standard, 2024

    2024

  79. [79]

    Panopticon: A Complete In- DRAM Rowhammer Mitigation,

    T. Bennett, S. Saroiu, A. Wolman, and L. Cojocar, “Panopticon: A Complete In- DRAM Rowhammer Mitigation, ” inDRAMSec, 2021

    2021

  80. [80]

    {ABACuS}:{All-Bank}activation counters for scalable and low overhead{RowHammer}mitigation,

    A. Olgun, Y. C. Tugrul, N. Bostanci, I. E. Yuksel, H. Luo, S. Rhyner, A. G. Yaglikci, G. F. Oliveira, and O. Mutlu, “{ABACuS}:{All-Bank}activation counters for scalable and low overhead{RowHammer}mitigation, ” inUSENIX Security, 2024

    2024

Showing first 80 references.