{"id":"ceb4eb5c-6c29-4183-9872-2807d6dfddb8","arxiv_id":"2501.06646","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"An attacker can abuse DDR5 Refresh Management so one DRAM bank's activity stalls all other banks, creating a 31.3 KB/s covert channel and up to 67% slowdown of co-running workloads.","lead":"This paper shows that DDR5's new Rowhammer defense mechanism, Refresh Management (RFM), lets one memory bank stall all the other banks. The authors turn that side effect into a covert channel that sends 31.3 KB/s per subchannel and a denial-of-service attack that slows co-running programs by up to 67%.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The attacks rest on an assumed immediate RFMab scheduling policy; deferred or batched RFM, which JEDEC permits, would shrink or erase the 356ns timing gap and the DoS slowdown.","rationale":"We reviewed the paper in good faith. The mechanism is coherent under the stated RFM policy: per-bank RAACtr, RFMab on threshold, and a 410ns tRFC stall. The simulated covert channel and DoS follow from that model, and the paper is transparent about its parameters and simulation setup. The load-bearing weakness is that this policy is an assumption, not a demonstrated property of real DDR5 controllers; Section 2.4 explicitly allows RFM to be issued earlier, and the paper does not evaluate other compliant schedulers. Since the receiver's 356ns gap and the repeated RFMab rate directly enable both attacks, a controller that batches or defers RFMab would weaken or eliminate them. The discrepancy between the analytical bound (16%/31%) and the simulated maximum slowdowns (29.3%/67%) further blurs whether the DoS effect is RFM-specific or ordinary memory contention. These are correctness risks rather than internal contradictions, and they do not invalidate the paper's contribution as a first security analysis of the RFM interface; they do justify a conditional rather than unconditional verdict. We therefore agree with the reader's CONDITIONAL verdict and recommend no change.","tokens_in":18959,"tokens_out":4727,"duration_ms":47556,"concrete_test":"Re-run the covert-channel and DoS experiments in DRAMsim3 with a modified RFM policy that defers RFMab until the first REF slot after any RAACtr reaches RAAMMT (or until two banks' counters are both non-zero), keeping all other parameters unchanged. If the receiver's timing gap falls from 356ns to below the rdtsc-based detection threshold, or if the DoS slowdown drops toward the analytical bound, the attacks depend on the assumed scheduling policy. A second check: run the DoS access pattern with RFM disabled and measure the slowdown from ACT contention alone; if this is comparable to the RFM-enabled case, the 67% slowdown is not RFM-specific.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim—that RFMab lets one bank block all banks for 410ns—is established only under the RFM policy assumed in Section 3.1: 'the memory controller issues an RFMab command when the RAACtr of any bank reaches RAAMMT.' Section 2.4 explicitly notes that the memory controller 'can also issue an RFM command before the RAACtr reaches RAAMMT,' and the JEDEC RFM interface leaves room for different scheduling choices. A real controller that defers RFMab until the next REF boundary, or that waits until several banks' counters are near RAAMMT before issuing a single RFMab, would not produce the deterministic 356ns receiver-visible timing gap in Section 4.4 nor the 1.37/2.6 RFMab-per-tREFI rates in Section 5.1. The paper provides no hardware measurements or reference to a deployed controller showing that the assumed immediate-scheduling policy is what DDR5 systems actually use. Additionally, the Appendix A analytical model caps RFM-induced slowdown at 16%/31%, yet the simulations report 29.3%/67%; this two-fold gap suggests that the reported DoS slowdown includes ordinary memory contention from the attacker's own ACT stream, not purely RFM-specific interference. Both issues mean the headline attack numbers are conditional on a non-guaranteed controller behavior.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":19280,"tokens_out":4884,"duration_ms":47383,"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":[{"comment":"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.","section":"Section 3.1 / Section 2.4"},{"comment":"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.","section":"Section 5.2 / Appendix A"},{"comment":"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.","section":"Section 2.4"},{"comment":"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.","section":"Section 4.5"},{"comment":"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.","section":"Section 3.1 / Section 5.1"}],"minor_comments":[{"comment":"In the paragraph describing the covert channel, 'the sender does trigger any ACTs' should read 'the sender does not trigger any ACTs'.","section":"Section 1"},{"comment":"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.","section":"Listing 1 / Listing 2"},{"comment":"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.","section":"Table 3"},{"comment":"Reference [13] is a duplicate of reference [12]; both point to the ChampSim arXiv report. Please remove the duplicate.","section":"References"},{"comment":"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).","section":"Figure 15"},{"comment":"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.","section":"Section 2.4"}],"recommendation":"major_revision","confidential_remarks":"This is a simulation-based security study of a DRAM interface whose real-world controller policies are not yet publicly characterized. The conditional nature of the results is expected for this type of work, and the paper is transparent about its assumptions. The main issue is not that the assumptions exist, but that the central quantitative claims (356 ns gap, 1.37/2.6 RFMab/tREFI, up to 67% slowdown) are presented as concrete security properties without a sensitivity analysis or a clear separation of RFM-specific effects from ordinary memory contention. These gaps are fixable within the manuscript's scope, which is why I recommend major revision rather than rejection. There is no citation or scope concern to flag: the self-citations to prior RFM-based Rowhammer defenses are appropriate, and the paper fits the venue's security focus."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First thing to know: this paper is the first, to my knowledge, to treat the DDR5 RFM interface as something an attacker can misuse rather than as a defense. That alone makes it worth a look. The central observation is correct: RFMab blocks all banks in a rank for tRFC even when only one bank's RAACtr hits RAAMMT, so one bank's activity can stall the other thirty-one. From that, the authors build a cross-bank timing covert channel that defeats bank partitioning, and a single-bank DoS pattern that slows co-running workloads by up to 67% in simulation. The covert channel is the stronger of the two; the DoS is more incremental.\n\nThe simulation work is solid. They modified DRAMsim3 for DDR5 sub-channels, and the reported 356 ns receiver-visible gap matches the expected 410 ns tRFC well. The analytical model for RFM frequency (Appendix A) is simple accounting and matches the simulated counts. No fitted constants are hiding the headline numbers.\n\nThe soft spots are real, though. The attacks assume the memory controller issues RFMab immediately when any bank's RAACtr reaches RAAMMT. The paper itself notes the controller may issue RFM before the threshold, and JEDEC leaves scheduling policy open. A controller that defers or batches RFMab would shrink or erase the deterministic timing gap and the 1.37/2.6 RFMab-per-tREFI rates. There is no hardware validation and no code shipped, so the numbers are conditional on an assumed RFM policy. Second, the analytical model caps RFM-induced slowdown at 16%/31%, but the simulations report 29.3%/67%. The paper never explains this factor-of-two gap. The likely explanation is that the measured slowdown includes ordinary memory contention from the attacker's own ACT stream, not purely RFM stalls. That dilutes the DoS claim; some of the slowdown is just a core hammering memory.\n\nWho is this for? DRAM/architecture researchers, Rowhammer people, and anyone doing memory isolation on DDR5. It deserves a serious referee: the concept is new and the presentation is transparent about the assumed policy. A strong revision would add a sensitivity study across plausible RFM schedulers or evidence that real controllers use immediate scheduling. I'd take it to review, with the understanding that the numbers are upper bounds under a worst-case controller.","headline":"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.","tokens_in":19788,"tokens_out":3052,"would_cite":true,"duration_ms":28871,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["Rowhammer","DDR5","Refresh Management (RFM)","covert channel","denial-of-service","bank interference","timing side channel","DRAM security"],"falsifier":"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.","tokens_in":18762,"feed_emoji":"🔓","tokens_out":9291,"duration_ms":79364,"temperature":0.7,"pith_summary":"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.","feed_headline":"DDR5 row-hammer fix creates a 31 KB/s covert channel","feed_subtitle":"Attackers in one bank stall the entire rank, defeating bank partitioning and slowing co-runners by up to 67%.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Establishes Rowhammer as repeated-activation bit flips, the threat the RFM counter exists to mitigate.","marker":"[27]"},{"why":"Documents the Rowhammer threshold falling to 4.8K, motivating low-threshold in-DRAM defenses.","marker":"[24]"},{"why":"Describes TRR's practice of stealing refresh time, the scalability limit RFM was introduced to fix.","marker":"[17]"},{"why":"Shows TRR-style in-DRAM defenses fail, supplying the motivation for dedicated RFM time.","marker":"[11]"},{"why":"Defines the RFM interface, RFMab, RAACtr, RAAIMT, and the rule that RFM is issued when a counter hits RAAMMT.","marker":"[22]"},{"why":"Supplies the DDR5 timing parameters (tRFC=410ns, tREFI=3900ns) that make the 356ns receiver-visible gap possible.","marker":"[35]"},{"why":"Is an RFM-based in-DRAM defense whose configuration (RAAIMT and RAAMMT values) the paper adopts for its attack model.","marker":"[34]"},{"why":"Is another RFM-based defense that informs the RAAIMT=16/32 and RAAMMT=3xRAAIMT settings used in evaluation.","marker":"[39]"},{"why":"Supplies the cycle-level multicore processor simulator used to obtain the workload slowdowns.","marker":"[12]"},{"why":"Supplies the detailed DRAM timing model in which the RFM policy and attacks are evaluated.","marker":"[32]"}],"fun_headline_variants":["RFM abuse: DDR5 covert channel at 31 KB/s and DoS","DDR5 RFM flaw: covert channel and 67% slowdown via refresh abuse","RogueRFM: Turning refresh management into a covert channel","DDR5's Rowhammer fix backfires: 31 KB/s covert channel","RFM side effects enable DDR5 covert channel, bypass partitioning"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["RFM abuse: DDR5 covert channel at 31 KB/s and DoS","DDR5 RFM flaw: covert channel and 67% slowdown via refresh abuse","RogueRFM: Turning refresh management into a covert channel","DDR5's Rowhammer fix backfires: 31 KB/s covert channel","RFM side effects enable DDR5 covert channel, bypass partitioning"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000305,"raw_usage":{"total_tokens":1804,"prompt_tokens":1052,"completion_tokens":752,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":668,"completion_tokens_details":{"reasoning_tokens":653}},"tokens_in":668,"tokens_out":752,"duration_ms":86678,"temperature":1.0,"reasoning_tokens":653,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T20:55:45.371165+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Flip- ping bits in memory without accessing them: An experimental study of dram disturbance errors","cited_arxiv_id":null,"evidence_quote":"Establishes Rowhammer as repeated-activation bit flips, the threat the RFM counter exists to mitigate."},{"cited_title":"Revisiting rowhammer: An experimental analysis of modern dram devices and mitigation techniques","cited_arxiv_id":null,"evidence_quote":"Documents the Rowhammer threshold falling to 4.8K, motivating low-threshold in-DRAM defenses."},{"cited_title":"Uncovering in-dram rowhammer protection mechanisms: A new methodology, custom rowhammer patterns, and implications","cited_arxiv_id":null,"evidence_quote":"Describes TRR's practice of stealing refresh time, the scalability limit RFM was introduced to fix."},{"cited_title":"TR- Respass: Exploiting the many sides of target row refresh","cited_arxiv_id":null,"evidence_quote":"Shows TRR-style in-DRAM defenses fail, supplying the motivation for dedicated RFM time."},{"cited_title":"Ddr5 sdram jedec standard (jesd79-5b), Sept 2022","cited_arxiv_id":null,"evidence_quote":"Defines the RFM interface, RFMab, RAACtr, RAAIMT, and the rule that RFM is issued when a counter hits RAAMMT."},{"cited_title":"DDR5 SDRAM Datasheet, 2022","cited_arxiv_id":null,"evidence_quote":"Supplies the DDR5 timing parameters (tRFC=410ns, tREFI=3900ns) that make the 356ns receiver-visible gap possible."},{"cited_title":"Pro- trr: Principled yet optimal in-dram target row refresh","cited_arxiv_id":null,"evidence_quote":"Is an RFM-based in-DRAM defense whose configuration (RAAIMT and RAAMMT values) the paper adopts for its attack model."},{"cited_title":"Mint: Securely mitigating rowhammer with a minimalist in-dram tracker","cited_arxiv_id":null,"evidence_quote":"Is another RFM-based defense that informs the RAAIMT=16/32 and RAAMMT=3xRAAIMT settings used in evaluation."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the detailed DRAM timing model in which the RFM policy and attacks are evaluated."}],"review_version":1}