RowArmor: Efficient and Comprehensive Protection Against DRAM Disturbance Attacks

Minbok Wi, Yoonyul Yoo, Yoojin Kim, Jaeho Shin, Jumin Kim, Yesin Ryu and 3 others

As DRAM chips shrink, repeatedly poking one row of memory can silently flip bits in its neighbors — the RowHammer family of attacks — and the usual defenses try to prevent every flip by watching activations and firing extra refreshes, which is slow and can itself be abused to freeze the memory; this work from Seoul National University and Sungkyunkwan takes the opposite stance with RowArmor, letting the rare disturbance errors happen and correcting them as they occur with stronger error-correcting codes plus address scrambling, defending against both silent corruption and denial-of-service at a reported overhead of under 1 percent.

The argument in one glance

Problem

Poking one DRAM row silently flips bits in its neighbors

As DRAM shrinks, repeatedly activating one row leaks charge from adjacent rows and flips their bits — the RowHammer family of disturbance attacks. This corrupts data the attacker cannot legitimately touch and can be used for privilege escalation or denial-of-service.
What people did

Prevent every flip by monitoring and extra refreshes

Track how often each row is activated and, when a row is hammered too much, issue extra refreshes to its vulnerable neighbors before a bit can flip, stopping the error before it happens.
Why it fell short

Prevention is costly and can itself be abused

The monitoring and the extra refreshes impose substantial performance overhead, and the mitigation can be weaponized: an attacker who keeps provoking the defense into refreshing can stall memory and cause the very denial-of-service it was meant to prevent. Newer patterns like RowPress can also slip past pattern-specific defenses.
This paper's idea

Let errors happen and correct them reactively (RowArmor)

RowArmor, according to its abstract, flips the strategy: instead of preventing every disturbance, it corrects the rare errors as they occur using enhanced error-correcting codes and address scrambling. This avoids the high cost of prevention while covering diverse patterns including RowPress, and defends against both data corruption and denial-of-service at a reported overhead of up to 0.7 percent.

Why this problem is worth solving

RowHammer turned a physics side effect into a security problem, and shrinking process technology keeps making it worse.

DRAM stores each bit as a small amount of electric charge in a capacitor, arranged in a grid of rows and columns; because the charge leaks away over time, the memory periodically refreshes every row to top it up. To read or write, the memory controller activates a row, and here is the vulnerability: activating a row disturbs its physical neighbors slightly, and as cells have shrunk and rows have been packed closer together, that disturbance has grown strong enough to matter. In a RowHammer attack, an adversary repeatedly activates one row — the aggressor — thousands of times between refreshes, and the accumulated disturbance leaks enough charge from the adjacent victim rows to flip some of their bits. The attacker never had permission to write those victim rows, yet can now silently change their contents, which has been used to corrupt page tables and escalate privilege, tamper with data, or simply crash the system. Because the effect comes from the physical layout of the chip, it is a hardware-level threat that ordinary software protections do not see.

The defenses that exist mostly try to prevent flips before they happen, and that stance has two weaknesses the paper targets.

The dominant approach is preventive: the memory system watches how many times each row is activated, and when a row’s count crosses a threshold that suggests hammering, it proactively issues extra refreshes to the endangered neighbor rows so their charge is restored before a bit can flip. This works, but it has costs. Tracking activation counts for many rows requires hardware and effort, and the extra refreshes steal memory bandwidth and time from real work, which is why preventive schemes often carry a noticeable performance overhead. More subtly, the mitigation can be turned into a weapon. An attacker who deliberately hammers rows can force the defense to fire its expensive extra refreshes over and over, saturating the memory with defensive activity and stalling legitimate access — producing a denial-of-service through the defense itself. On top of this, the disturbance threat is not a single fixed pattern: variants such as RowPress induce flips by keeping a row open for a long time rather than by many quick activations, so a mechanism narrowly tuned to classic hammering can miss them. A comprehensive, low-cost, hard-to-abuse defense is what the field still needs.

What people did before, and where it broke

Count activations and add targeted refreshes. Monitor per-row activation counts and refresh a hammered row’s neighbors before they can flip. Where it broke. The counting hardware and the extra refreshes impose substantial performance overhead, especially as thresholds must be set aggressively low on newer, more vulnerable chips.
Rely on standard memory error-correcting codes. Trust the ordinary error correction that servers already apply to memory to catch stray bit flips. Where it broke. Standard codes are sized for random, occasional errors, not for an adversary who can concentrate many correlated flips in one place, which can overwhelm them.
Randomize where rows physically live. Remap addresses so an attacker cannot easily learn which rows are neighbors and target them. Where it broke. Randomization raises the bar but, on its own, does not correct the flips that still occur, and clever attackers can still probe the layout.
Tune a defense to the known hammering pattern. Build mitigation around the classic many-activations RowHammer behavior. Where it broke. Newer disturbance patterns like RowPress use a different access behavior, so a defense specialized to one pattern does not comprehensively cover the family, and few preventive schemes address the denial-of-service angle at all.
The gap. No single mechanism cheaply covered the whole disturbance family, stopped both silent corruption and denial-of-service, and avoided being exploitable as a weapon. Providing that, by correcting errors reactively rather than preventing them, is what RowArmor sets out to do.

How RowArmor works

From preventing every flip to correcting the rare ones

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Correct the rare errors instead of preventing every one. RowArmor’s central choice, as described in its abstract, is to be reactive rather than preventive: disturbance flips are rare events, so instead of paying a constant tax to stop every possible flip through monitoring and extra refreshes, RowArmor lets them occur and corrects them when they do, using enhanced error-correcting codes. This trades a small, occasional correction cost for the elimination of a large, always-on prevention cost. Choosing to detect and repair the occasional fault as it happens, rather than spending continuously to guarantee it never happens, is the same move the silent-data-corruption work covered elsewhere on this site makes, accepting that faults will slip through and building a mechanism to catch and correct the corrupted values in flight so correctness is preserved without a prohibitively expensive guarantee against every error.

Scramble the addresses so an attacker cannot aim. A disturbance attack depends on the attacker knowing which physical rows are neighbors, so it can hammer precisely and concentrate its induced flips. RowArmor uses address scrambling to break that knowledge, remapping where data physically sits so the adversary cannot reliably target specific victim bits and cannot pile many correlated errors into one place where they might exceed what the code can fix. Randomizing the mapping between what software names and where the hardware actually stores it, so an attacker loses the predictable structure a physical attack relies on, is the same design the randomized RowHammer-mitigation work covered elsewhere on this site is built on, scrambling the layout to sever the link between an attacker’s chosen address and the physical cells they hope to disturb.

Defend against denial-of-service, not just corruption. The paper emphasizes that its scope is comprehensive: it addresses both silent data corruption and denial-of-service, whereas preventive counters can be provoked into a denial-of-service of their own. Because RowArmor corrects errors reactively rather than firing costly defensive refreshes whenever a row looks hammered, an attacker cannot turn the defense into a memory-stalling weapon, so the mitigation closes the very hole that activation-counting schemes can open. Taking care that a security mechanism does not itself become an exploitable cost, and reasoning about how an adversary might abuse the defense rather than only the original weakness, stands in deliberate contrast to the per-row-activation-counter work covered elsewhere on this site, whose counting-and-refresh strategy is exactly the preventive style RowArmor argues can be weaponized into the denial-of-service it instead sets out to prevent.

Following a disturbance attack against RowArmor

What happens when an attacker hammers memory protected by RowArmor

A conceptual trace based on the paper's abstract and standard RowHammer background; specific internal parameters were not available.

Step 1 of 5

The attacker hammers a row

An adversary repeatedly activates an aggressor row (classic RowHammer), or holds a row open for a long time (RowPress), trying to leak enough charge from neighboring rows to flip their bits and corrupt data they cannot legitimately write.

The disturbance comes from the physical proximity of shrinking cells.

Why it works

Disturbance flips are rare enough to correct. Because successful bit flips are occasional events rather than constant ones → the cost of correcting them when they happen is small → so a reactive correction can be far cheaper than always-on prevention.
Scrambling denies the attacker precision. Because a disturbance attack needs to know which physical rows are neighbors → scrambling the address mapping hides that structure → so errors cannot be concentrated on a chosen victim or piled up beyond what correction handles.
Stronger codes handle adversarial errors. Because standard memory ECC is sized for random, sparse faults → enhancing the codes raises how many correlated flips can be corrected → so deliberately induced disturbance errors are caught rather than slipping through.
Reacting to errors is pattern-agnostic. Because RowArmor responds to the errors themselves, not to a specific access signature → it does not need a separate rule for each hammering style → so it covers diverse patterns including RowPress.
No defensive refresh storm to exploit. Because RowArmor corrects rather than firing extra refreshes whenever a row looks hammered → an attacker cannot provoke a flood of defensive activity → so the mitigation itself cannot be turned into a denial-of-service.

What it costs (trade-offs and scope)

This explainer is based on the abstract, not the full paper. The full text was not openly available at the time of writing, so the specific design details — the exact error-correcting scheme, the scrambling algorithm, the threat model assumptions, and the evaluation methodology — are not reflected here beyond what the abstract states. Treat the mechanism description as the abstract’s high-level claims plus standard background.
Reactive correction accepts that errors occur. By design RowArmor allows disturbance flips to happen and relies on correcting them. If an attack could induce more correlated errors in one place than the enhanced codes can correct, correctness would depend on whether scrambling and the code strength keep that from happening — the balance the paper must establish and that the abstract asserts it achieves.
Enhanced ECC has its own cost. Stronger error-correcting codes require additional redundant storage and correction logic. The reported up-to-0.7-percent performance overhead is the headline figure, but the storage and area costs of the codes are part of the trade the full paper would detail.
The 0.7 percent figure is a single reported number. The abstract gives a negligible performance overhead of up to 0.7 percent; without the paper, the workloads, baseline, and conditions behind that number are not available here, so it should be read as the authors’ summary claim.
It targets the DRAM disturbance family. RowArmor addresses RowHammer, RowPress, and related disturbance attacks. It is a memory-integrity and availability defense, not a general fix for unrelated hardware side channels or software vulnerabilities.
Hardware support is implied. Error correction, address scrambling, and their integration into the memory system are hardware mechanisms; deploying RowArmor implies changes to the memory controller or DRAM subsystem rather than a software-only patch.

The evaluation

Two stances against DRAM disturbance attacks

Property	Preventive (counters and refresh)	Standard ECC alone
Basic strategy
Performance overhead
Denial-of-service		Not addressed
Covers RowPress and variants	Pattern-specific, may miss	Only if errors are sparse
Resists concentrated errors	Prevents by refreshing

Two stances against DRAM disturbance attacks, as framed by the RowArmor abstract (the full paper was not openly available, so the comparison reflects the abstract's claims and standard background rather than the paper's detailed evaluation). Preventive defenses count row activations and issue extra refreshes to stop bit flips before they occur; they work but impose substantial performance overhead and can be provoked into a denial-of-service by an attacker who forces constant defensive refreshes. Standard memory error-correcting codes catch occasional random flips but are sized for sparse faults and can be overwhelmed by an adversary concentrating many correlated errors, and they do not address denial-of-service. RowArmor takes a reactive stance: it lets the rare disturbance errors happen and corrects them as they occur using enhanced error-correcting codes, while address scrambling prevents an attacker from reliably targeting or concentrating errors. According to the abstract this covers diverse patterns including RowPress, defends against both data corruption and denial-of-service, and does so at a negligible performance overhead of up to 0.7 percent, avoiding the high cost of preventive methods.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s abstract, because the full text was not openly accessible when it was written, so read it as a faithful account of the abstract’s claims plus standard, well-established background on RowHammer, RowPress, DRAM refresh, and error-correcting codes — not as a report of the paper’s detailed mechanism or evaluation. With that caveat, the idea is clear and appealing. DRAM disturbance attacks like RowHammer exploit a physical side effect that shrinking process technology keeps worsening: repeatedly activating one row leaks charge from its neighbors and flips their bits, letting an attacker corrupt data they cannot legitimately touch, escalate privilege, or crash the machine, and newer variants such as RowPress reach the same end through a different access pattern. The dominant defenses are preventive — count activations, refresh endangered rows before a flip — but the abstract argues they cost too much and can be turned into a denial-of-service, since an attacker who keeps provoking the defense forces it to flood the memory with expensive refreshes. RowArmor inverts the strategy: rather than prevent every flip, it lets the rare errors happen and corrects them reactively with enhanced error-correcting codes, while address scrambling stops an attacker from precisely targeting or concentrating the errors. The abstract claims this covers both data corruption and denial-of-service, handles diverse patterns including RowPress, and costs a negligible up-to-0.7-percent performance overhead. What is not available here is exactly how strong the codes are, how the scrambling works, what threat model and error rates are assumed, and how the 0.7-percent figure was measured — all the specifics that would let one judge whether the reactive stance holds against a determined adversary who tries to induce more correlated errors than the code can correct. The durable idea worth taking away, even from the abstract alone, is that prevention is not the only stance against a hardware fault: when the fault is rare, correcting it reactively can be both cheaper and harder to weaponize than trying to forbid it outright.

Background

Why RowHammer defenses keep having to be rethought

It helps to see RowArmor within an ongoing arms race between DRAM disturbance attacks and their defenses. Since RowHammer was first shown to flip bits through mere memory access patterns, each generation of denser DRAM has lowered the number of activations needed to induce a flip, and researchers have kept finding new attack shapes that evade the previous defense. The row-coupling attack work covered elsewhere on this site reflects exactly this pressure, demonstrating a disturbance mechanism that exploits how rows interact in ways a defense built for classic hammering may not anticipate, which is precisely why a defense that reacts to the errors themselves rather than to a specific access signature is attractive. The common thread is that DRAM disturbance is a moving target driven by physics and manufacturing, so any defense pinned to today’s known attack pattern risks being outflanked by tomorrow’s, while the cost of preventive schemes climbs as thresholds must be set ever lower. RowArmor’s reactive, correction-based philosophy is one response to that dynamic, betting that catching and fixing the errors is more robust and cheaper than chasing every new way to prevent them. As DRAM continues to scale and new disturbance variants keep appearing, the tension this work sits within — between preventing faults and correcting them, and between defenses and the attacks that turn those defenses into weapons — is likely to keep shaping how memory systems are hardened.

If you remember only three things

1. DRAM stores bits as charge in tiny cells, and as process technology shrinks and rows pack closer, repeatedly activating one row (RowHammer) or holding it open (RowPress) leaks charge from neighboring rows and flips their bits, letting an attacker silently corrupt data they cannot legitimately write, escalate privilege, or cause a denial-of-service. The prevailing defenses are preventive: they count how often rows are activated and issue extra refreshes to endangered neighbors before a flip can occur. But this monitoring and the extra refreshes impose substantial performance overhead, they can be pattern-specific and miss newer variants like RowPress, and crucially they can be weaponized — an attacker who keeps provoking the defense forces it to refresh constantly and stalls the memory, causing the very denial-of-service it was meant to prevent.
2. RowArmor, according to its abstract, inverts the strategy from preventive to reactive: instead of trying to stop every disturbance flip, it lets the rare errors occur and corrects them as they happen, using enhanced error-correcting codes (stronger than standard memory ECC) together with address scrambling. The scrambling remaps where data physically sits so an attacker cannot reliably target which bits are adjacent or concentrate many correlated errors in one place, and the enhanced codes detect and fix the flips that do occur before they reach software. Because the defense reacts to the errors themselves rather than to a specific access pattern, the abstract states it covers diverse attack patterns including RowPress, and because it corrects rather than firing expensive defensive refreshes, it does not give an attacker a refresh storm to exploit — so it defends against both data corruption and denial-of-service.
3. The abstract reports that RowArmor defends against both data corruption and denial-of-service attacks at a negligible performance overhead of up to 0.7 percent, avoiding the high costs of preventive methods. Important caveat: this explainer is based on the abstract because the full paper was not openly available, so the specific error-correcting scheme, the scrambling algorithm, the threat model and assumed error rates, and how the 0.7-percent figure was measured are not reflected here. The durable idea, clear even from the abstract, is that prevention is not the only stance against a hardware fault: when disturbance flips are rare, correcting them reactively can be both cheaper and harder to turn into a weapon than trying to forbid every flip, which is a promising direction as denser DRAM makes disturbance attacks steadily easier to mount.

Check yourself

Check your understanding

1. What is a DRAM disturbance attack like RowHammer?
2. Why does the paper argue that preventive RowHammer defenses are problematic?
3. What is RowArmor's core strategy, according to its abstract?
4. What should you keep in mind about the evidence behind this explainer and RowArmor's reported result?

Sources

The paper is “RowArmor: Efficient and Comprehensive Protection Against DRAM Disturbance Attacks” by Minbok Wi, Yoonyul Yoo, Yoojin Kim, Jaeho Shin, Jumin Kim, Yesin Ryu, Saeid Gorgin, Jung Ho Ahn, and Jungrae Kim, published at ASPLOS 2026, DOI 10.1145/3779212.3790213. The authors are affiliated with Seoul National University and Sungkyunkwan University.

This explainer is based on the paper’s abstract (Creative Commons Attribution / CC-BY, as indicated by the publisher’s open-access metadata). The full text was not openly accessible at the time of writing — the ACM Digital Library copy was gated, there was no arXiv or author preprint available, and the Semantic Scholar, OpenAlex, and Unpaywall records pointed only to the gated version — so this page reflects the abstract’s stated claims (that RowArmor is a reactive defense correcting disturbance errors via address scrambling and enhanced error-correcting codes, that it addresses both data corruption and denial-of-service and diverse patterns including RowPress, and that it reports a negligible performance overhead of up to 0.7 percent) together with standard, well-established background on RowHammer, RowPress, DRAM organization and refresh, and error-correcting codes, provided to make the abstract’s contribution understandable. The specific design internals, threat model, and evaluation methodology are not reflected here beyond what the abstract states, and the mechanism descriptions in the flow and step-through sections are conceptual readings of the abstract plus standard background rather than details drawn from the full paper. This page is marked as a draft for that reason and should be confirmed against the full paper when it becomes available.