DRAM 5 min read

The Silicon Bug You Cannot Patch

What’s the scariest class of vulnerability in computer security? Not a zero-day. A zero-day gets patched. The scariest bug is the one that cannot be patched at all, because the flaw lives in physics rather than code.

That’s the category the recurring “spaghettifying DRAM” discussion belongs to. It attacks an assumption so basic that most engineers have never once questioned it: write a 1 to memory, read back a 1.

A note on scope. This particular topic generated almost no community chatter in the past 30 days, so instead of recapping live reaction, it’s worth asking why this line of research keeps resurfacing every couple of years.

Your RAM Is a Leaky Bucket

DRAM has the answer in its name. The D stands for dynamic, which sounds vaguely exciting but means exactly one thing: leave it alone and your data evaporates.

One cell is one transistor and one capacitor. Charge in the capacitor means 1. Empty means 0. The problem is that the capacitor leaks. So DRAM reads and rewrites every cell roughly every 64 milliseconds. Your computer is refreshing its entire memory more than fifteen times per second just to keep the bits from falling over.

That is where the attack surface opens up. Anything held together by a race against physics can be broken by physics.

Rowhammer: Knock on the Wall Until the Neighbors Change

The starting point is Rowhammer, published in 2014 by researchers at Carnegie Mellon and Intel. The mechanism is almost insultingly simple.

Read one row of DRAM very fast, over and over. The electrical interference bleeds into adjacent rows and drains their capacitors faster than expected. If enough charge escapes before the next refresh arrives, a bit in a row you never touched flips from 1 to 0.

You touch only your own memory. Someone else’s memory changes.

Google Project Zero showed why that matters in 2015: flip a single bit in a page table entry and you have kernel privileges. Then came Rowhammer.js, which pulled off the attack from JavaScript in a browser tab.

Process shrinks make it worse, not better. Smaller cells packed closer together mean stronger interference. DDR4’s TRR (Target Row Refresh) defense fell to the TRRespass research in 2020, and DDR5 keeps producing results showing it is no safe harbor either.

What “Spaghettification” Actually Names

In black hole physics, spaghettification is what tidal forces do to an object falling in: stretch it lengthwise until it tears apart. Borrow the metaphor for memory and the meaning is clear. The physical substrate stretches your abstraction layer until it rips.

We think of memory as an array. Write to 0x1000 and the value sits there; the neighboring address is irrelevant. But on the silicon, those two addresses are a few nanometers apart. Logical isolation is not physical isolation.

The person who did the most to popularize this way of looking at hardware is Christopher Domas, who goes by xoreaxeaxeax. His 2017 DEF CON tool sandsifter brute-forced the x86 instruction space and turned up undocumented instructions — including, on some CPUs, ring 3 code that halts the machine outright. It was a direct attack on the belief that a chip behaves the way its datasheet says.

Rowhammer, spaghettification, sandsifter: three approaches, one question. How much of the hardware spec you trust is actually true?

Software Cannot Save You Here

Meltdown and Spectre were bad, but they were at least addressable. Microcode updates, kernel patches, a performance tax you grit your teeth and pay. Electrical crosstalk between DRAM cells offers software nothing to grab onto.

Mitigations exist. ECC memory corrects single-bit errors — and then 2016’s ECCploit showed that multi-bit flips can slip past ECC anyway. DDR5 adds on-die ECC. You can shorten refresh intervals. Memory controllers can watch for suspicious access frequencies. Every one of these is mitigation, not a fix. Refresh more aggressively and you pay in power and performance.

A real fix means changing the cell structure, which means new processes, new designs, new fabs. That timeline is measured in years. And every DIMM currently seated in a rack stays exactly where it is.

In the Cloud, This Is Your Problem

On a laptop you own and physically control, Rowhammer is mostly academic. Anyone who can hammer your rows can already just take the machine.

Multi-tenant environments are the real story. Cloud instances mean many customers sharing one physical server. The hypervisor isolates memory, but that isolation is logical. Your VM’s data and your neighbor’s data can land in adjacent rows of the same DRAM bank. Cross-VM Rowhammer has been demonstrated in multiple papers.

Point this at AI infrastructure and it gets more interesting. The HBM stacked next to a GPU is still DRAM. Hundreds of gigabytes of it, holding model weights that cost hundreds of millions to train. Flipping a small number of bits with surgical precision to alter model behavior is no longer a thought experiment — it’s an active area of academic work.

The Takeaway

Twelve years after Rowhammer’s publication, the pattern hasn’t changed: a defense ships, a bypass follows, repeat. That’s what fighting physics looks like.

What this research really challenges is where you place your trust. We stack software abstractions and treat the hardware at the bottom as axiomatic. If that axiom is probabilistic, what happens to everything proved on top of it?

How far down the stack has the security of the service you’re using right now actually been verified?

DRAM hardware security Rowhammer memory vulnerabilities

Comments

    Loading comments...