{"id":"ab78ef22-a635-441c-8ac2-ea698ebeb817","arxiv_id":"2501.18857","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"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.","lead":"A new memory-controller defense, DAPPER-H, uses two secret hash tables to track RowHammer activations so that an attacker cannot cheaply overload the tracker and slow down co-running programs. In simulated DDR5 memory at a RowHammer threshold of 500, it slows benign workloads by about 0.9% even while a performance attack is running.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"A same-bank row scan captures DAPPER-H's row-group mapping with near-certainty in one refresh window, contradicting the claimed 99.99% prevention rate.","rationale":"The reader correctly flagged the probabilistic mapping-capture model, but the real flaw is deeper: Equations (6)-(7) arbitrarily limit the attacker to two random probes per trial. An attacker can prime one row to NM-2=248 and then scan all 64K rows of the same bank. Since each 8K group has about 8 rows in a bank, both of the target's group counters are hit multiple times; when both reach 250, the mitigative refresh reveals a mapping pair. This takes at most 3.1ms, well within the 32ms refresh window, so the attack succeeds with probability close to 1, not 0.01%. The bit-vector does not help because all probes are in the same bank, so the target's Table-1 bit remains set. Thus the central security claim is unsupported and should be reworked or rejected as stated.","tokens_in":26939,"tokens_out":35703,"duration_ms":372418,"concrete_test":"Run a Monte Carlo simulation: N_G=8192 groups, 32 banks, 65536 rows per bank, threshold 250. Prime a random target to 248, scan the same bank's rows, increment the target's two group counters on each probe, and record the first activation where both reach 250. Repeat 10,000 times and report success rate within 65536 probes. The paper's Eq. (6)-(7) predict ~1.5e-4 success per tREFW; the simulation will show success near 1.","verdict_should_be":"REJECT","load_bearing_attack":"Equations (6)-(7) assume the attacker makes exactly two random probes per trial, giving p≈(2/8192)^2 and T≈2.5K, hence an attack success probability of about 1.5e-4 per tREFW. This trial model is not an upper bound on the attacker. After priming a target row T in one bank to NM-2=248, the attacker can simply scan every other row in that same bank. A 64K-row bank contains about 8 rows from each of the 8K row groups, so T's two group counters each receive multiple hits during the scan; once both reach 250, DAPPER-H issues a mitigative refresh on the activation that delivered the final hit, revealing that the just-activated row shares one of T's groups. The scan takes at most 64K×48ns≈3.1ms, well within tREFW=32ms, so mapping capture succeeds with probability close to 1, not 0.01%. The bit-vector does not stop this attack because all probes are in the same bank: T's group bit stays set, so every same-bank row in that group increments Table 1. Thus the paper's central security guarantee is not established; the model's restriction to two random probes is the load-bearing gap.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes DAPPER, a host-side RowHammer mitigation tracker. DAPPER-S uses a single secure hash to randomize row-to-row-group-counter mappings, while DAPPER-H adds a second hash, a per-bank bit-vector, and a selective mitigative-refresh mechanism. The paper claims that DAPPER-H prevents Mapping-Capturing attacks with 99.99% probability per refresh window and incurs only 0.9% average slowdown under active Perf-Attacks at NRH=500, with 96KB SRAM per 32GB DRAM. The paper also demonstrates RH-Tracker-based Perf-Attacks against Hydra, START, CoMeT, and ABACUS, and evaluates DAPPER against those baselines, BlockHammer, PARA, PrIDE, and PRAC across 57 workloads.","tokens_in":27149,"tokens_out":14364,"duration_ms":138165,"significance":"If the security and performance claims held, DAPPER-H would be a notable advance in low-cost, low-overhead RowHammer mitigation at ultra-low thresholds. The paper's strengths include a systematic demonstration of Perf-Attacks on four existing trackers, a wide-ranging simulation study (57 workloads, multiple NRH values, blast radius and DRFM variants), and a concrete hardware design with modest SRAM overhead. The security analysis, however, contains a load-bearing gap: the probabilistic model undercounts the attacker's probing capabilities, and a simple same-bank scan defeats the claimed 99.99% prevention. Because this attack is within the paper's own threat model, the central contribution is not currently established.","major_comments":[{"comment":"The attack model assumes the attacker can make only two random probes per trial and therefore computes a per-trial success probability of about (2/8192)^2 and about 2500 trials, yielding a 0.01% failure rate per refresh window. This is not an upper bound. After priming a target row T in a single bank to NM-2=248 activations, an attacker can sequentially activate the other rows in the same bank. Because the bit-vector gates only first-time per-bank increments of Table 1, and T's bank bit is already set, any scanned row that shares T's Table-1 group increments that group's counter, and any scanned row that shares T's Table-2 group increments that group's counter. In a 64K-row bank with 8K groups, each group has about 8 rows per bank, so both counters reach 250 within roughly a few dozen activations (microseconds), far inside tREFW. The resulting mitigation reveals the triggering row as sharing one of T's groups, giving the attacker a mapping pair. The success probability is therefore close to 1, not 0.01%. The bit-vector does not prevent this attack because all probes are in the same bank.","section":"Section VI-C, Equations (6)-(7)"},{"comment":"The paper does not specify the behavior of an RGC when it reaches NM while the other table's RGC for the same row has not reached NM. Table 2 is incremented on every activation, while Table 1 is incremented only when the bank bit is already set; an attacker can therefore drive a Table-2 counter past NM (e.g., by activating rows that map to the same Table-2 group across many banks) without the corresponding Table-1 counter reaching NM. If counters are not saturating, this can lead to overflow, and if they saturate, the paper should say so and analyze the security impact of 'stuck' counters. As written, the design's behavior in this state is undefined and the security analysis does not cover it.","section":"Section VI-B, update operation"},{"comment":"The performance evaluation under Perf-Attacks only considers the streaming and refresh attacks; it does not include the same-bank Mapping-Capturing attack described above. Since that attack enables the attacker to learn the group mappings and then launch targeted mitigative-refresh storms, the reported 0.9% average slowdown under active Perf-Attacks does not represent the full attack surface that the paper claims to address.","section":"Section VI-D, Figure 10"}],"minor_comments":[{"comment":"Equation (1) uses tRC in the computation of t_left; please clarify that the priming phase takes (NM-1)*tRC and that t_left is treset minus that time.","section":"Section V-D"},{"comment":"The storage calculation appears inconsistent: 8K 1-byte entries per RGC table gives 8KB per table, i.e., 16KB for both tables, not 32KB; the bit-vector size also depends on the number of banks per rank and should be stated explicitly.","section":"Section VI-H"},{"comment":"The four-step annotation is difficult to follow; the text refers to steps (1)-(4) but the figure labels are small and not clearly connected to the described update and reset operations.","section":"Figure 8"},{"comment":"The paper states that the LLBC is resistant to shortcut attacks citing prior work; since this is a core security assumption, a brief discussion of why N-to-N encryption avoids the CEASER/CUBE attacks would be helpful.","section":"Section VI-C, Discussion"},{"comment":"There is a typo: 'slwdown' should be 'slowdown'.","section":"Section III-D"}],"recommendation":"reject","confidential_remarks":"The same-bank scan attack appears to break the central security claim. The paper's own acknowledgment of prior reviews (MICRO 2024, HPCA 2025) suggests this has been through several rounds; the security model remains inadequate. I recommend rejection unless the authors can substantially revise the design and analysis."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know. The Perf-Attack characterization of Hydra/START/CoMeT/ABACUS is the real contribution: tailored patterns that force counter-cache misses or repetitive all-row refreshes cause 60-90% slowdowns at NRH=500, far worse than cache thrashing. That part is solid, reproducible in Ramulator, and worth citing. The DAPPER-H design—double-hashed row-group counters, per-bank bit-vector, selective mitigative refresh—is clever, and the evaluation (57 workloads, multiple NRH, BR/DRFM variants, comparisons to BlockHammer/PARA/PrIDE/PRAC) is thorough. At NRH=500 the performance story is good: 0.9% average slowdown under active Perf-Attacks with 96KB SRAM per 32GB.\n\nThe soft spot is the security analysis, and it is load-bearing. Section VI-C claims 99.99% prevention of Mapping-Capturing attacks within tREFW, based on Equations (6)-(7). Those equations model a specific two-random-probe attack: prime a target to NM-2, guess two rows, check with a final activation. That is not an upper bound on the attacker. The stress-test note is right, and I checked the arithmetic. With NM=250, priming T 248 times in Bank 0 leaves RGC1=247 and RGC2=248. A same-bank scan of the 64K rows finds the ~8 rows in T's group1 and the ~8 rows in T's group2. Those few hits are enough: RGC1 needs only +3 and RGC2 needs only +2 to cross 250. The scan triggers a mitigative refresh with near-certainty, well within the 3.1ms scan time and long before the 32ms rehash. The attacker then knows the triggering row shares one of T's groups, and can repeat to learn the other. So the 99.99% claim is false. The bit-vector does not stop it because all probes are in the bank whose bit is already set.\n\nThe paper acknowledges the bit-vector limits cross-bank guesses, but the same-bank path is not modeled. Counter saturation and reset-counter behavior are also ignored. The LLBC is assumed secure from the CEASER/CUBE lineage, which is plausible for this use but not proven here.\n\nBottom line: the Perf-Attack study and the engineering are valuable, and DAPPER-H might be repairable—for example, by enforcing a per-bank cap on RGC increments or by not priming to NM-2—but those changes affect the security argument. As written, the central security guarantee does not hold. If I were handling this as a submission, I would send it to referees, because the problem is important and the performance work is strong, but I would expect a major revision that either fixes the attack or substantially weakens the claim. The Perf-Attack results deserve a cite regardless.","headline":"The Perf-Attack study is the real contribution; the 99.99% security claim is broken by a same-bank scan that the probabilistic model misses.","tokens_in":27743,"tokens_out":15347,"would_cite":true,"duration_ms":143594,"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":"The paper claims that a 96KB SRAM RowHammer tracker can absorb deliberate performance attacks at a RowHammer threshold of 500 with only 0.9% average slowdown.","keywords":["RowHammer","DRAM security","performance attack","row group counter","secure hashing","double hashing","memory controller","DDR5"],"falsifier":"Measure the actual mapping-capture rate: run an attacker that activates one row $N_M - 2$ times, probes random pairs of rows, and watches for mitigative refreshes; if more than roughly one in ten thousand refresh windows yields a successful mapping pair, the probability model is wrong. A second check is to test whether the LLBC output can be distinguished from a random permutation by timing or access-pattern side channels on real hardware.","tokens_in":26695,"feed_emoji":"🛡️","tokens_out":7364,"duration_ms":72063,"temperature":0.7,"pith_summary":"The paper targets a denial-of-service class that hurts the defender rather than the data: an adversary who finds it hard to flip bits can still cripple co-running applications by flooding the shared counters or reset mechanisms that RowHammer defenses rely on. It claims that existing scalable trackers suffer 60–90% slowdowns under such performance attacks, and proposes DAPPER-H to close the gap. DAPPER-H maps rows to shared row-group counters through two independent keyed hashes, uses a per-bank bit-vector to absorb streaming activations, and refreshes only the rows shared by the two mapped groups. The paper reports that at a RowHammer threshold of 500, DAPPER-H keeps average slowdown at 0.9% under active attacks with 96KB of SRAM per 32GB of DRAM, and that mapping-capturing attacks succeed within a refresh window with probability below 0.01%. If true, this means RowHammer defenses can remain cheap without becoming a performance liability.","feed_headline":"RowHammer defense keeps slowdown under 1% even under attack","feed_subtitle":"A 96KB secure tracker holds average slowdown to 0.9% at threshold 500 while blocking mapping-capturing attacks.","key_machinery":"The load-bearing object is DAPPER-H's two-table Row Group Counter (RGC) scheme. An RGC is a small SRAM counter shared by a fixed-size group of rows; DAPPER-H keeps two tables, each with its own Low-Latency Block Cipher (LLBC), a four-round keyed permutation that encrypts a row address before the address is divided into groups. A row increments a table's counter only if the per-bank bit-vector for the first table is already set, which prevents a streaming attacker from filling groups with one activation per bank. Mitigative refresh fires only when the counters in both tables reach the mitigation threshold ($N_M = N_{RH}/2$), and reset counters carry over the other table's count when a group is mitigated. The scheme's security rests on the two independent keyed mappings being unpredictable between key rotations every $t_{REFW} = 32$ms, so that an attacker cannot deliberately concentrate activations in one group.","core_discovery":"The central claim is that the performance overhead of RowHammer mitigation comes not from tracking rows, but from letting an attacker predict the tracking structure. Existing low-cost trackers share counters across rows and keep counters in DRAM or the last-level cache; an adversary who controls which rows map to which counter can force counter-cache misses or repeated full-bank refreshes. DAPPER-H makes the row-to-counter assignment unobservable: two independent four-round block ciphers map every activated row to a group in each of two SRAM tables, a per-bank bit-vector stops cross-bank streaming from inflating the first table, and a mitigation refreshes only the rows appearing in both groups. Because the cipher keys rotate every 32ms refresh window, capturing a single pair of mappings is claimed to be preventable with 99.99% probability per window. The paper supports this with a probabilistic analysis and with simulations across 57 workloads showing less than 1% average slowdown at a threshold of 500 under active performance attacks, and less than 6% even at a threshold of 125.","pith_inferences":["Editorial inference: the same two-table hash plus bit-vector pattern could transfer to other shared performance counters in the memory controller, such as wear-leveling or prefetch-throttle counters, where set-conflict and streaming attacks create denial-of-service.","Editorial inference: the paper's security argument counts a single refresh window in isolation; a persistent adversary who accumulates one successful capture every few hours could still learn a partial map over days, so a stronger design might rekey more often than 32ms or rotate the number of tables.","Editorial inference: the analysis assumes the attacker cannot distinguish LLBC outputs from random permutations; if future cryptanalytic shortcuts appear, replacing the four-round cipher with a stronger low-latency permutation would preserve the architecture while changing only the cipher block."],"forward_implications":["If DAPPER-H works as claimed, the performance-attack class becomes survivable at thresholds as low as 500: average slowdown under active attacks is 0.9%, versus 60–90% for existing shared-counter trackers.","The same 96KB SRAM budget keeps benign workloads at 0.1% average slowdown, so the security comes without a standing performance tax.","Even at an ultra-low threshold of 125, the paper projects at most a 6% slowdown under refresh attacks, indicating graceful degradation as DRAM becomes more fragile.","Per-bank mitigative refresh is a major cost lever: switching to same-bank DRFM commands raises slowdown to 8% at a threshold of 500, so future DRAM refresh commands should preserve bank-level granularity.","A single brief mapping leak is survivable because keys rotate every 32ms; attackers need repeated success across refresh windows to sustain a denial-of-service, and DAPPER-H's design denies that."],"supporting_citations":[{"why":"Supplies the Hydra shared-group-counter baseline whose row-counter-cache misses are exploited by the paper's Perf-Attacks.","marker":"[50]"},{"why":"Supplies the CoMeT count-min-sketch baseline whose Recent Aggressor Table misses and repetitive full-bank refreshes are exploited.","marker":"[4]"},{"why":"Supplies the START baseline whose LLC-resident RowHammer counters are flooded by streaming attacks.","marker":"[60]"},{"why":"Supplies the ABACUS all-bank activation counter baseline whose shared Misra-Gries tracker overflow is exploited, and whose per-bank bit-vector idea DAPPER-H adapts.","marker":"[45]"},{"why":"Provides the encrypted-address remapping idea and the four-round low-latency block cipher pattern that DAPPER reuses for row-group assignment.","marker":"[51]"},{"why":"Provides the low-latency block cipher construction and the N-to-N encryption argument used to argue resistance to shortcut attacks.","marker":"[26]"},{"why":"Defines the RowHammer threshold and victim-refresh model that the tracker's mitigation threshold and refreshes are built on.","marker":"[28]"},{"why":"Supplies the cycle-accurate memory-system simulator used for all measured slowdowns in the paper.","marker":"[29]"},{"why":"Supplies the PRAC-based comparison point and the analysis of same-bank versus per-bank refresh command overheads.","marker":"[73]"}],"fun_headline_variants":["DAPPER: RowHammer defense that beats perf attacks","96KB tracker keeps RowHammer slowdown under 1%","DAPPER-H: Secure RowHammer defense with 0.9% overhead","New tracker thwarts RowHammer performance attacks"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The security number rests on the assumption that the four-round block cipher looks like a random permutation to software, and that the paper's probability model counts every guess an attacker can make inside one refresh window; if either fails, mapping-capturing attacks become easier and the 99.99% prevention claim does not hold.","fun_headline_variants_meta":{"raw":{"variants":["DAPPER: RowHammer defense that beats perf attacks","96KB tracker keeps RowHammer slowdown under 1%","DAPPER-H: Secure RowHammer defense with 0.9% overhead","New tracker thwarts RowHammer performance attacks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000181,"raw_usage":{"total_tokens":1370,"prompt_tokens":1070,"completion_tokens":300,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":686,"completion_tokens_details":{"reasoning_tokens":227}},"tokens_in":686,"tokens_out":300,"duration_ms":3969,"temperature":1.0,"reasoning_tokens":227,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-09T22:12:12.636384+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure the actual mapping-capture rate: run an attacker that activates one row $N_M - 2$ times, probes random pairs of rows, and watches for mitigative refreshes; if more than roughly one in ten thousand refresh windows yields a successful mapping pair, the probability model is wrong. A second check is to test whether the LLBC output can be distinguished from a random permutation by timing or access-pattern side channels on real hardware.","supporting_citations":[{"cited_title":"Hydra: Enabling low-overhead mitigation of row-hammer at ultra-low thresholds via hybrid tracking,","cited_arxiv_id":null,"evidence_quote":"Supplies the Hydra shared-group-counter baseline whose row-counter-cache misses are exploited by the paper's Perf-Attacks."},{"cited_title":"Start: Scalable tracking for any rowhammer threshold,","cited_arxiv_id":null,"evidence_quote":"Supplies the START baseline whose LLC-resident RowHammer counters are flooded by streaming attacks."},{"cited_title":"ABACuS: All-Bank activation counters for scalable and low overhead RowHammer mitigation,","cited_arxiv_id":null,"evidence_quote":"Supplies the ABACUS all-bank activation counter baseline whose shared Misra-Gries tracker overflow is exploited, and whose per-bank bit-vector idea DAPPER-H adapts."},{"cited_title":"Ceaser: Mitigating conflict-based cache attacks via encrypted-address and remapping,","cited_arxiv_id":null,"evidence_quote":"Provides the encrypted-address remapping idea and the four-round low-latency block cipher pattern that DAPPER reuses for row-group assignment."},{"cited_title":"Ramulator: A fast and extensible dram simulator,","cited_arxiv_id":null,"evidence_quote":"Supplies the cycle-accurate memory-system simulator used for all measured slowdowns in the paper."},{"cited_title":"ScatterCache: Thwarting cache attacks via cache set randomization,","cited_arxiv_id":null,"evidence_quote":"Supplies the PRAC-based comparison point and the analysis of same-bank versus per-bank refresh command overheads."}],"review_version":1}