{"id":"74a10d63-3dce-4a77-bfb0-a2eaa7e0884b","arxiv_id":"2505.10111","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"PRAC's Alert Back-Off mitigation creates observable memory latency spikes that leak partial AES keys, and periodic activity-independent RFMs close the leak with 3.4 percent average overhead.","lead":"PRAC, the new DDR5 defense against RowHammer memory attacks, leaks information through the timing of its own mitigation delays. The authors show how to read half of an AES key using these delays, and propose a periodic fix that costs about 3.4 percent performance.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Defense overhead claim uses NBO≈1024 while the AES attack uses NBO=256; at the attack's NBO, TB-Window must be ~0.25 tREFI, not 1.6 tREFI, so the 3.4% overhead at NRH=1024 is not tied to the demonstrated attack configuration.","rationale":"In good faith, the paper's attack is plausible and the artifact is a real strength: the AES T-table mechanism and the first-ABO-row encoding are sensible under the stated model. The load-bearing issue is not the existence of the channel but the joint configuration of the attack and defense. PRAC's ABO protocol (Section 2.3, Table 1) allows up to ABOACT=3 extra activations after Alert, so a safe system with NRH=1024 must use NBO well below 1024; the paper's own attack chooses NBO=256, a realistic safe setting. TPRAC's TB-Window is chosen via TMAX<NBO (Eq. 1), not directly from NRH. Figure 7 shows TMAX≈900 at 1.6 tREFI, so the Section 6.2 claim that one TB-RFM every 1.6 tREFI suffices at NRH=1024 only holds if NBO≈1024, which is unsafe by the paper's own ABOACT model. At NBO=256, the required window is about 0.25 tREFI, and Figure 13's trend indicates roughly 14% overhead, not 3.4%. This is an internal consistency check that can be run with the released code; it does not require real PRAC hardware. If the check confirms the higher overhead, the defense's headline cost is not tied to the demonstrated attack configuration. The verdict remains conditional: the attack contribution stands, but the defense's quantitative claim must be re-evaluated at a consistent NBO.","tokens_in":35954,"tokens_out":17975,"duration_ms":172974,"concrete_test":"Using the released ChampSim-Ramulator2 artifact, rerun the Figure 10 performance experiment with NBO fixed to 256 (the value used in the Section 3.3 AES attack), NRH=1024, ABOACT=3, and set TB-Window to the largest interval satisfying TMAX<NBO via the provided Figure 7 security script. Compare average weighted speedup to the claimed 3.4%. If the slowdown is materially higher (approaching the 14.1% reported at NRH=256 in Figure 13), the defense overhead claim is not valid for the attacked configuration. An even stronger check: also confirm whether the NBO=1024 configuration used in Figure 10 permits 1027 activations before mitigation under the ABOACT=3 model; if so, that configuration is not RowHammer-safe.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The strongest quantitative claim—TPRAC closes the channel at 3.4% average slowdown for NRH=1024—rests on an NBO value inconsistent with the demonstrated attack. Section 3.3's AES side-channel explicitly uses NBO=256 and leaks the key in fewer than 200 encryptions. The TPRAC evaluation (Section 6.2) states one TB-RFM every 1.6 tREFI (6.2us) suffices at NRH=1024. But TPRAC's security condition is TMAX < NBO (Eq. 1), and Figure 7 puts TMAX near 900 at 1.6 tREFI; this only satisfies TMAX < NBO if NBO≈1024. Setting NBO=1024 with NRH=1024 is unsafe under the paper's own PRAC model: Section 2.3 and Table 1 allow ABOACT=3 additional activations after Alert, so a row can reach 1027 activations before mitigation, exceeding NRH. Conversely, at the NBO=256 used in the attack, Figure 7 requires TB-Window around 0.25 tREFI (TMAX≈118), which corresponds to the regime where Figure 13 reports roughly 14.1% slowdown (at NRH=256). Thus the paper either evaluates TPRAC at an unsafe NBO (overstating security and understating overhead) or at a different NBO than the attack, and the headline 3.4% cost does not apply to the configuration in which the key-leak channel is demonstrated.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper studies timing channels introduced by the JEDEC PRAC RowHammer mitigation framework. It proposes PRACLeak, a set of covert- and side-channel attacks that exploit the Alert Back-Off (ABO) protocol and the Refresh Management (RFM) commands: when a row's activation counter reaches the back-off threshold NBO, the DRAM asserts Alert and the memory controller issues RFMab commands that block the channel for about 350 ns, creating a system-visible latency spike. The paper demonstrates activity-based and activation-count-based covert channels in simulation, and an AES T-table side channel that recovers 4 bits of each key byte (50% of a 128-bit key) in fewer than 200 encryptions. To close the channel, the paper proposes Timing-Safe PRAC (TPRAC), which replaces activity-dependent ABO/ACB RFMs with periodic, activity-independent Timing-Based RFMs (TB-RFMs) configured so that no row reaches NBO under the Feinting/Wave worst-case attack. TPRAC is evaluated in ChampSim-Ramulator2 simulations and reported to close the channel with an average 3.4% performance overhead at an RH threshold of 1024, using a single-entry per-bank mitigation queue.","tokens_in":36295,"tokens_out":7952,"duration_ms":80852,"significance":"If the central claims hold, this is a timely and important result: PRAC is the industry's standard direction for DDR5 RowHammer mitigation, and the observation that its mitigation machinery itself creates a precise, cross-process timing channel is novel and security-relevant. The paper also ships a substantial artifact: the Ramulator2 modifications, trace generators, ChampSim-Ramulator2 integration, and plotting scripts are all archived, which strengthens reproducibility. The proposed TPRAC defense is standards-compatible, does not require DRAM modifications, and the idea of decoupling RFM issuance from activation counts is a clean conceptual fix. The performance evaluation covers 50 workloads, multiple NRH values, PRAC levels, targeted refresh co-design, and counter-reset policies, and the reported energy and storage overheads are explicitly quantified.","major_comments":[{"comment":"The headline overhead claim is disconnected from the demonstrated attack configuration. The AES side channel in Section 3.3 is explicitly demonstrated with NBO=256 (Figure 4 and the accompanying text), and the covert-channel evaluation in Table 2 spans NBO=256 to 1024. The TPRAC performance evaluation in Section 6.2, however, claims that at NRH=1024, issuing one TB-RFM every 1.6 tREFI suffices, which corresponds to NBO=1024 in Figure 7 (TMAX≈900 < NBO). Under the paper's own Equation (1) and Figure 7, NBO=256 requires a TB-Window near 0.25 tREFI, and Figure 13 reports a 14.1% slowdown at NRH=256. Thus the 3.4% figure does not apply to the configuration in which the key-leak channel is actually demonstrated. The paper should either demonstrate the side channel at NBO=1024 or report the defense overhead at NBO=256 as the cost of closing the demonstrated channel.","section":"Section 6.2 vs. Section 3.3 and Table 2"},{"comment":"The security condition TACT < NBO ignores the ABOACT slack in the paper's own PRAC model. Table 1 states that after a row crosses NBO, the DRAM permits up to ABOACT=3 additional activations before the RFM is issued. If NBO is set equal to NRH (as the evaluation appears to do, since TPRAC's overhead is reported 'at the RH threshold of 1024' with NBO=1024), a baseline PRAC system without TPRAC would allow a row to reach NBO+ABOACT=1027 activations before mitigation, exceeding NRH. The paper should either justify that NBO is always chosen at least ABOACT below NRH in all experiments, or explain explicitly why the ABOACT slack does not affect the claimed RH efficacy of the evaluated configuration.","section":"Section 4.2.2, Eq. (1), and Table 1"},{"comment":"The attack's central premise that every RFMab produces a deterministic, system-wide 350 ns stall observable to all cores is not validated on any real memory controller or DRAM implementation. All PRACLeak and TPRAC results are produced with Ramulator2/ChampSim using JEDEC-derived timing parameters; real controllers may buffer or coalesce requests, hide RFM latency under queued traffic, or implement the ABO protocol differently from the UPRAC/QPRAC model used here. The paper should either provide a real-system validation of the global 350 ns observability assumption or add a sensitivity analysis (e.g., to scheduling policy, request queue depth, and RFM-to-request overlap) and temper the abstract's 'demonstrate' wording to reflect simulation-only evidence.","section":"Section 3.1 and Section 5"},{"comment":"The mechanism by which TPRAC eliminates Activation-Based RFMs (ACB-RFMs) is not specified. Section 4.2 states that the goal is to eliminate ABO-RFMs 'and consequently' ACB-RFMs, but the design description in Section 4 only disables RFM postponing and introduces TB-RFMs; it does not state that ACB-RFMs are disabled or that the Bank Activation Threshold is set to infinity. Since any remaining ACB-RFM is itself activity-dependent and exploitable as a timing channel (as the paper argues in Section 2.6 and Figure 2(b)), the paper must state explicitly how TPRAC prevents ACB-RFMs in the evaluated configuration.","section":"Section 4.2 and Section 5"},{"comment":"The claim that a single-entry, frequency-based mitigation queue achieves security equivalent to the idealized UPRAC design is supported only by three informal scenarios and one illustrative example, not by a proof or a formal invariant. Given that the TB-Window calculation in Section 4.2 is the security foundation for TPRAC, the paper should either provide a rigorous argument that the single-entry queue always mitigates the row that would otherwise reach NBO first, or state the exact replacement rule and timing model and prove that TMAX remains below NBO under that rule.","section":"Section 4.2.3"}],"minor_comments":[{"comment":"The sentence 'TPRAC without counter reset incurs a 73.9% slowdown, compared to 77.4% with reset, resulting in a 3.4% performance improvement' appears to have the two conditions reversed. Since counter resets reduce TMAX in Figure 7 and should allow a longer TB-Window, the text should be checked for consistency with Figure 14.","section":"Section 6.6"},{"comment":"The workload categorization table lists several benchmark names twice within the same category (e.g., 470.lbm, 483.xalancbmk, 471.omnetpp, 456.hmmer, 464.h264ref, 481.wrf); please deduplicate the list.","section":"Table 4"},{"comment":"The paper uses both 'tRFM' and 'tRFMab' for the RFM-all-bank blocking duration; please use one consistent symbol throughout, and state whether the 350 ns value is tRFMab or tRFM.","section":"Section 3.1 and Table 1"},{"comment":"The abstract says the AES key is leaked in 'fewer than 200 encryptions,' while Figure 5 is described as running '200 encryptions.' Please clarify whether the attack succeeds before or after 200 encryptions and make the wording uniform.","section":"Abstract and Section 3.3"},{"comment":"Equation (3) uses Ri without defining how the row-pool size evolves after each round, and the floor-bracket notation is not typeset clearly. Please define Ri for each round and rewrite the equation with standard floor notation.","section":"Section 4.2.2, Eq. (3)"}],"recommendation":"major_revision","confidential_remarks":"The paper cites QPRAC, the authors' own prior work, as the representative secure PRAC implementation and as the baseline for TPRAC comparisons; this is a legitimate reuse but should be disclosed clearly as a self-citation. The artifact is genuinely strong and the simulation infrastructure is a plus. The main reason for major_revision rather than rejection is that the inconsistency between the attack's NBO=256 configuration and the defense's NBO=1024 headline overhead is addressable: the paper already reports the 14.1% overhead at NRH=256, so the fix is to align the claims and evaluations rather than to re-do the entire study. The lack of real-hardware validation is a limitation that should be stated prominently, but the forward-looking nature of PRAC makes simulation a defensible evaluation vehicle if the assumptions are made explicit."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Hi [Name],\n\nQuick take on arXiv:2505.10111. The paper's core claim is that PRAC's Alert Back-Off and RFM commands create an observable timing channel, and that this is distinct from prior DRAM side channels like DRAMA. I think that observation is solid and new. The authors show a cross-core covert channel at tens of Kbps and an AES T-table side channel leaking half the key in under 200 encryptions. They also propose TPRAC, a periodic-RFM defense, with released artifacts and a security analysis against Feinting. That is real work and the artifact appendix is unusually complete.\n\nNow the soft spots, in proportion. Everything is simulation. The attack and defense hinge on the assumption that an RFMab produces a fixed, system-wide 350ns stall observable by any process. That's plausible from the JEDEC spec, but it is not measured on real DRAM or a real memory controller. The higher-bandwidth channels also require shared rows, which depends on address mapping and page size. The generalization to other PRAC implementations (QPRAC, MOAT) is asserted, not tested.\n\nThe bigger problem is the defense headline. The AES attack is demonstrated at NBO=256. The TPRAC evaluation reports 3.4% overhead at NRH=1024, which corresponds to NBO≈1024. At the attack's NBO, Figure 7 says TB-Window must be ~0.25 tREFI, and Figure 13 shows roughly 14% slowdown in that regime. Worse, setting NBO=1024 with NRH=1024 looks unsafe under their own model: Table 1 allows ABOACT=3 extra activations after Alert, so a row can reach 1027 before mitigation, exceeding NRH. So the headline cost does not apply to the demonstrated attack configuration, and the configuration it does apply to may not be safe. This is a load-bearing inconsistency in the paper's own numbers, not a nitpick. It can be fixed, but the abstract and Section 6.2 overstate what is shown.\n\nAlso minor: the AES leak recovers only 4 of 8 bits per key byte, and only against a vulnerable T-table implementation; the comparison to obfuscation-based defenses is qualitative and short.\n\nWho is this for? Anyone working on RowHammer mitigations, DRAM security, or JEDEC standardization. It deserves a serious referee despite the issues. I would send it to review, with the expectation of heavy revision on the defense evaluation.\n\nRegards.","headline":"Solid new timing-channel finding on PRAC's ABO/RFM, but the defense's headline 3.4% overhead is tied to an NBO inconsistent with the attack demo and possibly unsafe at NRH=1024.","tokens_in":36838,"tokens_out":2290,"would_cite":true,"duration_ms":20675,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"PRAC's RowHammer mitigation creates a timing channel that leaks AES key bits.","keywords":["RowHammer","PRAC","DDR5","timing channel","side-channel attack","AES T-table","Refresh Management","covert channel"],"falsifier":"Run a real PRAC-enabled DDR5 module with one core repeatedly activating a row to the back-off threshold while another core measures memory latency on the same channel; if no reproducible system-wide latency spike appears, or the spike's timing is not tied to the activation count, the proposed channel is not exploitable as described. The paper's evidence is simulation-only on this point.","tokens_in":35755,"feed_emoji":"🔓","tokens_out":8346,"duration_ms":72902,"temperature":0.7,"pith_summary":"Per Row Activation Counting (PRAC) is DDR5's standard defense against RowHammer, but the paper claims the defense itself is leaky: when a row's activation counter crosses the back-off threshold, the DRAM asserts an Alert and the memory controller stalls every memory request on the channel for 350 nanoseconds. Because this stall is triggered by activity and is observable from any core, it forms a timing channel. The paper demonstrates PRACLeak, which turns the stall into a covert channel and into a side channel that recovers the top four bits of each byte of a 128-bit AES key in fewer than 200 encryptions. It then proposes Timing-Safe PRAC (TPRAC), which issues Refresh Management commands on a fixed schedule independent of row activations, and reports that TPRAC closes the channel with a 3.4% average slowdown at a RowHammer threshold of 1024. If correct, PRAC-based RowHammer defense needs this timing dimension to be designed in, not bolted on.","feed_headline":"PRAC RowHammer defense leaks AES keys via memory timing","feed_subtitle":"A 350ns back-off stall becomes a covert channel; a periodic-refresh fix closes it for 3.4%.","key_machinery":"The load-bearing mechanism is the Alert Back-Off (ABO) protocol: each DRAM row has an activation counter, and when the counter reaches the back-off threshold $N_{BO}$, the DRAM asserts an Alert, prompting the memory controller to issue an RFM All Bank (RFMab) command that stalls the entire channel for 350 ns. This converts per-row activation counts into globally observable latency. The attack part of the paper is carried by the activation-count-based side channel: shared-row activation counts are probed by counting how many attacker activations are needed to complete an ABO. The defense part is carried by TPRAC's Timing-Based RFM (TB-RFM), issued on a fixed timer independent of memory activity, together with a single-entry frequency-based mitigation queue per bank that identifies the most-activated row to refresh during each TB-RFM.","core_discovery":"The central discovery is that the Alert Back-Off (ABO) protocol and Refresh Management (RFM) commands in PRAC turn a security mechanism into an information channel. Each ABO event produces an RFM All Bank (RFMab) command that blocks all requests to the DRAM channel for $t_{RFMab}=350$ ns, and the number of activations needed to reach the back-off threshold $N_{BO}$ is exactly controllable. In an activation-count-based channel, a sender and receiver sharing one physical DRAM row encode a value by leaving $k$ activations in the row counter; the receiver activates the same row and observes after $N_{BO}-k$ activations when the ABO latency spike fires, recovering the sender's value $k$. Because $k$ can range up to $N_{BO}$, each transmission carries several bits. The same mechanism leaks a victim's row-activation pattern: in a chosen-plaintext AES T-table implementation, the DRAM row corresponding to the secret-dependent T-table entry gets the most activations, and the row that first triggers an ABO during probing reveals the top four bits of each key byte, 64 of 128 bits total. The paper's defense, TPRAC, issues Timing-Based RFMs at fixed intervals and mitigates the most-activated row per bank from a single-entry queue, so no row can reach $N_{BO}$ and no attacker-triggerable ABO latency exists.","pith_inferences":["The leak is a general instance of security metadata creating a timing channel: any future DRAM feature that counts per-row activity and signals the controller with a fixed, globally visible stall will likely suffer a similar channel.","If real controllers implement TB-RFM with timing jitter or hide the 350 ns stall by overlapping it with other work, the residual leakage would be far smaller than the simulated worst case; measuring the real latency distribution on PRAC hardware would calibrate the required interval.","The AES attack's structure, making one secret-dependent row the most-activated and then probing which row trips the counter, should generalize to other table-driven cryptographic implementations with attacker-controllable inputs and shared rows.","A testable extension is an adaptive TB-RFM interval that responds to observed activation rates; the paper analyzes fixed intervals, and an adaptive schedule could lower the performance cost at small RowHammer thresholds."],"forward_implications":["Any PRAC-style mitigation that issues activation-dependent RFMs, whether Alert Back-Off or activation-based proactive RFMs, carries a timing channel because the latency depends on row access counts.","A user-level attacker sharing a DRAM module with a vulnerable T-table AES victim can recover 64 of 128 key bits in fewer than 200 encryptions; constant-time AES or other table-free implementations avoid this specific leak.","TPRAC closes the channel without changing DRAM chips or the JEDEC interface: one register stores the RFM interval and one mitigation-queue entry per bank is enough.","At a RowHammer threshold of 1024, TPRAC's average performance cost is 3.4%, and co-design with targeted refreshes can reduce or eliminate that cost.","At lower RowHammer thresholds the required TB-RFM frequency grows, with slowdown rising from 6.5% at a threshold of 512 to 22.6% at 128, so very-low-threshold systems face a performance-security trade-off."],"supporting_citations":[{"why":"Defines the DDR5 PRAC specification: the Alert Back-Off protocol, the back-off threshold, and the 350 ns RFM stall that the attacks rely on.","marker":"[41]"},{"why":"Supplies the open-source PRAC implementation used as the modeled design for the attack evaluation.","marker":"[8]"},{"why":"A secure PRAC design with a mitigation queue; serves as the underlying PRAC implementation for TPRAC's performance comparison.","marker":"[102]"},{"why":"A PRAC design with per-row counters and counter reset; provides the counter-reset model used in TPRAC's worst-case analysis.","marker":"[77]"},{"why":"Defines the Feinting worst-case activation pattern used to size the TB-RFM interval.","marker":"[61]"},{"why":"Supplies the DRAM simulator used to demonstrate the PRACLeak covert and side channels.","marker":"[60]"},{"why":"Supplies the processor simulator used, together with the DRAM simulator, to measure TPRAC's performance overhead.","marker":"[24]"}],"fun_headline_variants":["PRAC timing leak exposes AES keys; periodic RFM fixes it","RowHammer defense leaks secrets via 350ns timing stalls","PRACLeak: RowHammer mitigation opens covert timing channel","Timing-Safe PRAC blocks leak, 3.4% overhead","PRAC back-off stalls leak AES keys; refresh fix stops them"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The attack and the defense both assume that every RFM All Bank command produces a fixed, system-wide 350 nanosecond stall that any process can measure; if real memory controllers hide, localize, or randomize that delay, the channel weakens or disappears.","fun_headline_variants_meta":{"raw":{"variants":["PRAC timing leak exposes AES keys; periodic RFM fixes it","RowHammer defense leaks secrets via 350ns timing stalls","PRACLeak: RowHammer mitigation opens covert timing channel","Timing-Safe PRAC blocks leak, 3.4% overhead","PRAC back-off stalls leak AES keys; refresh fix stops them"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000179,"raw_usage":{"total_tokens":1338,"prompt_tokens":1024,"completion_tokens":314,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":640,"completion_tokens_details":{"reasoning_tokens":222}},"tokens_in":640,"tokens_out":314,"duration_ms":3282,"temperature":1.0,"reasoning_tokens":222,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T21:16:18.868592+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a real PRAC-enabled DDR5 module with one core repeatedly activating a row to the back-off threshold while another core measures memory latency on the same channel; if no reproducible system-wide latency spike appears, or the spike's timing is not tied to the activation count, the proposed channel is not exploitable as described. The paper's evidence is simulation-only on this point.","supporting_citations":[],"review_version":1}