[jbfoo]

Shouldn't cloud-grade computers be immune to rowhammer (or at least rowhammer should be much less efficient) as they typically use ECC RAM. Switching ECC RAM in a way that also modifies checksum in a deterministic way is (was?) not practical?

[dmm]

ECC doesn't protect you from from all rowhammer problems because they can flip more than two bits at a time, the limit which ECC can detect.

"Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word"

https://en.wikipedia.org/wiki/Row_hammer#Mitigation

[hathawsh]

OTOH, a rowhammer attack on ECC memory will likely flip 1 bit before it flips 2, making attacks theoretically detectable. Without ECC, there's no clear way to detect an attack.

[lolc]

I'd assume that parity is checked on access, which may give enough time to flip more than one bit before it's detected.

[Rebellos]

ECC memory controller performs memory scrubbing periodically, in the background, during which it checks parity and corrects any bitflips. Otherwise ECC would not work nearly as well as it does.

[Dylan16807]

Parity isn't checked during every single row refresh?

[cesarb]

AFAIK, row refresh is done within each memory chip, while the ECC bits are normally on a separate chip (for instance, where a non-ECC module has 8 chips, an ECC modules has 9 chips), so ECC scrubbing has to be done in the memory controller.

[dboreham]

ECC wasn't designed to protect against this type of failure. It assumes a low probability of coincident multi-bit errors.

[justincormack]

Yes one would thin so. And the mitigation patches in Linux suggest a CPU bug that could be fixed in future CPUs, not just rowhammer like attacks that are related to memory. So still think the attack path may be different.

[thrill]

The bit flip would be done in a normal fashion - i.e. a command issued that changed the memory location, and hence updates the checksum. The occasional (about one bit flip per Terabyte per hour I think, on average) stray cosmic ray inducing a momentary over-voltage causing the checksum to now disagree would hopefully be within the design's ability to flip back.

[rocqua]

That's not how rowhammer works.

It's a hardware level thing. Essentially, when you start rapidly flipping a single bit, that starts to 'leak' some current to the adjacent physical bits. This then allows you to flip a single bit. Especially if you can control bits on both sides of your target.

It's like you are using the bits you can control to 'simulate' an actual stray cosmic ray.