It's really worth noting that ECC does impact Rowhammer effectiveness, even if it is not enough to prevent the attack 100% of the time.

But as part of this it'll also have a high chance of triggering a system shutdown due to ECC mismatch, right? So in most cases it can't be exploited for things other than DoS.

ECC won't necessarily shut the system down as it can actually repair single bit errors, and mismatches can be monitored for as well. But your point stands - for an attacker to do damage they'll likely end up flipping bits in unintended ways first.

Can Rowhammer bypass ECC and not be detected by an hw_event_mc_err_type? I don't think so. Why would someone have ECC without a sufficiently sophisticated driver?

> Can Rowhammer bypass ECC and not be detected by an hw_event_mc_err_type?

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)

> Can Rowhammer bypass ECC and not be detected by an hw_event_mc_err_type?

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.

We should be using memory encryption with random per-boot keys to prevent cold boot attacks, which would also solve the issue. Then the software doesn't know how its data maps to the encrypted data at the RAM. Rows may map 1:1, but you wouldn't know which bits you're targeting.

Good point. Although memory encryption is much more useful if applied at the CPU rather than the memory controler (which would need a way to turn encryption off for DMA regions, since the memory controller doesn't know the key), there's no actual reason why you couldn't do it in the memory controller, if you trust all the hardware with DMA access, or (more plausibly) trust the memory controller to limit that access properly.

> Why would someone have ECC without a sufficiently sophisticated driver?

Have you, personally, tested your servers to make sure the driver correctly handles bit errors? Can't say I have.

Last time I tested such things, they handled ECC correctly (x86 and arm).