---
title: 'PRAC: Per-Row Activation Counters in DDR5 DRAM'
url: https://www.emergentmind.com/topics/per-row-activation-counters-prac
type: topic
---

# PRAC: Per-Row Activation Counters in DDR5 DRAM

Per-Row Activation Counting (PRAC) is the JEDEC DDR5 in-DRAM framework for mitigating RowHammer and related read-disturbance phenomena by maintaining an activation counter for every DRAM row and invoking mitigation through Alert Back-Off (ABO) when a row approaches a danger threshold. In the literature, PRAC is presented as a standards-based move from approximate or tracker-limited mitigation toward precise per-row accounting. At the same time, it is also presented as a framework rather than a complete defense: its security, performance, energy, and even confidentiality properties depend on how counters are updated, how hot rows are selected for mitigation, how ABO is scheduled, and how resets interact with refresh and other DRAM operations [2605.17358] [2406.19094].

## 1. Core mechanism and protocol semantics

PRAC’s defining abstraction is exact row-granular activation tracking. Each DRAM row is associated with an activation counter, and each activation of row $r$ increases that row’s count. Several papers describe the counting event conceptually as occurring on every ACT, while implementation-oriented treatments place the actual counter update on the row-close or precharge path via an internal read-modify-write. This distinction matters operationally, but the semantic intent is stable across papers: PRAC attempts to know exactly how many times each row has been activated, rather than infer risk from a small tracker or a sampled history [2507.18581] [2505.10111].

PRAC is coupled to the ABO protocol. When a row’s counter reaches a back-off or alert threshold, the DRAM asserts Alert to the memory controller. Papers modeling DDR5 PRAC commonly describe a controller reaction window of about 180 ns, after which the controller issues one or more Refresh Management commands. JEDEC configurations discussed in the literature allow 1, 2, or 4 RFMs per Alert, corresponding to PRAC-1, PRAC-2, and PRAC-4 style configurations, and studies report representative RFM latencies of about 195 ns in one timing model and about 350 ns in others, depending on the modeled DDR5 timing bin and interpretation of the recovery interval [2406.19094] [2507.18581].

The thresholding model is likewise parameterized. One analysis expresses the back-off threshold as $BO = \alpha \cdot NRH$, where $NRH$ is the minimum activation count that induces the first bitflip and $\alpha$ is 70%, 80%, 90%, or 100% in the DDR5 specification update it analyzes. Other papers denote the alert threshold by $N$ and the physical RowHammer threshold by $T$, with the intended invariant that $N < T$ so mitigative refresh occurs before physical disturbance reaches the failure boundary [2406.19094] [2506.11970].

A recurring clarification in the literature is that PRAC is not a single concrete microarchitecture. Papers on MOAT, QPRAC, Chronus, PRACtical, and CnC-PRAC all treat PRAC as a standardized interface and semantics layer whose implementation choices remain open. This is why papers can simultaneously describe PRAC as a strong framework and still show insecure or impractical realizations of it [2407.09995] [2501.18861].

## 2. Cost structure: timing, area, energy, and observed slowdown

The dominant cost identified in many studies is that PRAC counter maintenance lies on or near the critical path of row closure. Standard PRAC implementations increment the per-row counter during precharge using a read-modify-write sequence. Across multiple timing studies, this stretches $t_{RP}$ from about 15–16 ns to 36 ns, and $t_{RC}$ from about 47–48 ns to 52 ns. The same timing tables also report associated shifts such as $t_{RAS}$ from 32 ns to 16 ns, $t_{RTP}$ from 7.5 ns to 5 ns, and $t_{WR}$ from 30 ns to 10 ns. The literature consistently identifies the enlarged precharge-related delay, especially the $t_{RP}$ increase, as the principal source of benign-workload overhead [2502.12650] [2507.05556].

Area and storage costs are described in two different ways. One study cites an early Samsung DSAC estimate of roughly a 9% increase in DRAM core area due to per-row counter cells and update logic. Another, using an 8-bit-counter accounting model with 128K rows per bank and 16 Kbit per DRAM row, notes that one bank needs 128 KB of counter metadata, fitting into 64 DRAM rows and corresponding to only 0.05% capacity overhead. These figures are not contradictory; they quantify different things. One is core-area impact of integrating counter logic, while the other is metadata capacity expressed in DRAM rows [2605.17358] [2502.12650].

Reported performance overheads vary widely with threshold, timing model, controller policy, workload class, and evaluation methodology. Cycle-level analyses report that secure PRAC configurations can incur 9.7% average and 13.4% maximum system performance overhead at $RH = 1K$, and 81.2% average and 91.9% maximum at $RH = 20$. Another study using a QPRAC-based PRAC implementation reports about 14% average slowdown across workloads at $T=500$, with 21.8% slowdown on high-memory-intensity workloads, and shows a speed-scaling effect from 2.2% slowdown at 3200 MT/s to 14% at 8000 MT/s [2502.12650] [2605.17358].

Real-machine measurements complicate the picture. A hardware study on modern Intel systems with DDR5-4800 reports that PRAC’s average and maximum overheads for SPEC CPU2017 are 1.06% and 3.28%, up to 9.15x lower than simulator-based reports. That work also shows a strong positive correlation between RBMPKI and PRAC overhead, with Pearson correlation coefficient 0.81 and $p < 10^{-5}$, and argues that close page policy can hide much of the elongated precharge latency from the critical path [2507.05556].

## 3. Security conditions and implementation-dependent correctness

Exact counting does not by itself settle the security problem. The literature repeatedly formalizes PRAC security as a bound on the number of extra activations that can occur after a row reaches the alert threshold but before mitigative refresh completes. AutoPRAC states this explicitly as
$$
N + \text{Max} < T,
$$
where $N$ is the PRAC alert or back-off threshold, $\text{Max}$ is the worst-case number of extra activations beyond $N$, and $T$ is the physical RowHammer threshold. The same work separates verification into a mitigation-policy safety property, $\max(\text{counters}) \le T$, and a counter-reset safety property requiring that a row’s real physical damage never exceed its PRAC counter value [2606.23905].

Early analyses of DDR5 PRAC under the Wave attack conclude that secure configurations exist down to about $NRH = 20$ or $RH = 20$, typically with aggressive settings such as $N_{BO}=1$ and 4 RFMs per recovery period. These results establish that PRAC can, in principle, protect very vulnerable chips, but only with careful configuration of the threshold and recovery behavior [2406.19094] [2502.12650].

A central line of research argues that queueing and selection policy are decisive. MOAT shows that Panopticon, which inspired PRAC+ABO, is insecure as a JEDEC-style implementation because a row can continue accumulating activations while waiting in the mitigation queue. Its Jailbreak pattern causes 1152 activations on an attack row for a Panopticon threshold of 128, and the randomized variant still produces about 1145 activations. MOAT responds with dual thresholds—ETH, an Eligibility Threshold, and ATH, an ALERT Threshold—and reports that MOAT configured with ATH=64 can safely tolerate a Rowhammer threshold of 99, while ATH=128 yields a safe threshold of 161 [2407.09995].

QPRAC extends this line by replacing FIFO-style service with a priority-based service queue that stores both RowID and activation count. Its claim is that a full queue is not a failure mode if the queue is ordered by the hottest rows. In its default configuration with $N=32$, QPRAC reports secure thresholds of 71, 58, and 52 for PRAC-1, PRAC-2, and PRAC-4, respectively, and argues that the PSQ behaves identically to ideal PRAC for the wave/feinting family as long as the queue size is at least the number of RFMs per Alert [2501.18861].

Formal verification has also exposed flaws in apparently secure designs. AutoPRAC discovers a previously unreported MOAT bug in the periodic-refresh counter-reset policy, showing a concrete attack with 195 ACTs on a row prior to mitigation, or 34 activations above the claimed $T=161$. This result makes a broader methodological point: PRAC security cannot be established by hand-crafted attack patterns alone when mitigation ordering, periodic refresh, and counter reset all interact [2606.23905].

## 4. Side channels and availability hazards induced by PRAC

PRAC introduces attack surfaces that are not miscounting failures. The most direct is a timing channel created by activity-dependent ABO and RFM issuance. PRACLeak shows that an attacker sharing a DRAM channel can infer victim activity from the latency spikes caused by all-bank RFM stalls. The paper reports activity-based covert channels at 11–41 Kbps and activation-count-based covert or side channels at 39–124 Kbps, and demonstrates leakage of 64 out of 128 AES key bits from a vulnerable T-table implementation in under 200 encryptions [2505.10111].

The channel exists because PRAC metadata becomes externally visible through timing. With one RFM per ABO, the extra observed delay is about 120 ns; with 2 RFMs, about 470 ns; with 4 RFMs, about 1150 ns. The same study proposes Timing-Safe PRAC (TPRAC), which replaces activity-triggered RFMs with periodic Timing-Based RFMs and a single-entry per-bank mitigation queue. At $N=1024$, it reports that one TB-RFM every 1.6 $t_{REFI}$ eliminates ABO-RFMs and incurs 3.4% average slowdown [2505.10111].

Availability is another recurring concern. One analysis of PRAC under an availability-oriented Wave attack reports that a malicious pattern can hog up to 94% of DRAM throughput and reduce system throughput by up to 94.5% in the worst case, with average degradation around 86.8% across 60 workloads for $NRH = 20$. A separate PRACtical study shows that the channel-wide nature of standard $RFM_{ab}$ is itself a vulnerability: on average only 1.16 out of 64 banks require recovery when an ABO event occurs, yet the baseline stalls all banks. PRACtical’s bank-isolated $RFM_{MASK}$ design reduces performance degradation from aggressive performance attacks to less than 6%, while the original PRAC+ABO design can suffer slowdowns above 80% [2406.19094] [2507.18581].

These results show that PRAC’s exactness addresses one class of RowHammer uncertainty—identifying hot rows—but does not by itself solve confidentiality or availability problems created by the control protocol around those counters.

## 5. Implementation strategies inside the PRAC design space

A large body of work treats PRAC not as a fixed mechanism but as a design space structured by four recurring questions: where counters reside, whether counter updates can overlap with data accesses, how hot rows are prioritized, and how recovery is scoped. Chronus attacks two weaknesses of baseline PRAC: critical-path counter update and bursty fixed-size recovery. It moves counters into a separate counter subarray to enable Concurrent Counter Update and replaces fixed back-off with dynamic control of the number of preventive refreshes performed. In its evaluation, Chronus reports near-zero average performance overhead at $RH=1K$ and 8.3% average overhead at $RH=20$, versus 81.2% for PRAC-4 at the same low threshold [2502.12650].

PRACtical pursues a different optimization path. It uses a centralized increment circuit to overlap the counter update of a previously precharged row with the activation of the next row when accesses target non-conflicting subarrays, thereby restoring subarray-level parallelism. It also replaces channel-wide recovery with bank-level recovery isolation using a DRAM-resident BA register and $RFM_{MASK}$. Relative to opportunistic PRAC+ABO, it reports 8% average performance improvement, up to 20% in the best cases, and 19% average energy reduction, while preserving RowHammer protection [2507.18581].

Queue management has produced another branch of PRAC designs. MOAT uses CTA and CMA state with ETH and ATH thresholds, reporting 7 bytes of SRAM per bank and 0.28% average slowdown for ATH=64. QPRAC instead uses a CAM-based priority-based service queue, evaluated with 5 entries per bank, 15 bytes per bank, and about 0.038 mm\(^2\) overhead, or 0.05% of a DDR5 chip. It reports 0.8% slowdown for benign workloads in the default design and 0% slowdown with proactive mitigations, though the fully proactive variant raises energy overhead to 14.6% and motivates the energy-aware QPRAC+Proactive-EA alternative [2407.09995] [2501.18861].

CnC-PRAC extends the off-critical-path idea by buffering and coalescing counter read-modify-write requests that map to the same physical counter row. With default parameters $M=4$ and $K=4$, it reports almost 75%–83% fewer counter-row activations than Chronus, negligible slowdown, and only 0.84%–1% dynamic energy overhead compared to insecure DDR5 DRAM. Its practical claim is that “coalesce, not cache” is a better optimization lever than trying to cache a very large hot-row working set [2506.11970].

## 6. Behavior under nonstandard access patterns and full-system interactions

PRAC was designed around conventional one-row-at-a-time activation, and some later workloads stress that assumption directly. PuDHammer studies processing-using-DRAM operations such as CoMRA and SiMRA, which activate multiple rows simultaneously. The paper argues that this creates a direct mismatch with standard PRAC, because one logical operation may require updating multiple counters at once. It evaluates an area-optimized PRAC-AO that updates counters sequentially and a performance-optimized PRAC-PO that updates them simultaneously, then introduces weighted counting:
$$
w_{\text{op}} = \frac{HC_{first}^{RH}}{HC_{first}^{op}},
$$
yielding weight 10 for CoMRA and 200 for SiMRA from the reported $HC_{first}$ values. PRAC-PO-WC prevents all read-disturbance bitflips at an RDT of about 20, but still incurs 48.26% average and 98.83% maximum system performance overhead across 60 five-core multiprogrammed workload mixes, with weighted speedup normalized to a no-mitigation baseline [2506.12947].

System-level interactions with prefetching are likewise significant. ORAP studies PRAC in a Zen4-like DDR5 environment with PRAC threshold 512 and reports that PRAC changes nRP from 16.25 ns to 36.25 ns while leaving other timing dimensions largely unchanged except for the standard PRAC-related shifts. In that setup, baseline PRAC causes only 0.15% multi-core slowdown, but the paper argues that prefetchers reshape activation patterns, increasing DRAM activation rates and amplifying PRAC-related energy overheads. ORAP responds by caching large portions of DRAM rowbuffer contents in the LLC, reducing activation rates by 51.3% and reducing energy overheads by 11.8% under PRAC mitigations [2602.13434].

Real-hardware evidence suggests that controller policy can dominate the observed overhead. The first real-machine PRAC study reports 1.06% average and 3.28% maximum overhead on SPEC CPU2017 with hardware prefetchers enabled, and identifies close page policy as the best setting for minimizing PRAC overhead because it hides the longer row precharge operations from the critical path. A plausible implication is that PRAC evaluation is inherently a joint problem over DRAM timing, page policy, prefetching, and workload row-buffer locality, rather than a property of the counter mechanism alone [2507.05556].

## 7. Relation to approximate, victim-based, and probabilistic alternatives

PRAC is often treated as the exact-counting reference point against which alternative RowHammer defenses are judged. CoMeT is explicitly PRAC-like in spirit but replaces exact per-row counters with Count-Min-Sketch-based tracking. Its crucial property is that it may overestimate but never underestimate a row’s activation count, preserving safety while reducing storage dramatically. At $N_{RH}=125$, it reports 4.01% average performance overhead across 61 benign single-core workloads and 74.2x less area overhead than Graphene, while positioning itself as a compressed approximation to the exactness of PRAC [2402.18769].

PVAC challenges PRAC more fundamentally. It argues that PRAC counts the aggressor while RowHammer physically threatens the victim, and that this mismatch causes monotonic counter accumulation even in an idle bank because PRAC increments on ACT, REF, and RFM-induced ACT but resets only during explicit RFM. PVAC instead performs per-victim-row counting, resetting the activated row’s counter and incrementing victim-row counters, and uses a dedicated counter subarray to overlap updates with normal accesses. The paper states that PVAC maintains the same worst-case safety guarantee as PRAC while avoiding spurious Alerts and eliminating PRAC timing penalties [2604.20576].

Probabilistic designs offer a third contrast. Loaded Dice positions PRAC as the strong exact baseline and compares it with MINT and the proposed PrISM. At $T=500$, PrISM incurs 0.2% average slowdown versus 14% for PRAC, requires no DRAM array changes or per-row counters, and uses only 625B of SRAM per bank. At $T=250$, it reports 1.5% average slowdown versus 10.7% for MINT. The paper’s central comparison is not that PRAC is insecure, but that exact per-row accounting may be too costly when thresholds fall and commodity timing budgets remain tight [2605.17358].

Across these comparisons, PRAC occupies a stable conceptual role. It is the standardized exact-counting endpoint: the mechanism that makes row-granular mitigation semantically straightforward, but simultaneously exposes the engineering difficulty of integrating exact state into the DRAM timing and control plane. Subsequent research either attempts to make that exactness practical, verifies or repairs its security semantics, or relaxes exactness in favor of lower area, lower energy, lower latency, or better alignment with the victim-side physics of disturbance.

Source: https://www.emergentmind.com/topics/per-row-activation-counters-prac