Pith. sign in

REVIEW 3 major objections 6 minor 67 references

QPRAC: Towards Secure and Practical PRAC-based Rowhammer Mitigation using Priority Queues

T0 review · 3 major / 6 minor · reviewed 2026-08-09 · deepseek-v4-flash

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

Pith's one-line read QPRAC claims that a priority-based service queue makes JEDEC's PRAC Rowhammer defense both secure and practical at sub-100 thresholds.

desk verdict QPRAC's priority-queue design and corrected PRAC analysis are real contributions, the evaluation is solid and reproducible, but the 'deterministic security' claim is ahead of the proof: the worst-case attack model is assumed, not proven. read the letter →

arxiv 2501.18861 v5 pith:SF5VZCQU submitted 2025-01-31 cs.CR

Jeonghyun Woo , Chris S. Lin , Prashant J. Nair , Aamer Jaleel , Gururaj Saileshwar This is my paper · ORCID
classification cs.CR
keywords RowhammerPRACDDR5priorityqueueAlertBack-OffDRAMsecurityRowhammermitigationactivationcounting
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

QPRAC is a design for implementing JEDEC's Per Row Activation Counting (PRAC) framework in DDR5 DRAM that aims to make Rowhammer mitigation both secure and practical at very low Rowhammer thresholds. The paper argues that existing PRAC-based defenses are either insecure, because FIFO service queues can be bypassed during the non-blocking Alert window, or impractical, because they require reading all activation counters on each Alert. QPRAC replaces the FIFO with a small priority-based service queue that always keeps the highest-activated rows, and it adds opportunistic and proactive mitigation opportunities. The authors claim that with a queue size of at least the number of RFMs per Alert, QPRAC provides deterministic security matching an ideal PRAC implementation, supporting thresholds as low as 22 and 71 in its default configuration with 0.8% slowdown or less. This matters because future DRAM generations are expected to have Rowhammer thresholds below 100, and current mitigations do not scale to that regime.

What carries the argument

The key mechanism is the Priority-Based Service Queue (PSQ), a per-bank queue that stores row IDs and their activation counts, sorted in descending order of count, and is designed to be full at all times. On each activation, if the activated row's count exceeds the minimum entry in the queue, that entry is evicted and the new row is inserted, so the queue always tracks the highest-activated rows even when an Alert window delivers extra activations. This design prevents the 'bypass when full' attack that breaks FIFO-based queues: a row hammered during the Alert window cannot escape tracking because it inserts by priority. The PSQ also drives the mitigation policy: when its highest count crosses the back-off threshold NBO, an Alert is raised and the top rows are mitigated in priority order, with blast-radius victim refreshes.

What would settle it

Run a custom attack in the paper's simulator (or on real DDR5 with PRAC) that alternates between two disjoint row sets so that the PSQ's minimum entry is always a low-count row, while a target row is hammered only during Alert windows; if the target row's activation count exceeds NBO + Nonline (e.g., NBO + 46 for PRAC-1 at NBO=1) without any mitigation, the deterministic security claim is false.

Watch

Extended reading notes

Core claim

The central claim is that QPRAC achieves deterministic Rowhammer security at sub-100 thresholds while remaining practical and spec-compliant. Specifically, the paper shows that a priority-based service queue of size N ≥ Nmit (the number of RFMs per Alert) makes QPRAC's security identical to that of an 'ideal' PRAC that always mitigates the globally top-N activated rows, even under optimized wave/feinting attacks with transitive blast-radius effects. Under this model, QPRAC is secure for Rowhammer thresholds as low as 44, 29, and 22 at a back-off threshold NBO of 1 with 1, 2, or 4 RFMs per Alert, and for a threshold of 71 at the default NBO=32 with 1 RFM/Alert. The paper additionally shows that opportunistic mitigation on all-bank RFMs and energy-aware proactive mitigation during refresh reduce the slowdown to 0.8% and 0%, respectively, on benign workloads, with 15 bytes of storage per bank.

Load-bearing premise

The security bounds assume that the wave/feinting attack—extended with transitive blast-radius effects—is the strongest possible attack on a PRAC-based defense, and that any attack forcing the PSQ to mitigate locally-maximum rows is sub-optimal.

Editorial extensions

If this is right

  • If QPRAC's security analysis is correct, DRAM vendors can implement PRAC with a 5-entry priority queue per bank and achieve deterministic Rowhammer protection at thresholds as low as 71 with 1 RFM per Alert, without modifying the JEDEC specification.
  • With the energy-aware proactive mitigation scheme, the performance overhead drops to 0% on benign workloads while energy overhead stays near 1.9%, making sub-100 threshold protection essentially free for typical usage.
  • QPRAC scales to 4 RFMs per Alert, lowering the supported threshold to 22 at NBO=1, and maintains under 1% slowdown across queue sizes from 1 to 5, giving vendors flexibility in choosing a queue size.
  • Compared with existing in-DRAM mitigations that lose 7% to 69% performance at thresholds between 64 and 512, QPRAC's near-zero overhead at those thresholds could extend the usable life of DDR5 as thresholds fall.

Reading between the lines

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

  • We infer that the 'always full' priority-queue principle is a general antidote to insertion-bypass attacks: any tracking structure that evicts the lowest-count entry instead of the oldest entry retains information about the most dangerous rows, so the idea could transfer beyond PRAC to other defense contexts.
  • The security bound rests on a worst-case attack model (wave/feinting); a new attack that deliberately forces mitigations of locally-maximum rows while holding a global maximum outside the queue could shift the bounds, so the claimed TRH numbers should be re-verified against adaptive attacks not covered by the model.
  • The paper's performance-attack analysis shows that the all-bank RFM interface is the main bottleneck at NBO below 64; we infer that a per-bank RFM command, which the paper discusses as a specification change, would be the natural next step for making very low thresholds affordable under adversarial load.
  • We also infer that the 7-bit per-row counter sizing derived from the worst-case bound could be re-derived for any new threat model; if a stronger attack is found, the counter size and the queue threshold would need to grow together.
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.

Referee Report

3 major / 6 minor

Summary. The paper proposes QPRAC, an implementation of the JEDEC PRAC framework for DDR5 that uses a small per-bank priority-based service queue (PSQ) to track the most activated rows and issue Rowhammer mitigations on Alert Back-Off (ABO) events. The authors argue that FIFO-based PRAC implementations such as Panopticon are insecure under the non-blocking ABO protocol, and that queue-free designs such as UPRAC are impractical. QPRAC mitigates the highest-count row(s) in the PSQ on each Alert, performs opportunistic mitigations for all banks on all-bank RFMs, and optionally performs proactive mitigations during refresh, with an energy-aware variant gated by threshold NPRO. The security analysis models a wave/feinting attack against an idealized PRAC that mitigates the global top-N rows, derives a recurrence (Eq. 3) for the online-phase activation count, and claims that a PSQ of size at least Nmit achieves the same security as the ideal. The paper reports deterministic security at Rowhammer thresholds as low as 22 (NBO=1, 4 RFMs/Alert) and 71 at the default NBO=32 with 1 RFM/Alert, with 0.8% slowdown (0% with proactive mitigations) and 15 bytes of storage per bank.

Significance. If correct, QPRAC would be a significant step toward practical in-DRAM Rowhammer mitigation at sub-100 thresholds, with negligible performance overhead and a storage footprint far smaller than prior trackers. The paper is unusually strong on reproducibility: the artifact includes Python scripts that regenerate the security figures and a Ramulator2-based performance simulation with traces. The analytical model's predictions match the wave-attack simulations within 1%. The performance evaluation across 57 workloads and the comparison with Mithril, PrIDE, and MOAT are useful. The main reservation is that the deterministic security claim rests on an informal worst-case argument rather than a formal invariant or exhaustive search, and the energy-aware default variant lacks a quantitative security bound; both need to be addressed before the headline claims can be taken at face value.

major comments (3)
  1. [Section IV.B, Eq. (3)] The central security claim that the wave/feinting recurrence in Eq. (3) bounds the worst case for QPRAC is not formally established. The 'Alternative Attacks Are Inferior' paragraph in Section IV.B argues by example that any attack forcing mitigations on locally maximum rows is sub-optimal, but it does not prove that no schedule can keep a high-count row outside the PSQ while successively boosting sacrificial entries above it. The insertion rule uses a strictly-greater-than comparison against the PSQ minimum, and the ABOACT window permits activations after an Alert; the argument in Section IV.B does not bound the cumulative effect of such activations across successive Alert cycles. Because the headline TRH values (22, 71, etc.) are derived from Eq. (3) under a specific uniform wave schedule, the authors should either (a) provide a formal invariant showing that every row outside the PSQ is reinserted after a bounded number of activations independent of the schedule, or (b) qualify the abstract and Section III.C.3 claims as security against known wave/feinting attacks. The supplied artifact scripts evaluate Eqs. (2)-(3) for the wave attack only and do not search the space of adversarial schedules, so they cannot close this gap.
  2. [Section IV.C and Table III] QPRAC+Proactive-EA is presented as the default energy-optimized design, yet no security analysis is provided for it. The paper states only that it 'achieves a security level between QPRAC and QPRAC+Proactive' and that it reduces the setup-phase pool to a lesser extent than proactive mitigation on every REF. Since NPRO determines which proactive mitigations are skipped, the supported TRH for this variant depends on NPRO; without a quantitative analysis, the security guarantee for the configuration recommended in the abstract and evaluation (Table III, Figure 13) is unsupported. Please derive the worst-case TRH as a function of NPRO (e.g., by modeling the setup-phase mitigation rate with the threshold) or state explicitly which TRH values are claimed for QPRAC+Proactive-EA.
  3. [Section VI.F] The reported energy per activation for PSQ logic, '0.23 µJ per ACT', is inconsistent with the accompanying statement that this is 'just 0.05% of the activation energy' for a DDR5 device. Per-activation DRAM energy is on the order of a few nanojoules, so 0.23 µJ (230 nJ) would be roughly two orders of magnitude larger, not 0.05% of the activation energy. This appears to be a unit error (likely 0.23 nJ). Because Table III and Section VI.F use this number to support the negligible-energy-overhead conclusion, the authors should correct the unit and re-verify the percentages.
minor comments (6)
  1. [Section I] The word 'Opportuinsitc' in the introduction should be 'Opportunistic'.
  2. [Section IV.C.2] The word 'Onlie' in the subsection heading should be 'Online'.
  3. [Table III] The phrase 'PRAC Level' is used without definition; please state that it refers to the number of RFMs per Alert (PRAC-1/2/4).
  4. [Section III.D.2 and III.E] The minimum PSQ size is stated as Nmit in Section III.C.3 and as Nmit+1 for proactive mitigation in Section III.E; please clarify that the 5-entry design is chosen to support Nmit up to 4 plus one refresh-time mitigation, and that a smaller PSQ (Nmit+1) suffices for PRAC-1 with proactive mitigation.
  5. [Abstract and Section VII.A] The claim 'first secure, scalable, and practical' should be qualified given the concurrent MOAT work discussed in Section VII.A; please clarify how the comparison is positioned relative to that publication.
  6. [Figure 15] The y-axis label and caption use different phrasings for the same quantity ('ABO occurrences per tREFI interval' versus 'Alert Back-Off (ABO) occurrences'); please make the terminology consistent.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the TRH bounds are derived from a parameter-free attack model and verified by independent simulation; the priority-queue equivalence is argued under the same wave/feinting attack model, not fitted to the claimed outcomes.

full rationale

The central security derivation is self-contained. Equations (1)-(3) define an analytical worst-case model for the wave/feinting attack using stated parameters (NBO, Nmit, ABOACT, ABODelay, BR, tREFW) taken from the JEDEC PRAC specification and prior attack literature; the minimum TRH values (44/29/22 at NBO=1, and 71 at NBO=32) are direct outputs of these recurrences, not fitted values. The Ramulator2 simulations reproduce the analytical Nonline within 1% and are used for validation, not for tuning any parameter to force the headline numbers. Section IV.B's claim that a size-Nmit PSQ matches ideal PRAC is argued for the same wave/feinting attack and checked by simulation; the 'alternative attacks are inferior' discussion is an informal optimality argument, but it does not define QPRAC's security in terms of its own conclusion. The authors' self-citations (PrIDE, MINT, Hydra, RRoS, Aqua, and related tracker work) appear in comparisons and related work, not as the load-bearing justification for QPRAC's security. The main caveat, that the wave/feinting attack is assumed to be the worst case for PRAC, is an unproven modeling assumption and a correctness/validity risk, but it is not circular reasoning. No step in the derivation reduces to its own inputs, and no fitted parameter is renamed as a prediction.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

The central claim rests on JEDEC PRAC specification parameters, the wave-attack worst-case assumption, blast-radius assumptions, and the 32ms refresh window. The hand-chosen operating points (NBO=32, NPRO=NBO/2, PSQ size 5) are design parameters, not fitted to data. No new physical entities are introduced.

free parameters (4)
  • NBO (Back-Off Threshold) = 32 (default; analyzed across 1 to 256)
    Hand-chosen operating point that sets Alert frequency and the minimum supported TRH; not fitted to data but central to the security/performance tradeoff.
  • NPRO (Proactive Mitigation threshold) = 16 (NBO/2 at default NBO=32)
    Hand-chosen to reduce energy overhead while keeping performance at 0%; no sensitivity analysis is provided.
  • PSQ size = 5 entries
    Set to Nmit+1 to support PRAC-4 (4 RFMs per Alert); the security equivalence claim requires size >= Nmit.
  • BR (blast radius) = 2 (assumed)
    Appears in Eq. (2) as +BR in the security bound; if the blast radius is larger, the minimum TRH would increase.
assumptions (4)
  • domain assumption JEDEC PRAC protocol parameters: non-blocking Alerts, ABOACT max 3 ACTs (180ns), ABODelay = Nmit, NBO <= TRH.
    Used throughout Sections III and IV; if JEDEC changes these, the attack surface and security bounds change.
  • domain assumption The wave/feinting attack is the worst-case attack pattern for PRAC-based defenses.
    Section IV.A builds TRH bounds on this attack; the paper argues but does not formally prove that no stronger attack exists.
  • domain assumption Blast radius BR=2 and mitigative refresh increments victim row counters.
    Used in Eq. (2) and Section III.C.2, based on prior DRAM behavior such as Half-Double and ProTRR.
  • domain assumption The tREFW refresh window is 32ms and bounds the total attack time.
    Section IV.A.3 uses tREFW to constrain the starting row pool R1 in Figure 7.

how reviews work

0 comments
Cite this review

Pith. "Pith review of QPRAC: Towards Secure and Practical PRAC-based Rowhammer Mitigation using Priority Queues." pith.science (2026). https://pith.science/paper/SF5VZCQU

@misc{pith2026250118861,
  author       = {Pith},
  title        = {Pith review of: QPRAC: Towards Secure and Practical PRAC-based Rowhammer Mitigation using Priority Queues},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SF5VZCQU}},
  note         = {Machine review of arXiv:2501.18861}
}
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. PRAC enables a holistic mitigation of Rowhammer attacks even at ultra-low Rowhammer thresholds. PRAC uses an Alert Back-Off (ABO) protocol to request the memory controller to issue Rowhammer mitigation requests. However, recent PRAC implementations are either insecure or impractical. For example, Panopticon, the inspiration for PRAC, is rendered insecure if implemented per JEDEC's PRAC specification. On the other hand, the recent UPRAC proposal is impractical since it needs oracular knowledge of the `top-N' activated DRAM rows that require mitigation. This paper provides the first secure, scalable, and practical RowHammer solution using the PRAC framework. The crux of our proposal is the design of a priority-based service queue (PSQ) for mitigations that prioritizes pending mitigations based on activation counts to avoid the security risks of prior solutions. This provides principled security using the reactive ABO protocol. Furthermore, we co-design our PSQ, with opportunistic mitigation on Refresh Management (RFM) operations and proactive mitigation during refresh (REF), to limit the performance impact of ABO-based mitigations. QPRAC provides secure and practical RowHammer mitigation that scales to Rowhammer thresholds as low as 71 while incurring a 0.8% slowdown for benign workloads, which further reduces to 0% with proactive mitigations.

Figures

Figures reproduced from arXiv: 2501.18861 by the authors.

Figure 1
Figure 1. (a) With the PRAC framework, DRAM can request a time for mitigation when it needs it (based on per-row activation counters), using Alerts to [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. The security vulnerability of Panopticon [ [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. The security vulnerability of Panopticon (with full counter com [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (18 more)
Figure 4
Figure 4. Figure 4: Overview of QPRAC design. It consists of three components: [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Design of Priority-Based Service Queue (PSQ). Any activation can [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Maximum Row Activations in Online Attack (N [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Maximum Starting Row Pool (R1) versus Back-Off Threshold (NBO). As NBO increases, the maximum possible R1 decreases. This is because the time taken by the setup phase increases at higher NBO. 4) Quantifying TRH: Using the constraints on R1 for dif￾ferent NBO from [PIT…
Figure 8
Figure 8. Figure 8: TRH values for which PRAC-N is secure as NBO varies. At NBO of 1, the lowest possible TRH for PRAC-1, 2, and 4 is 44, 29, and 22, respectively. A similar analysis in prior work, UPRAC [4], fails to account for the activations in the last round for a single row and the …
Figure 9
Figure 9. Figure 9: FIFO-based queues vs QPRAC’s PSQ. FIFO is vulnerable to insertion [PITH_FULL_IMAGE:figures/full_fig_p008_9.png]
Figure 11
Figure 11. Figure 11: Maximum Starting Row Pool Size (R1) in the wave attack for QPRAC with proactive mitigation compared to QPRAC without proactive mitigation (labeled simply as QPRAC). For higher NBO, where the Setup phase consumes more time, the R1 size reduces considerably due to proac…
Figure 12
Figure 12. Figure 12: Maximum Activations Per Row in Online Phase (N [PITH_FULL_IMAGE:figures/full_fig_p009_12.png]
Figure 13
Figure 13. Figure 13: The TRH values for QPRAC with proactive mitigation and without proactive mitigation (labeled simply as QPRAC). With proactive mitigation, the lowest possible TRH at NBO of 1 is 40, 27, and 20 for QPRAC-1, 2, and 4, respectively. In contrast, the lowest possible TRH wi…
Figure 14
Figure 14. Figure 14: Normalized performance of QPRAC with a 5-entry priority queue at a Back-Off threshold (N [PITH_FULL_IMAGE:figures/full_fig_p010_14.png]
Figure 15
Figure 15. Figure 15: The frequency of Alert Back-Off (ABO) occurrences per tREFI interval for different QPRAC implementations at a Back-Off threshold of 32 and 1 RFM [PITH_FULL_IMAGE:figures/full_fig_p010_15.png]
Figure 16
Figure 16. Figure 16: Slowdown of QPRAC for RFMs/Alert values of 1, 2, and 4 (default [PITH_FULL_IMAGE:figures/full_fig_p010_16.png]
Figure 17
Figure 17. Figure 17: Slowdown of QPRAC as the queue size varies for different proactive [PITH_FULL_IMAGE:figures/full_fig_p011_17.png]
Figure 19
Figure 19. Figure 19: Maximum DRAM Activation Bandwidth (BW) reduction under [PITH_FULL_IMAGE:figures/full_fig_p011_19.png]
Figure 18
Figure 18. Figure 18: Performance overhead of QPRAC as the Back-Off Threshold (N [PITH_FULL_IMAGE:figures/full_fig_p011_18.png]
Figure 21
Figure 21. Figure 21: compares the performance of MOAT and QPRAC for PRAC-1 (1 RFM per Alert) as NBO varies. We assume MOAT uses an enqueuing threshold of NBO/2 and a single￾entry queue with an additional register, as described in their work [46]. Both QPRAC and MOAT show negligible slow￾d…
Figure 20
Figure 20. Figure 20: Normalized performance of QPRAC, Mithril, and PrIDE as the [PITH_FULL_IMAGE:figures/full_fig_p012_20.png]
Figure 23
Figure 23. Figure 23: The security vulnerability of Panopticon with blocking ABO [PITH_FULL_IMAGE:figures/full_fig_p013_23.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

67 extracted references · 55 canonical work pages

  1. [1]

    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,” in ASPLOS, 2016

    work page 2016

  2. [2]

    Panopticon: A complete in-dram rowhammer mitigation,

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

    work page 2021

  3. [3]

    Comet: Count-min-sketch- based row tracking to mitigate rowhammer at low cost,

    F. N. Bostanci, I. E. Y ¨uksel, A. Olgun, K. Kanellopoulos, Y . C. Tu˘grul, A. G. Ya˘glic ¸i, M. Sadrosadati, and O. Mutlu, “Comet: Count-min-sketch- based row tracking to mitigate rowhammer at low cost,” in 2024 IEEE International Symposium on High-Performance Computer Architecture (HPCA), 2024, pp. 593–612

    work page 2024

  4. [4]

    Understanding the security benefits and overheads of emerging industry solutions to dram read disturbance,

    O. Canpolat, A. G. Ya ˘glıkc ¸ı, G. F. Oliveira, A. Olgun, O. Ergin, and O. Mutlu, “Understanding the security benefits and overheads of emerging industry solutions to dram read disturbance,” in Workshop on DRAM Security (DRAMSec) , 2024

    work page 2024

  5. [5]

    13.2 a 32gb 8.0gb/s/pin ddr5 sdram with a symmetric-mosaic architecture in a 5th-generation 10nm dram process,

    I. Choi, S. Hong, K. Kim, J.-S. Hwang, S. Woo, Y .-S. Kim, C.-R. Cho, E.-Y . Lee, H.-J. Lee, M.-S. Jung, H.-Y . Jung, J.-S. Hwang, J. Yoon, W. Lim, H.-J. Yoo, W.-K. Lee, J.-K. Oh, D.-S. Lee, J.-E. Lee, J.-H. Kim, Y .-K. Kim, S.-J. Park, B.-K. Ho, B.-W. Na, H.-I. Choi, C.-K. Lee, S.-J. Lee, H. Shin, Y .-K. Lee, J.-W. Ryu, S. Shin, S. Park, D. Lim, S.- J. B...

    work page 2024

  6. [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,” in IEEE Symposium on Security and Privacy (SP) , 2019

    work page 2019

  7. [7]

    Benchmarking cloud serving systems with ycsb,

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

    2010

  8. [8]

    Spec cpu2006 benchmark suite,

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

    2006

Show all 67 references
  1. [9]

    Safeguard: Reducing the security risk from row-hammer via low-cost integrity protection,

    A. Fakhrzadehgan, Y . N. Patt, P. J. Nair, and M. K. Qureshi, “Safeguard: Reducing the security risk from row-hammer via low-cost integrity protection,” in HPCA. IEEE, 2022

    2022

  2. [10]

    Apache hadoop

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

  3. [11]

    TRRespass: Exploiting the many sides of target row refresh,

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

    2020

  4. [12]

    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

  5. [13]

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

    2018

  6. [14]

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

    2016

  7. [15]

    Crow: A low-cost substrate for improv- ing dram performance, energy efficiency, and reliability,

    H. Hassan, M. Patel, J. S. Kim, A. G. Yaglikci, N. Vijaykumar, N. M. Ghiasi, S. Ghose, and O. Mutlu, “Crow: A low-cost substrate for improv- ing dram performance, energy efficiency, and reliability,” in Proceedings of the 46th International Symposium on Computer Architecture ,...

    2019

  8. [16]

    Uncovering 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, “Uncovering in-dram rowhammer protection mechanisms: A new methodology, custom rowhammer patterns, and implications,” in MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture,...

    2021

  9. [17]

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

    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 algorithm,” arXiv:2302.03591, 2023

    2023 arXiv

  10. [18]

    Probabilistic tracker management policies for low-cost and scalable rowhammer mitigation,

    A. Jaleel, S. W. Keckler, and G. Saileshwar, “Probabilistic tracker management policies for low-cost and scalable rowhammer mitigation,” arXiv:2404.16256, 2024

    2024 arXiv

  11. [19]

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

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

    2024

  12. [20]

    BLACK- SMITH: Rowhammering in the Frequency Domain,

    P. Jattke, V . van der Veen, P. Frigo, S. Gunter, and K. Razavi, “BLACK- SMITH: Rowhammering in the Frequency Domain,” in 43rd IEEE Symposium on Security and Privacy’22 (Oakland) , 2022

    2022

  13. [21]

    Zenhammer: Rowhammer attacks on amd zen-based platforms,

    P. Jattke, M. Wipfli, F. Solt, M. Marazzi, M. B ¨olcskei, and K. Razavi, “Zenhammer: Rowhammer attacks on amd zen-based platforms,” in33rd USENIX Security Symposium (USENIX Security 2024) , 2024

    2024

  14. [22]

    Csi: Rowhammer-cryptographic security and integrity against rowhammer,

    J. Juffinger, L. Lamster, A. Kogler, M. Eichlseder, M. Lipp, and D. Gruss, “Csi: Rowhammer-cryptographic security and integrity against rowhammer,” in 2023 IEEE Symposium on Security and Privacy (SP) . IEEE Computer Society, 2022, pp. 236–252

    2023

  15. [23]

    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,”IEEE CAL, vol. 14, no. 1, pp. 9–12, 2014

    2014

  16. [24]

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

    J. S. Kim, M. Patel, A. G. Ya ˘glıkc ¸ı, H. Hassan, R. Azizi, L. Orosa, and O. Mutlu, “Revisiting rowhammer: An experimental analysis of modern dram devices and mitigation techniques,” in ISCA, 2020

    2020

  17. [25]

    Hammerfilter: Robust protection and low hardware overhead method for rowhammer,

    K. Kim, J. Woo, J. Kim, and K.-S. Chung, “Hammerfilter: Robust protection and low hardware overhead method for rowhammer,” in 2021 IEEE 39th International Conference on Computer Design (ICCD), 2021, pp. 212–219

    2021

  18. [26]

    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,” in HPCA, 2022

    2022

  19. [27]

    How to kill the second bird with one ecc: The pursuit of row hammer resilient dram,

    M. J. Kim, M. Wi, J. Park, S. Ko, J. Choi, H. Nam, N. S. Kim, J. H. Ahn, and E. Lee, “How to kill the second bird with one ecc: The pursuit of row hammer resilient dram,” in MICRO, 2023

    2023

  20. [28]

    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

  21. [29]

    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

    2014

  22. [30]

    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

  23. [31]

    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,” in USENIX Security Symposium , 2022

    2022

  24. [32]

    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,” in 2020 IEEE Symposium on Security and Privacy (SP) . IEEE, 2020, pp. 695–711

    2020

  25. [33]

    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,” in ISCA, 2019

    2019

  26. [34]

    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,” in ISCA, 2022

    2022

  27. [35]

    Rowpress: Amplifying read disturbance in modern dram chips,

    H. Luo, A. Olgun, A. G. Ya ˘glıkc ¸ı, Y . C. Tu˘grul, S. Rhyner, M. B. Cavlak, J. Lindegger, M. Sadrosadati, and O. Mutlu, “Rowpress: Amplifying read disturbance in modern dram chips,” in ISCA-50, 2023

    2023

  28. [36]

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

    H. Luo, Y . C. Tu ˘grul, F. N. Bostancı, A. Olgun, A. G. Ya ˘glıkc ¸ı, 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

  29. [37]

    Revisiting residue codes for modern memories,

    E. Manzhosov, A. Hastings, M. Pancholi, R. Piersma, M. T. I. Ziad, and S. Sethumadhavan, “Revisiting residue codes for modern memories,” in 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 2022, pp. 73–90

    2022

  30. [38]

    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,” in IEEE Symposium on Security and Privacy (SP) . IEEE, 2022, pp. 735–753

    2022

  31. [39]

    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,” in IEEE Symposium on Security and Privacy (SP) . IEEE, 2023

    2023

  32. [40]

    JESD79-5C

    JEDEC. JESD79-5C. https://www.jedec.org/document search?search api views fulltext=jesd79-5c

  33. [41]

    DDR5 SDRAM Datasheet: Directed Refresh Management (DRFM), Page-290,

    “DDR5 SDRAM Datasheet: Directed Refresh Management (DRFM), Page-290,” Micron Technology Inc., 2022. [Online]. Available: https://www.micron.com/-/media/client/global/documents/ products/data-sheet/dram/ddr5/ddr5 sdram core.pdf

    2022

  34. [42]

    System Power Calculators,

    Micron Technology Inc., “System Power Calculators,” https://www. micron.com/support/tools-and-utilities/power-calc

  35. [43]

    Read disturbance in high bandwidth memory: A detailed experimental study on hbm2 dram chips,

    A. Olgun, M. Osseiran, A. G. Ya ˘glıkc ¸ı, Y . C. Tu˘grul, H. Luo, S. Rhyner, B. Salami, J. G. Luna, and O. Mutlu, “Read disturbance in high bandwidth memory: A detailed experimental study on hbm2 dram chips,” in 2024 54th Annual IEEE/IFIP International Conference on Dependabl...

    2024

  36. [44]

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

    2024

  37. [45]

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

    2020

  38. [46]

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

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

    2025

  39. [47]

    Mint: Securely mitigating rowham- mer with a minimalist in-dram tracker,

    M. Qureshi, S. Qazi, and A. Jaleel, “Mint: Securely mitigating rowham- mer with a minimalist in-dram tracker,” in 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2024, pp. 899– 914

    2024

  40. [48]

    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

  41. [49]

    ABACuS — GitHub Repository,

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

    2023

  42. [50]

    Randomized row- swap: mitigating row hammer by breaking spatial correlation between aggressor and victim rows,

    G. Saileshwar, B. Wang, M. Qureshi, and P. J. Nair, “Randomized row- swap: mitigating row hammer by breaking spatial correlation between aggressor and victim rows,” in ASPLOS, 2022

    2022

  43. [51]

    Rubix: Reducing the overhead of secure rowhammer mitigations via randomized line-to-row mapping,

    A. Saxena, S. Mathur, and M. Qureshi, “Rubix: Reducing the overhead of secure rowhammer mitigations via randomized line-to-row mapping,” in Proceedings of the 29th ACM International Conference on Archi- tectural Support for Programming Languages and Operating Systems, Volume 2...

    2024

  44. [52]

    Start: Scalable tracking for any rowhammer threshold,

    A. Saxena and M. Qureshi, “Start: Scalable tracking for any rowhammer threshold,” in 2024 IEEE International Symposium on High-Performance Computer Architecture (HPCA). IEEE, 2024, pp. 578–592

    2024

  45. [53]

    Pt-guard: Integrity-protected page tables to defend against breakthrough rowhammer attacks,

    A. Saxena, G. Saileshwar, J. Juffinger, A. Kogler, D. Gruss, and M. Qureshi, “Pt-guard: Integrity-protected page tables to defend against breakthrough rowhammer attacks,” in DSN, 2023

    2023

  46. [54]

    Aqua: Scalable rowhammer mitigation by quarantining aggressor rows at runtime,

    A. Saxena, G. Saileshwar, P. J. Nair, and M. Qureshi, “Aqua: Scalable rowhammer mitigation by quarantining aggressor rows at runtime,” in MICRO, 2022

    2022

  47. [55]

    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

    2015

  48. [56]

    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,” in ISCA, 2018

    2018

  49. [57]

    Making dram stronger against row hammering,

    M. Son, H. Park, J. Ahn, and S. Yoo, “Making dram stronger against row hammering,” in Design Automation Conference , 2017

    2017

  50. [58]

    SPEC CPU2017 Benchmark Suite,

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

  51. [59]

    Go go gadget hammer: Flipping nested pointers for arbitrary data leakage,

    Y . Tobah, A. Kwong, I. Kang, D. Genkin, and K. G. Shin, “Go go gadget hammer: Flipping nested pointers for arbitrary data leakage,” in USENIX Security, 2024

    2024

  52. [60]

    TPC Benchmarks

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

  53. [61]

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

    2016

  54. [62]

    SHADOW: Preventing Row Hammer in DRAM with Intra-Subarray Row Shuffling,

    M. Wi, J. Park, S. Ko, M. J. Kim, N. S. Kim, E. Lee, and J. H. Ahn, “SHADOW: Preventing Row Hammer in DRAM with Intra-Subarray Row Shuffling,” in HPCA, 2023

    2023

  55. [63]

    Dapper: A performance-attack-resilient tracker for rowhammer defense,

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

    2025

  56. [64]

    Scalable and secure row-swap: Efficient and safe row hammer mitigation in memory systems,

    J. Woo, G. Saileshwar, and P. J. Nair, “Scalable and secure row-swap: Efficient and safe row hammer mitigation in memory systems,” in 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA), 2023, pp. 374–389

    2023

  57. [65]

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

    A. G. Ya ˘glikc ¸iet al., “Blockhammer: Preventing rowhammer at low cost by blacklisting rapidly-accessed dram rows,” in HPCA, 2021

    2021

  58. [66]

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

    A. G. Ya ˘glikc ¸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

  59. [67]

    Mrloc: Mitigating row-hammering based on memory locality,

    J. M. You and J.-S. Yang, “Mrloc: Mitigating row-hammering based on memory locality,” in 2019 56th ACM/IEEE Design Automation Conference (DAC). IEEE, 2019, pp. 1–6. 17

    2019

Pith tools

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