MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters

Rowhammer is a hardware attack where hammering one DRAM row over and over flips bits in its neighbors, letting an attacker corrupt memory they don't own and seize control of a machine — and it keeps getting worse, because the number of hammers needed to cause a flip has fallen from about 140,000 a decade ago toward just a few hundred, leaving almost no margin; the small in-DRAM trackers that watch for hammering keep getting overwhelmed by crafted access patterns, so DDR5 now adds a per-row activation counter (PRAC) and an "ALERT" signal that lets the DRAM tell the CPU to pause while it repairs — but that's just a mechanism, and naive designs on top of it are still breakable; this paper (Georgia Tech and Google) builds MOAT, a PROVABLY secure defense that tracks just one row per bank in 7 bytes and uses two thresholds — a low one for cheap proactive repair and a high one that raises the ALERT as a guaranteed safety net — defending a hammer threshold as low as 99 at under 0.3% slowdown, while exposing new attacks that break naive counter-based designs.

The argument in one glance

Problem

Hammering a DRAM row flips bits in its neighbors — and it keeps getting easier

DRAM stores each bit as charge in a tiny capacitor, packed so densely that electrical activity in one row disturbs its neighbors. Rowhammer exploits this: by repeatedly ACTIVATING (opening) one row very fast, an attacker leaks enough charge from physically adjacent rows to FLIP their bits — without ever touching that memory legitimately. That is a serious security hole, because flipping the right bit in a page table or a permission field lets an attacker who only owns their own memory corrupt memory they do not own, escalate to full control, or break confidentiality. And the problem is getting worse: the ROWHAMMER THRESHOLD, the number of activations needed to cause a flip, has fallen from about 140,000 in 2014 to about 4,800 in 2020, heading toward a few hundred — so there is almost no margin left for a defense to work in.
What people did

Watch for hammered rows in the DRAM and refresh their victims

The standard defense lives inside the DRAM chip. A small on-chip tracker (a handful to a few dozen SRAM entries per memory bank) watches which rows are being activated a lot; when a row looks like an aggressor, the DRAM performs a mitigating refresh — a Victim Row Refresh that tops up the charge of the neighboring rows before their bits can flip. Targeted Row Refresh (TRR) and similar schemes ship in real DRAM on exactly this principle: spot the hammering, refresh the victims in time.
Why it fell short

Small trackers get overwhelmed, and the new counter substrate still needs a secure design

The trouble is that the tracker is tiny, and attackers overwhelm it. TRRespass thrashes the tracker with hundreds of different aggressor rows so the real one is never watched; Blacksmith uses decoy rows to evict a tracked aggressor from the limited queue. These are HEURISTIC defenses — they catch the patterns their designers imagined, not the worst case an adversary can craft — so they have been broken again and again. In response, DDR5 adds a stronger substrate: PRAC (Per-Row Activation Counting), an exact counter inlined with EVERY row so the DRAM always knows each row's activation count, and ALERT-Back-Off (ABO), a signal the DRAM raises to tell the memory controller "pause — I need time to mitigate." But JEDEC leaves the DESIGN unspecified, and a naive design on top of these counters is still breakable: a security guarantee requires proving the worst case, not just having the counters.
This paper's idea

A provably secure design: one entry per bank and two thresholds

This paper (Georgia Tech and Google — Qureshi and Qazi) builds MOAT, a PROVABLY secure Rowhammer defense on the DDR5 PRAC and ABO substrate. Its first move is counterintuitive: track only ONE row per bank, not a queue. Prior queue-based designs (Panopticon, which inspired the standard) are broken because a hammered row can be "aged" in the queue — kept under attack while it waits for its turn to be mitigated, piling on far more activations than the threshold (their Jailbreak attack reaches 9x the threshold). MOAT keeps just the single highest-count row in 7 bytes of SRAM. Its second move is two internal thresholds: ETH (Eligibility Threshold), a low bar above which a row becomes eligible for cheap PROACTIVE victim refresh during normal refreshes, saving energy; and ATH (ALERT Threshold), a higher bar at which the DRAM raises an ALERT to force the controller to give it time for a REACTIVE mitigation — the safety net that guarantees the bound. MOAT closes subtle corner cases (safely carrying counts across refresh boundaries) and PROVES a guaranteed-safe threshold by analyzing the worst-case adversary. It defends a Rowhammer threshold as low as 99 (at ATH 64) with 0.28% slowdown, or 161 (at ATH 128) with essentially none — in 7 bytes per bank — while exposing new attacks (Jailbreak, Ratchet, and a staggered-ALERT denial-of-service) that break naive counter-based designs.

Why this problem is worth solving

Rowhammer is one of the few attacks that reaches through every software defense to corrupt memory at the physical level, and as DRAM density climbs it is getting easier, not harder — so a defense that actually holds is a genuine need. Understanding the attack and why the usual fixes fail comes first. A

ROWHAMMER is a hardware vulnerability in which repeatedly activating (opening) one DRAM row causes bit-flips in its physically adjacent rows, because the electrical disturbance from the hammered row leaks charge from its neighbors. An attacker with only ordinary access to their own memory can thus flip bits in memory they do not own — and by targeting a bit in a page table, a permission field, or a cryptographic key, escalate privilege or break security. The MITIGATION is a Victim Row Refresh: refresh the neighbor rows to restore their charge before a flip occurs. The defender’s budget is set by the ROWHAMMER THRESHOLD, the number of activations needed to induce a flip — the fewer activations it takes, the less margin the defender has to notice the hammering and refresh in time. That threshold has collapsed across generations (roughly 140,000 in 2014, 4,800 in 2020, and trending toward a few hundred), so defenses that worked with a large margin no longer do

is the setting. The falling threshold is what makes an old, apparently solved problem urgent again.

The reason the standard defenses keep failing, and what MOAT builds on, is a mismatch between a small tracker and a determined adversary — now addressed by a new hardware substrate. A

the in-DRAM defenses that ship today track aggressor rows in a tiny SRAM structure (a few to a few dozen entries per bank), and attackers defeat them by OVERWHELMING that structure — flooding it with more aggressor rows than it can hold, or using decoys to evict the row that matters. To fix this at the root, DDR5’s specification was extended with two mechanisms. PRAC (Per-Row Activation Counting) inlines an exact activation COUNTER with every DRAM row, so the DRAM always knows precisely how many times each row was activated — a small tracker can no longer be thrashed, because every row is counted. ALERT- Back-Off (ABO) lets the DRAM raise an ALERT to the memory controller when a counter is high, forcing the controller to pause activations and grant the DRAM time to perform mitigating refreshes. Crucially, JEDEC standardized these MECHANISMS but not the POLICY for using them, so a design must still choose thresholds and behavior that are provably safe — a naive design on the same counters remains breakable

is the foundation. The counters remove the overwhelm attack, but security still depends on the design laid on top of them.

What people did before, and where it broke

Small in-DRAM trackers (TRR, DSAC, PAT). Watch a few dozen rows and refresh their victims. Cheap, but the tiny tracker is overwhelmed by crafted patterns (TRRespass floods it, Blacksmith evicts with decoys) — broken repeatedly.
Software and OS mitigations. Isolate pages, avoid risky layouts. Add overhead and cover only known patterns; they do not close the physical vulnerability.
Idealized large trackers (TRR-Ideal). A hypothetical infinite queue could tolerate a much higher threshold, but is impractical and still vulnerable to “feinting” tricks — not a real defense.
Naive PRAC designs (Panopticon and the inspiring proposals). Use the new per-row counters, but with a multi-entry queue. Broken by the Jailbreak attack: a hammered row is aged in the queue while it waits for mitigation, accumulating up to 9x the threshold in extra activations.
The gap. No design used the DDR5 counters with a PROVABLY secure policy — one whose thresholds are set by worst-case analysis to guarantee safety even against an adaptive adversary, at low cost. That is the gap MOAT fills.

How MOAT securely mitigates Rowhammer

Track one row, use two thresholds, close the corner cases, and prove the bound

The threat and the new DDR5 substrate

Hammering a row flips its neighbors' bits, and the threshold to do so keeps falling. Small in-DRAM trackers get overwhelmed by crafted patterns, so DDR5 adds exact per-row activation counters (PRAC) and an ALERT signal (ABO) — but the policy for using them is unspecified, and naive designs are still breakable.
↓ →
Track only ONE row per bank, not a queue new

A queue is itself an attack surface: an entry can be "aged", kept under attack while it waits its turn for mitigation, piling on extra activations. MOAT instead keeps just the single highest-count row in 7 bytes of SRAM, so there is no waiting window to exploit.
↓ →
Use two thresholds — eligibility and alert new

ETH (Eligibility Threshold) is a low bar: only rows above it are eligible for cheap PROACTIVE victim refresh during normal refreshes, saving energy on rarely-hammered rows. ATH (ALERT Threshold) is a higher bar: reaching it makes the DRAM raise an ALERT and force the controller to grant time for a REACTIVE refresh — the safety net that sets the guaranteed threshold.
↓ →
Carry counts safely across refresh boundaries new

Naively resetting a counter at a refresh boundary is exploitable: an attacker hammers a row just before and just after a refresh, doubling its true activations while the counter looks low. MOAT keeps replicas of the counters of the only two rows that could be targeted before the next refresh group completes, so the count carries over correctly.
↓ →
Prove the worst-case bound new

MOAT analyzes the strongest adversarial pattern rather than trusting the counters alone. Tracking one entry removes the Jailbreak aging attack; a model bounds the Ratchet attack that concentrates activations in the small gaps JEDEC permits between consecutive ALERTs. The analysis yields a guaranteed-safe Rowhammer threshold from the chosen ATH.
↓ →
Confirm negligible overhead and no serious denial-of-service new

On benign workloads, ALERTs almost never fire (0.28% average slowdown at ATH 64, essentially zero at ATH 128), because real programs hammer far less than an attacker. Deliberately abusing ALERTs to slow the system (a staggered-ALERT attack) is no worse than ordinary memory contention, not a new denial-of-service.

Evaluated in a cycle-level simulator (8-core out-of-order, DDR5 timing, ABO Level 1) on 15 SPEC-2017 and 6 GAP graph workloads. Storage is 7 bytes of SRAM per bank; it also analyzes and breaks Panopticon and naive PRAC designs. A defensive design paper.

The idea

Prove security against the worst case — do not just patch the attacks you have seen. Every prior in-DRAM defense was heuristic: it stopped the access patterns its designers anticipated, and adversaries kept finding a pattern it did not. MOAT’s defining stance is to reason about the STRONGEST possible adversary and set its thresholds so that even the worst pattern cannot reach a bit-flip, deriving a guaranteed-safe Rowhammer threshold from a worst-case model. Proving a security property instead of arguing from tested patterns is the same rigor the site’s memory-timing-defense page brings when it formally verifies non-interference, and the speculation-contract fuzzing page brings when it treats the defender’s model as something to be adversarially checked — and it is the direct answer to the recurring lesson across the site’s security pages that a defense which only blocks known attacks WILL be broken. Here the proof is what separates MOAT from the naive counter designs it breaks: same hardware, but a policy whose safety is analyzed, not assumed.

A cheap common-case action, guarded by a guaranteed-safe trigger. MOAT’s two thresholds split the work the way robust systems often do: the low ETH drives a cheap, proactive victim-refresh in the common case (and skips it for rarely-hammered rows to save energy), while the high ATH is the reactive safety net — when a counter climbs dangerously, the DRAM raises an ALERT and the controller is forced to give it time, guaranteeing the mitigation happens before a flip. The fast, cheap path handles normal life; a correct, more expensive fallback holds the security guarantee. This optimize-the-common-case-with-a-safe-guard structure is one the site rewards repeatedly — the microsecond-BFT page runs a signature-free fast path backed by a signed slow path, the datacenter-power page boosts aggressively within a bounded risk budget backed by recovery buffers, and the approximate-query page runs a cheap path backstopped by an exact one. Safety lives in the fallback, so the common case can be cheap.

Less machinery is more secure — the queue was the attack surface. The most surprising choice is that tracking ONE row per bank is safer than tracking many. A queue seems more thorough, but it creates a window between when a hammered row is noticed and when it is mitigated, and that window is exactly what the Jailbreak attack exploits by aging an entry. Removing the queue removes the window. Cutting away complexity because the complexity itself is the vulnerability is the same shrink-the-attack- surface, simplicity-is-security discipline the site’s isolation and consensus pages apply when they minimize what must be trusted — and it pairs with the broader lesson that an optimization can create the very hole it was meant to help close. MOAT’s security comes not from watching more, but from watching one thing and mitigating it before it can be aged.

Turning a per-row counter into a proof of security

From heuristic defenses to a worst-case guarantee

Securing DRAM against Rowhammer on the DDR5 PRAC and ABO substrate. Numbers from the paper's analysis and simulation.

Step 1 of 5

Why heuristics keep breaking

In-DRAM trackers have only a few dozen SRAM entries, and attackers overwhelm them — flooding with hundreds of aggressor rows (TRRespass) or evicting the tracked one with decoys (Blacksmith). A defense that stops the patterns its designers imagined is not secure against the worst pattern an adversary can craft.

the Rowhammer threshold has fallen from about 140,000 to about 4,800 and toward a few hundred, shrinking the margin
the root problem is a small tracker versus an adversary who can generate arbitrary access patterns

Why it works

Small in-DRAM trackers can be overwhelmed by crafted patterns → DDR5’s exact per-row counters cannot be thrashed, since every row is counted → the defender always has complete information about activation counts.
A queue creates a window between noticing a hammered row and mitigating it → tracking one entry per bank removes the window that the Jailbreak aging attack exploits → no entry can accumulate extra activations while waiting.
A single fixed threshold either wastes refresh bandwidth or reacts too late → a low ETH gates cheap proactive refresh and a high ATH forces a guaranteed reactive mitigation → the common case is cheap and the safety bound still holds.
Resetting counters at refresh boundaries hides activations from an attacker hammering around the boundary → replicating the two targetable rows’ counters carries the count over → the worst-case bound cannot be bypassed at the seam.
Real programs hammer far less than an attacker → benign workloads run thousands of activations per ALERT versus tens for an attack → the slowdown on real software is about 0.28%, a hundred times below the attack-scenario cost.

What it costs (trade-offs and scope)

It requires the DDR5 PRAC and ABO hardware. MOAT is a secure policy on a new substrate, not deployable on older DRAM, and it inherits PRAC’s timing cost (precharge time rises from 16 to 36 nanoseconds, the row cycle from 48 to 52) regardless of the policy.
The guarantee holds only at a chosen operating point. MOAT provably defends a Rowhammer threshold at or above what its thresholds tolerate (99 at ATH 64). If a future DRAM’s real threshold drops below that, ATH must be raised, costing more overhead — the security is provable at a set point that must track the hardware.
Security and performance trade off. ATH 64 gives a threshold of 99 at 0.28% slowdown; ATH 128 gives essentially zero slowdown but only tolerates a HIGHER threshold, i.e. less protection against very low thresholds. The knob must be set per device.
Attackers can still cause some slowdown. Abusing ALERTs — a single-row hammer (about 10% slowdown) or a staggered-ALERT attack across many banks (up to about 52% throughput loss) — is possible, though the paper argues it is comparable to normal memory contention and not a new denial-of-service.
The proof depends on subtle design details being exactly right. MOAT itself shows that naive designs on the same specification (Jailbreak, Ratchet, staggered-ALERT) are broken, so the security rests on getting details right — storing counter values, resisting refresh postponement, choosing the ABO level — and a mis-implementation reintroduces the vulnerability.

The evaluation

A cycle-level simulator (8-core out-of-order, DDR5 timing with a 52 nanosecond row cycle and a 3.9 microsecond refresh interval, ABO Level 1), on 15 SPEC-2017 and 6 GAP graph-analytics workloads under a stressful closed-page policy, measuring slowdown, ALERT frequency, storage, energy, and mitigation capacity, plus worst-case security analysis and attack case studies against Panopticon and naive PRAC designs.

Defending DRAM against Rowhammer

Property	Heuristic tracker (TRR)	Naive PRAC queue (Panopticon)	MOAT (this work)
Tracking
Security
Lowest threshold defended
Storage
Slowdown

Heuristic trackers are overwhelmed by crafted patterns, and a naive queue on the new per-row counters is broken by aging a hammered entry (9x over threshold). MOAT tracks one row per bank in 7 bytes and uses a low proactive threshold plus a high alert threshold whose worst case is analyzed — provably defending a Rowhammer threshold as low as 99 at 0.28% slowdown.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

Read the guarantees and scope precisely. MOAT requires the DDR5 PRAC and ABO hardware (per-row counters and the ALERT signal); it is a secure policy on a new substrate, not deployable on older DRAM, and it inherits PRAC’s timing cost regardless. Its security is a bound at a chosen operating point, not zero risk for all time: it provably defends a Rowhammer threshold at or above what its thresholds tolerate (99 at ATH 64), and if a future DRAM’s real threshold falls below that, ATH must be raised at extra cost. Security and performance trade off through that knob (ATH 64 gives a threshold of 99 at 0.28%; ATH 128 gives near-zero slowdown but tolerates only a higher threshold). Attackers can still cause some slowdown by abusing ALERTs — up to about 52% throughput loss with a staggered attack across many banks — which the paper argues is comparable to ordinary memory contention rather than a new denial-of-service, but it is a residual effect, not zero. And the proof depends on getting subtle details exactly right, since the paper itself breaks naive designs on the same specification. Within that scope the lessons are sharp and general: secure a system by proving safety against the worst-case adversary, not by patching the attacks you have seen; pair a cheap common-case action with a guaranteed-safe fallback trigger; and remember that extra machinery (a queue) can be the attack surface, so the most secure design is often the simplest one that still does the job.

Background

Prove the worst case, guard the common case, and cut the attack surface

This paper sits in the site’s hardware-security cluster and rhymes with several ideas covered elsewhere on this site. Its governing stance is to prove security against the STRONGEST adversary rather than patch observed patterns — the same prove-do-not-argue rigor the memory-timing-defense page brings when it formally verifies non-interference and the speculation- contract fuzzing page brings when it treats the defender’s model as something to adversarially check, and the direct answer to the recurring lesson across the site’s side-channel pages that a defense which only stops known attacks will be broken. Its structure pairs a cheap common-case action (the low ETH driving proactive refresh) with a guaranteed-safe fallback trigger (the high ATH raising an ALERT), the same optimize-the- common-case-with-a-safe-guard shape the microsecond-BFT page uses with its fast and slow paths, the datacenter-power page uses with a bounded risk budget and recovery buffers, and the approximate-query page uses with a cheap path backstopped by an exact one — safety in the fallback so the common case is cheap. Its most striking move is that less machinery is more secure: tracking one row beats a queue because the queue’s waiting window is the attack surface, the same shrink-the-attack-surface, simplicity-is- security discipline the memory-isolation and consensus pages apply when they minimize what must be trusted, and the same optimization-created-the- vulnerability caution the coherent-NIC page raises about caching. It also builds on exact per-row counters that cannot be thrashed, the complete- information answer to the overwhelm attack, echoing the measure-the-true- thing discipline elsewhere on the site. Together they make MOAT a case study in turning a new hardware mechanism into a provably secure defense by reasoning about the worst case, not the average one.

If you remember only three things

1. Rowhammer flips bits in DRAM rows adjacent to one that is repeatedly activated, letting an attacker corrupt memory they do not own and seize control, and it is worsening because the ROWHAMMER THRESHOLD (activations needed for a flip) has fallen from about 140,000 in 2014 toward a few hundred. Small in-DRAM trackers that watch for hammering keep getting overwhelmed by crafted patterns (TRRespass, Blacksmith), so DDR5 added PRAC (an exact per-row activation counter that cannot be thrashed) and ALERT-Back-Off (the DRAM can force the memory controller to pause for mitigation) — but the standard leaves the policy unspecified, and naive designs on it are still breakable.
2. MOAT is a provably secure defense on that substrate. Counterintuitively it tracks only ONE row per bank in 7 bytes, because a queue's window between noticing and mitigating a hammered row is itself the attack surface (their Jailbreak attack ages a queued entry to 9x the threshold). It uses two thresholds — a low ETH that gates cheap proactive victim refresh (saving energy on rarely-hammered rows) and a high ATH that raises the ALERT for a guaranteed reactive mitigation. It carries counts safely across refresh boundaries and derives a guaranteed-safe threshold by analyzing the worst-case adversary, also exposing new attacks (Ratchet, staggered-ALERT) that break naive PRAC designs.
3. MOAT defends a Rowhammer threshold as low as 99 (at ATH 64) with 0.28% slowdown, or 161 (at ATH 128) with essentially zero, in 7 bytes per bank and under 0.5% energy, because benign workloads run thousands of activations per ALERT versus tens for an attack. The transferable lessons: secure a system by proving safety against the worst-case adversary rather than patching the attacks you have seen; pair a cheap common-case action with a guaranteed-safe fallback trigger; exact counting beats a small tracker an attacker can overwhelm; and extra machinery (a queue) can be the attack surface, so the simplest sufficient design is often the most secure.

Check yourself

Check your understanding

1. Prior in-DRAM Rowhammer defenses like TRR were repeatedly broken, and MOAT argues the fix is not a cleverer tracker but a change in how security is argued. Predict what that change is.
2. MOAT tracks only ONE row per bank, while prior designs used a queue of many entries. Predict why fewer entries is MORE secure here.
3. MOAT uses two thresholds — a low ETH and a high ATH — rather than one. Predict the role of each and why two are better than one.
4. MOAT provably defends a low Rowhammer threshold, yet real programs slow down only about 0.28%. Predict why the overhead on benign software is so small.

Sources

MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters (arXiv:2407.09995) — ASPLOS 2025 (full text read via ar5iv).
Author PDF (Georgia Tech) — full paper.
ACM DL: MOAT (DOI 10.1145/3669940.3707278) — published version.