Home · ASPLOS 2024 · Datacenter, Cloud & Networking

TAROT: A CXL SmartNIC-Based Defense Against Multi-bit Errors by Row-Hammer Attacks

Chihun Song, Michael Jaemin Kim, Tianchen Wang, Houxiang Ji, Jinghan Huang, Ipoom Jeong and 5 others

Conference
ASPLOS 2024
Published
2024
Pages
981-998
Citations
9

Rowhammer flips memory bits by repeatedly reading nearby rows, and server memory already corrects a single flipped bit — the crash only comes when two bits in the same word go at once; this paper (Illinois and Seoul National) hammered seventeen memory modules for three weeks and found the addresses where that can actually happen number in the single digits per module, because the vulnerable cells are fixed manufacturing defects, so the defence becomes a 130-line kernel module that touches just those addresses — and then hands the job to the idle processor cores sitting on a network card.

The argument in one glance

  1. Problem

    Reading memory in one place corrupts it in another

    Repeatedly activating a row of memory electrically disturbs the rows beside it and flips their bits. An attacker who can only write to their own memory can therefore corrupt memory they do not own, and the number of activations needed has fallen sharply across memory generations.

  2. What people did

    Watch every row, or refresh everything more often

    Hardware defences count activations per row and act when a count gets high. System defences double the refresh rate or lean on error-correcting codes. Software defences monitor cache misses to spot hammering as it happens.

  3. Why it fell short

    All of them treat every address as equally at risk

    That uniformity is what makes them expensive: counters in every bank, refresh bandwidth doubled, or processor cycles spent sampling counters constantly. One measured software defence costs 8.3 percent of throughput. And the in-memory hardware schemes have repeatedly been broken by more sophisticated hammering patterns.

  4. This paper's idea

    Very few addresses can actually produce a crash, and they never move

    The vulnerable cells come from manufacturing defects fixed at fabrication. An uncorrectable error needs two weak cells in the same word, which is rare. Three weeks of hammering seventeen modules found single-digit numbers of such addresses per module — so touch exactly those, and let a network card do it.

Why this problem is worth solving

The mechanism is a physical defect story rather than a probabilistic one.

Repeatedly activating a row of memory disturbs its neighbours and flips their bits. What matters here is why particular cells flip and others do not. Two device-level effects are responsible: parasitic coupling between the aggressor’s wordline and the victim’s access transistors, whose strength depends on the physical distance between them, and interface traps, which are atomic-level defects inside those transistors. Both come from manufacturing process variation. Both affect only specific cells. And crucially, neither changes over time — so the set of vulnerable addresses is a fixed property of an individual chip, different from every other chip, and knowable in advance.
is therefore a defect map, not a lottery.

The distinction that shrinks the problem is an arithmetic one.

Server memory stores 72 bits for every 64 bits of data, enough to correct any single flipped bit and detect any two. So one flipped bit is a non-event, silently repaired. Two or more flipped bits in the same 64-bit word cannot be corrected, and the machine crashes. That threshold is what makes the target set small: a word only becomes dangerous if it happens to contain at least two of the rare defective cells, and the chance of two landing together is far lower than the chance of one landing anywhere. Defences that protect against any flip at all are therefore working much harder than the failure mode requires.
is the asymmetry the whole design rests on.

What people did before, and where it broke

  • Count activations in hardware and act on the hot rows. The manufacturers’ own approach, and the subject of a large research literature. Where it broke. Two ways. It costs real silicon — published designs need kilobytes of tracking memory per bank — and the proprietary in-memory versions shipped in older generations have repeatedly been broken by sophisticated many-sided hammering patterns.
  • Double the refresh rate. The immediate response after the vulnerability was disclosed, and trivially deployable. Where it broke. It halves the time available for real memory traffic, costing 2.5 percent on throughput benchmarks here and more on memory-intensive ones, and it still does not fully protect the system.
  • Monitor cache misses and refresh the victims you infer. A software defence that samples performance counters, spots hammering, and refreshes the neighbours. Where it broke. The sampling is expensive. Measured across many cores, where each core must read its own counter and one core must aggregate them, it costs 8.3 percent of throughput — and it is sampling-based, so it occasionally misses victims entirely.
  • Detect the reconnaissance phase and move the pages. Another software defence, which notices the correctable errors an attacker generates while mapping out a chip and migrates those pages elsewhere. Where it broke. It only stops that one phase, and it cannot protect rows holding pages the system is unable to move.
  • Strengthen the error-correcting code. Adding authentication to the parity can turn arbitrary flips into detected failures. Where it broke. Detecting is not preventing. The system still has to do something drastic, like reboot, and the strengthening costs either correction power or performance.
  • Just stop using the vulnerable rows. The obvious response once you know where they are. Where it broke. The paper simulates it: removing 8,000 random rows from a 128-gigabyte system cuts the number of available 2-megabyte huge pages by 12 percent and eliminates 1-gigabyte huge pages entirely — and that is the best case, measured on a freshly booted machine before any fragmentation.
  • The gap. Every one of these treats all addresses as equally at risk, which is what forces the cost to be paid everywhere. Nobody had measured how few addresses can actually produce the failure that matters, or built a defence that only visits those.

How a defect map becomes a defence

From protecting all of memory to protecting a handful of addresses

  1. new

  2. new

  3. new

  4. new

  5. new

Seventeen DDR4 modules hammered for three weeks, plus performance evaluation on a dual-socket Xeon server against three prior defences, with a network card standing in for hardware that does not yet exist.

The idea

Permanence is what makes the threat tractable. The usual mental model of rowhammer is statistical — hammer enough and something somewhere will flip. The device physics says otherwise. Parasitic coupling depends on the physical distance between an aggressor’s wordline and a victim’s access transistors, and that distance is set by process variation at fabrication. Interface traps are atomic-level defects in specific transistors. Neither drifts. So the weak cells are a permanent, chip-specific defect map, and the measurements bear this out sharply: 99.99 percent of bits in one module never flipped in three weeks, the most-flipped tenth of the bits that did flip went at least 332 times while the least-flipped tenth went at most 9, and one chip in a module accounted for 28.3 percent of all flips while six of sixteen chips in another produced none at all. That a fault’s permanence is precisely the property making it manageable, rather than the property making it terrifying, is the same inversion the low-voltage drone work covered elsewhere on this site turns on, where errors that recur identically are the ones a learning process can absorb.

A network card cannot refresh a row it cannot reach, and over PCIe it often cannot. This is the subtle failure the paper’s headline design exists to fix. If the dangerous address happens to be sitting in the host processor’s cache, a conventional card’s read is answered by that cache and never becomes a memory activation — so the refresh silently does not happen. Worse, the attacker’s hammering of nearby uncached rows still damages that victim row perfectly well. The defence therefore fails in exactly the circumstances where it is being relied upon, and a conventional card has no way to flush a host cache line to force the issue. What fixes it is joining the host’s coherence domain, which lets the device issue cache-line flushes to host memory the way a processor core does. Discovering that the interesting capability of a coherent interconnect is not raw bandwidth but the ability to participate in host cache operations is the same finding the cache-coherent network interface work covered elsewhere on this site arrives at from the performance side.

The work is a periodic tax, and taxes should be paid by whoever is idle. Flushing and reading a few thousand scattered addresses every 8 milliseconds is not much computation, but it is disruptive in a specific way: it arrives as a burst of cache flushes and random memory reads, which is close to worst-case interference for a latency-sensitive service. On a 128-gigabyte machine that costs a database 28.2 percent of its tail latency, and at 512 gigabytes the tail latency more than doubles again. Meanwhile network cards in these servers already carry general-purpose processors, and the paper measures that saturating the card’s regular-expression accelerator at around 50 gigabits per second uses at most five of its eight cores. Three sit idle. Moving the chore there takes the host cost to 0.1 percent of throughput and 1.0 percent of tail latency. Finding an underused processor already inside the machine and giving it the recurring background work is the same manoeuvre the recommendation-training work covered elsewhere on this site makes with leftover accelerator capacity.

Following one dangerous address

From a fabrication defect to a row that gets refreshed

The list is small enough that the whole cycle costs a few thousand memory operations every 8 milliseconds.

Step 1 of 5

A defect exists before the chip ever ships

Process variation leaves a cell with unusually strong coupling to a neighbouring wordline, or with interface traps in its access transistor. It will lose charge under hammering; the cell beside it will not. Nothing about this changes over the life of the part.

Because the cause is physical variation, the map differs not just between modules but between chips in one module and banks within one chip. Measured differences run to 3.4 times between chips and 2.3 times between banks in the same chip.

Why it works

  • Two defects must coincide, and that is much rarer than one. The error-correcting code silently repairs any single flipped bit → a crash needs two flips in the same 64-bit word → so the dangerous set is not the set of weak cells but the set of words containing two of them, which measurement puts at under a tenth of a percent of rows.
  • A fixed defect map can be discovered once and reused forever. Coupling distance and interface traps are set at fabrication and do not drift → so the vulnerable addresses of a specific chip are a stable property, unlike a threat that moves → which is what makes a precomputed list written into the module viable at all.
  • The flush is what turns a read into a refresh. Reading an address that is already cached never touches memory → so a defence that merely reads its list would silently do nothing for exactly the addresses most likely to be in use → issuing a cache-line flush first guarantees the load reaches memory and activates the row.
  • Targeting beats sampling on both cost and coverage. A monitor that samples cache misses spends processor cycles constantly and can still miss a victim → visiting a known list spends cycles proportional to the list and cannot miss → measured at an 8 millisecond period the targeted version produced no errors while the sampling one still failed occasionally at 6 milliseconds, at a fifth of the throughput cost.
  • The disruption is about interference, not about total work. The chore is only a few thousand memory operations → but they arrive as a burst of flushes and random reads that is close to worst-case interference for a latency-sensitive service → so moving the same work to idle cores elsewhere in the machine removes 28.2 percent of tail latency without changing what is being done.

What it costs (trade-offs and scope)

  • The central hardware does not exist, and the emulation is loose. No coherent-interconnect network card is available, so the evaluation uses the second socket of a dual-socket server, downclocked to 1.2 gigahertz with a conventional network card attached, as a stand-in. The actual network card was used only to measure how many of its cores the accelerators need, and to check that its processor performs comparably to the downclocked Xeon on one benchmark.
  • The measurement arguably undercuts the premise. Every module manufactured between 2019 and 2023 produced no uncorrectable errors at all in three weeks. The dangerous addresses the defence is built around — 13, 5 and 5 — all come from 2016-era modules. Eight of the seventeen modules produced no bit flips whatsoever, and most modules had to have their refresh rate halved before they would flip anything.
  • Security depends on a list staying secret. The threat model assumes an attacker cannot read the vulnerable addresses from the module identification chip. If they can, they know precisely where to hammer, and the small target set becomes an advantage for the attacker rather than the defender.
  • Correctable errors are deliberately left unprotected. Rows that only produce single-bit flips are never refreshed. The authors acknowledge an adversary could farm those errors to trip the machine-check monitoring that operating systems use to declare hardware unhealthy, and argue this is unlikely on recent modules rather than showing it cannot happen.
  • It requires infrastructure nobody builds today. Manufacturers would have to test for these addresses and program them into the identification chip. Testing at one temperature is insufficient, since some cells are only vulnerable in a certain range, and the union across temperatures is 2.3 times the largest single set. The paper calls the testing method orthogonal to the work.
  • The cost scales with the thing expected to get worse. The penalty is proportional to how many addresses must be visited, and the authors expect that number to rise as thresholds fall and capacities grow. The gap between the two variants already grows from a few times at 128 gigabytes to 20.6 times at 512.
  • The comparison against the leading software defence is not a like-for-like reproduction. Its measured 8.3 percent is far worse than its own published figure, and the paper explains why — it was originally evaluated on a single core, whereas here every core must sample its own counter and one must aggregate them. That is a fair criticism of how it scales, and it is also not the same experiment.
  • The refresh period is empirical. The 8 millisecond figure was chosen by measuring error rates against a black-box in-memory defence over 24 hours, not derived. A separate analytic argument bounds the activations an attacker can achieve, but it rests on assumed parameters for a tracking scheme the vendors do not document.
  • The offloaded version is only a software solution for machines that have the card. The authors state this plainly, and add that it depends on future coherent cards being designed and used the way current ones are, with their processors serving as a control plane and their cores underused.

The evaluation

Four defences on the same 128-gigabyte server

PropertyDouble the refresh rateMonitor cache missesTargeted refresh, on the host or offloaded
Throughput cost
Tail latency cost on a databaseNot reportedNot compared, having already lost on throughput
Protection achieved
Behaviour as memory growsRoughly constant as a fractionWorsens with more cores and more misses
What it assumesNothing beyond existing hardwarePerformance counters and constant sampling
Seventeen DDR4 modules from three manufacturers spanning 2016 to 2023, hammered for three weeks with published many-sided patterns at controlled temperature.Underlined values explain themselves when clicked.

Check yourself

Check your understanding

  1. 1. Why is the set of addresses worth defending so much smaller than the set of cells that can flip?

  2. 2. Why does the defence flush each address from the cache before reading it?

  3. 3. What does a cache-coherent interconnect provide that a conventional PCIe attachment does not, for this purpose?

  4. 4. What is the strongest reason to be cautious about this result?

Sources

The paper is “TAROT: A CXL SmartNIC-Based Defense Against Multi-bit Errors by Row-Hammer Attacks” by Chihun Song, Michael Jaemin Kim, Tianchen Wang, Houxiang Ji, Jinghan Huang, Ipoom Jeong, Jaehyun Park, Hwayong Nam, Minbok Wi, Jung Ho Ahn and Nam Sung Kim, published at ASPLOS 2024, pages 981-998, DOI 10.1145/3620666.3651325. It is open access under a Creative Commons licence and includes an artifact appendix.

This explainer is written from the full 18-page text. Everything above comes from the paper’s own sections: the device-level account of parasitic coupling and interface traps and why they produce fixed, chip-specific vulnerability; the survey of hardware, software and system-level defences with their respective costs and the note that in-memory schemes have been broken by sophisticated attacks; the background on coherent interconnect protocols and what distinguishes a coherent network card from a conventional one; the three-week experimental campaign covering the seventeen modules and their manufacture dates, the two evaluation platforms, the temperature control, the hammering patterns and refresh-rate reductions used, and the three observations about cell-level, chip-level and address-level variation with their supporting numbers; the convergence of dangerous address counts per module, the absence of uncorrectable errors in the newer modules, and the synthesis of a thousand virtual modules with their mean and four-sigma counts; the design of the host-side defence including storage in the module identification chip, the temperature-dependence complication, the boot-time address translation, the flush-then-read loop, the stated threat model and the analytic security bound with its assumed parameters; the offloaded design including the measurement of how many network card cores its accelerators require, the explanation of why a conventional card cannot activate a cached row, and the emulation setup with its downclocked second socket; and the evaluation covering error rates against refresh period, throughput results across the benchmark suites, tail latency results across memory capacities, the effect on the network card’s own functions, the interconnect bandwidth estimates, and the stated limitations regarding correctable errors, growing address counts and dependence on future hardware, together with the huge-page fragmentation simulation that rules out simply unmapping the vulnerable rows.

Related papers on Datacenter, Cloud & Networking

See all 163 →