On Mon, Mar 09, 2015 at 01:15:50PM -0700, Tim wrote: > > Here's a related issue, but far far worse than Seagate/TLS issues: > > http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
The problem is row-to-row disturb - and that will depend on how the chips are designed, and operational conditions like clock rate, refresh rate, and temperature. I imagine MEMTST could be tweaked to test for hardware-specific vulnerabilities like this. I use a lot of second-hand hardware, and run MEMTST for a week before deploying machines. I would rather run a more elaborate test than 100 runs of the same thing. Machines that permit overclocking can also be underclocked (?). Different RAM manufacturers will have different sensitivities. Find the best and reward them for it. Allocating RAM with "firebreaks" between kernel and independent user processes, and judiciously assigning memory blocks for security separation, would probably help, too. In the long term, select RAM manufacturers with the most secure RAM designs, and make them aware of why you buy from them. Purchase memory controllers that can be programmed to refresh more frequently; 64 milliseconds is way too long, 1 millisecond refresh would be a tiny performance hit. And keep the machine cool ... leakage doubles with every 10C temperature rise. It isn't surprising that this bug is there; when was the last time anyone let security features influence their consumer hardware decisions? If you aren't willing to pay for security, hardware makers won't compromise banner specs to give it to you for free. They will merely lose customers to manufacturers who push banner spec performance at the expense of reliability, durability, and security. Keith -- Keith Lofstrom [email protected] _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
