Pith. sign in

REVIEW 5 major objections 6 minor 2 cited by

RogueRFM: Attacking Refresh Management for Covert-Channel and Denial-of-Service

T0 review · 5 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

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

Pith's one-line read The DDR5 refresh-management interface lets one bank stall the entire rank, which the paper turns into a covert channel and a denial-of-service attack.

desk verdict First paper to attack DDR5's RFM interface; the cross-bank interference insight is real, but the headline numbers rest on an assumed immediate-scheduling controller and the DoS slowdown conflates RFM stalls with ordinary memory contention. read the letter →

arxiv 2501.06646 v1 pith:MDG3HBF2 submitted 2025-01-11 cs.CR cs.AR

Hritvik Taneja , Moinuddin Qureshi This is my paper · ORCID
classification cs.CRcs.AR
keywords RowhammerDDR5RefreshManagement(RFM)covertchanneldenial-of-servicebankinterferencetimingsideDRAMsecurity
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 aims to show that the DDR5 Refresh Management (RFM) interface, designed to give in-DRAM Rowhammer defenses dedicated time to refresh victim rows, introduces a cross-bank interference side effect that an attacker can turn into a covert channel and a denial-of-service attack. The load-bearing behavior is that the all-bank RFMab command fires when any single bank's activation counter reaches the threshold, so one bank can block every other bank in the rank for about 410ns. The paper demonstrates a covert channel running at 31.3 KB/s per subchannel and a DoS pattern that slows co-running workloads up to 67% in simulation, with both attacks remaining effective in bank-partitioned systems. It also shows that a simple activation-limiting countermeasure cuts the average DoS slowdown to about 10-14% while barely affecting benign workloads. If correct, this means a security feature added to stop Rowhammer becomes a new shared-resource timing oracle.

What carries the argument

The central mechanism is the Rolling Accumulated ACT counter (RAACtr), a per-bank counter in the memory controller that increments on every activation to that bank. When any bank's RAACtr reaches the Maximum Manageable Threshold (RAAMMT), the controller is required to issue RFMab, an all-bank refresh-management command that stalls every bank in the rank for tRFC (about 410ns) and decrements all counters by RAAIMT. Because the threshold condition is checked per bank but the stall is applied rank-wide, the counter converts one bank's activation pattern into a global timing signal; this single threshold-to-rank mapping is what carries both attacks.

What would settle it

On a real DDR5 system with RFM enabled, run the sender's activation pattern in one bank while measuring the completion time of loads in another bank within the same refresh window. If the expected ~410ns stall does not appear when the sender crosses the threshold, or if the receiver-visible gap between a '0' and a '1' is far below the predicted 356ns, the central claim is falsified.

Watch

Extended reading notes

Core claim

On an RFM-enabled DDR5 system, a single bank's activation rate can dictate the timing and throughput of every other bank in the rank. The paper's central claim is that the RFMab command, which exists to give in-DRAM Rowhammer defenses dedicated mitigation time, is issued as soon as any one bank's rolling activation counter (RAACtr) reaches the vendor threshold (RAAMMT), and that RFMab then stalls all banks in the rank for tRFC, about 410ns. Because an attacker can reach that threshold from one bank without touching a victim's bank, the victim's load latency becomes a readable signal of the attacker's activity. The paper demonstrates this twice: a sender/receiver pair that transmits one bit per refresh interval at 31.3 KB/s per subchannel (up to 62.6 KB/s per channel), and a single-bank activation pattern that slows co-running workloads by up to 67% in simulation. Both attacks work when the OS partitions banks between security domains, which is the standard defense against older DRAM timing channels.

Load-bearing premise

The attacks assume that real DDR5 controllers implement the RFM policy exactly as modeled: any bank crossing RAAMMT immediately triggers an RFMab that stalls all banks for the full 410ns, and a refresh decrements the counters by exactly RAAIMT/2.

Editorial extensions

If this is right

  • Bank partitioning no longer blocks memory-based covert channels, because the sender and receiver can sit in different banks and still share the RFMab timing signal.
  • Any process capable of issuing many activations to a single bank can degrade the performance of all co-resident workloads in the same rank; the paper measures up to 29.3% (RAAIMT=32) and 67% (RAAIMT=16) slowdown.
  • The covert channel's raw rate is one bit per tREFI per subchannel, i.e. 31.3 KB/s per subchannel and 62.6 KB/s per two-subchannel DDR5 channel.
  • Limiting per-core activations per bank per refresh interval caps the average DoS slowdown to about 10.2-14.2% while costing benign workloads under 1%.
  • With RFM enabled, a bank's load latency depends on activity elsewhere in the rank, so deterministic per-bank performance isolation is no longer available on such systems.

Reading between the lines

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

  • Beyond the paper: the same threshold-triggered, rank-wide stall pattern could appear in future DRAM management interfaces such as the PRAC/ALERT-Back-Off mechanism the paper mentions, making the cross-bank channel an architectural pattern rather than a one-time RFM bug.
  • Beyond the paper: the one-bit-per-tREFI rate cap implies the covert channel's bandwidth scales inversely with the refresh interval; if future standards shorten tREFI or use RFMsb in fine-grained refresh mode, the per-subchannel rate could double.
  • Beyond the paper: the DoS slowdown tracks activation intensity, so the paper's average figures likely understate real-world impact for memory-bound co-tenants, where the worst-case workload already hit 67%.
  • Beyond the paper: a testable follow-up would be to vary RAAMMT over a wider range than 48/96 and check whether the analytical RFMab/tREFI model from the appendix predicts the slowdown linearly, letting defenders set thresholds by availability budget rather than only by Rowhammer safety.
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

5 major / 6 minor

Summary. The paper identifies a previously unexplored security side effect of the DDR5 Refresh Management (RFM) interface: an RFMab command, triggered when the activation counter of any single bank reaches the RAAMMT threshold, stalls all banks in the rank for the full tRFC period. The authors build two attacks on this observation. First, a covert channel in which a sender in one bank triggers RFMab, and a receiver in a different bank detects the resulting delay in its own loads; the channel operates at 1 bit per tREFI (31.3 KB/s per subchannel) and is claimed to remain 83-90% accurate under co-running workloads. Second, a denial-of-service (DoS) pattern that continuously activates a single bank to saturate its RAACtr, causing 1.37 or 2.6 RFMab commands per tREFI for RAAIMT=32 and 16, respectively, and slowing co-running SPEC2017, PARSEC, and LIGRA workloads by up to 29.3% and 67% in simulation. The paper also presents an analytical model for the RFMab rate, a countermeasure based on per-core activation limiting, and a discussion of RFMsb-based channels.

Significance. If the assumed RFM scheduling policy holds, this is the first study of intentional misuse of the RFM interface and it makes a credible contribution: the cross-bank interference property is real in the protocol model, and the attacks resist bank partitioning. The paper's strengths include a cycle-accurate DDR5 simulation environment built on DRAMsim3, a parameter-free analytical model (Eq. 2) that closely matches the observed RFMab/tREFI counts, a noise-sensitivity study of the covert channel, and an evaluated countermeasure. The significance is, however, conditional: the headline numbers rely on a specific immediate-RFM-scheduling policy and on an assumed RAACtr-decrement value during REF, neither of which is validated against real DDR5 controllers, and the DoS slowdown conflates RFM stalls with ordinary memory contention. These are load-bearing gaps that must be addressed before the quantitative claims can be taken at face value.

major comments (5)
  1. [Section 3.1 / Section 2.4] The attacks assume that the memory controller issues RFMab immediately when the RAACtr of any bank reaches RAAMMT. The paper itself notes in Section 2.4 that 'the memory controller can also issue an RFM command before the RAACtr reaches RAAMMT,' and JEDEC-style RFM permits scheduling flexibility. A controller that delays RFMab until the next REF boundary, batches it until several banks are near the threshold, or otherwise schedules differently would shrink or remove the deterministic 356 ns receiver-visible gap (Section 4.4) and the 1.37/2.6 RFMab-per-tREFI rates (Section 5.1). The manuscript provides no hardware measurements, no reference to a deployed controller, and no sensitivity analysis over alternative policies. Please either supply evidence that real DDR5 controllers use the assumed immediate-scheduling policy, or re-run the evaluation under deferred/batched policies and state the resulting attack rates as a function of controller behavior.
  2. [Section 5.2 / Appendix A] There is a two-fold discrepancy between the analytical model and the simulation results. Equation (2) and the accompanying calculation yield a maximum RFM-induced slowdown of about 16% for RAAIMT=32 and 31% for RAAIMT=16, yet Figure 14 reports maximum weighted slowdowns of 29.3% and 67% for streamcluster. This gap suggests that the measured DoS slowdown includes substantial ordinary memory contention from the attacker's continuous ACT stream, which would slow the victim even if RFM were disabled. The paper should isolate the RFM-specific contribution, for example by running the same activation pattern with the RFM mechanism disabled, so that readers can see the marginal slowdown attributable to RFMab stalls rather than to bandwidth and queueing contention.
  3. [Section 2.4] The covert channel depends on the assumption that during a REF command, the RAACtr is decremented by exactly RAAIMT/2 (the MR59:OP[7:6] setting). This value is stated without justification or a citation to a specific vendor configuration. The sender's steady state (RAACtr=64, Figure 8), the sender's ACT counts (32 for '1', 16 for '0'), and the resulting 1-bit-per-tREFI rate all hinge on this exact decrement. If a real system uses a different decrement, such as zero or the full RAAIMT, the initialization phase, the receiver threshold, and the bit timing would all have to be recalibrated. Please provide a justification for this assumption or evaluate the channel's sensitivity to the decrement value.
  4. [Section 4.5] The accuracy results weaken the claimed robustness of the covert channel. Under one or two co-running workloads, average accuracy is 85% and 83%, and for several specific workloads accuracy falls to 50%, the level of random guessing (Figure 10). Even with resynchronization every 100 bits, the average accuracy is only 90%. The paper describes the channel as 'effective' in noisy systems, but without an error model or forward-error correction, a 10-17% bit error rate is not negligible for covert communication. Please qualify the claim and discuss the realistic throughput after error correction, or provide a mechanism for reliable transmission.
  5. [Section 3.1 / Section 5.1] The paper's threat model and evaluation place the attacker on cores 0 and 1 with the victim on cores 2 and 3, and it assumes bank partitioning as a secure baseline. This is a reasonable and even conservative setup, but the DoS result conflates the attacker's own memory traffic with the RFM-induced stalls. In addition to the marginal-slowdown experiment suggested above, the paper should report the victim's slowdown under a conventional high-bandwidth ACT attack with RFM disabled, so that the security contribution of the RFM-specific effect is clear.
minor comments (6)
  1. [Section 1] In the paragraph describing the covert channel, 'the sender does trigger any ACTs' should read 'the sender does not trigger any ACTs'.
  2. [Listing 1 / Listing 2] The use of 'sleep(wait_cycles)' is ambiguous: it is not defined whether this is a CPU delay loop, a simulator-provided stall, or a memory-timing mechanism. Since the sender and receiver timing is central to the channel, please clarify how the wait cycles are implemented in the simulator and in a real deployment.
  3. [Table 3] The columns labeled 'Benign', 'DOS (With Mitig.)', and 'DOS (No Mitig.)' each contain Max and Avg sub-entries, but the table layout does not make the pairing obvious. Please restructure the table so that the Max and Avg values are explicitly associated with each workload class.
  4. [References] Reference [13] is a duplicate of reference [12]; both point to the ChampSim arXiv report. Please remove the duplicate.
  5. [Figure 15] The x-axis of Figure 15 is not labeled; the text describes RAAIMT values of 32, 16, 8, and 4, but the figure does not show tick labels. Please add axis labels so that the reader can verify the match with Equation (2).
  6. [Section 2.4] The phrase 'RAAIMT 16 and 32' in the RFM Thresholds paragraph would be clearer as 'RAAIMT = 16 and 32', matching the notation used elsewhere in the paper.

Circularity Check

1 steps flagged · score 2.0 of 10

The central 'bank interference' insight is definitional rather than derived, but the attack numbers come from explicit simulator assumptions and no fitted-parameter circularity; only minor self-citations set parameter values.

  1. self definitional [Section 1, 'Key Insight']
    "During an RFMab command, all the banks in a rank are blocked for 410ns to perform a mitigative action. Next, an RFMab command is issued even if the RAACtr of only one bank has reached RAAMMT. This means that a single bank is allowed to block all the banks in a rank for 410ns."

    The claimed 'insight' is a restatement of the definition of the RFMab (RFM all-bank) command: an all-bank command that stalls the whole rank for tRFC. The paper presents this as a discovered side effect ('Our paper shows that RFM introduces new side effects'), but the conclusion is contained in the premise. No measurement, simulation result, or analytical derivation is needed to establish that one bank can block all banks once RFMab is defined. This is a framing/taxonomy issue rather than a statistical circularity: the actual attacks still require engineering (eviction sets, tREFI synchronization, sender/receiver steady states), and the reported accuracy and slowdown numbers are not fitted to this insight.

full rationale

No fitted parameter is renamed as a prediction anywhere in the paper. The 356 ns receiver timing gap, the 31.3 KB/s covert-channel bandwidth, and the 1.37/2.6 RFMab-per-tREFI counts are accounting identities derived from tREFI, tRFC, tRC, and the chosen RAAIMT/RAAMMT values under the explicitly stated RFM policy; they are consistency results of the simulator's assumptions, not independent empirical predictions that could be circularly forced. The analytical model in Appendix A is a closed-form solution of the same timing accounting used in the simulation, so it is a sanity check rather than a separate first-principles derivation. Self-citations to prior RFM defense work ([19], [39]) are used only to select RAAIMT values of 16 and 32; the existence of the covert channel and DoS attack does not depend on those exact values, so this is not load-bearing circularity. The main weakness is that the headline numbers are conditional on the assumed immediate-issue RFMab policy, which is an assumption rather than a circularity. Overall, the paper's core attack construction is self-contained against external benchmarks, and the only definitional element is the framing of RFMab's all-bank blocking as a newly shown side effect.

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

No new physical entities are introduced. The central derivation is a timing budget; the analysis rests on vendor-configurable RFM parameters and the assumed memory controller policy.

free parameters (4)
  • RAAIMT (RFM decrement) = 16 and 32
    Chosen from prior RFM-based defense papers [19,25,39]; attack rate and slowdown scale with it. Not fitted to simulation results but hand-selected.
  • RAAMMT (RFM threshold) = 48 and 96 (3x RAAIMT)
    Set as 3x RAAIMT following the assumed policy; determines how aggressively RFMab is triggered.
  • REF RAACtr decrement = RAAIMT/2
    Assumed in Section 2.4: 'we assume that during REF, the RAACtr is decremented by RAAIMT/2'; the covert channel's steady state and 1-bit-per-tREFI bandwidth rely on this.
  • Receiver detection threshold and wait cycles = THRESHOLD, wait_cycles=825 (receiver), 100 (sender)
    Gadget parameters in Listings 1 and 2 are hand-tuned; no sensitivity analysis or real calibration is provided.
assumptions (4)
  • domain assumption DDR5 RFM protocol as specified: per-bank RAACtr, RAAMMT, RFMab blocks all banks for tRFC and decrements RAACtr by RAAIMT.
    Section 2.4; if real devices or controllers deviate, both attacks weaken.
  • domain assumption Memory controller always issues RFMab immediately when any bank's RAACtr reaches RAAMMT.
    Section 2.4 and 3.1: 'we assume an RFM policy where the memory controller issues an RFMab command when the RAACtr of any bank reaches RAAMMT.'
  • ad hoc to paper During REF, RAACtr decrements by RAAIMT/2.
    Section 2.4: 'For this work, we assume that during REF, the RAACtr is decremented by RAAIMT/2.' This is not a JEDEC fixed value and is essential for the covert channel steady state.
  • domain assumption Physical address bits selecting the LLC set also select the DRAM bank, so an eviction set maps to one bank.
    Section 4.1 and Figure 7; needed to generate same-bank ACTs. Authors note it can be reverse-engineered, but the attack design depends on it.

how reviews work

0 comments
Cite this review

Pith. "Pith review of RogueRFM: Attacking Refresh Management for Covert-Channel and Denial-of-Service." pith.science (2026). https://pith.science/paper/MDG3HBF2

@misc{pith2026250106646,
  author       = {Pith},
  title        = {Pith review of: RogueRFM: Attacking Refresh Management for Covert-Channel and Denial-of-Service},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MDG3HBF2}},
  note         = {Machine review of arXiv:2501.06646}
}
read the original abstract

With lowering thresholds, transparently defending against Rowhammer within DRAM is challenging due to the lack of time to perform mitigation. Commercially deployed in-DRAM defenses like TRR that steal time from normal refreshes~(REF) to perform mitigation have been proven ineffective against Rowhammer. In response, a new Refresh Management (RFM) interface has been added to the DDR5 specifications. RFM provides dedicated time to an in-DRAM defense to perform mitigation. Several recent works have used RFM for the intended purpose - building better Rowhammer defenses. However, to the best of our knowledge, no prior study has looked at the potential security implications of this new feature if an attacker subjects it to intentional misuse. Our paper shows that RFM introduces new side effects in the system - the activity of one bank causes interference with the operation of the other banks. Thus, the latency of a bank becomes dependent on the activity of other banks. We use these side effects to build two new attacks. First, a novel memory-based covert channel, which has a bandwidth of up to 31.3 KB/s, and is also effective even in a bank-partitioned system. Second, a new Denial-of-Service (DOS) attack pattern that exploits the activity within a single bank to reduce the performance of the other banks. Our experiments on SPEC2017, PARSEC, and LIGRA workloads show a slowdown of up to 67\% when running alongside our DOS pattern. We also discuss potential countermeasures for our attacks.

Figures

Figures reproduced from arXiv: 2501.06646 by the authors.

Figure 1
Figure 1. (a) Overview of RFM: RAACtr is incremented on activations, and when RAACtr=RAAMMT, the MC issues an RFMab command. (b) As RFMab blocks all banks for 410 ns, allowing one bank to impact the performance of others. (c) A sender can trigger RFMab to slow all banks, enabling a timing-based covert channel. (d) Continuous ACTs to one bank can cause frequent RFMab operations, leading to a DOS-like scenario. that can have se… view at source ↗
Figure 2
Figure 2. When an RFM command is launched, the mem￾ory controller is blocked from issuing activation for 410ns. During this period, the in-DRAM refreshes the victims of an attacker row that has breached 𝑇𝑅𝐻 . 3 [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. In the presence of RFM, activations from only one bank can interfere with the operation of all the other banks. bank will saturate its RAACtr, forcing the memory controller to issue an RFMab, stalling all the banks for 410ns. As a result, any new or queued requests from all the other banks will now have to wait until the RFM command finishes execution. Side Effects of RFM. The ability of banks to interfere with the … view at source ↗
Figures from the paper (12 more)
Figure 3
Figure 3. Figure 3: RFM Mechanism: Per-bank RAACtr is incremented on an activation. If the RAACtr of any bank reaches the threshold, the MC issues an RFM and reduces the RAACtr. RFM Commands. To allow further activations, the RFM commands decrement the RAACtr by RAAIMT (specified by DRAM …
Figure 5
Figure 5. Figure 5: Two side effects of RFM. The latency of one bank is affected by the activity of other banks. One bank has the ability to slow down all the other banks. 2.6 Goal: Exploiting Bank Interference from RFM RFM is a powerful interface that an in-DRAM defense can use to reques…
Figure 7
Figure 7. Figure 7: The bits that determine the cache set index also determine the bank index in DRAM. This ensures that all the elements of the eviction set reside in the same bank, and every access to it results in an ACT in the same bank. Receiver Gadget. The goal of the receiver is to…
Figure 6
Figure 6. Figure 6: Covert Channel: The RFM interface allows two parties to communicate via a timing channel. 4.1 Access Pattern to Invoke ACTs We want both the sender and the receiver to be able to invoke ACTs to a particular bank. To do that, we first ensure that the data is not served …
Figure 8
Figure 8. Figure 8: Sender Initialization: The sender issues 96 ACTs to reach the steady state (RAACtr=64) in 2 tREFIs. After this, the sender can trigger an RFMab every tREFI. Sender Gadget. To send a ‘1’, the sender issues 48 ACTs to its bank within tREFI. Since the RAACtr of the sender…
Figure 9
Figure 9. Figure 9: ACT trace when transmitting 0 vs. 1: Frequent ACTs from the sender when transmitting 1 trigger RFMab, resulting in a longer response time for receiver requests. separates the two requests. Our sender and receiver pro￾cesses can use this technique to synchronize to the …
Figure 10
Figure 10. Figure 10: Accuracy of the covert channel when running SPEC2017, LIGRA, and PARSEC workloads in parallel with the covert channel. The average accuracy of the channel with one (1-Core Noise) and two (2-Core Noise) extra workloads running in parallel to add noise is 85% and 83%, r…
Figure 11
Figure 11. Figure 11: Once synchronized to tREFI, the sender and receiver can be kept aligned to tREFI by waiting for an appropriate amount of time before the next transmit. Time Difference. The time taken by the receiver to com￾plete 16 loads when receiving ‘0’ and ‘1’ is 3109 ns and 3465…
Figure 12
Figure 12. Figure 12: The activations of the sender and receiver over time. While sending ‘1’, the sender triggers RFMab, which causes a significant delay in the response to the receiver. Speed and Bandwidth. The steady state of our covert chan￾nel relies on the REF command decrementing th…
Figure 13
Figure 13. Figure 13: DOS Overview: The RFM interface allows one bank to reduce the performance of all the other banks. 5.1 Attack Pattern The access pattern for the DOS attack is similar to that of the covert-channel. The attacker creates a self-evicting set and accesses it continuously i…
Figure 14
Figure 14. Figure 14: Normalized weighted slowdown caused by a DOS adversary triggering RFMab. On average, the slowdown caused by the DOS adversary is 14.7% for RAAIMT=32 and 27.7% for RAAIMT=16. We see a worst-case slowdown of 29.3% and 67% for the streamcluster workload. the countermeasu…
Figure 15
Figure 15. Figure 15: Average number of RFM triggered by the DOS pattern. The analytical and observed values closely align. Maximum Slowdown in Coresident Applications. RFMab roughly consumes 11.7% of time within a tREFI window and with RAAIMT=32 and 16, the attacker can trigger a 1.37 and…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

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

    cs.CR 2025-01 conditional novelty 7.0 of 10

    DAPPER-H is a RowHammer tracker that resists performance attacks by double-hashing row-group counters, adding per-bank bit-vector filters, and refreshing only the rows shared between matched groups.

  2. ShadowScope: GPU Monitoring and Validation via Composable Side Channel Signals

    cs.CR 2025-08 conditional novelty 5.0 of 10

    ShadowScope detects GPU kernel attacks by segmenting kernel execution with marker functions and comparing PMU traces against pre-collected golden references, achieving up to 100% detection in its experiments.

Reference graph

Works this paper leans on

57 extracted references · 55 canonical work pages · cited by 2 Pith papers

  1. [1]

    Spec cpu2017 benchmark suite

    work page

  2. [2]

    Anvil: Software-based protection against next-generation rowhammer at- tacks

    Zelalem Birhanu Aweke, Salessawi Ferede Yitbarek, Rui Qiao, Reetu- parna Das, Matthew Hicks, Yossi Oren, and Todd Austin. Anvil: Software-based protection against next-generation rowhammer at- tacks. ACM SIGPLAN Notices, 51(4):743–755, 2016

    work page 2016

  3. [3]

    Panop- ticon: A complete in-dram rowhammer mitigation

    Tanj Bennett, Stefan Saroiu, Alec Wolman, and Lucian Cojocar. Panop- ticon: A complete in-dram rowhammer mitigation. In Workshop on DRAM Security (DRAMSec), 2021

    work page 2021

  4. [4]

    The parsec benchmark suite: Characterization and architectural implica- tions

    Christian Bienia, Sanjeev Kumar, Jaswinder Pal Singh, and Kai Li. The parsec benchmark suite: Characterization and architectural implica- tions. In Proceedings of the 17th international conference on Parallel architectures and compilation techniques , pages 72–81, 2008

    work page 2008

  5. [5]

    Rip-rh: Preventing rowhammer-based inter- process attacks

    Carsten Bock, Ferdinand Brasser, David Gens, Christopher Liebchen, and Ahamd-Reza Sadeghi. Rip-rh: Preventing rowhammer-based inter- process attacks. In Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security , pages 561–572, 2019

    work page 2019

  6. [6]

    Can’t touch this: Software-only mitiga- tion against rowhammer attacks targeting kernel memory

    Ferdinand Brasser, Lucas Davi, David Gens, Christopher Liebchen, and Ahmad-Reza Sadeghi. Can’t touch this: Software-only mitiga- tion against rowhammer attacks targeting kernel memory. In 26th {USENIX} Security Symposium ({USENIX} Security 17), pages 117–130, 2017

    work page 2017

  7. [7]

    Ex- ploiting correcting codes: On the effectiveness of ecc memory against rowhammer attacks

    Lucian Cojocar, Kaveh Razavi, Cristiano Giuffrida, and Herbert Bos. Ex- ploiting correcting codes: On the effectiveness of ecc memory against rowhammer attacks. In 2019 IEEE Symposium on Security and Privacy (SP), pages 55–71. IEEE, 2019

    work page 2019

  8. [8]

    SMASH: Synchronized Many-sided Rowhammer Attacks from JavaScript

    Finn de Ridder, Pietro Frigo, Emanuele Vannacci, Herbert Bos, Cris- tiano Giuffrida, and Kaveh Razavi. SMASH: Synchronized Many-sided Rowhammer Attacks from JavaScript. In USENIX Security 21, 2021

    work page 2021

Show all 57 references
  1. [9]

    Restating the case for weighted- ipc metrics to evaluate multiprogram workload performance

    Stijn Eyerman and Lieven Eeckhout. Restating the case for weighted- ipc metrics to evaluate multiprogram workload performance. IEEE Computer Architecture Letters, 13(2):93–96, 2013

    2013

  2. [10]

    When frodo flips: End- to-end key recovery on frodokem via rowhammer

    Michael Fahr Jr, Hunter Kippen, Andrew Kwong, Thinh Dang, Jacob Lichtinger, Dana Dachman-Soled, Daniel Genkin, Alexander Nelson, Ray Perlner, Arkady Yerukhimovich, et al. When frodo flips: End- to-end key recovery on frodokem via rowhammer. In Proceedings of the 2022 ACM SIGSA...

    2022

  3. [11]

    TR- Respass: Exploiting the many sides of target row refresh

    Pietro Frigo, Emanuele Vannacc, Hasan Hassan, Victor Van Der Veen, Onur Mutlu, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi. TR- Respass: Exploiting the many sides of target row refresh. In 2020 IEEE Symposium on Security and Privacy (SP) , pages 747–762. IEEE, 2020

    2020

  4. [13]

    The championship simulator: Architectural simulation for education and competition

    Nathan Gober, Gino Chacon, Lei Wang, Paul V Gratz, Daniel A Jimenez, Elvira Teran, Seth Pugsley, and Jinchun Kim. The championship simulator: Architectural simulation for education and competition. arXiv preprint arXiv:2210.14324, 2022

    arXiv

  5. [14]

    An- other flip in the wall of rowhammer defenses

    Daniel Gruss, Moritz Lipp, Michael Schwarz, Daniel Genkin, Jonas Juffinger, Sioli O’Connell, Wolfgang Schoechl, and Yuval Yarom. An- other flip in the wall of rowhammer defenses. In2018 IEEE Symposium on Security and Privacy (SP) , pages 245–261. IEEE, 2018

    2018

  6. [15]

    Rowham- mer.js: A remote software-induced fault attack in javascript

    Daniel Gruss, Clémentine Maurice, and Stefan Mangard. Rowham- mer.js: A remote software-induced fault attack in javascript. In Juan Caballero, Urko Zurutuza, and Ricardo J. Rodríguez, editors, Detec- tion of Intrusions and Malware, and Vulnerability Assessment , pages 300–321,...

    2016

  7. [16]

    Flush+ flush: a fast and stealthy cache attack

    Daniel Gruss, Clémentine Maurice, Klaus Wagner, and Stefan Man- gard. Flush+ flush: a fast and stealthy cache attack. In Detection of Intrusions and Malware, and Vulnerability Assessment: 13th Interna- tional Conference, DIMV A 2016, San Sebastián, Spain, July 7-8, 2016, Proce...

    2016

  8. [17]

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

    Hasan Hassan, Yahya Can Tugrul, Jeremie S Kim, Victor Van der Veen, Kaveh Razavi, and Onur 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 Mi...

    2021

  9. [18]

    Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4

    Intel. Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4. https: //cdrdv2.intel.com/v1/dl/getContent/671200, 2024

    2024

  10. [19]

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

    Aamer Jaleel, Gururaj Saileshwar, Stephen W Keckler, and Moinuddin Qureshi. Pride: Achieving secure rowhammer mitigation with low- cost in-dram trackers. In ISCA. IEEE, 2024

    2024

  11. [20]

    Blacksmith: Scalable rowhammering in the frequency domain

    Patrick Jattke, Victor Van Der Veen, Pietro Frigo, Stijn Gunter, and Kaveh Razavi. Blacksmith: Scalable rowhammering in the frequency domain. In 2022 IEEE Symposium on Security and Privacy (SP) , pages 716–734. IEEE, 2022

    2022

  12. [21]

    Jedec updates jesd79-5c ddr5 sdram standard: Elevating per- formance and security for next-gen technologies, April 2024

    JEDEC. Jedec updates jesd79-5c ddr5 sdram standard: Elevating per- formance and security for next-gen technologies, April 2024

    2024

  13. [22]

    Ddr5 sdram jedec standard (jesd79-5b), Sept 2022

    JEDEC. Ddr5 sdram jedec standard (jesd79-5b), Sept 2022

    2022

  14. [23]

    Architec- tural support for mitigating row hammering in dram memories

    Dae-Hyun Kim, Prashant J Nair, and Moinuddin K Qureshi. Architec- tural support for mitigating row hammering in dram memories. IEEE CAL, 14(1):9–12, 2014

    2014

  15. [24]

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

    Jeremie S Kim, Minesh Patel, A Giray Yağlıkçı, Hasan Hassan, Ro- knoddin Azizi, Lois Orosa, and Onur Mutlu. Revisiting rowhammer: An experimental analysis of modern dram devices and mitigation techniques. In ISCA, pages 638–651. IEEE, 2020

    2020

  16. [25]

    Mithril: Cooperative row hammer protection on commodity dram leveraging managed refresh

    Michael Jaemin Kim, Jaehyun Park, Yeonhong Park, Wanju Doh, Namhoon Kim, Tae Jun Ham, Jae W Lee, and Jung Ho Ahn. Mithril: Cooperative row hammer protection on commodity dram leveraging managed refresh. In 2022 IEEE International Symposium on High- Performance Computer Archite...

    2022

  17. [26]

    Woongrae Kim, Chulmoon Jung, Seongnyuh Yoo, Duckhwa Hong, Jeongjin Hwang, Jungmin Yoon, Ohyong Jung, Joonwoo Choi, Sanga Hyun, Mankeun Kang, Sangho Lee, Dohong Kim, Sanghyun Ku, Don- hyun Choi, Nogeun Joo, Sangwoo Yoon, Junseok Noh, Byeongyong Go, Cheolhoe Kim, Sunil Hwang, Mi...

    2023

  18. [27]

    Flip- ping bits in memory without accessing them: An experimental study of dram disturbance errors

    Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, and Onur Mutlu. Flip- ping bits in memory without accessing them: An experimental study of dram disturbance errors. ACM SIGARCH Computer Architecture News, 42(3):361–372, 2014

    2014

  19. [28]

    Half-Double: Hammering from the next row over

    Andreas Kogler, Jonas Juffinger, Salman Qazi, Yoongu Kim, Moritz Lipp, Nicolas Boichat, Eric Shiu, Mattias Nissler, and Daniel Gruss. Half-Double: Hammering from the next row over. In USENIX Security Symposium, 2022

    2022

  20. [29]

    ZebRAM: comprehensive and compatible software protection against rowham- mer attacks

    Radhesh Krishnan Konoth, Marco Oliverio, Andrei Tatar, Dennis An- driesse, Herbert Bos, Cristiano Giuffrida, and Kaveh Razavi. ZebRAM: comprehensive and compatible software protection against rowham- mer attacks. In 13th USENIX - (OSDI 18) , pages 697–710, 2018

    2018

  21. [30]

    Ram- bleed: Reading bits in memory without accessing them

    Andrew Kwong, Daniel Genkin, Daniel Gruss, and Yuval Yarom. Ram- bleed: Reading bits in memory without accessing them. In 2020 IEEE 12 Symposium on Security and Privacy (SP) , pages 695–711. IEEE, 2020

    2020

  22. [31]

    Twice: preventing row-hammering by exploiting time window coun- ters

    Eojin Lee, Ingab Kang, Sukhan Lee, G Edward Suh, and Jung Ho Ahn. Twice: preventing row-hammering by exploiting time window coun- ters. In Proceedings of the 46th International Symposium on Computer Architecture, pages 385–396, 2019

    2019

  23. [32]

    Shang Li, Zhiyuan Yang, Dhiraj Reddy, Ankur Srivastava, and Bruce L. Jacob. DRAMsim3: A Cycle-Accurate, Thermal-Capable DRAM Simu- lator. IEEE Comput. Archit. Lett., 19(2):110–113, 2020

    2020

  24. [33]

    Last-level cache side-channel attacks are practical

    Fangfei Liu, Yuval Yarom, Qian Ge, Gernot Heiser, and Ruby B Lee. Last-level cache side-channel attacks are practical. In 2015 IEEE sym- posium on security and privacy , pages 605–622. IEEE, 2015

    2015

  25. [34]

    Pro- trr: Principled yet optimal in-dram target row refresh

    Michele Marazzi, Patrick Jattke, Flavien Solt, and Kaveh Razavi. Pro- trr: Principled yet optimal in-dram target row refresh. In 2022 IEEE Symposium on Security and Privacy (SP) , pages 735–753. IEEE, 2022

    2022

  26. [35]

    DDR5 SDRAM Datasheet, 2022

    Micron Technology Inc. DDR5 SDRAM Datasheet, 2022

    2022

  27. [36]

    Cache attacks and countermeasures: the case of aes

    Dag Arne Osvik, Adi Shamir, and Eran Tromer. Cache attacks and countermeasures: the case of aes. In Topics in Cryptology–CT-RSA 2006: The Cryptographers’ Track at the RSA Conference 2006, San Jose, CA, USA, February 13-17, 2005. Proceedings , pages 1–20. Springer, 2006

  28. [37]

    Graphene: Strong yet lightweight row hammer protection

    Yeonhong Park, Woosuk Kwon, Eojin Lee, Tae Jun Ham, Jung Ho Ahn, and Jae W Lee. Graphene: Strong yet lightweight row hammer protection. In 2020 53rd Annual IEEE/ACM MICRO, pages 1–13. IEEE, 2020

    2020

  29. [38]

    {DRAMA}: Exploiting{DRAM} addressing for {Cross-CPU} attacks

    Peter Pessl, Daniel Gruss, Clémentine Maurice, Michael Schwarz, and Stefan Mangard. {DRAMA}: Exploiting{DRAM} addressing for {Cross-CPU} attacks. In 25th USENIX security symposium (USENIX security 16), pages 565–581, 2016

    2016

  30. [39]

    Mint: Securely mitigating rowhammer with a minimalist in-dram tracker

    Moinuddin Qureshi, Salman Qazi, and Aamer Jaleel. Mint: Securely mitigating rowhammer with a minimalist in-dram tracker. In MICRO. IEEE, 2024

    2024

  31. [40]

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

    Moinuddin Qureshi, Aditya Rohan, Gururaj Saileshwar, and Prashant 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, pages 699– 710, 2022

    2022

  32. [41]

    New attacks and defense for encrypted-address cache

    Moinuddin K Qureshi. New attacks and defense for encrypted-address cache. In Proceedings of the 46th International Symposium on Computer Architecture, pages 360–371, 2019

    2019

  33. [42]

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

    Gururaj Saileshwar, Bolin Wang, Moinuddin Qureshi, and Prashant 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 Programmin...

    2022

  34. [43]

    Busmon- itor: A hypervisor-based solution for memory bus covert channels

    Brendan Saltaformaggio, Dongyan Xu, and Xiangyu Zhang. Busmon- itor: A hypervisor-based solution for memory bus covert channels. Proceedings of EuroSec, 2013

    2013

  35. [44]

    Start: Scalable tracking for any rowhammer threshold

    Anish Saxena and Moinuddin Qureshi. Start: Scalable tracking for any rowhammer threshold. In 2024 IEEE International Symposium on High-Performance Computer Architecture (HPCA), pages 578–592. IEEE, 2024

    2024

  36. [45]

    Aqua: Scalable rowhammer mitigation by quarantining aggressor rows at runtime

    Anish Saxena, Gururaj Saileshwar, Prashant J Nair, and Moinuddin Qureshi. Aqua: Scalable rowhammer mitigation by quarantining aggressor rows at runtime. In 2022 55th IEEE/ACM International Sym- posium on Microarchitecture (MICRO) , pages 108–123. IEEE, 2022

    2022

  37. [46]

    Exploiting the DRAM rowhammer bug to gain kernel privileges

    Mark Seaborn and Thomas Dullien. Exploiting the DRAM rowhammer bug to gain kernel privileges. Black Hat, 15:71, 2015

    2015

  38. [47]

    Mit- igating wordline crosstalk using adaptive trees of counters

    Seyed Mohammad Seyedzadeh, Alex K Jones, and Rami Melhem. Mit- igating wordline crosstalk using adaptive trees of counters. In 2018 ACM/IEEE 45th Annual International Symposium on Computer Archi- tecture (ISCA), pages 612–623. IEEE, 2018

    2018

  39. [48]

    Blelloch

    Julian Shun and Guy E. Blelloch. Ligra: A lightweight graph process- ing framework for shared memory. In Proceedings of the 18th ACM SIGPLAN Symposium on Principles and Practice of Parallel Program- ming, PPoPP ’13, page 135–146, New York, NY, USA, 2013. Association for Comput...

    2013

  40. [49]

    Making dram stronger against row hammering

    Mungyu Son, Hyunsun Park, Junwhan Ahn, and Sungjoo Yoo. Making dram stronger against row hammering. In Proceedings of the 54th Annual Design Automation Conference 2017, pages 1–6, 2017

    2017

  41. [50]

    Drammer: Deterministic rowhammer attacks on mobile platforms

    Victor van der Veen, Yanick Fratantonio, Martina Lindorfer, Daniel Gruss, Clementine Maurice, Giovanni Vigna, Herbert Bos, Kaveh Razavi, and Cristiano Giuffrida. Drammer: Deterministic rowhammer attacks on mobile platforms. In Proceedings of the 2016 ACM SIGSAC Conference on C...

    2016

  42. [51]

    Guardion: Practical mitigation of dma-based rowhammer attacks on arm

    Victor Van der Veen, Martina Lindorfer, Yanick Fratantonio, Harikrish- nan Padmanabha Pillai, Giovanni Vigna, Christopher Kruegel, Herbert Bos, and Kaveh Razavi. Guardion: Practical mitigation of dma-based rowhammer attacks on arm. In International Conference on Detection of I...

    2018

  43. [52]

    Theory and practice of finding eviction sets

    Pepe Vila, Boris Köpf, and José F Morales. Theory and practice of finding eviction sets. In 2019 IEEE Symposium on Security and Privacy (SP), pages 39–54. IEEE, 2019

    2019

  44. [53]

    Shadow: Preventing row hammer in dram with intra-subarray row shuffling

    Minbok Wi, Jaehyun Park, Seoyoung Ko, Michael Jaemin Kim, Nam Sung Kim, Eojin Lee, and Jung Ho Ahn. Shadow: Preventing row hammer in dram with intra-subarray row shuffling. In 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA), pages 333–346. IEEE, 2023

    2023

  45. [54]

    Whispers in the hyper- space: high-bandwidth and reliable covert channel attacks inside the cloud

    Zhenyu Wu, Zhang Xu, and Haining Wang. Whispers in the hyper- space: high-bandwidth and reliable covert channel attacks inside the cloud. IEEE/ACM Transactions on Networking, 23(2):603–615, 2014

    2014

  46. [55]

    Security implications of memory deduplication in a virtualized environment

    Jidong Xiao, Zhang Xu, Hai Huang, and Haining Wang. Security implications of memory deduplication in a virtualized environment. In 2013 43rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN) , pages 1–12. IEEE, 2013

    2013

  47. [56]

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

    A Giray Yağlikçi, Minesh Patel, Jeremie S Kim, Roknoddin Azizi, Ataberk Olgun, Lois Orosa, Hasan Hassan, Jisung Park, Konstanti- nos Kanellopoulos, Taha Shahroodi, et al. Blockhammer: Preventing rowhammer at low cost by blacklisting rapidly-accessed dram rows. In 2021 IEEE Int...

    2021

  48. [57]

    In 23rd USENIX security symposium (USENIX security 14) , pages 719–732, 2014

    Yuval Yarom and Katrina Falkner.{FLUSH+ RELOAD}: A high res- olution, low noise, l3 cache{Side-Channel} attack. In 23rd USENIX security symposium (USENIX security 14) , pages 719–732, 2014

    2014

  49. [58]

    Mrloc: Mitigating row-hammering based on memory locality

    Jung Min You and Joon-Sung Yang. Mrloc: Mitigating row-hammering based on memory locality. In 2019 56th ACM/IEEE Design Automation Conference (DAC), pages 1–6. IEEE, 2019. 13

    2019

Pith tools

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