DDR5 Alert Back-Off (ABO) Overview

• ABO is a DDR5 signaling protocol that alerts the memory controller when per-row activation counters reach thresholds to trigger Rowhammer mitigation.
• It governs timing rules and recovery intervals by linking DRAM counters to refresh management, balancing security margins with performance overhead.
• Recent refinements apply bank-aware and periodic mitigations to reduce energy consumption, mitigate timing channels, and enhance overall system security.

Searching arXiv for the specified ABO-related papers to ground the article. Alert Back-Off (ABO) is the standardized signaling and control mechanism in DDR5 that connects in-DRAM per-row activation counters (PRAC) to Rowhammer mitigation actions. In this setting, a DRAM device asserts ABO when a PRAC counter reaches or exceeds a configured Alert threshold, and the memory controller must then schedule mitigation through Refresh Management operations. Recent work treats ABO as a central element of PRAC-based Rowhammer defense because its timing rules determine when mitigation begins, how much parallelism is lost during recovery, and what security margin remains before an aggressor row can exceed a safe activation bound (Nazaraliyev et al., 24 Jul 2025).

1. Definition and protocol role

In DDR5 with PRAC, ABO is an Alert Back-Off signal or protocol exported by the DRAM device to the memory controller. It is asserted when any PRAC counter in a bank reaches or exceeds a configured Alert threshold, where that threshold is a number of activations less than or equal to the safe Rowhammer threshold. ABO is not itself the mitigation; it is a notification or handshake that tells the controller that mitigation must be executed soon (Nazaraliyev et al., 24 Jul 2025).

PRAC supplies the state that makes ABO meaningful. Each DRAM row is extended with a local activation counter stored in DRAM itself. In the DDR5 PRAC design, the counter is incremented on precharge rather than on activation: when a PRE is issued, the bank’s global row buffer logic performs a read-modify-write on the counter of the row being closed. If, after increment, the counter value is greater than or equal to the Alert threshold for that bank, the DRAM asserts ABO to the controller. The ABO line does not provide the identity of the row or the specific bank; it reports only that an alert occurred somewhere in the device or channel, depending on the implementation model (Nazaraliyev et al., 24 Jul 2025).

The standardized timing model couples this alert to a delayed recovery sequence. On ABO assertion, the memory controller enters a 180 ns pre-recovery window during which it continues to serve normal memory traffic. After 180 ns, it issues a mitigation command. DDR5 also defines a minimum spacing between alerts: there must be at least $n$ ACTs between two consecutive ABO events, with $n \in \{1,2,4\}$, referred to as PRAC-1, PRAC-2, and PRAC-4. In the model used by PRACtical, each ABO interval consists of a 180 ns pre-recovery period followed by one or multiple 350 ns recovery executions, giving minimum and maximum ABO intervals from about 350 ns to 1500 ns (Nazaraliyev et al., 24 Jul 2025).

2. Baseline DDR5 behavior and its costs

The mitigation phase triggered by ABO is represented as $RFM_{\text{ab}}$, an all-bank Refresh Management operation. In the baseline behavior modeled for DDR5, ABO is asserted by DRAM, the controller waits through the 180 ns pre-recovery window, and then issues $RFM_{\text{ab}}$. Each $RFM_{\text{ab}}$ has a fixed execution latency of 350 ns, operates at channel granularity, and stalls all requests to the channel while DRAM performs targeted refresh of victim rows and related recovery work. If multiple alerts occur close in time, multiple $RFM_{\text{ab}}$ commands are issued, each with its own 350 ns window and with spacing constrained by the $n$-ACT rule (Nazaraliyev et al., 24 Jul 2025).

Two costs dominate this baseline PRAC+ABO design. First, PRAC counter updates extend precharge and row-cycle timing because the read-modify-write is performed at bank level near the global row buffer. The counter update adds about 21 ns to PRE, increasing $t_{RP}$ from 15 ns to 36 ns and $t_{RC}$ from 47 ns to 52 ns. Across memory-intensive workloads, this yields an average slowdown of about 6% and up to about 20% slowdown, with the dominant source being the almost $2\times$ increase in PRE latency rather than the modest increase in $n \in \{1,2,4\}$0 (Nazaraliyev et al., 24 Jul 2025).

Second, the recovery action induced by ABO is coarse-grained. Prior work and the default Ramulator DDR5 model exploit the all-bank stall to perform opportunistic mitigation, refreshing adjacent rows even in banks that do not have a hot row. In benign workloads, on average only 1.16 out of 64 banks need actual mitigation when an alert occurs, yet $n \in \{1,2,4\}$1 stalls all 64 banks. Opportunistic mitigation performs over $n \in \{1,2,4\}$2 more RFM refreshes than strictly necessary and increases RFM-related energy by about 70%. Under performance attacks that intentionally trigger frequent ABOs, one ABO per refresh interval can cause 20–30% slowdown, and three ABOs per interval can cause more than 80% slowdown for many applications (Nazaraliyev et al., 24 Jul 2025).

This baseline behavior establishes a recurring theme in later work: ABO’s logical role is simple, but the granularity at which the system interprets and services the alert determines whether PRAC remains practical.

3. Refinements of ABO-driven mitigation

Subsequent designs keep ABO as the trigger but alter how DRAM and the controller interpret and service it.

Design	ABO treatment	Reported outcome
PRACtical (Nazaraliyev et al., 24 Jul 2025)	Keeps ABO logically identical; adds bank-aware recovery through a BA register and RFM_MASK	8% average performance improvement, up to 20%; 19% energy reduction
MOAT (Qureshi et al., 2024)	Uses two thresholds, ETH and ATH, with reactive ABO	ATH=64 safely tolerates a Rowhammer threshold of 99; 0.28% average slowdown
QPRAC (Woo et al., 31 Jan 2025)	Co-designs reactive ABO with a priority-based service queue	Secure up to Rowhammer threshold 71 with 0.8% slowdown; 0% with proactive mitigations
TPRAC (Woo et al., 15 May 2025)	Replaces activity-dependent ABO-RFMs with periodic Timing-Based RFMs	Closes timing channels; 3.4% overhead at threshold 1024

PRACtical preserves ABO semantics but changes the response path after an alert. Its first change is subarray-level counter update, which removes most PRAC timing overhead without changing when ABO is asserted. Its second change is bank-level recovery isolation. A DRAM-resident Bank Alert register stores one bit per bank, and RFM_MASK both initiates recovery for banks whose BA bit is set and returns the BA mask to the controller. From the controller’s perspective, ABO still means that one or more banks have hit the threshold and that RFM must be scheduled soon, but the back-off becomes per-bank rather than per-channel. In the reported evaluation, this design improves performance by 8% on average, by up to 20%, saves about 19% energy, and limits slowdown from aggressive performance attacks to less than 6%, while preserving Rowhammer protection (Nazaraliyev et al., 24 Jul 2025).

MOAT treats ABO as the security-critical boundary of a provably secure PRAC design. It introduces an Eligibility Threshold (ETH) for proactive mitigation and an ALERT Threshold (ATH) for initiating ABO. Because JEDEC permits a few activations between consecutive ALERTs, MOAT explicitly models how many activations can slip through before mitigation begins and derives a safe bound on the tolerated Rowhammer threshold. With ATH=64, MOAT can safely tolerate a Rowhammer threshold of 99, while incurring an average slowdown of 0.28% and requiring 7 bytes of SRAM per bank (Qureshi et al., 2024).

QPRAC argues that reactive ABO can remain secure and practical if the mitigation queue is priority-based rather than FIFO-based. Its priority-based service queue stores pending mitigations in descending order of activation count, so the rows serviced by ABO-induced RFMs are the rows closest to dangerous counts. QPRAC co-designs this queue with opportunistic mitigation on RFM operations and proactive mitigation during refresh, and reports security down to Rowhammer threshold 71 with 0.8% slowdown for benign workloads, which further reduces to 0% with proactive mitigations (Woo et al., 31 Jan 2025).

TPRAC takes the opposite direction: it identifies ABO-induced, activity-dependent RFMs as a timing-channel source and therefore issues Timing-Based RFMs periodically and independent of memory activity. Its goal is not to refine the alert response granularity, but to eliminate the timing observability of activity-dependent recovery. At a Rowhammer threshold of 1024, the reported performance overhead is 3.4% (Woo et al., 15 May 2025).

4. Security properties, attacks, and correctness conditions

The central security question is whether ABO-mediated recovery can guarantee that no row receives more activations than the safe Rowhammer bound before mitigation. Several papers show that this depends on queue semantics, inter-alert timing, and how much information accompanies an alert.

MOAT shows that a prior design, Panopticon, is insecure under PRAC+ABO as modeled for DDR5. Its Jailbreak pattern can cause 1150 activations on an attack row for Panopticon configured for a threshold of 128. The core issue is that a row can continue accumulating activations while queued for mitigation, and the delayed, non-blocking alert semantics allow additional activations before RFMs are issued. MOAT therefore recommends avoiding large queues, storing counters in queue entries, and using ABO Level 1, which has shorter alert stall and smaller impact of delayed ALERT on the tolerated Rowhammer threshold (Qureshi et al., 2024).

QPRAC extends this critique to JEDEC-style non-blocking Alert behavior. It describes Toggle+Forget and Fill+Escape attacks, in which a full FIFO queue plus the allowed ABO activations after Alert lets a target row cross a mitigation threshold without being enqueued or serviced. QPRAC’s priority-based service queue is designed specifically to remove this FIFO vulnerability: when a row’s activation count exceeds the smallest count already in the queue, it displaces that entry and rises toward the top of the service order. The paper’s formal analysis states that, with PSQ size at least the number of RFMs per Alert, the worst-case maximum activations per row before mitigation matches that of Ideal PRAC under the strongest known wave or feint attacks (Woo et al., 31 Jan 2025).

PRACtical addresses a different corner case. Bank-level isolation allows one bank to remain accessible while another bank is in recovery, which means a row in a non-mitigated bank can receive a few more activations before its own recovery is scheduled. Using a 350 ns RFM_MASK window and $n \in \{1,2,4\}$3 ns, the maximum number of new ACTs to the same bank during recovery is about 6, so a row at $n \in \{1,2,4\}$4 could reach at most $n \in \{1,2,4\}$5 activations before its own recovery is scheduled. PRACtical preserves the same security as PRAC+ABO by lowering the effective bank-bit threshold by at least this worst-case slack, or equivalently by adjusting thresholds so that the total number of activations between mitigations does not exceed the safe bound assumed by baseline PRAC+ABO (Nazaraliyev et al., 24 Jul 2025).

These analyses show that ABO’s security meaning is not exhausted by “assert alert, then mitigate.” The queue discipline, the maximum delayed activations, and the granularity of recovery all enter the proof obligation.

5. Performance attacks and timing-channel exposure

ABO has also been studied as an attack surface in its own right. In PRACtical, aggressive performance attacks trigger frequent alerts so that the channel repeatedly enters the 180 ns pre-recovery period and 350 ns recovery stall. Under this model, channel-wide stalls are the dominant reason that 1–3 ABOs per refresh interval can degrade performance by 20–80%, whereas bank-level recovery isolation sharply reduces the attack’s leverage because only banks marked in the BA register are stalled (Nazaraliyev et al., 24 Jul 2025).

MOAT studies denial-of-service and performance attacks due to ALERTs more explicitly. It models ABO as a mechanism that can reduce available throughput during sustained hammering because the controller must repeatedly back off and issue RFMs. The paper also describes a Torrent-of-Staggered-ALERT attack that staggers ALERTs across banks so that mitigation opportunities do not align well across the system. In the reported analysis, throughput loss reaches 24% across 4 banks and up to 52% across 17 banks, although the paper argues that such slowdown remains comparable to severe ordinary memory contention (Qureshi et al., 2024).

PRACLeak identifies a different consequence: a timing channel introduced by the ABO protocol and RFM commands. Because ABO-triggered RFMs occur when a row’s activation counter exceeds the Back-Off threshold and because each RFM stalls all banks in the channel for about 350 ns, a co-resident attacker can observe latency spikes and infer row-activation behavior. The paper reports an activity-based covert channel with 41.4 Kbps at $n \in \{1,2,4\}$6 and an activation-count-based covert channel with 123.6 Kbps at the same threshold, both with error rate below 0.1%. It further shows that PRACLeak can leak 64 out of 128 bits of an AES key in under 200 encryptions from a vulnerable T-table implementation. TPRAC is proposed specifically to close this timing channel by making RFMs periodic and independent of memory activity (Woo et al., 15 May 2025).

A plausible implication is that ABO must now be evaluated along three axes simultaneously: Rowhammer safety, performance isolation, and timing-channel opacity.

6. Compatibility, implementation, and significance

A notable feature of the DDR5 literature is that most improvements do not discard ABO; they reinterpret or constrain it. PRACtical is designed to be compatible with existing JEDEC PRAC+ABO semantics: it does not change the ABO signal itself, the alert timing rules, or the fundamental definition of PRAC counters. Its additional hardware consists of a centralized increment unit, routing to subarray local row buffers, subarray-level decode and comparator logic, and a 64-bit BA register for a 64-bank channel. The reported area overhead of the increment path and additional logic is only 0.03% of DRAM area, with a 10 ns register read latency folded into RFM_MASK (Nazaraliyev et al., 24 Jul 2025).

Other designs adopt similarly small state additions around ABO. MOAT uses 7 bytes of SRAM per bank for CTA, CMA, and safe-reset counters. QPRAC uses a 5-entry per-bank priority-based service queue; its reported QPRAC-specific area is about 0.05% of a 32 Gb DDR5 chip. TPRAC adds a 24-bit RFM Interval Register per controller and a single-entry mitigation queue per bank, while remaining compatible with the existing DDR5 interface (Qureshi et al., 2024).

Across these designs, ABO remains the same logical trigger: a DRAM-resident counter crosses a threshold and the controller must provide mitigation time. What changes is the interpretation of that trigger. In baseline DDR5 modeling, ABO induces a coarse all-bank or channel-wide recovery phase. In PRACtical, the same alert becomes bank-aware through BA and RFM_MASK. In MOAT and QPRAC, ABO is embedded in formal security arguments about maximum permissible activations before mitigation. In TPRAC, the activity-dependent use of ABO is treated as unsafe for confidentiality and is replaced in practice by periodic RFMs (Woo et al., 15 May 2025).

This trajectory suggests that ABO is best understood not as a complete mitigation, but as the control boundary between precise activation counting and the scheduling of recovery. The research record shows that this boundary is simultaneously a security interface, a performance interface, and, if left activity-dependent, a timing-observable interface.