Google says Rowhammer attacks are gaining range as RAM is getting denser

We already have error correction detection available to us and it's in use today.

> RAM should always hold what was last written to it, under all conditions of software accesses.

OK? That's what anyone who is advocating for ECC is already advocating for. ECC is error correcting up to 1 bit and error detecting up to 2 bits. The goal is to ensure that the property you've described holds.

> It only got created because the RAM companies have forsaken correctness,

This problem exists because... physics. Do you actually have a design for RAM that can match today's cell density while somehow providing perfect isolation? Saying this problem didn't exist 15 years ago is like saying that malware didn't impact the abacus - RAM 15 years ago was designed completely differently, and had considerably lower capabilities in terms of storage and latency.

And for reference, hamming codes (which back ECC) were created in the 1950s for error correction in punch cards. This is not a new problem.

ECC is the existing, obvious solution to this problem, it just wasn't built for this threat - but it's an excellent, proven method for correcting bit flips. Even without being designed to prevent rowhammer it already makes the attack much slower, less likely to succeed, and easier to detect (just monitor for a massive spike in ecc corrections).

Trying to design high density RAM that maintains perfect isolation seems pointless. Improving ECC or ECC-like approaches is likely going to be much more effective.

No, ECC is there to correct any errors, including normal errors that occur during operation. It allows us to build technologies that have a much higher raw channel error rate, and decrease the system error rate to better than before. In return, we get much higher density, performance, or whatever other metric you want to optimize for.

This is basic information theory. It is extremely inefficient to attempt to build a channel with a low enough raw bit error rate to be usable. Instead we let the bit error rate rise, then correct the errors with error correction codes. This reduces the bandwidth, proportional to error rate for advanced error correction, which is still a negligible amount compared to the total channel bandwidth - the performance improvements from allowing the raw error rate to rise more than make up for this, and result in orders of magnitude better performance.

> Now you've turned specific access patterns into "attack attempts"

Ever heard of files you can't burn on CD-R, or transmit through certain variants of Ethernet? We use technologies that are probabilistic all the time; they assume data is not correlated with a pseudorandom internal characteristic of some sort. These files only exist because someone explicitly targeted them; the chances of someone stumbling onto such data randomly are basically nonexistent (for any well designed system).

That said, this can be mitigated without throwing ECC out the window.

> RAM should always hold what was last written to it, under all conditions of software accesses.

And it will, after ECC. Why are you drawing an arbitrary line for RAM and saying it can't use ECC? Are you also against HDDs (LDPC error correction), Wi-Fi (convolutional codes), NAND storage of all kinds (increasingly advanced ECC), USB (error detection and re-transmission), TCP (error detection and re-transmission), the internet as a whole (flow control by dropping packets), CDs (three layers of error correction for data!), Bluetooth (FEC and/or ARQ), Digital TV (ATSC, DVB, ISDB all use FEC of some kind), QR codes (reed-solomon), and even things like RAID6? The people who designed these systems aren't dumb, they know the only way to get performance and reliability is to use error correction.

It's a damn miracle we get away with non-ECC RAM, today. That stuff should've died 20 years ago, and ECC should be standard. Even the caches inside CPUs often have ECC these days.

> Where manufacturers are trying to sell 2-4x the capacity with 1/4 to 1/16th of the endurance? That's a rant for another thread...

Yes, manufacturers having a race for the bottom to achieve the highest capacity at the expense of all reliability and performance metrics is a completely different problem that doesn't mean we need to throw ECC out the window, which would also hurt all of those metrics. Optimizing for endurance and performance still requires ECC.

The solution is simple: don't buy QLC flash. That stuff's garbage, at least today.

Or would you prefer to go back to the era of 16MB CompactFlash cards (that's MB) using SLC NOR Flash? That stuff doesn't need ECC, certainly, and the endurance is amazing. Let me know how the cost per gigabyte and write performance metrics work out in your NOR world, though :-)

Or perhaps you'd rather have us store all of our data on 16KB EEPROM chips, with even better endurance! I'm sure nobody will mind the 1KB/s write performance (if you're lucky). Maybe if you RAID a few thousand of those it'll work! Oh wait, then random errors will kill your data anyway, without something like RAID-6. Oops!

> This problem didn't exist 15 years ago.

15 years ago the average computer had 256MB of RAM. I had one of those. And I had a bad RAM bit back then, which I had to mask out with a kernel patch (that I had to port from x86 to amd64, as I was an early adopter of 64-bit), which would've been a non-issue with ECC RAM.

I don't know about that. Rowhammer really emphasizes the hammer. A normal read pattern will basically never hit the lines in a small area that much, it will hit cache instead.

> Now you've turned specific access patterns into "attack attempts", and by discriminating against them as such, entirely destroyed a fundamental part of general-purpose computing.

Can you show me any code that causes this kind of access pattern that wasn't deliberately designed to implement rowhammer?

> Where manufacturers are trying to sell 2-4x the capacity with 1/4 to 1/16th of the endurance?

We could go the other way too and glue together multiple SLC cells to increase endurance and cost. Are you claiming there is a specific correct amount of endurance? Because "as much as possible" isn't feasible and "as much as SLC used to have" could only be correct from an extreme coincidence or from conflating nostalgia with correctness. Is there a different number you have in mind?

> This problem didn't exist 15 years ago. It only got created because the RAM companies have forsaken correctness, and somehow managed to convince everyone else that it's not their own fault.

Old ram had errors too. RAM companies can and should put in mechanisms to prevent rowhammer, but if I was buying a stick of ram and had a choice between ECC and perfect rowhammer prevention I'd choose ECC.

At least I had no issues getting ECC to work on my Threadripper box, but sure, that's HEDT.

ECC was standard on first IBM PC 5150, on PS/2 line, on pretty much all 286 clones etc.

Intel market segmentation shenanigans started around 1995 with Pentium line, with ECC absent from all consumer oriented product lines.

a) Attackers would have to develop the POC. This will require a somewhat different skillset than typical exploitation, so there's effort involved.

b) Rowhammer is best for privilege escalation. For desktop users (where the most money is) privesc is already pretty trivial - no need for fancy exploits, you can pretty much just ask for root or use a much more straightforward exploit.

c) Exploit devs don't typically like a lot of attention. You don't want to be the first person selling rowhammer exploits unless you can charge out the ass for it, because you're gonna get way more attention for it.

These incentives aren't super technical, they're mostly market driven, and it's why we don't see fancier attacks in practice, even if they're practical. As one attacker I know was saying to me, they wish they had an excuse to do the fancy thing, but it's never worth the investment when you can own boxes way more easily. Another hacker said "I don't want a Krebs article on me because I did something clever".

NSA's incentives are not super difference, except they're not as directly financial. They also have crazy resources to fuck around with this stuff, so it would make sense that they'd demo it in a lab. Would they actually deploy it? Eh, doubtful. Against another advanced defender rowhammer should be pretty detectable by monitoring ECC metrics, and again, why would you do something fancy when you can just buy 0days - the USG purchases hundreds a year from private companies and develops more themselves.

But if there are corner cases like this, they should be added to specs. Most likely it would require memory controller to remember last addresses and insert delays if rowhammer attempt is detected. And/or make CPU microoperation scheduler avoid it. No idea how expensive would that be, surely nontrivial.

ECC RAM is pretty effective as-is against rowhammer, and imo you could very likely tweak ECC's approach to get even further.

The 'worst case' solution wouldn't be more than 2x, right? Since you'd just have to keep a clone of RAM, but obviously shuffled so that the same errors wouldn't occur in the same places. So 2x seems like the sort of absurd upper bound, but I feel like we could do a lot better.