Pith. sign in

REVIEW 3 major objections 5 minor 80 references

DAPPER: A Performance-Attack-Resilient Tracker for RowHammer Defense

T0 review · 3 major / 5 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 The paper claims that a 96KB SRAM RowHammer tracker can absorb deliberate performance attacks at a RowHammer threshold of 500 with only 0.9% average slowdown.

desk verdict The Perf-Attack study is the real contribution; the 99.99% security claim is broken by a same-bank scan that the probabilistic model misses. read the letter →

arxiv 2501.18857 v2 pith:AWUEMYMQ submitted 2025-01-31 cs.CR

Jeonghyun Woo , Prashant J. Nair This is my paper · ORCID
classification cs.CR
keywords RowHammerDRAMsecurityperformanceattackgroupcountersecurehashingdoublememorycontrollerDDR5
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

The paper targets a denial-of-service class that hurts the defender rather than the data: an adversary who finds it hard to flip bits can still cripple co-running applications by flooding the shared counters or reset mechanisms that RowHammer defenses rely on. It claims that existing scalable trackers suffer 60–90% slowdowns under such performance attacks, and proposes DAPPER-H to close the gap. DAPPER-H maps rows to shared row-group counters through two independent keyed hashes, uses a per-bank bit-vector to absorb streaming activations, and refreshes only the rows shared by the two mapped groups. The paper reports that at a RowHammer threshold of 500, DAPPER-H keeps average slowdown at 0.9% under active attacks with 96KB of SRAM per 32GB of DRAM, and that mapping-capturing attacks succeed within a refresh window with probability below 0.01%. If true, this means RowHammer defenses can remain cheap without becoming a performance liability.

What carries the argument

The load-bearing object is DAPPER-H's two-table Row Group Counter (RGC) scheme. An RGC is a small SRAM counter shared by a fixed-size group of rows; DAPPER-H keeps two tables, each with its own Low-Latency Block Cipher (LLBC), a four-round keyed permutation that encrypts a row address before the address is divided into groups. A row increments a table's counter only if the per-bank bit-vector for the first table is already set, which prevents a streaming attacker from filling groups with one activation per bank. Mitigative refresh fires only when the counters in both tables reach the mitigation threshold ($N_M = N_{RH}/2$), and reset counters carry over the other table's count when a group is mitigated. The scheme's security rests on the two independent keyed mappings being unpredictable between key rotations every $t_{REFW} = 32$ms, so that an attacker cannot deliberately concentrate activations in one group.

What would settle it

Measure the actual mapping-capture rate: run an attacker that activates one row $N_M - 2$ times, probes random pairs of rows, and watches for mitigative refreshes; if more than roughly one in ten thousand refresh windows yields a successful mapping pair, the probability model is wrong. A second check is to test whether the LLBC output can be distinguished from a random permutation by timing or access-pattern side channels on real hardware.

Watch

Extended reading notes

Core claim

The central claim is that the performance overhead of RowHammer mitigation comes not from tracking rows, but from letting an attacker predict the tracking structure. Existing low-cost trackers share counters across rows and keep counters in DRAM or the last-level cache; an adversary who controls which rows map to which counter can force counter-cache misses or repeated full-bank refreshes. DAPPER-H makes the row-to-counter assignment unobservable: two independent four-round block ciphers map every activated row to a group in each of two SRAM tables, a per-bank bit-vector stops cross-bank streaming from inflating the first table, and a mitigation refreshes only the rows appearing in both groups. Because the cipher keys rotate every 32ms refresh window, capturing a single pair of mappings is claimed to be preventable with 99.99% probability per window. The paper supports this with a probabilistic analysis and with simulations across 57 workloads showing less than 1% average slowdown at a threshold of 500 under active performance attacks, and less than 6% even at a threshold of 125.

Load-bearing premise

The security number rests on the assumption that the four-round block cipher looks like a random permutation to software, and that the paper's probability model counts every guess an attacker can make inside one refresh window; if either fails, mapping-capturing attacks become easier and the 99.99% prevention claim does not hold.

Editorial extensions

If this is right

  • If DAPPER-H works as claimed, the performance-attack class becomes survivable at thresholds as low as 500: average slowdown under active attacks is 0.9%, versus 60–90% for existing shared-counter trackers.
  • The same 96KB SRAM budget keeps benign workloads at 0.1% average slowdown, so the security comes without a standing performance tax.
  • Even at an ultra-low threshold of 125, the paper projects at most a 6% slowdown under refresh attacks, indicating graceful degradation as DRAM becomes more fragile.
  • Per-bank mitigative refresh is a major cost lever: switching to same-bank DRFM commands raises slowdown to 8% at a threshold of 500, so future DRAM refresh commands should preserve bank-level granularity.
  • A single brief mapping leak is survivable because keys rotate every 32ms; attackers need repeated success across refresh windows to sustain a denial-of-service, and DAPPER-H's design denies that.

Reading between the lines

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

  • Editorial inference: the same two-table hash plus bit-vector pattern could transfer to other shared performance counters in the memory controller, such as wear-leveling or prefetch-throttle counters, where set-conflict and streaming attacks create denial-of-service.
  • Editorial inference: the paper's security argument counts a single refresh window in isolation; a persistent adversary who accumulates one successful capture every few hours could still learn a partial map over days, so a stronger design might rekey more often than 32ms or rotate the number of tables.
  • Editorial inference: the analysis assumes the attacker cannot distinguish LLBC outputs from random permutations; if future cryptanalytic shortcuts appear, replacing the four-round cipher with a stronger low-latency permutation would preserve the architecture while changing only the cipher block.
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 / 5 minor

Summary. The paper proposes DAPPER, a host-side RowHammer mitigation tracker. DAPPER-S uses a single secure hash to randomize row-to-row-group-counter mappings, while DAPPER-H adds a second hash, a per-bank bit-vector, and a selective mitigative-refresh mechanism. The paper claims that DAPPER-H prevents Mapping-Capturing attacks with 99.99% probability per refresh window and incurs only 0.9% average slowdown under active Perf-Attacks at NRH=500, with 96KB SRAM per 32GB DRAM. The paper also demonstrates RH-Tracker-based Perf-Attacks against Hydra, START, CoMeT, and ABACUS, and evaluates DAPPER against those baselines, BlockHammer, PARA, PrIDE, and PRAC across 57 workloads.

Significance. If the security and performance claims held, DAPPER-H would be a notable advance in low-cost, low-overhead RowHammer mitigation at ultra-low thresholds. The paper's strengths include a systematic demonstration of Perf-Attacks on four existing trackers, a wide-ranging simulation study (57 workloads, multiple NRH values, blast radius and DRFM variants), and a concrete hardware design with modest SRAM overhead. The security analysis, however, contains a load-bearing gap: the probabilistic model undercounts the attacker's probing capabilities, and a simple same-bank scan defeats the claimed 99.99% prevention. Because this attack is within the paper's own threat model, the central contribution is not currently established.

major comments (3)
  1. [Section VI-C, Equations (6)-(7)] The attack model assumes the attacker can make only two random probes per trial and therefore computes a per-trial success probability of about (2/8192)^2 and about 2500 trials, yielding a 0.01% failure rate per refresh window. This is not an upper bound. After priming a target row T in a single bank to NM-2=248 activations, an attacker can sequentially activate the other rows in the same bank. Because the bit-vector gates only first-time per-bank increments of Table 1, and T's bank bit is already set, any scanned row that shares T's Table-1 group increments that group's counter, and any scanned row that shares T's Table-2 group increments that group's counter. In a 64K-row bank with 8K groups, each group has about 8 rows per bank, so both counters reach 250 within roughly a few dozen activations (microseconds), far inside tREFW. The resulting mitigation reveals the triggering row as sharing one of T's groups, giving the attacker a mapping pair. The success probability is therefore close to 1, not 0.01%. The bit-vector does not prevent this attack because all probes are in the same bank.
  2. [Section VI-B, update operation] The paper does not specify the behavior of an RGC when it reaches NM while the other table's RGC for the same row has not reached NM. Table 2 is incremented on every activation, while Table 1 is incremented only when the bank bit is already set; an attacker can therefore drive a Table-2 counter past NM (e.g., by activating rows that map to the same Table-2 group across many banks) without the corresponding Table-1 counter reaching NM. If counters are not saturating, this can lead to overflow, and if they saturate, the paper should say so and analyze the security impact of 'stuck' counters. As written, the design's behavior in this state is undefined and the security analysis does not cover it.
  3. [Section VI-D, Figure 10] The performance evaluation under Perf-Attacks only considers the streaming and refresh attacks; it does not include the same-bank Mapping-Capturing attack described above. Since that attack enables the attacker to learn the group mappings and then launch targeted mitigative-refresh storms, the reported 0.9% average slowdown under active Perf-Attacks does not represent the full attack surface that the paper claims to address.
minor comments (5)
  1. [Section V-D] Equation (1) uses tRC in the computation of t_left; please clarify that the priming phase takes (NM-1)*tRC and that t_left is treset minus that time.
  2. [Section VI-H] The storage calculation appears inconsistent: 8K 1-byte entries per RGC table gives 8KB per table, i.e., 16KB for both tables, not 32KB; the bit-vector size also depends on the number of banks per rank and should be stated explicitly.
  3. [Figure 8] The four-step annotation is difficult to follow; the text refers to steps (1)-(4) but the figure labels are small and not clearly connected to the described update and reset operations.
  4. [Section VI-C, Discussion] The paper states that the LLBC is resistant to shortcut attacks citing prior work; since this is a core security assumption, a brief discussion of why N-to-N encryption avoids the CEASER/CUBE attacks would be helpful.
  5. [Section III-D] There is a typo: 'slwdown' should be 'slowdown'.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: DAPPER-H's performance results come from Ramulator simulations and its security bound follows from explicit probability equations, with self-citations used only for baselines or alignment, not as load-bearing justification.

full rationale

The paper's central performance claim (0.9% average slowdown under Perf-Attacks at N_RH=500) is obtained from cycle-accurate Ramulator simulations of 57 workloads, not from fitting a parameter to a target number. The design parameters (row group size 256, N_M = N_RH/2, tREFW-based reset) are standard choices drawn from prior published RowHammer trackers and JEDEC timing specifications, and the paper reports measured slowdowns rather than using the slowdown numbers to calibrate the security analysis. The security claim for DAPPER-H is derived arithmetically from Equations (6) and (7), which define p as the probability that two random accesses hit both target row-group counters and T as the number of trials allowed within one refresh window; the 99.99% prevention figure is a direct computation from those expressions and the stated 8K row groups and 2.5K trials. No equation in the paper equates the security result to a fitted or observed value. The same-bank scanning attack raised by a skeptical reader challenges whether Equations (6)-(7) model an upper bound on attacker capability; that is a correctness or threat-model limitation, not circularity, because a flawed or overly optimistic model is not the same as a model that assumes its own conclusion. Self-citations are present but not load-bearing: [73] (QPRAC, with author overlap) is used only as a comparison baseline for PRAC, and [50] (Hydra, with coauthor Nair) is used as a baseline to demonstrate Perf-Attacks, not to justify DAPPER-H's properties. The LLBC randomness assumption is imported from external prior work (CEASER, CUBE, SCARF), and the paper's own earlier RowHammer defenses are not used to establish the uniqueness or correctness of the proposed mechanism. Overall, the derivation chain is self-contained with respect to its measured performance and its stated probabilistic model; no circular reduction was found.

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

No new physical entities, particles, or forces are introduced. The invention is a microarchitectural mechanism (hash-based counters), which is not an 'entity' in the sense of the ledger. The free parameters are design choices with values from prior work or standard DRAM timing, not fitted to target outcomes.

free parameters (4)
  • row group size (RG) = 256 rows
    Chosen to keep SRAM low (8KB per table per rank) while making group overestimation unlikely; not derived from data.
  • mitigation threshold (NM) = NRH/2 (e.g., 250 at NRH=500)
    Set to half of RowHammer threshold, following prior work (Hydra, CoMeT), to ensure counter reset occurs before bit-flips.
  • reset period (treset) = 12-36 us for DAPPER-S, tREFW (32 ms) for DAPPER-H
    DAPPER-S uses short resets to reduce mapping-capture risk; DAPPER-H uses the standard refresh window. These are design choices, not fitted.
  • LLBC rounds = 4
    Low-latency block cipher configuration borrowed from CEASER/CUBE; not independently optimized here.
assumptions (5)
  • domain assumption The four-round low-latency block cipher (LLBC) behaves as a secure pseudorandom permutation against a software adversary.
    The security of DAPPER's randomized row-group mapping rests on the indistinguishability of the LLBC output from random; the paper cites CEASER, CUBE, and SCARF for this property (Section V-B).
  • domain assumption The adversary can observe timing differences caused by mitigative refreshes.
    The Mapping-Capturing attack (Section V-D) assumes attackers have exclusive access and can detect when a mitigative refresh is issued.
  • domain assumption The memory controller can issue per-bank victim row refresh (VRR) commands.
    The low overhead results (0.9%) assume VRR with blast radius 1; current JEDEC DDR5 only provides all-bank or same-bank DRFM commands (Section VI-G).
  • domain assumption Row-to-group mapping under the secure hash is uniformly random and independent for each row.
    The probabilistic security analysis (Equations 3, 6, 7) and the expected intersection of RGC groups rely on this uniformity.
  • domain assumption A user-level attacker can execute malicious code on one or more cores while benign workloads run on others.
    Standard RowHammer threat model (Section II-C) and the basis for Perf-Attacks.

how reviews work

0 comments
Cite this review

Pith. "Pith review of DAPPER: A Performance-Attack-Resilient Tracker for RowHammer Defense." pith.science (2026). https://pith.science/paper/AWUEMYMQ

@misc{pith2026250118857,
  author       = {Pith},
  title        = {Pith review of: DAPPER: A Performance-Attack-Resilient Tracker for RowHammer Defense},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AWUEMYMQ}},
  note         = {Machine review of arXiv:2501.18857}
}
read the original abstract

RowHammer vulnerabilities pose a significant threat to modern DRAM-based systems, where rapid activation of DRAM rows can induce bit-flips in neighboring rows. To mitigate this, state-of-the-art host-side RowHammer mitigations typically rely on shared counters or tracking structures. While these optimizations benefit benign applications, they are vulnerable to Performance Attacks (Perf-Attacks), where adversaries exploit shared structures to reduce DRAM bandwidth for co-running benign applications by increasing DRAM accesses for RowHammer counters or triggering repetitive refreshes required for the early reset of structures, significantly degrading performance. In this paper, we propose secure hashing mechanisms to thwart adversarial attempts to capture the mapping of shared structures. We propose DAPPER, a novel low-cost tracker resilient to Perf-Attacks even at ultra-low RowHammer thresholds. We first present a secure hashing template in the form of DAPPER-S. We then develop DAPPER-H, an enhanced version of DAPPER-S, incorporating double-hashing, novel reset strategies, and mitigative refresh techniques. Our security analysis demonstrates the effectiveness of DAPPER-H against both RowHammer and Perf-Attacks. Experiments with 57 workloads from SPEC2006, SPEC2017, TPC, Hadoop, MediaBench, and YCSB show that, even at an ultra-low RowHammer threshold of 500, DAPPER-H incurs only a 0.9% slowdown in the presence of Perf-Attacks while using only 96KB of SRAM per 32GB of DRAM memory.

Figures

Figures reproduced from arXiv: 2501.18857 by the authors.

Figure 1
Figure 1. Normalized performance of state-of-the-art host-side RowHammer [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. An overview of the RH-Tracker-based Performance Attacks (Perf-Attack) tailored for state-of-the-art host-side low-cost RowHammer tracking mechanisms: Hydra [50], CoMeT [4], START [60], and ABACUS [45]. These attacks induce additional memory accesses or repetitive mitigative refreshes. Workloads with ≥ 2 Row Buffer Misses per Kilo Instructions All Workloads [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. The performance impact of state-of-the-art RowHammer (RH) trakcers: Hydra [ [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (14 more)
Figure 5
Figure 5. Figure 5: Normalized performance of scalable RowHammer (RH) mitigations [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 4
Figure 4. Figure 4: Normalized performance of scalable RowHammer (RH) mitigations [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 6
Figure 6. Figure 6: Overview of DAPPER-S. The key operation involves updating the Row Group Counter (RGC) during each memory access. (a) Rows are securely hashed to ensure even distribution across RGCs, with each counter tracking 256 rows. (b) When an RGC reaches the mitigation threshold …
Figure 7
Figure 7. Figure 7: illustrates a Mapping-Capturing attack that targets the static hash mapping of DAPPER-S to identify rows mapped to the same row group and overflow the Row Group Counter (RGC). By inflating RGCs, this attack triggers unnecessary mitigative refreshes with fewer activatio…
Figure 8
Figure 8. Figure 8: Overview of DAPPER-H. It uses two hashes to filter out accesses that overwhelm the Row Group Counter (RGC). DAPPER-H performs mitigations only when both RGCs are equal to the Mitigation threshold (NM). SPEC2K6 (23) SPEC2K17 (18) TPC (4) Hadoop (3) MediaBench (3) YCSB (…
Figure 9
Figure 9. Figure 9: Performance impact of two Mapping-Agnostic attacks, streaming and refresh attacks, on DAPPER-S. The streaming attack drops performance by 13%, while the refresh attack leads to a 20% slowdown. VI. ENHANCING THE DAPPER TRACKER We introduce DAPPER-H, an enhanced tracker …
Figure 10
Figure 10. Figure 10: Normalized performance of DAPPER-H under two Mapping-Agnostic attacks, streaming and refresh attacks, at an ultra-low RowHammer threshold (NRH) of 500. The performance of three benign applications is normalized to a non-secure baseline system. Despite the active Perf-…
Figure 11
Figure 11. Figure 11: Normalized performance of DAPPER-H on benign applications compared to an insecure baseline at an ultra-low RowHammer threshold (NRH) of 500. DAPPER-H incurs only 0.1% slowdown on average and a maximum slowdown of 4.4%, as the double-hashing, novel reset, and bit-vecto…
Figure 12
Figure 12. Figure 12: illustrates DAPPER-H’s performance sensitivity as NRH varies from 125 to 4K. DAPPER-H incurs less than 1% overheads at NRH ≥ 500, even under active Performance Attacks (Perf-Attacks). Additionally, it minimizes its perfor￾mance impact even at lower NRH by avoiding unn…
Figure 13
Figure 13. Figure 13: Normalized performance of DAPPER-H with a blast radius (BR) of 1 (default) and BR of 2, as well as Same-Bank Directed Refresh Management (DRFMsb), under benign applications and the refresh attack. Increasing the BR slightly raises slowdowns while using DRFMsb results …
Figure 14
Figure 14. Figure 14: Performance comparison of DAPPER-H and BlockHammer [75] under benign applications as the RowHammer threshold (NRH) varies. Block￾Hammer significantly drops performance at ultra-low NRH (NRH ≤ 500) due to unnecessary throttling. At NRH of 250, for example, BlockHammer …
Figure 16
Figure 16. Figure 16: compares the performance of DAPPER-H, PrIDE, and PARA under Perf-Attacks. At NRH of 125, DAPPER￾H incurs only a 6% performance drop, while PARA and PrIDE suffer significant slowdowns of 14.6% and 22.8%, respectively, due to frequent mitigations and reduced DRAM bandwi…
Figure 15
Figure 15. Figure 15: compares the performance of DAPPER-H under benign applications to two state-of-the-art probabilistic miti￾gations, PrIDE [19] and PARA [28], as NRH varies from 125 to 4K. All evaluated methods are assumed to support per-bank granularity mitigations by default, with ad…
Figure 17
Figure 17. Figure 17: compares the performance of DAPPER-H and PRAC under benign applications and Perf-Attacks. We im￾plement PRAC based on the state-of-the-art secure QPRAC design [73]. PRAC incurs an average of 7% and up to 20% overhead on benign applications, even at NRH of 4K, mainly d…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

80 extracted references · 52 canonical work pages

  1. [1]

    UBC Advanced Research Computing,

    “UBC Advanced Research Computing, ”UBC ARC Sockeye.” UBC Advanced Research Computing, 2019, doi: 10.14288/SOCKEYE.”

    doi:10.14288/sockeye 2019

  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

    work page 2021

  3. [3]

    Brutus: Refuting the security claims of the cache timing randomiza- tion countermeasure proposed in ceaser,

    R. Bodduna, V . Ganesan, P. SLPSK, K. Veezhinathan, and C. Rebeiro, “Brutus: Refuting the security claims of the cache timing randomiza- tion countermeasure proposed in ceaser,” IEEE Computer Architecture Letters, vol. 19, no. 1, pp. 9–12, 2020

    work page 2020

  4. [4]

    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

    2024

  5. [5]

    SCARF – a Low-Latency block cipher for secure Cache-Randomization,

    F. Canale, T. G ¨uneysu, G. Leander, J. P. Thoma, Y . Todo, and R. Ueno, “SCARF – a Low-Latency block cipher for secure Cache-Randomization,” in 32nd USENIX Security Symposium (USENIX Security 23) . Anaheim, CA: USENIX Association, Aug. 2023, pp. 1937–1954. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity23/presentation/canale

    work page 2023

  6. [6]

    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

    2024

  7. [7]

    Breakhammer: Enhancing rowhammer mitigations by carefully throttling suspect threads,

    O. Canpolat, A. G. Ya ˘glıkc ¸ı, A. Olgun, I. E. Yuksel, Y . C. Tu ˘grul, K. Kanellopoulos, O. Ergin, and O. Mutlu, “Breakhammer: Enhancing rowhammer mitigations by carefully throttling suspect threads,” in 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2024, pp. 915–934

    2024

  8. [8]

    Towards variation-aware system-level power estimation of drams: an empirical approach,

    K. Chandrasekar, C. Weis, B. Akesson, N. Wehn, and K. Goossens, “Towards variation-aware system-level power estimation of drams: an empirical approach,” in Proceedings of the 50th Annual Design Automation Conference , ser. DAC ’13. New York, NY , USA: Association for Computing Machinery, 2013. [Online]. Available: https://doi.org/10.1145/2463209.2488762

    work page arXiv 2013

Show all 80 references
  1. [9]

    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 2019 IEEE Symposium on Security and Privacy (SP) , 2019, pp. 55– 71

    2019

  2. [10]

    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 , ser. SoCC ’10. New York, NY , USA: Association for Computing Machinery, 2010, p. 143–154. [Online]....

  3. [11]

    Spec cpu2006 benchmark suite,

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

    2006

  4. [12]

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

    A. Fakhrzadehgan, Y . Patt, P. Nair, and M. Qureshi, “Safeguard: Reduc- ing the security risk from row-hammer via low-cost integrity protection,” in 2022 IEEE International Symposium on High Performance Computer Architecture (HPCA). IEEE, 2022

    2022

  5. [13]

    Apache hadoop

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

  6. [14]

    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, media and Stream Processing. [Online]. Available: https://www.science...

    2009

  7. [15]

    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 2018 IEEE Symposium on Security and Privacy (SP) . IEEE, 2018, pp. 245–261

    2018

  8. [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,” in Proceedings of the 13th International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment - V olume 9721 , ser. DIMV A 2016. Berlin, Heide...

    2016 doi

  9. [17]

    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

  10. [18]

    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,” 2023. [Online]. Available: https://arxiv.org/abs/2302.03591

    2023 arXiv

  11. [19]

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

    A. Jaleel, G. Saileshwar, S. W. Keckler, and M. Qureshi, “Pride: Achiev- ing secure rowhammer mitigation with low-cost in-dram trackers,” in 2024 ACM/IEEE 51st Annual International Symposium on Computer Architecture (ISCA), 2024, pp. 1157–1172

    2024

  12. [20]

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

    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,” in 33rd USENIX Security Symposium (USENIX Security 24). Philadelphia, PA: USENIX Association, Aug. 2024, pp. 1615–1633. [Online]. Available: http...

    2024

  14. [22]

    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

  15. [23]

    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 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA) . IEEE,...

    2020

  16. [24]

    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

  17. [25]

    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 2022 IEEE International Sympo- sium on High-Performance Computer Architecture (HPCA) , 2022, pp. 115...

    2022

  18. [26]

    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 Proceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture , ser. MICRO ’23. ...

    2023

  19. [27]

    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

  20. [28]

    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,” ACM SIGARCH Computer Architecture News , vol. 42, no. 3, pp. 361–372, 2014

    2014

  21. [29]

    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

  22. [30]

    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,” Aug. 2022, 31st USENIX Security Symposium : USENIX Security ’22, USENIX ’22 ; Conference date: 10-08-2022 Through 12- 08-2022

    2022

  23. [31]

    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) , 2020, pp. 695–711

    2020

  24. [32]

    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 Proceedings of the 46th International Symposium on Computer Architecture , 2019, pp. 385–396

    2019

  25. [33]

    Newcache: Secure cache architecture thwarting cache side-channel attacks,

    F. Liu, H. Wu, K. Mai, and R. B. Lee, “Newcache: Secure cache architecture thwarting cache side-channel attacks,” IEEE Micro, vol. 36, no. 5, pp. 8–16, 2016

    2016

  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 Proceedings of the 49th Annual International Symposium on Computer Architecture , ser. ISCA ’22. New York, NY , USA: Association...

    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 Proceedings of the 50th Annual International Symposium on Computer Architecture , ser. IS...

  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]

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

    2022

  30. [38]

    JESD79-5C

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

  31. [39]

    DDR5 SDRAM Datasheet

    Micron. DDR5 SDRAM Datasheet. https://media-www.micron.com/- /media/client/global/documents/products/data-sheet/dram/ddr5/ddr5 sdram core.pdf

  32. [40]

    Memory performance attacks: Denial of memory service in Multi-Core systems,

    T. Moscibroda and O. Mutlu, “Memory performance attacks: Denial of memory service in Multi-Core systems,” in 16th USENIX Security Symposium (USENIX Security 07) . Boston, MA: USENIX Association, Aug. 2007. [Online]. Available: https://www.usenix.org/conference/16th-usenix-secu...

    2007

  33. [41]

    Stall-time fair memory access scheduling for chip multiprocessors,

    O. Mutlu and T. Moscibroda, “Stall-time fair memory access scheduling for chip multiprocessors,” in 40th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO 2007) , 2007, pp. 146–160

    2007

  34. [42]

    Sudoku: Tolerating high- rate of transient failures for enabling scalable sttram,

    P. J. Nair, B. Asgari, and M. K. Qureshi, “Sudoku: Tolerating high- rate of transient failures for enabling scalable sttram,” in 2019 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN) , 2019, pp. 388–400

    2019

  35. [43]

    Archshield: Architectural framework for assisting dram scaling by tolerating high error rates,

    P. J. Nair, D.-H. Kim, and M. K. Qureshi, “Archshield: Architectural framework for assisting dram scaling by tolerating high error rates,” in Proceedings of the 40th Annual International Symposium on Computer Architecture, ser. ISCA ’13. New York, NY , USA: Association for Com...

    2013

  36. [44]

    Xed: Exposing on-die error detection information for strong memory reliability,

    P. J. Nair, V . Sridharan, and M. K. Qureshi, “Xed: Exposing on-die error detection information for strong memory reliability,” in 2016 ACM/IEEE 43rd Annual International Symposium on Computer Architecture (ISCA) , 2016, pp. 341–353

    2016

  37. [45]

    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

  38. [46]

    Graphene: Strong yet lightweight row hammer protection,

    Y . Park, W. Kwon, E. Lee, T. J. Ham, J. Ho Ahn, and J. W. Lee, “Graphene: Strong yet lightweight row hammer protection,” in 2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), 2020, pp. 1–13

    2020

  39. [47]

    Systematic analysis of randomization-based protected cache architectures,

    A. Purnal, L. Giner, D. Gruss, and I. Verbauwhede, “Systematic analysis of randomization-based protected cache architectures,” in 2021 IEEE Symposium on Security and Privacy (SP) , 2021, pp. 987–1002

    2021

  40. [48]

    Moat: Securely mitigating rowhammer with per-row activation counters,

    M. Qureshi and S. Qazi, “Moat: Securely mitigating rowhammer with per-row activation counters,” 2025

    2025

  41. [49]

    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

  42. [50]

    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 Proceedings of the 49th Annual International Symposium on Computer Architecture , ser. ISCA ’22. New York, NY , USA: Ass...

    2022

  43. [51]

    Ceaser: Mitigating conflict-based cache attacks via encrypted-address and remapping,

    M. K. Qureshi, “Ceaser: Mitigating conflict-based cache attacks via encrypted-address and remapping,” in 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), 2018, pp. 775– 787

    2018

  44. [52]

    New attacks and defense for encrypted-address cache,

    M. K. Qureshi, “New attacks and defense for encrypted-address cache,” in Proceedings of the 46th International Symposium on Computer Architecture, ser. ISCA ’19. New York, NY , USA: Association for Computing Machinery, 2019, p. 360–371. [Online]. Available: https://doi.org/10....

    2019

  45. [53]

    Enhancing lifetime and security of pcm-based main memory with start-gap wear leveling,

    M. K. Qureshi, J. Karidis, M. Franceschini, V . Srinivasan, L. Lastras, and B. Abali, “Enhancing lifetime and security of pcm-based main memory with start-gap wear leveling,” in Proceedings of the 42nd Annual IEEE/ACM International Symposium on Microarchitecture , ser. MICRO

  46. [54]

    Avatar: A variable-retention-time (vrt) aware refresh for dram systems,

    M. K. Qureshi, D.-H. Kim, S. Khan, P. J. Nair, and O. Mutlu, “Avatar: A variable-retention-time (vrt) aware refresh for dram systems,” in 2015 45th Annual IEEE/IFIP International Conference on Dependable Systems and Networks , 2015, pp. 427–437

    2015

  47. [55]

    New York, NY , USA: Association for Computing Machinery, 2009, p. 14–23. [Online]. Available: https://doi.org/10.1145/1669112.1669117

    2009

  48. [56]

    MIRAGE: Mitigating Conflict- Based cache attacks with a practical Fully-Associative design,

    G. Saileshwar and M. Qureshi, “MIRAGE: Mitigating Conflict- Based cache attacks with a practical Fully-Associative design,” in 30th USENIX Security Symposium (USENIX Security 21) . USENIX Association, Aug. 2021, pp. 1379–1396. [Online]. Available: https: //www.usenix.org/confe...

    2021

  49. [57]

    ABACuS — GitHub Repository,

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

    2023

  50. [58]

    Impress: Securing dram against data-disturbance errors via implicit row-press mitigation,

    A. Saxena, A. Jaleel, and M. Qureshi, “Impress: Securing dram against data-disturbance errors via implicit row-press mitigation,” in 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO) , 2024, pp. 935–948

    2024

  51. [59]

    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 Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Op...

    2022

  52. [60]

    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) , 2024, pp. 578–592

    2024

  53. [61]

    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 15 on Architectural Support for Programming Languages and Operating Systems, V olume...

    2024

  54. [62]

    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

  55. [63]

    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 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2022, pp. 108–123

    2022

  56. [64]

    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 2018 ACM/IEEE 45th Annual International Symposium on Computer Architecture (ISCA) . IEEE, 2018, pp. 612–623

    2018

  57. [65]

    Security refresh: prevent malicious wear-out and increase durability for phase- change memory with dynamically randomized address mapping,

    N. H. Seong, D. H. Woo, and H.-H. S. Lee, “Security refresh: prevent malicious wear-out and increase durability for phase- change memory with dynamically randomized address mapping,” in Proceedings of the 37th Annual International Symposium on Computer Architecture, ser. ISCA ...

  58. [66]

    SPEC CPU2017 Benchmark Suite,

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

    2017

  59. [67]

    Making dram stronger against row hammering,

    M. Son, H. Park, J. Ahn, and S. Yoo, “Making dram stronger against row hammering,” in 2017 54th ACM/EDAC/IEEE Design Automation Conference (DAC), 2017, pp. 1–6

    2017

  60. [68]

    Roguerfm: Attacking refresh management for covert-channel and denial-of-service,

    H. Taneja and M. Qureshi, “Roguerfm: Attacking refresh management for covert-channel and denial-of-service,” 2025. [Online]. Available: https://arxiv.org/abs/2501.06646

    2025 arXiv

  61. [69]

    The blacklisting memory scheduler: Achieving high performance and fairness at low cost,

    L. Subramanian, D. Lee, V . Seshadri, H. Rastogi, and O. Mutlu, “The blacklisting memory scheduler: Achieving high performance and fairness at low cost,” in 2014 IEEE 32nd International Conference on Computer Design (ICCD) , 2014, pp. 8–15

    2014

  62. [70]

    New cache designs for thwarting software cache-based side channel attacks,

    Z. Wang and R. B. Lee, “New cache designs for thwarting software cache-based side channel attacks,” SIGARCH Comput. Archit. News, vol. 35, no. 2, p. 494–505, Jun. 2007. [Online]. Available: https://doi.org/10.1145/1273440.1250723

    2007

  63. [71]

    TPC Benchmarks

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

  64. [72]

    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 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA) . IEEE, 2023, pp. 333–346

    2023

  65. [73]

    ScatterCache: Thwarting cache attacks via cache set randomization,

    M. Werner, T. Unterluggauer, L. Giner, M. Schwarz, D. Gruss, and S. Mangard, “ScatterCache: Thwarting cache attacks via cache set randomization,” in 28th USENIX Security Symposium (USENIX Security 19) . Santa Clara, CA: USENIX Association, Aug. 2019, pp. 675–692. [Online]. Ava...

    2019

  66. [74]

    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

  67. [75]

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

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

    2025

  68. [76]

    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,” in 29th USENIX Security Symposium (USENIX Security 20) . USENIX Association, Aug. 2020, pp. 1463–1480. [Online]. Available: https://www.usenix...

    2020

  69. [77]

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

    A. G. Ya ˘glikc ¸i, M. Patel, J. S. Kim, R. Azizi, A. Olgun, L. Orosa, H. Hassan, J. Park, K. Kanellopoulos, T. Shahroodi et al. , “Block- hammer: Preventing rowhammer at low cost by blacklisting rapidly- accessed dram rows,” in 2021 IEEE International Symposium on High Perfor...

    2021

  70. [78]

    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), 2019, pp. 1–6. 16

    2019

  71. [79]

    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 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2022, pp. 815– 834

    2022

  72. [2023]

    Available: https://doi.org/10.1145/3579371.3589063

    [Online]. Available: https://doi.org/10.1145/3579371.3589063

Pith tools

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