DRAM Row Hammer

# DRAM Row Hammer: Disturbance Architecture, the Activation-Threshold Theory, and Target Row Refresh Application

Row hammer is what happens when the same electrical margins this project has spent five keywords tracing get attacked on purpose instead of just leaking passively. Repeatedly opening and closing one DRAM row — thousands of times, far faster than any real workload would — injects enough electrical disturbance into the rows physically next to it that their storage capacitors lose charge faster than normal retention leakage ever would, flipping bits in cells that were never directly read or written at all. It was first demonstrated as a real exploit in 2014, and every DRAM generation since has had to treat it as a first-class reliability requirement, not a lab curiosity.

One Row Hammered, Two Neighbors Pay the Price repeatedly opening and closing one row injects disturbance into the rows physically beside it ACT → PRE → ACT → PRE … tens of thousands of times within one refresh window WL — victim row WL — aggressor row WL — victim row C_s C_s leaks faster than t_REFW assumes neither victim's own word line ever switches — the disturbance arrives purely from being next door the same field-crowding and coupling paths covered in the STI and buried-word-line articles are what carries the disturbance — row hammer doesn't open a new physical weakness, it just exploits the existing one far faster than any natural leakage process ever would on its own

Whether a victim cell actually flips comes down to a charge budget, the same one this entire series has been tracking. Every aggressor activation drains a small, roughly fixed amount of extra charge from each neighboring cell; once the accumulated disturbance plus ordinary leakage exceeds the margin the sense amplifier needs, the bit is gone before the next scheduled refresh ever arrives to save it. That gives a clean activation-count threshold:

$$ N_{th} \approx \frac{Q_{margin}}{q_{dist}} $$

where $Q_{margin}$ is exactly the surviving charge budget from $Q = C_s V_{cell}$ after everything else this series has covered, and $q_{dist}$ is the disturbance charge lost per activation. Because $Q_{margin}$ only shrinks as the storage capacitor scales down, $N_{th}$ has fallen by more than an order of magnitude across DRAM generations — attacks that needed hundreds of thousands of activations in 2014 need only a few thousand on recent parts.

The Activation Threshold Keeps Falling, Generation to Generation a smaller charge margin means fewer hammer activations are needed to cross it aggressor activations within one refresh window → victim bit-flip probability → older, larger C_s — threshold near 450k newer, scaled C_s — threshold near 10k N_th ≈ Q_margin / q_dist — the same shrinking Q_margin from every earlier keyword in this series this is why mitigations had to move from "wait and hope" to actively tracking activation counts in real time

That falling threshold is exactly why a passive, fixed-schedule refresh controller stops being enough. The controller covered in the previous keyword guarantees every row gets refreshed within $t_{REFW}$, but it has no idea which rows are being hammered right now — so the industry's fix, Target Row Refresh (TRR), bolts an activation tracker directly onto the same command arbiter, watching per-row activation counts and injecting an out-of-schedule refresh of a row's physical neighbors the moment that count gets dangerously close to $N_{th}$, well before the normal schedule would ever have reached them.

Target Row Refresh — Watching Activation Counts in Real Time the same arbiter from the refresh controller, now fed by a counter that watches every ACT tREFI timer normal schedule activation tracker per-row ACT counts, watches against N_th REF command generator neighbor-row refresh, out of schedule pending R/W commands command arbiter the arbiter now has two refresh sources instead of one — the slow, guaranteed schedule from t_REFI, and a fast, targeted interrupt the moment any single row's activation count looks dangerous neither replaces the other — TRR only has to win the race for the specific rows actually under attack

That targeted-interrupt design is a direct, structural extension of the refresh controller, not a separate subsystem bolted on afterward. Every later-generation defense — DDR5's per-row activation counting (PRAC) and the refresh-management (RFM) commands that let the memory controller trigger extra refresh cycles on demand — is the same idea pushed earlier and faster: stop assuming leakage is always passive, and start treating any row's activation count as a signal the refresh scheduler has to react to immediately, not just a statistic to average over the whole refresh window.

Read row hammer through a *disturbance-is-leakage-on-a-deadline* lens rather than a *"memory hacking trick"* lens: it uses the exact same $Q = C_s V_{cell}$ charge budget, the same STI and word-line coupling paths, and the same $\Delta V(t) = \Delta V(0)e^{t/\tau}$ sensing margin this series has traced from the storage capacitor all the way to the sense amplifier — the only thing row hammer changes is the clock. Every other keyword here was about a leak measured in milliseconds; this one is the same leak measured in microseconds, which is exactly fast enough to outrun a refresh controller that was only ever designed to race against nature, not against an adversary.

Take DRAM row hammer further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app