Target Row Refresh

Target row refresh is the JEDEC-defined mitigation DDR4/DDR5 DRAM uses to stop row-hammer bit flips before they happen, by having the DRAM itself count how many times each row is accessed and proactively refresh the physical rows next to any row that gets hammered. At a high level, the defense loop looks like this:

Aggressor row activated
Repeated ACT/PRE cycles
Per-row activation counter
Tracked in DRAM, not the controller
Counter crosses threshold (MAC)Maximum Activate Count — typically tens of thousands
Identify adjacent victim rows
Physical row ± 1 (and ± 2 on some parts)
Issue extra refresh
Steals a cycle from normal tREFI window
Victim charge restored
Before leakage + disturb flips a bit

A few things are worth knowing about why this had to be built into the DRAM itself rather than left to the memory controller:

Row hammer is a physical disturb effect, not a software bug. Hammering one DRAM row with activate/precharge cycles tens of thousands of times couples enough electrical disturbance into the physically adjacent rows' capacitors that their stored charge drifts, and a bit that would have survived until its next scheduled refresh flips early. Because the failure is about physical row adjacency on the silicon, not logical address adjacency, only the DRAM die itself — which knows true physical layout — can reliably identify which rows are actually at risk; a memory controller working in logical addresses cannot.

Target Row Refresh: Protecting the Neighbors hammering one row disturbs the physically adjacent rows, not logically adjacent addresses row N-1 (victim) row N (aggressor — hammered) row N+1 (victim) electrical disturb electrical disturb per-row activation counter in DRAM threshold = MAC Target Row Refresh fires refreshes row N-1 and row N+1 before the next scheduled cycle cost: steals refresh bandwidth from tREFI — too aggressive a threshold hurts performance, too loose leaves a security gap

The counter threshold is a security-versus-performance dial, not a fixed constant. JEDEC's Maximum Activate Count (MAC) sets how many activations a row can tolerate before its neighbors must be refreshed — set it too high and an attacker has more room to flip bits before the defense engages; set it too low and legitimate high-locality workloads trigger extra refreshes that steal bandwidth from the normal tREFI refresh schedule, hurting throughput and tail latency. That same tension is why row-hammer defense has kept evolving generation to generation — DDR5 lowered the practical MAC and added per-bank refresh management (RFM) specifically because DDR4's original TRR thresholds were shown to be bypassable by patterns that hammered just below the counter's trigger point.

It only works because DRAM already has a refresh mechanism to borrow from. Every DRAM row must be refreshed periodically anyway to replace leaking capacitor charge — target row refresh doesn't invent a new circuit, it repurposes that existing refresh pathway and schedules extra cycles against suspect rows ahead of their normal turn. That reuse is also its limitation: the defense can only ever be as fast as the refresh bandwidth already provisioned in the part, so hammering fast enough to outrun the extra refresh cycles' bandwidth remains the open attack surface each new JEDEC revision tries to close.

Read target row refresh as DRAM defending itself with the only tool it already has — refresh bandwidth — against an attack that exploits the same physical charge-leakage sensitivity refresh exists to fix in the first place: every generation's fix is really a retuning of how early and how often that existing mechanism fires, not a new kind of circuit.

Take target row refresh 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