Re:The mysterious case of the Linux Page Table Isolation pat...
by jbfoo on Monday January 01, 2018 @12:02PM
(#16046812)
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?
[ Parent
| on HN ]
Re:The mysterious case of the Linux Page Table Isolation pat...
by dmm on Monday January 01, 2018 @01:20PM
(#16047219)
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"
Re:The mysterious case of the Linux Page Table Isolation pat...
by hathawsh on Monday January 01, 2018 @02:50PM
(#16047677)
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.
Re:The mysterious case of the Linux Page Table Isolation pat...
by lolc on Monday January 01, 2018 @05:21PM
(#16048363)
I'd assume that parity is checked on access, which may give enough time to flip more than one bit before it's detected.
Re:The mysterious case of the Linux Page Table Isolation pat...
by Rebellos on Monday January 01, 2018 @11:46PM
(#16049935)
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.
Re:The mysterious case of the Linux Page Table Isolation pat...
by Dylan16807 on Tuesday January 02, 2018 @06:18AM
(#16051232)
Parity isn't checked during every single row refresh?
Re:The mysterious case of the Linux Page Table Isolation pat...
by cesarb on Tuesday January 02, 2018 @07:55AM
(#16051568)
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.
Re:The mysterious case of the Linux Page Table Isolation pat...
by dboreham on Monday January 01, 2018 @01:40PM
(#16047320)
ECC wasn't designed to protect against this type of failure. It assumes a low probability of coincident multi-bit errors.
Re:The mysterious case of the Linux Page Table Isolation pat...
by justincormack on Monday January 01, 2018 @12:23PM
(#16046924)
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.
Re:The mysterious case of the Linux Page Table Isolation pat...
by thrill on Monday January 01, 2018 @12:12PM
(#16046863)
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.
Re:The mysterious case of the Linux Page Table Isolation pat...
by rocqua on Monday January 01, 2018 @02:48PM
(#16047668)
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.