The mysterious case of the Linux Page Table Isolation patches

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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?

[ Parent | on HN ]

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.

[ Parent | on HN ]