Half-Double: A New DRAM Rowhammer Vulnerability

[stormcrow]

Rowhammer is not stopped by ECC. That's from the original papers on the topic. It stands to reason variations on the theme won't be stopped by ECC either. That's because ECC only works on single bit errors. It's designed to stop low rate accidental bit flips by the random fluctuations of hardware errors and the occasional cosmic ray. It isn't intended to and will not stop the intentional flipping of many bits at once induced by Rowhammer. Some of the more advanced ECC systems will send a HALT and kill the system, but that isn't a common hardware setup. It's also very inconvenient and pretty much overkill for anything but the most sensitive work. If you think ECC setups will entirely protect you from Rowhammer, you're sorely mistaken.

I suggest reading the actual papers on the original Rowhammer attack, TRESpass, and SMASH for background (which are linked to from the Google abstract).

The only way to fix this is to re-engineer the geometries on RAM modules to prevent the underlying physics these attacks exploit. Or, alternatively, just not browse the web with your computer if you're that concerned.

EDIT to add: It might show you if an attack is possibly occurring if you know what you're looking at. That's a big IF.

[torsionbar28]

Rowhammer is not stopped by ECC. That's from the original papers on the topic. It stands to reason variations on the theme won't be stopped by ECC either. That's because ECC only works on single bit errors. It's designed to stop low rate accidental bit flips by the random fluctuations of hardware errors and the occasional cosmic ray. It isn't intended to and will not stop the intentional flipping of many bits at once induced by Rowhammer.

Sure, all true... but I don't think anyone is claiming otherwise. ECC won't protect against multi-bit errors, and therefore won't protect against any variant of Rowhammer.

ECC will however *detect* multibit errors, and therefore will *detect* a Rowhammer attack. I've seen what multibit errors look like in the Linux syslog, it isn't pretty, and you'll immediately know something is wrong provided you are monitoring syslog.

Without ECC, the attack is carried out silently, without any indication to the user. Pretty significant difference there.

[stormcrow]

Sure, all true... but I don't think anyone is claiming otherwise. ECC won't protect against multi-bit errors, and therefore won't protect against any variant of Rowhammer.

ECC will however *detect* multibit errors, and therefore will *detect* a Rowhammer attack. I've seen what multibit errors look like in the Linux syslog, it isn't pretty, and you'll immediately know something is wrong provided you are monitoring syslog.

Without ECC, the attack is carried out silently, without any indication to the user. Pretty significant difference there.

I did mention as much in the addendum. But there are plenty of people asking if this affects ECC RAM and/or expecting ECC RAM to protect them from it. I was pointing out the research is clear it won't. It's also likely that the attack has already been carried out and exfiltration may have already occurred before many people will notice something is up in the syslog even if they have ECC RAM, and assuming they are specifically looking for Rowhammer shenanagans. I presume most people won't know till after they have other IOCs simply based on general attentiveness. Plenty of people don't realize that ECC RAM requires certain vigilance to be effective as an IOC or even as a IOEF.

Not contradicting you, just pointing out that there are people that have asked it, still ask it, and will ask it in the future about Rowhammer attacks when they come up again. Not everyone knows how ECC works nor what to look for.

[piorunz]

Some of the more advanced ECC systems will send a HALT and kill the system, but that isn't a common hardware setup. It's also very inconvenient and pretty much overkill for anything but the most sensitive work. If you think ECC setups will entirely protect you from Rowhammer, you're sorely mistaken.

Writing a script to halt or restart the system upon discovery of unrecoverable error, with help of edac-util tool for example, takes literally few lines of code.

[Azrael5]

Why just the ddr4 are affected?

[Azrael5]

I suppose, this time, my being a lazy cheapskate who's still on a DDR3-based system works in my favour.

ddr3s are affected too.

[ssokolow]

ddr3s are affected too.

In that case, serves me right for being too busy to read the paper itself and being too tired to realize the summary might be saying "DDR4 isn't immune" rather than "DDR4's speed introduced this problem".

[Azrael5]

In that case, serves me right for being too busy to read the paper itself and being too tired to realize the summary might be saying "DDR4 isn't immune" rather than "DDR4's speed introduced this problem".

The article should have to clarify better.

[WorBlux]

Does it affect ECC RAM as well?

Yes, but it's harder. You have to find flip at least 3 vulnerable bits. The Hamming variant ECC uses can correct any 1 bit flip and detect any 2 bit flip. And it can still detect many other groups of bit flips, but 3 bits is the minimum you need to flip to be undetected and uncorrected.

[torsionbar28]

Yes, but it's harder. You have to find flip at least 3 vulnerable bits. The Hamming variant ECC uses can correct any 1 bit flip and detect any 2 bit flip. And it can still detect many other groups of bit flips, but 3 bits is the minimum you need to flip to be undetected and uncorrected.

While these rowhammer attacks may be technically feasible against an ECC system, the likelihood of an attack on ECC being successful in the real world is absurdly low. I.e. more of a laboratory academic exercise than a flaw that can be exploited in a repeatable manner. The bit flips would all have to occur within the same word (64 bytes), as each word has its own unique parity information.