Randomized row-swap: mitigating Row Hammer by breaking spatial correlation between aggressor and victim rows

Every Row Hammer defense refreshed the victims and left the aggressor in place — so attackers learned to hammer around the defense. Randomized Row-Swap instead teleports the aggressor row to a random location every 800 activations, making the attack a years-long lottery.

Why this problem is worth solving

DRAM stores each bit as charge in a tiny capacitor, with cells arranged in rows. Reading data activates a whole row, and activation slightly disturbs the charge in physically adjacent rows. Do it fast enough, often enough — before the periodic 64-millisecond refresh restores everyone’s charge — and neighboring bits flip. That is Row Hammer: a software-only fault-injection attack, first demonstrated in 2014.

The security consequences are as bad as they sound. Bits are flipped in memory the attacker cannot address — including page tables, whose corruption yields kernel privileges, and other tenants’ data, which can be silently corrupted or even inferred (the flips are data-dependent). Process isolation, the foundation of multi-tenant computing, rests on DRAM not doing this.

The problem is worsening on a schedule. The Row Hammer threshold — how many activations an aggressor row needs to flip a neighbor’s bit — has collapsed as DRAM density grew: 139,000 in 2014-era DDR3, 22,400 in newer DDR3, 10,000 in newer DDR4, and 4,800 in 2020-era LPDDR4 — a 30× reduction in seven years. Every defense sized for yesterday’s threshold is undersized tomorrow. And a bank can perform 1.36 million activations in one 64-millisecond refresh window, so at a threshold of 4,800 an attacker has budget to hammer hundreds of rows per window.

What people did before, and where it broke

Hardware defenses share a two-part shape: a tracker identifies aggressor rows (probabilistically, like PARA, or with counters, like Graphene’s Misra-Gries tracker), and a mitigating action fires when a row’s count crosses a threshold. Before this paper, essentially every proposal used the same action: refresh the aggressor’s immediate neighbors — the presumed victims — restoring their charge before it degrades. The paper names this victim-focused mitigation, and identifies two structural weaknesses.

You must know who the victims are. DRAM vendors scramble the mapping from row addresses to physical row order, and do not publish it. A memory controller refreshing “address X+1” may be refreshing a row physically nowhere near X.

You must assume the blast radius. Victim refreshing protects exactly the rows it refreshes. In 2021, Google’s Half-Double attack showed the radius assumption fails: hammer a row heavily, and the defense dutifully refreshes — that is, activates — the immediate neighbors. Those mitigation-induced activations, plus the attacker’s, hammer the neighbor row, whose own neighbors (distance two from the original aggressor) start flipping — over a hundred bit flips in 64 ms on real LPDDR4, straight through every deployed and proposed victim-refresh defense. Extending refreshes to distance two just relocates the problem to distance three. The defense’s fundamental gift to the attacker: after mitigation, the aggressor row is still there, still next to the same victims, free to continue orchestrating — Half-Double needs 900,000 activations on one row in a window, and victim-focused defenses give it all the time it needs.

The idea

Break the spatial link, not the symptom

The insight is a re-framing: Row Hammer damage requires an aggressor to spend time next to its victims. Victim-focused defenses treat the symptom (drained charge) and leave the adjacency intact. Aggressor-focused mitigation attacks the adjacency itself: every time a row accumulates T_RRS = 800 activations, swap its contents with a randomly selected row in the same bank. The hammered address now lives somewhere new, next to different rows; the physical location it vacated keeps its accumulated disturbance but loses its tormentor. No neighborhood ever absorbs more than 800 activations’ worth of hammering from one row — far below the 4,800 needed to flip a bit — no matter what the access pattern is. Single-sided, double-sided, Half-Double, or patterns not yet invented: the defense makes no assumption about blast radius, and none about the vendor’s row mapping.

The two structures, and why they had to be rebuilt

The Hot-Row Tracker must catch every row crossing 800 activations — a probabilistic tracker would gamble security. The Misra-Gries algorithm (from Graphene) gives a guarantee: with 1.36 million activations possible per window, 1,700 counters provably suffice to flag every row at each multiple of 800. But Graphene’s implementation used content-addressable memory, which does not scale to 1,700 entries; the paper substitutes a two-way skewed-associative design that keeps single-cycle lookups and — crucially for security — never evicts an entry prematurously due to conflicts.

The Row-Indirection Table (RIT) records every swap as a pair ⟨X→Y, Y→X⟩ and is consulted on every memory access (a 4-cycle lookup) to route requests to rows’ current homes. Sizing is a security property, not a performance one: at most 1,700 swaps per window, up to two table entries each (re-swapping an already-swapped row chains to fresh destinations), so 3,400 tuples guarantee an attacker can never overflow the table and force a premature un-swap. Entries carry lock bits so nothing installed in the current window can be evicted before the window ends; old entries drain lazily rather than in a torrent.

The swap itself streams each 8 KB row through per-channel swap buffers: four row-sized transfers, about 1.46 microseconds, 2.9 with the un-swap an eviction may trigger. During a swap the channel is busy — which is fine, because benign workloads average just 68 swaps per 64 ms window (about 0.1 ms of channel time), while the destination randomness comes from a PRINCE-cipher PRNG at sub-2-nanosecond latency.

Security as a lottery the attacker cannot rig

After a swap, continuing to hammer the same address is useless — it now points at a fresh row with a fresh count. The attacker’s only play is to guess where the hot physical row went: hammer a random address 800 times (forcing a swap), hoping its physical location was already hot from an earlier swap — a birthday-paradox game over the bank’s 128K rows. The paper models this best-possible strategy with balls and buckets: reaching 4,800 activations on one physical row requires landing six swaps on it in one 64 ms window, and the expected time for that is 1.9 billion attack iterations — 3.8 years of continuous, optimal hammering. The knob is explicit: swap at 960 activations instead and security collapses to 6.9 days; swap at 685 and it stretches to 762 years. Attacking all 16 banks at once backfires — the swaps steal so much activation bandwidth that expected attack time rises to 5.1 years.

ACT(X): 1, 2, ..., 800  <- tracker flags X
damage to X’s neighbors so far: 1/6 of what a flip needs

Why it works

Because bit flips require an aggressor to accumulate thousands of activations next to the same victims, and RRS caps residence at 800 activations per neighborhood, damage can never reach the flip threshold anywhere — independent of the attack pattern, the blast radius, or the vendor’s secret row layout. → Because the tracker is deterministic (Misra-Gries with provably sufficient entries) and the indirection table is sized for the worst case with locked entries, there is no counter the attacker can evade and no table they can overflow. → Because swap destinations come from a cryptographic PRNG over 128K rows, relocating the attack becomes a birthday lottery whose expected jackpot — six swaps stacking on one physical row in one 64 ms window — takes 3.8 years of optimal play. → Because benign programs almost never cross 800 activations on a single row in 64 ms, the heavy machinery almost never engages: 0.4% average slowdown, 0.5% DRAM power overhead. → Therefore the defense inverts the economics that doomed victim refreshing: the attacker’s cleverness about where damage lands is worthless, because the defense never needed to know.

What it costs

• Every access pays a toll. The indirection lookup adds 4 cycles to every DRAM access, hammered or not — the price of not trusting any row’s address to be its location.
• SRAM in the controller. 42.9 KB per bank (686 KB per rank) for tracker, indirection table and swap buffers, plus 903 mW — modest, but scaling inversely with the Row Hammer threshold: if thresholds keep falling, the structures keep growing.
• Swaps block the channel. Each swap holds the memory channel ~1.5–2.9 microseconds (worst case 4.4). Benign workloads rarely trigger it, but a worst-case benign program (bzip2, gcc — working sets that just exceed the cache) pays ~5%.
• Security is probabilistic and time-bounded. 3.8 years is an expected value against the modeled optimal attacker, not a proof of impossibility — the paper is explicit that a lower swap threshold buys more margin at higher cost.
• The threat model has edges. An attacker with physical access, or one who can learn the DRAM address mapping and swap history, is out of scope; so is data leakage through the swap timing itself (lookups are constant- time by design).

The evaluation

Simulation on USIMM (the Memory Scheduling Championship simulator) with an 8-core out-of-order system, DDR4-3200, 2 channels, 16 banks of 128K rows; 78 workloads spanning SPEC2006, SPEC2017, GAP, BIOBENCH, PARSEC and commercial traces, run to 1 billion instructions per core.