Attack or otherwise, this is ultimately a hardware reliability problem. Any access pattern that can cause bit errors is indicative of faulty memory. If I remember correctly, the original Rowhammer paper shows that RAM from ~2009 and before was completely unaffected. Yet in the continuing quest for higher densities and lower costs (is RAM not cheap enough already?) the manufacturers are sacrificing reliability and correctness, and IMHO that is not acceptable, nor is their insistence that this is not a problem (it seems they were powerful enough to convince one well-known memory testing application to make the RH test optional(!) and spread FUD that it wasn't really a concern if that test failed, because a lot of RAM would fail it.) NO access pattern should ever cause errors to occur on correctly functioning hardware.
Surprisingly, Rowhammer-like memory problems go back to the early 1950s. Early computers (such as Manchester Baby and the IBM 701) used electrostatic Williams tubes as their main memory, storing data as dots and dashes on CRT tubes. One problem with Williams tubes was that if you accessed a location on the screen multiple times, the charge on a neighboring spot could be affected, flipping the bit. (Of course back then this was a correctness issue, not a security issue.) The quality of the tube was measured by the read-around ratio, the number of times you could read a bit without corrupting the neighbors. A good tube might have a read-around ratio of 50. Nobody missed Williams tubes when they were replaced by core memory.
Couldn't the error rate of the ECC system be monitored, to detect an attack in progress and raise an alarm?<p>Even if the attacker was able to get the flipping completely reliable, there would presumably be a learning/probing phase with a period of elevated ECC. Either this probe could be detected, or the attacker would be forced to remain below a threshold of detectability slowing the attack down enough to make it impractical?
I wonder if having a separate stick of RAM exclusively dedicated to kernelspace would provide any mitigation against privelige escalation via rowhammer. Are we considering a future where every "ring" is literally a separate set of CPU, RAM, etc in order to stymie side channels, or is that just too crazy?
Haven't read the full article, but if I remember correctly in order for ECCploit to work you do need to reverse the ECC function of a memory controller first.<p>Also for people who just want the link of the academic article (including abstract):<p><a href="https://cs.vu.nl/~lcr220/ecc/ecc-rh-paper-eccploit-press-preprint.pdf" rel="nofollow">https://cs.vu.nl/~lcr220/ecc/ecc-rh-paper-eccploit-press-pre...</a>
This is certainly a serious threat.<p>However, it's my understanding that exploits depend on running code (including JavaScript) on the target system (or in a sandbox or VM). Is that true?