What I want to know is if this works on ECC memory. I'm guessing not, which makes the "vulnerability" even more of a non-issue in mission-critical applications that likely moved to ECC a while ago.
What I want to know is if this works on ECC memory. I'm guessing not, which makes the "vulnerability" even more of a non-issue in mission-critical applications that likely moved to ECC a while ago.
See here: https://www.vusec.net/projects/eccploit/
Afaik, yes it can (unless you're counting HW_EVENT_ERR_CORRECTED). They specifically try to get 1 or 3 bit flips, never 2.
See here: https://www.vusec.net/projects/eccploit/
(yes, that's the same link)
It's definitely possible in theory. You'd need four bit flips rather than three, so you'd probably need more time between accesses to the victim row, but thats a quantitative improvement at best. This can be mitigated by using different ECC bit encodings per memory location[0], so hammered data, with correct ECC for its row, always has wrong ECC values for the adjacent rows, but I don't think anyone does that.
0: This is important in order to make fake ECC memory, which uses a (cheap) combinatoric circuit in place of a (more expensive) ninth DRAM chip, not work, so it should be happening even without Rowhammer, but AFAIK it isn't.
Have you, personally, tested your servers to make sure the driver correctly handles bit errors? Can't say I have.