{"id":"3cc03751-ca9d-4044-8b04-9812663b400e","arxiv_id":"2506.11970","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"CnC-PRAC uses an in-DRAM request buffer to coalesce per-row activation counter updates, cutting counter row activations by 75-83 percent versus Chronus.","lead":"CnC-PRAC is a new Rowhammer defense design for DDR5 memory that groups together updates to per-row activation counters, reducing the extra energy of counting row activations. It claims near-zero slowdown and about 1 percent extra energy compared to insecure DRAM, improving on prior PRAC schemes.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The claimed 75-83% activation reduction and <1% dynamic energy overhead rest on K=4 counter RMWs fitting in one data-activation shadow, which Section 3.4 explicitly defers to future work.","rationale":"The reader's weakest_assumption correctly identifies the unvalidated K=4 timing assumption as the most load-bearing point. My reading of the paper confirms that both the energy and activation-reduction claims are computed under this assumption, and Section 3.4 explicitly defers the needed validation. The mismatch between the DDR3 tiered-latency citation and a DDR5 counter subarray, plus the need for four RMWs and a precharge to fit within a data activation shadow, makes this a genuine correctness risk rather than a stylistic caveat. However, the paper is transparent about the deferral, provides a plausible mechanism, and includes a sensitivity study showing graceful degradation as coalescing effectiveness decreases. There is no internal contradiction in the simulation results. Thus the appropriate disposition remains a conditional accept: the claims should be re-verified with a cycle-accurate or silicon timing evaluation before the exact numbers are relied upon. No new concern beyond the reader's was found that would change the verdict.","tokens_in":13869,"tokens_out":5631,"duration_ms":74335,"concrete_test":"Build a timing-accurate model of a 64-row DDR5 counter subarray (using published DDR5 tRCD/tRAS/tRP/tCCD_s/tWR or SPICE-level array timing) and compute whether four 1-byte read-modify-write operations plus precharge of the counter row can complete within the shortest data row activation shadow (ACT-to-PRECHARGE, tRAS) of the data subarray. If the budget fails, re-run the Ramulator2 evaluation with M=K=2 and M=K=3; if the dynamic energy overhead stays below roughly 2% and the activation reduction remains substantial, the qualitative contribution survives, but the precise 75-83% and 0.84-1% claims should be restated as conditional on M=4.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central quantitative claims of CnC-PRAC depend on the assumption in Section 3.4 that up to four single-byte counter read-modify-writes to the same counter row can complete within the shadow of one data row activation, with K=4 used both as the coalescing batch size and as the security back-off reduction. The paper cites only [16] (DDR3 tiered-latency DRAM) for a reduced tRCD in small arrays and explicitly states 'we assume K = 4. A precise evaluation of these timings for DDR5 is left for future work.' If four byte-RMWs plus precharge do not fit in the shadow, the valid coalescing batch shrinks. The paper's own sensitivity analysis (Figure 8) shows that reduced coalescing effectiveness directly raises counter-row activations and dynamic energy; at a 16-entry buffer, activations rise from 27% to 75% of Chronus and energy from 1% to 1.8%. A factor-of-two change in K/M would similarly erode, but not necessarily destroy, the headline: the exact '75-83%' and '0.84-1%' numbers, and the 'negligible slowdown' claim, would need re-evaluation. This is a load-bearing timing assumption, not a mere implementation detail, because the entire design is built around decoupling and then batching exactly four counter updates.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents CnC-PRAC, an in-DRAM Rowhammer mitigation built on the PRAC framework and the Chronus disjoint counter sub-array. It decouples counter read-modify-write operations from the data-access critical path and buffers them in a small CAM structure, coalescing multiple counter updates that map to the same counter row so that a single counter row activation serves several increments. The authors evaluate two buffer organizations (per-row and unified) with Ramulator2 on 57 workloads, reporting counter row activation reductions of 72.9%-82.4% relative to Chronus, dynamic energy overhead of 0.84%-1% relative to an insecure DDR5 baseline, and negligible slowdown.","tokens_in":14173,"tokens_out":6852,"duration_ms":81705,"significance":"If the central timing assumption (four single-byte counter RMWs in one data-activation shadow) holds, the result is a practical and significant step toward low-overhead PRAC: it retains the determinism of per-row counters while avoiding the 10%-class slowdown of inline-counter designs and the added activation energy of Chronus. The coalescing idea is well motivated by the locality analysis, and the paper is honest about its assumptions, explicitly deferring DDR5 timing verification and background-energy modeling to future work. The simulator-based evaluation is standard for this community, and the sensitivity analysis on buffer size gives useful insight.","major_comments":[{"comment":"The paper's central quantitative claims—75-83% reduction in counter row activations, 0.84-1% dynamic energy overhead, and negligible slowdown—all depend on the assumption in §3.4 that K=4 single-byte counter RMWs to the same counter row can be completed within the shadow of one data row activation. The manuscript explicitly states 'we assume K = 4. A precise evaluation of these timings for DDR5 is left for future work,' and the only cited support is [16], a DDR3 tiered-latency DRAM study. This is load-bearing: if the valid batch size is smaller, the coalescing benefit shrinks (the paper's own Figure 8 shows a 16-entry buffer roughly triples counter activations), and the 'negligible slowdown' claim may fail. Please either provide a DDR5-timing-grounded validation (published timings, circuit-level modeling, or a conservative timing model) or re-run the evaluation with a range of K values and restate the conclusions accordingly.","section":"§3.4"},{"comment":"The energy comparison is limited to dynamic energy. Footnote 2 of §4.3 states that the counter sub-array is assumed to consume 19% of the background energy of the data sub-array, and that 'a more accurate estimation of the background energy is left for future work.' In addition, the unified request buffer is estimated to draw 4.3 mW per chip of static power, yet the paper does not compare this to typical DRAM background power or add it to the reported energy overheads. Since the paper's title and abstract promise efficient PRAC, the total-energy picture (including static/buffer power) should be quantified; as written, the '1% overhead' refers only to dynamic energy.","section":"§4.3"},{"comment":"The security argument is stated but not proven. The paper asserts in §3.2 that no counter request is buffered for more than K repeated activations because an entry is removed when RepCount reaches K, and that lowering the back-off threshold by K preserves Rowhammer security. However, the manuscript does not analyze worst-case timing under adversarial traffic when multiple rows require simultaneous removal or when the counter sub-array is busy; the removal RMW itself takes time, and it is not shown that the lag never exceeds K. Because 'no security impact' is a headline contribution, a formal invariant or an adversarial evaluation (e.g., alternating multi-bank patterns that fill the buffer) is needed.","section":"§3.2"}],"minor_comments":[{"comment":"The claim that both Chronus and CnC-PRAC have 'negligible performance overheads (below 0.5%)' is stated without a corresponding performance figure or table; please include the data.","section":"§4.3"},{"comment":"The symbols M and K are both set to 4 but serve different roles (coalescing batch size vs. security threshold); please define them distinctly and use them consistently throughout.","section":"§3.2 and §3.4"},{"comment":"The static power comparison is numerically imprecise: the text says the per-row design's 0.25 mW is 'around 20× less' than the unified design's 4.3 mW, but 4.3/0.25 is approximately 17×.","section":"§4.3"},{"comment":"The y-axis label says 'Average Same Counter Row Requests' while the caption describes the highest number of requests within a window; please align the label with the metric actually plotted.","section":"Figure 3"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is built on the authors' own QPRAC work and on Chronus; the contribution is incremental but solidly presented. The main risk is the unverified K=4 timing assumption, which should be resolved by obtaining or simulating DDR5 timing data, or by presenting results for a range of K values. The paper otherwise fits the scope of a systems/security venue."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know about this paper. First, the coalescing request buffer is a genuinely new idea in the PRAC space: prior work either cached counts or put them inline, and this paper shows that buffering and merging updates to the same counter row cuts counter row activations by 75-83% over Chronus in simulation. Second, the paper's central performance claim — negligible slowdown — leans entirely on an assumption stated in Section 3.4: that four single-byte counter RMWs can complete inside one data activation shadow. The paper cites a DDR3 tiered-latency result for smaller arrays and says explicitly that a precise DDR5 evaluation is future work. That is a load-bearing gap, not an afterthought.\n\nWhat's good: The paper does the right kind of evaluation for a design paper: 57 workloads, multiple buffer designs, a sensitivity analysis tying buffer size to activations and energy, and a reasonable argument for why caching fails (footprint too large). The authors are also transparent about the assumptions they borrow from Chronus (19% extra activation energy) and about what they don't model (static/background energy). That transparency is credible.\n\nSoft spots: The timing issue is the big one. Their own Figure 8 shows that a smaller coalescing batch increases activations from 27% to 75% of Chronus; if K drops from 4 to 2, the headline numbers would look much worse, even if the design still helps. The energy numbers are also dynamic-only, and the static power of the unified buffer (4.3 mW per chip) is not negligible against a chip-scale energy budget. They leave a more accurate background-energy estimate to future work, which is fine, but it means the '0.84-1% overhead' is a lower bound, not a complete accounting. No artifacts are provided, which makes it harder to check the simulator changes.\n\nWho it's for: DRAM security and architecture researchers. The paper is a solid design optimization within the PRAC research program; if the timing assumption is validated by measurements or more detailed simulation, it's a meaningful step toward practical PRAC. The open question is exactly the kind of thing a good referee should push on.\n\nRecommendation: This deserves a serious referee. It's not a desk reject, and the conditional verdict is right — the central idea stands on its own, but the evaluation's headline numbers need to be pinned down. I'd engage with it.","headline":"A clean coalescing design for PRAC counters that is likely right about activation reduction, but the 'negligible slowdown' claim rests on an unverified DDR5 timing assumption that the paper itself defers.","tokens_in":14700,"tokens_out":2601,"would_cite":true,"duration_ms":119851,"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":"CnC-PRAC claims that coalescing counter-row updates makes PRAC-based Rowhammer defense cost under 1% energy with negligible slowdown.","keywords":["Rowhammer","PRAC","DRAM security","activation counting","counter coalescing","DDR5","energy overhead","memory controller"],"falsifier":"Measure on a DDR5 device or a validated DDR5 timing model whether a counter sub-array can service four one-byte read-modify-writes to the same row within the precharge and row-cycle shadow of a data activation; if those column operations serialize and delay precharge, CnC-PRAC's claimed negligible slowdown fails even though activation counting may still be reduced.","tokens_in":13636,"feed_emoji":"🛡️","tokens_out":5859,"duration_ms":62183,"temperature":0.7,"pith_summary":"This paper proposes CnC-PRAC, a way to implement DRAM's per-row activation counting (PRAC) that brings Rowhammer defense close to cost-free. Instead of caching activation counts, it buffers counter-update requests in a small in-DRAM structure and coalesces requests that hit the same counter row into a single row activation. The paper reports that this reduces counter row activations by roughly 75% to 83% compared with a state-of-the-art PRAC design, bringing dynamic energy overhead down to 0.84% to 1% over an insecure DDR5 baseline while keeping slowdown negligible. If correct, precise per-row activation counting is practical at near-zero cost.","feed_headline":"Coalescing counter updates cuts Rowhammer defense cost to ~1%","feed_subtitle":"Batching counter updates in a request buffer cuts counter activations by up to 83 percent with negligible slowdown.","key_machinery":"The load-bearing mechanism is an in-DRAM counter request buffer, a small content-addressable memory whose entries store a counter-row identifier, a byte position, and a repeat count. On each data row activation, the counter increment for that row is inserted into the buffer instead of being performed immediately; when K (default 4) requests to the same counter row are present, the buffer issues a single counter-row activation that performs all K read-modify-writes in parallel with a data activation. A unified 64-entry variant tracks the row with the highest outstanding count and removes those entries first, approximating an ideal sorted queue.","core_discovery":"The central claim is that decoupling counter updates from the critical path of data row activations, and then coalescing buffered counter read-modify-writes that target the same counter row, removes nearly all of the energy overhead that current PRAC implementations pay. Counter requests are collected in a request buffer; when four requests to the same counter row accumulate, one counter-row activation services all four in the shadow of a data activation. The paper evaluates a per-row buffer and a smaller unified buffer and reports that the unified variant retains most of the benefit, reducing counter row activations to about 27% of the state-of-the-art design while using only 192 bytes per bank.","pith_inferences":["Beyond the paper: if the K=4 timing assumption holds in silicon, the same coalescing idea could be applied to other per-row DRAM metadata updates that currently stretch row cycle times.","Beyond the paper: the approximate max-count eviction policy suggests that even cheaper counting structures than a full CAM might capture most of the coalescing benefit.","Beyond the paper: a hardware testbed that measures whether four one-byte column RMWs truly overlap within one row activation would settle the main open timing question."],"forward_implications":["PRAC-based Rowhammer mitigation could be deployed on DDR5 without the roughly 10% slowdowns reported for inline-counter designs.","Dynamic energy overhead falls to about 1% (0.84% for the per-row variant), making precise counting competitive with insecure DRAM on energy.","Security is preserved deterministically: the back-off threshold is lowered by K so no counter update is ever delayed by more than K activations.","Shrinking the unified buffer from 64 to 16 entries degrades gracefully, raising counter activations from 27% to about 75% of the state-of-the-art design.","The counter sub-array can be protected against its own bit-flips with guard rows or parallel refresh at negligible storage or energy cost."],"supporting_citations":[{"why":"Provides the disjoint counter sub-array substrate and the energy-overhead baseline that CnC-PRAC builds on.","marker":"[13]"},{"why":"Defines the PRAC and Alert Back-Off framework that this work implements.","marker":"[10]"},{"why":"Introduces priority mitigation queues used in the evaluation and represents a prior PRAC implementation with security guarantees.","marker":"[12]"},{"why":"Establishes the inline-counter PRAC approach and its slowdown problem that motivates decoupling counters.","marker":"[11]"},{"why":"Shows sub-array level parallelism, the mechanism that lets counter activations overlap data activations.","marker":"[14]"},{"why":"Supports the timing assumption that smaller counter sub-arrays have reduced tRCD, making K=4 coalesced increments feasible.","marker":"[16]"},{"why":"Supplies the simulation infrastructure used for the performance and energy results.","marker":"[21]"}],"fun_headline_variants":["Coalesce, don't cache: Rowhammer defense for ~1% energy","Counter coalescing cuts Rowhammer defense overhead by 83%","Near-zero cost Rowhammer defense with coalesced counters","Batch counter updates to make Rowhammer defense cost ~1%","CnC-PRAC: coalesce counter rows, cut Rowhammer cost 83%"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The design assumes that four single-byte counter read-modify-writes to the same counter row can complete within the shadow of one data row activation without changing DDR5 timings; the paper states this assumption and leaves precise DDR5 timing evaluation to future work.","fun_headline_variants_meta":{"raw":{"variants":["Coalesce, don't cache: Rowhammer defense for ~1% energy","Counter coalescing cuts Rowhammer defense overhead by 83%","Near-zero cost Rowhammer defense with coalesced counters","Batch counter updates to make Rowhammer defense cost ~1%","CnC-PRAC: coalesce counter rows, cut Rowhammer cost 83%"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000568,"raw_usage":{"total_tokens":2686,"prompt_tokens":937,"completion_tokens":1749,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":553,"completion_tokens_details":{"reasoning_tokens":1655}},"tokens_in":553,"tokens_out":1749,"duration_ms":16731,"temperature":1.0,"reasoning_tokens":1655,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T00:59:25.169677+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure on a DDR5 device or a validated DDR5 timing model whether a counter sub-array can service four one-byte read-modify-writes to the same row within the precharge and row-cycle shadow of a data activation; if those column operations serialize and delay precharge, CnC-PRAC's claimed negligible slowdown fails even though activation counting may still be reduced.","supporting_citations":[{"cited_title":"Chronus: Understanding and securing the cutting-edge industry solutions to dram read disturbance,","cited_arxiv_id":null,"evidence_quote":"Provides the disjoint counter sub-array substrate and the energy-overhead baseline that CnC-PRAC builds on."},{"cited_title":"JESD79-5C","cited_arxiv_id":null,"evidence_quote":"Defines the PRAC and Alert Back-Off framework that this work implements."},{"cited_title":"QPRAC: Towards secure and practical prac-based rowhammer mitigation using priority queues,","cited_arxiv_id":null,"evidence_quote":"Introduces priority mitigation queues used in the evaluation and represents a prior PRAC implementation with security guarantees."},{"cited_title":"MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters,","cited_arxiv_id":null,"evidence_quote":"Establishes the inline-counter PRAC approach and its slowdown problem that motivates decoupling counters."},{"cited_title":"A case for exploiting subarray-level parallelism (salp) in dram,","cited_arxiv_id":null,"evidence_quote":"Shows sub-array level parallelism, the mechanism that lets counter activations overlap data activations."},{"cited_title":"Tiered-latency dram: A low latency and low cost dram architecture,","cited_arxiv_id":null,"evidence_quote":"Supports the timing assumption that smaller counter sub-arrays have reduced tRCD, making K=4 coalesced increments feasible."},{"cited_title":"Ramulator 2.0: A modern, modular, and extensible dram simulator,","cited_arxiv_id":null,"evidence_quote":"Supplies the simulation infrastructure used for the performance and energy results."}],"review_version":1}