CnC-PRAC: Coalesce, not Cache, Per Row Activation Counts for an Efficient in-DRAM Rowhammer Mitigation

Chris S. Lin; Gururaj Saileshwar; Jeonghyun Woo; Prashant J. Nair

REVIEW 3 major objections 4 minor 49 references

CnC-PRAC: Coalesce, not Cache, Per Row Activation Counts for an Efficient in-DRAM Rowhammer Mitigation

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read CnC-PRAC claims that coalescing counter-row updates makes PRAC-based Rowhammer defense cost under 1% energy with negligible slowdown.

desk verdict A clean coalescing design for PRAC counters that is likely right about activation reduction, but the 'negligible slowdown' claim rests on an unverified DDR5 timing assumption that the paper itself defers. read the letter →

arxiv 2506.11970 v1 pith:7QXHBPCW submitted 2025-06-13 cs.CR

Chris S. Lin , Jeonghyun Woo , Prashant J. Nair , Gururaj Saileshwar This is my paper · ORCID

classification cs.CR

keywords RowhammerPRACDRAMsecurityactivationcountingcountercoalescingDDR5energyoverheadmemorycontroller

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper proposes CnC-PRAC, a way to implement DRAM's per-row activation counting (PRAC) that brings Rowhammer defense close to cost-free. Instead of caching activation counts, it buffers counter-update requests in a small in-DRAM structure and coalesces requests that hit the same counter row into a single row activation. The paper reports that this reduces counter row activations by roughly 75% to 83% compared with a state-of-the-art PRAC design, bringing dynamic energy overhead down to 0.84% to 1% over an insecure DDR5 baseline while keeping slowdown negligible. If correct, precise per-row activation counting is practical at near-zero cost.

What carries the argument

The load-bearing mechanism is an in-DRAM counter request buffer, a small content-addressable memory whose entries store a counter-row identifier, a byte position, and a repeat count. On each data row activation, the counter increment for that row is inserted into the buffer instead of being performed immediately; when K (default 4) requests to the same counter row are present, the buffer issues a single counter-row activation that performs all K read-modify-writes in parallel with a data activation. A unified 64-entry variant tracks the row with the highest outstanding count and removes those entries first, approximating an ideal sorted queue.

What would settle it

Measure on a DDR5 device or a validated DDR5 timing model whether a counter sub-array can service four one-byte read-modify-writes to the same row within the precharge and row-cycle shadow of a data activation; if those column operations serialize and delay precharge, CnC-PRAC's claimed negligible slowdown fails even though activation counting may still be reduced.

Watch

Extended reading notes

Core claim

The central claim is that decoupling counter updates from the critical path of data row activations, and then coalescing buffered counter read-modify-writes that target the same counter row, removes nearly all of the energy overhead that current PRAC implementations pay. Counter requests are collected in a request buffer; when four requests to the same counter row accumulate, one counter-row activation services all four in the shadow of a data activation. The paper evaluates a per-row buffer and a smaller unified buffer and reports that the unified variant retains most of the benefit, reducing counter row activations to about 27% of the state-of-the-art design while using only 192 bytes per bank.

Load-bearing premise

The design assumes that four single-byte counter read-modify-writes to the same counter row can complete within the shadow of one data row activation without changing DDR5 timings; the paper states this assumption and leaves precise DDR5 timing evaluation to future work.

Editorial extensions

If this is right

PRAC-based Rowhammer mitigation could be deployed on DDR5 without the roughly 10% slowdowns reported for inline-counter designs.
Dynamic energy overhead falls to about 1% (0.84% for the per-row variant), making precise counting competitive with insecure DRAM on energy.
Security is preserved deterministically: the back-off threshold is lowered by K so no counter update is ever delayed by more than K activations.
Shrinking the unified buffer from 64 to 16 entries degrades gracefully, raising counter activations from 27% to about 75% of the state-of-the-art design.
The counter sub-array can be protected against its own bit-flips with guard rows or parallel refresh at negligible storage or energy cost.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Beyond the paper: if the K=4 timing assumption holds in silicon, the same coalescing idea could be applied to other per-row DRAM metadata updates that currently stretch row cycle times.
Beyond the paper: the approximate max-count eviction policy suggests that even cheaper counting structures than a full CAM might capture most of the coalescing benefit.
Beyond the paper: a hardware testbed that measures whether four one-byte column RMWs truly overlap within one row activation would settle the main open timing question.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Two things to know about this paper. First, the coalescing request buffer is a genuinely new idea in the PRAC space: prior work either cached counts or put them inline, and this paper shows that buffering and merging updates to the same counter row cuts counter row activations by 75-83% over Chronus in simulation. Second, the paper's central performance claim — negligible slowdown — leans entirely on an assumption stated in Section 3.4: that four single-byte counter RMWs can complete inside one data activation shadow. The paper cites a DDR3 tiered-latency result for smaller arrays and says explicitly that a precise DDR5 evaluation is future work. That is a load-bearing gap, not an afterthought.

What's good: The paper does the right kind of evaluation for a design paper: 57 workloads, multiple buffer designs, a sensitivity analysis tying buffer size to activations and energy, and a reasonable argument for why caching fails (footprint too large). The authors are also transparent about the assumptions they borrow from Chronus (19% extra activation energy) and about what they don't model (static/background energy). That transparency is credible.

Soft spots: The timing issue is the big one. Their own Figure 8 shows that a smaller coalescing batch increases activations from 27% to 75% of Chronus; if K drops from 4 to 2, the headline numbers would look much worse, even if the design still helps. The energy numbers are also dynamic-only, and the static power of the unified buffer (4.3 mW per chip) is not negligible against a chip-scale energy budget. They leave a more accurate background-energy estimate to future work, which is fine, but it means the '0.84-1% overhead' is a lower bound, not a complete accounting. No artifacts are provided, which makes it harder to check the simulator changes.

Who it's for: DRAM security and architecture researchers. The paper is a solid design optimization within the PRAC research program; if the timing assumption is validated by measurements or more detailed simulation, it's a meaningful step toward practical PRAC. The open question is exactly the kind of thing a good referee should push on.

Recommendation: This deserves a serious referee. It's not a desk reject, and the conditional verdict is right — the central idea stands on its own, but the evaluation's headline numbers need to be pinned down. I'd engage with it.

Referee Report

3 major / 4 minor

Summary. The paper presents CnC-PRAC, an in-DRAM Rowhammer mitigation built on the PRAC framework and the Chronus disjoint counter sub-array. It decouples counter read-modify-write operations from the data-access critical path and buffers them in a small CAM structure, coalescing multiple counter updates that map to the same counter row so that a single counter row activation serves several increments. The authors evaluate two buffer organizations (per-row and unified) with Ramulator2 on 57 workloads, reporting counter row activation reductions of 72.9%-82.4% relative to Chronus, dynamic energy overhead of 0.84%-1% relative to an insecure DDR5 baseline, and negligible slowdown.

Significance. If the central timing assumption (four single-byte counter RMWs in one data-activation shadow) holds, the result is a practical and significant step toward low-overhead PRAC: it retains the determinism of per-row counters while avoiding the 10%-class slowdown of inline-counter designs and the added activation energy of Chronus. The coalescing idea is well motivated by the locality analysis, and the paper is honest about its assumptions, explicitly deferring DDR5 timing verification and background-energy modeling to future work. The simulator-based evaluation is standard for this community, and the sensitivity analysis on buffer size gives useful insight.

major comments (3)

[§3.4] The paper's central quantitative claims—75-83% reduction in counter row activations, 0.84-1% dynamic energy overhead, and negligible slowdown—all depend on the assumption in §3.4 that K=4 single-byte counter RMWs to the same counter row can be completed within the shadow of one data row activation. The manuscript explicitly states 'we assume K = 4. A precise evaluation of these timings for DDR5 is left for future work,' and the only cited support is [16], a DDR3 tiered-latency DRAM study. This is load-bearing: if the valid batch size is smaller, the coalescing benefit shrinks (the paper's own Figure 8 shows a 16-entry buffer roughly triples counter activations), and the 'negligible slowdown' claim may fail. Please either provide a DDR5-timing-grounded validation (published timings, circuit-level modeling, or a conservative timing model) or re-run the evaluation with a range of K values and restate the conclusions accordingly.
[§4.3] The energy comparison is limited to dynamic energy. Footnote 2 of §4.3 states that the counter sub-array is assumed to consume 19% of the background energy of the data sub-array, and that 'a more accurate estimation of the background energy is left for future work.' In addition, the unified request buffer is estimated to draw 4.3 mW per chip of static power, yet the paper does not compare this to typical DRAM background power or add it to the reported energy overheads. Since the paper's title and abstract promise efficient PRAC, the total-energy picture (including static/buffer power) should be quantified; as written, the '1% overhead' refers only to dynamic energy.
[§3.2] The security argument is stated but not proven. The paper asserts in §3.2 that no counter request is buffered for more than K repeated activations because an entry is removed when RepCount reaches K, and that lowering the back-off threshold by K preserves Rowhammer security. However, the manuscript does not analyze worst-case timing under adversarial traffic when multiple rows require simultaneous removal or when the counter sub-array is busy; the removal RMW itself takes time, and it is not shown that the lag never exceeds K. Because 'no security impact' is a headline contribution, a formal invariant or an adversarial evaluation (e.g., alternating multi-bank patterns that fill the buffer) is needed.

minor comments (4)

[§4.3] The claim that both Chronus and CnC-PRAC have 'negligible performance overheads (below 0.5%)' is stated without a corresponding performance figure or table; please include the data.
[§3.2 and §3.4] The symbols M and K are both set to 4 but serve different roles (coalescing batch size vs. security threshold); please define them distinctly and use them consistently throughout.
[§4.3] The static power comparison is numerically imprecise: the text says the per-row design's 0.25 mW is 'around 20× less' than the unified design's 4.3 mW, but 4.3/0.25 is approximately 17×.
[Figure 3] The y-axis label says 'Average Same Counter Row Requests' while the caption describes the highest number of requests within a window; please align the label with the metric actually plotted.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: the core coalescing result is a simulated activation reduction, with a load-bearing K=4 timing assumption and a self-cited QPRAC service queue as inputs rather than circular derivations.

full rationale

The derivation chain for the main result—75%-83% reduction in counter row activations relative to Chronus—is self-contained: it is obtained by simulating the request-buffer coalescing policies (PerRow vs. Unified) in Ramulator2 and comparing normalized counter subarray activations (Figure 6). No equation is fitted to the target reduction, and the reduction is not defined in terms of the coalescing parameters by construction; it is a measured consequence of the buffering policy. The dynamic-energy overhead (0.84%-1%) is a derived quantity: it multiplies simulated counter activation counts by the 19% per-activation energy ratio explicitly imported from Chronus [13], so it inherits that modeling assumption but does not reduce to a self-fit. The only self-citation affecting the evaluation is QPRAC's priority-based mitigation service queue (Section 4.1), used for both Chronus and CnC-PRAC; this is an external, peer-reviewed input, not a result being re-derived here, and it does not force the activation-reduction claim. The key caveat is not circularity but unverified timing: Section 3.4 states 'we assume K = 4. A precise evaluation of these timings for DDR5 is left for future work,' and the negligible-slowdown and activation-reduction numbers depend on four single-byte counter RMWs fitting in the shadow of one data activation, with Figure 8 showing sensitivity to buffer size. That is a load-bearing empirical assumption, not a circular derivation. No circular step is therefore scored.

Assumptions & free parameters 3 free parameters · 5 assumptions · 1 invented entities

The design relies on the Chronus substrate, several hand-picked parameters (M, K, buffer size), and three unverified assumptions: counter RMW timing, 19 percent energy ratio, and security of threshold reduction. The request buffer is a new simulated structure with no independent physical evidence.

free parameters (3)

Coalescing batch size M = 4
Chosen so four 1-byte counter RMWs fit in the shadow of one 8-byte data access; feasibility assumed, not measured for DDR5 (Sections 3.2 and 3.4).
RepCount security threshold K = 4
Limits delayed increments per counter to 4 and reduces back-off threshold from 32 to 28; hand-set as sufficient for capturing counter hits (Section 3.2).
Request buffer size (unified) = 64 entries
Set to the number of counter rows per bank; sensitivity analysis shows activations rise from 27% to 75% of Chronus when reduced to 16 entries (Section 4.4).

assumptions (5)

domain assumption Counters stored in a separate counter sub-array can be activated in parallel with data rows (Chronus substrate).
Adopted from Chronus [13]; enables decoupling of counter access from the critical path (Sections 2.2, 3).
ad hoc to paper Four single-byte counter RMWs can complete within the shadow of one data row activation without increasing DRAM timings.
Stated in Section 3.4; relies on prior small-array timing work [16] but no DDR5 measurement; paper defers precise evaluation to future work.
domain assumption A counter sub-array activation consumes 19% extra energy compared to a data row activation.
Taken from Chronus [13] and used for all dynamic energy estimates in Section 4.3.
ad hoc to paper Lowering the back-off threshold by K preserves Rowhammer security when counter updates lag by up to K increments.
Plausible bounding argument in Sections 3.2 and 3.5; no formal proof or adversarial pattern analysis is provided.
domain assumption Ramulator2 models DDR5 performance and energy accurately enough for the reported comparisons.
Standard simulator used by prior Rowhammer works [20,21]; no validation against real DDR5 silicon in this paper.

invented entities (1)

In-DRAM counter request buffer (CAM structure)
purpose: Buffers and coalesces counter update requests to the same counter row, reducing counter row activations.
The buffer exists only in simulation; area and power are estimated with Eva-CAM and CACTI (Section 4.3), not measured in silicon.

how reviews work

0 comments

Cite this review

Pith. "Pith review of CnC-PRAC: Coalesce, not Cache, Per Row Activation Counts for an Efficient in-DRAM Rowhammer Mitigation." pith.science (2026). https://pith.science/paper/7QXHBPCW

@misc{pith2026250611970,
  author       = {Pith},
  title        = {Pith review of: CnC-PRAC: Coalesce, not Cache, Per Row Activation Counts for an Efficient in-DRAM Rowhammer Mitigation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7QXHBPCW}},
  note         = {Machine review of arXiv:2506.11970}
}

read the original abstract

JEDEC has introduced the Per Row Activation Counting (PRAC) framework for DDR5 and future DRAMs to enable precise counting of DRAM row activations using per-row activation counts. While recent PRAC implementations enable holistic mitigation of Rowhammer attacks, they impose slowdowns of up to 10% due to the increased DRAM timings for performing a read-modify-write of the counter. Alternatively, recent work, Chronus, addresses these slowdowns, but incurs energy overheads due to the additional DRAM activations for counters. In this paper, we propose CnC-PRAC, a PRAC implementation that addresses both performance and energy overheads. Unlike prior works focusing on caching activation counts to reduce their overheads, our key idea is to reorder and coalesce accesses to activation counts located in the same physical row. Our design achieves this by decoupling counter access from the critical path of data accesses. This enables optimizations such as buffering counter read-modify-write requests and coalescing requests to the same row. Together, these enable a reduction in row activations for counter accesses by almost 75%-83% compared to state-of-the-art solutions like Chronus and enable a PRAC implementation with negligible slowdown and a minimal dynamic energy overhead of 0.84%-1% compared to insecure DDR5 DRAM.

Figures

Figures reproduced from arXiv: 2506.11970 by the authors.

**Figure 2.** The skew (max/mean) of accesses across the 64 rows [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** The highest number of same row counter requests [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

Figures from the paper (7 more)

**Figure 4.** Figure 4: Design of CnC-PRAC. Any data row activation inserts a counter request into the buffer. An entry is removed when M requests to the same row can be coalesced, if the buffer is full, or if it requires removal for security. 3 [PITH_FULL_IMAGE:figures/full_fig_p003_4.png]

**Figure 5.** Figure 5: Designs for the Counter Request Buffer in CnC-PRAC [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]

**Figure 6.** Figure 6: Normalized counter row activations for the different request buffer (RB) designs including Unified RB - FCFS (using the [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]

**Figure 7.** Figure 7: Dynamic energy overhead of Chronus and CnC-PRAC, normalized to non-secure baseline. Compared to Chronus, which [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]

**Figure 8.** Figure 8: Sensitivity of CnC-PRAC-Unified’s counter row activations as the request buffer size varies. Reducing to 1/4 of the original size results in an increase of normalized activation from 27.1% to 74.7%. 5. Why Not Cache Row Activation Counts? CnC-PRAC advocates for coales…

**Figure 9.** Figure 9: Activations to unique DRAM rows across 64 banks, sorted by activation count. We classify workloads into (a) small, (b) [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]

**Figure 10.** Figure 10: Counter row activations with CnC-PRAC without [PITH_FULL_IMAGE:figures/full_fig_p007_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 48 canonical work pages

[16]

Tiered-latency dram: A low latency and low cost dram architecture,

D. Lee, Y. Kim, V. Seshadri, J. Liu, L. Subramanian, and O. Mutlu, “Tiered-latency dram: A low latency and low cost dram architecture, ” in2013 IEEE 19th International Symposium on High Performance Computer Architecture (HPCA) , 2013, pp. 615–626

work page 2013
[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, ”ISCA, 2014

work page 2014
[2]

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, vol. 15, p. 71, 2015

work page 2015
[3]

TRRespass: Exploiting the many sides of target row refresh,

P. Frigo, E. Vannacc, H. Hassan, V. Van Der Veen, O. Mutlu, C. Giuffrida, H. Bos, and K. Razavi, “TRRespass: Exploiting the many sides of target row refresh, ” inIEEE Symposium on Security and Privacy , 2020

work page 2020
[4]

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, ” inIEEE Symposium on Security and Privacy , 2018

work page 2018
[5]

Anvil: Software-based protection against next-generation rowhammer attacks,

Z. B. Aweke, S. F. Yitbarek, R. Qiao, R. Das, M. Hicks, Y. Oren, and T. Austin, “Anvil: Software-based protection against next-generation rowhammer attacks, ” inASPLOS, 2016

work page 2016
[6]

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, ” inIEEE Symposium on Security and Privacy (SP) , 2019

work page 2019
[7]

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, ” inDetection of Intrusions and Malware, and Vulnerability Assessment, 2016

work page 2016

Show all 49 references

[8]

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, ” inACM-CCS, 2016

2016
[9]

Revisiting rowhammer: An experimental analysis of modern dram devices and mitigation techniques,

J. S. Kim, M. Patel, A. G. Yağlıkçı, H. Hassan, R. Azizi, L. Orosa, and O. Mutlu, “Revisiting rowhammer: An experimental analysis of modern dram devices and mitigation techniques, ” inISCA, 2020

2020
[10]

JESD79-5C

J EDEC. JESD79-5C. https://www.jedec.org/document_search?search_api_views_ fulltext=jesd79-5c
[11]

MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters,

M. Qureshi and S. Qazi, “MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters, ” inProceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS) , 2025. 7

2025
[12]

QPRAC: Towards secure and practical prac-based rowhammer mitigation using priority queues,

J. Woo, S. C. Lin, P. J. Nair, A. Jaleel, and G. Saileshwar, “QPRAC: Towards secure and practical prac-based rowhammer mitigation using priority queues, ” in2025 IEEE International Symposium on High Performance Computer Architecture (HPCA) . IEEE, 2025, pp. 1021–1037

2025
[13]

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, ” in2025 IEEE International Symposium on High Performance Comput...

2025
[14]

A case for exploiting subarray-level parallelism (salp) in dram,

Y. Kim, V. Seshadri, D. Lee, J. Liu, and O. Mutlu, “A case for exploiting subarray-level parallelism (salp) in dram, ” in2012 39th Annual International Symposium on Computer Architecture (ISCA), 2012, pp. 368–379

2012
[15]

Panopticon: A complete in-dram rowhammer mitigation,

T. Bennett, S. Saroiu, A. Wolman, and L. Cojocar, “Panopticon: A complete in-dram rowhammer mitigation, ” inWorkshop on DRAM Security (DRAMSec) , 2021

2021
[17]

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, ” inInternational Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. S...

2018
[18]

ZebRAM: comprehensive and compatible software protection against rowhammer attacks,

R. K. Konoth, M. Oliverio, A. Tatar, D. Andriesse, H. Bos, C. Giuffrida, and K. Razavi, “ZebRAM: comprehensive and compatible software protection against rowhammer attacks, ” in13th USENIX - (OSDI 18) , 2018, pp. 697–710

2018
[19]

REGA: Scalable Rowhammer Mitigation with Refresh-Generating Activations,

M. Marazzi, F. Solt, P. Jattke, K. Takashi, and K. Razavi, “REGA: Scalable Rowhammer Mitigation with Refresh-Generating Activations, ” inIEEE Symposium on Security and Privacy (SP). IEEE, 2023

2023
[20]

Ramulator: A fast and extensible dram simulator,

Y. Kim, W. Yang, and O. Mutlu, “Ramulator: A fast and extensible dram simulator, ” IEEE Computer architecture letters , vol. 15, no. 1, pp. 45–49, 2015

2015
[21]

Ramulator 2.0: A modern, modular, and extensible dram simulator,

H. Luo, Y. C. Tuğrul, F. N. Bostancı, A. Olgun, A. G. Yağlıkçı, and O. Mutlu, “Ramulator 2.0: A modern, modular, and extensible dram simulator, ”IEEE Computer Architecture Letters, vol. 23, no. 1, pp. 112–116, 2024

2024
[22]

Blockhammer: Preventing rowhammer at low cost by blacklist- ing rapidly-accessed dram rows,

A. G. Yağlikçi et al., “Blockhammer: Preventing rowhammer at low cost by blacklist- ing rapidly-accessed dram rows, ” inHPCA, 2021

2021
[23]

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, ” in2024 IEEE International Symposium on High- Performance Computer Architecture ...

2024
[24]

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, ” in33rd USENIX Security Symposium (USENIX Security 24) . Philadelphia,...

2024
[25]

Hira: Hidden row activation for reducing refresh latency of off-the-shelf dram chips,

A. G. Yağlikçi, A. Olgun, M. Patel, H. Luo, H. Hassan, L. Orosa, O. Ergin, and O. Mutlu, “Hira: Hidden row activation for reducing refresh latency of off-the-shelf dram chips, ” in MICRO, 2022

2022
[26]

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-50, 2023

2023
[27]

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, ” inWorkshop on DRAM Security (DRAMSec) , 2024

2024
[28]

Dapper: A performance-attack-resilient tracker for rowham- mer defense,

J. Woo and P. J. Nair, “Dapper: A performance-attack-resilient tracker for rowham- mer defense, ” in2025 IEEE International Symposium on High-Performance Computer Architecture (HPCA), 2025

2025
[29]

Spec cpu2006 benchmark suite,

S. P. E. Corporation, “Spec cpu2006 benchmark suite, ” 2006. [Online]. Available: http://www.spec.org/cpu2006/

2006
[30]

SPEC CPU2017 Benchmark Suite,

“SPEC CPU2017 Benchmark Suite, ” Standard Performance Evaluation Corporation. [Online]. Available: http://www.spec.org/cpu2017/
[31]

TPC Benchmarks

Transaction Processing Performance Council, “TPC Benchmarks. ” [Online]. Available: http://tpc.org/
[32]

Apache hadoop

A. Foundation, “Apache hadoop. ” [Online]. Available: http://hadoop.apache.org/
[33]

Mediabench ii video: Expediting the next generation of video systems research,

J. E. Fritts, F. W. Steiling, J. A. Tucek, and W. Wolf, “Mediabench ii video: Expediting the next generation of video systems research, ”Microprocessors and Microsystems, vol. 33, no. 4, pp. 301–318, 2009

2009
[34]

Benchmarking cloud serving systems with ycsb,

B. F. Cooper, A. Silberstein, E. Tam, R. Ramakrishnan, and R. Sears, “Benchmarking cloud serving systems with ycsb, ” inProceedings of the 1st ACM symposium on Cloud computing, 2010, pp. 143–154

2010
[35]

ABACuS — GitHub Repository,

SAFARI Research Group, “ABACuS — GitHub Repository, ” 2023. [Online]. Available: https://github.com/CMU-SAFARI/ABACuS

2023
[36]

Eva-cam: A circuit/architecture-level evaluation tool for general content addressable memories,

L. Liu, M. M. Sharifi, R. Rajaei, A. Kazemi, K. Ni, X. Yin, M. Niemier, and X. S. Hu, “Eva-cam: A circuit/architecture-level evaluation tool for general content addressable memories, ” in2022 Design, Automation & Test in Europe Conference & Exhibition (DATE), 2022, pp. 1173–1176

2022
[37]

Cacti 7: New tools for interconnect exploration in innovative off-chip memories,

R. Balasubramonian, A. B. Kahng, N. Muralimanohar, A. Shafiee, and V. Srinivas, “Cacti 7: New tools for interconnect exploration in innovative off-chip memories, ” ACM Transactions on Architecture and Code Optimization (TACO) , vol. 14, no. 2, pp. 1–25, 2017

2017
[38]

Uncov- ering in-dram rowhammer protection mechanisms: A new methodology, custom rowhammer patterns, and implications,

H. Hassan, Y. C. Tugrul, J. S. Kim, V. Van der Veen, K. Razavi, and O. Mutlu, “Uncov- ering in-dram rowhammer protection mechanisms: A new methodology, custom rowhammer patterns, and implications, ” inMICRO-54, 2021, pp. 1198–1213

2021
[39]

Protrr: Principled yet optimal in-dram target row refresh,

M. Marazzi, P. Jattke, F. Solt, and K. Razavi, “Protrr: Principled yet optimal in-dram target row refresh, ” inIEEE Symposium on Security and Privacy (SP) . IEEE, 2022, pp. 735–753

2022
[40]

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. IEEE, 2020, pp. 1–13

2020
[41]

An ultra-dense 2fefet tcam design based on a multi-domain fefet model,

X. Yin, K. Ni, D. Reis, S. Datta, M. Niemier, and X. S. Hu, “An ultra-dense 2fefet tcam design based on a multi-domain fefet model, ”IEEE Transactions on Circuits and Systems II: Express Briefs , vol. 66, no. 9, pp. 1577–1581, 2019

2019
[42]

Hydra: enabling low-overhead mitigation of row-hammer at ultra-low thresholds via hybrid tracking,

M. Qureshi, A. Rohan, G. Saileshwar, and P. J. Nair, “Hydra: enabling low-overhead mitigation of row-hammer at ultra-low thresholds via hybrid tracking, ” in ISCA, 2022

2022
[43]

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
[44]

TWiCe: preventing row-hammering by exploiting time window counters,

E. Lee, I. Kang, S. Lee, G. E. Suh, and J. H. Ahn, “TWiCe: preventing row-hammering by exploiting time window counters, ” inISCA, 2019

2019
[45]

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

2022
[46]

Dsac: Low-cost rowhammer mitigation using in-dram stochastic and approximate counting algo- rithm,

S. Hong, D. Kim, J. Lee, R. Oh, C. Yoo, S. Hwang, and J. Lee, “Dsac: Low-cost rowhammer mitigation using in-dram stochastic and approximate counting algo- rithm, ”arXiv:2302.03591, 2023

2023 arXiv
[47]

W. Kim, C. Jung, S. Yoo, D. Hong, J. Hwang, J. Yoon, O. Jung, J. Choi, S. Hyun, M. Kang, S. Lee, D. Kim, S. Ku, D. Choi, N. Joo, S. Yoon, J. Noh, B. Go, C. Kim, S. Hwang, M. Hwang, S.-M. Yi, H. Kim, S. Heo, Y. Jang, K. Jang, S. Chu, Y. Oh, K. Kim, J. Kim, S. Kim, J. Hwang, S. ...

2023
[48]

Pride: Achieving secure rowham- mer mitigation with low-cost in-dram trackers,

A. Jaleel, G. Saileshwar, S. Keckler, and M. Qureshi, “Pride: Achieving secure rowham- mer mitigation with low-cost in-dram trackers, ” inAnnual International Symposium on Computer Architecture, 2024

2024
[49]

Tinylfu: A highly efficient cache admission policy,

G. Einziger, R. Friedman, and B. Manes, “Tinylfu: A highly efficient cache admission policy, ”ACM Transactions on Storage (ToS), vol. 13, no. 4, pp. 1–31, 2017. 8

2017

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [16]

Tiered-latency dram: A low latency and low cost dram architecture,

D. Lee, Y. Kim, V. Seshadri, J. Liu, L. Subramanian, and O. Mutlu, “Tiered-latency dram: A low latency and low cost dram architecture, ” in2013 IEEE 19th International Symposium on High Performance Computer Architecture (HPCA) , 2013, pp. 615–626

work page 2013

[2] [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, ”ISCA, 2014

work page 2014

[3] [2]

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, vol. 15, p. 71, 2015

work page 2015

[4] [3]

TRRespass: Exploiting the many sides of target row refresh,

P. Frigo, E. Vannacc, H. Hassan, V. Van Der Veen, O. Mutlu, C. Giuffrida, H. Bos, and K. Razavi, “TRRespass: Exploiting the many sides of target row refresh, ” inIEEE Symposium on Security and Privacy , 2020

work page 2020

[5] [4]

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, ” inIEEE Symposium on Security and Privacy , 2018

work page 2018

[6] [5]

Anvil: Software-based protection against next-generation rowhammer attacks,

Z. B. Aweke, S. F. Yitbarek, R. Qiao, R. Das, M. Hicks, Y. Oren, and T. Austin, “Anvil: Software-based protection against next-generation rowhammer attacks, ” inASPLOS, 2016

work page 2016

[7] [6]

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, ” inIEEE Symposium on Security and Privacy (SP) , 2019

work page 2019

[8] [7]

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, ” inDetection of Intrusions and Malware, and Vulnerability Assessment, 2016

work page 2016