Once again, I pine for ECC memory on my Laptop. I know you can get ECC SODIMMS, I got 16GB worth for a Supermicro ITX motherboard. And while the paper talks about multi-bit errors getting through ECC (which is certainly possible with enough flips) single flips causing alerts and double flips causing halts would really get your attention that something bad was happening. As opposed to silently sitting there while my memory is shredded.
There was an older paper discussing using various methods of fault injection (heat, voltage changes, etc) to attack Java smart cards, essentially destroying the type system guarantees and thus opening up an attack surface: "The Sorcerer’s Apprentice Guide to Fault Attacks", <a href="https://eprint.iacr.org/2004/100.pdf" rel="nofollow">https://eprint.iacr.org/2004/100.pdf</a>
The starting research that enabled this security work appeared last year at ISCA, but didn't fully discuss the security implications:<p><a href="https://www.ece.cmu.edu/~safari/pubs/kim-isca14.pdf" rel="nofollow">https://www.ece.cmu.edu/~safari/pubs/kim-isca14.pdf</a>
You know, this makes me wonder. If a car manufacturer or a toy company made a product that was found to be unsafe, there would be a recall. If hardware manufacturers make a product that is insecure, will there be a recall? Unfortunately, I suspect that this is a case where the law hasn't caught up with technology.
Laptops are particularly at risk for stuff like this: components are more densely packed and may use smaller process sizes and have less powerful supplies which may be a factor in keeping bits in adjacent rows stable.<p>That may be the reason why the desktops mentioned are less sensitive, they'll use full size memory modules and will have beefy power supplies.<p>It'd be interesting to repeat the experiments with the laptops running off their internal battery.
Very little information on time scales. In one case they speak about 5 minutes vs 40 minutes (both might be acceptable for an exploit). Also no information about how long it took to bitflip in their per-hardware table.<p>And why name no hardware vendor ? I'm guessing they expect people to use the tool they provided and draw their own conclusions, but I don't understand why they'd treat them differently from software vendors.
On my desktop (DH87RL / i7-4770 / 2x8GB Crucial DDR3L-1600), rowhammer_test reported errors after ~20 iterations (less than a minute).<p>I went into the BIOS and tried lowering the tREFI value from 6300 to 3150 (not sure what the units are). So far, it's gone 1000 iterations with no problems detected.<p>Edit: Actually, the units are probably multiples of the cycle time, just like CAS latency. So, for DDR3-1600, that would mean 6300x1.25ns=7.8μs, and 3150x1.25ns=3.9μs<p><a href="http://en.wikipedia.org/wiki/CAS_latency" rel="nofollow">http://en.wikipedia.org/wiki/CAS_latency</a>
Is a memory error actually an exploit? If so then are the unwanted changes that occur with no deliberate action an example of the computer cracking itself?<p>Philosophical...