How much/what hardware does the rowhammer DRAM bug affects?

[jim bell]

  From: Georgi Guninski <guninski at guninski.com>
On Wed, Sep 16, 2015 at 11:46:26PM -0400, grarpamp wrote:


>> Some paper has said systems using ECC RAM are resistant / immune>> to rowhammer.
>> There is still a fair bump in cost for ECC system
>> however once you've seen your first syslog entry
>> you forget about the cost. Regardless of rowhammer.
>ECC appears controversial:
  http://blog.erratasec.com/2015/03/some-notes-on-dram-rowhammer.html

>Update: This is really just meant as a primer, as background on the
i>ssue, not really trying to derive any conclusions. I chatted a bit
>Chris Evans (@scarybeasts) from google about some of those conclusion,
>so I thought I'd expand a bit on them.

>Does ECC protect you? Maybe not. While it will correct single bit flips
>most of the time, it won't protect when multiple bits flip at once.
 Not exactly.  Generally, ECC with enough correction bits will at least detect all double-bit errors, although it will not correct those errors.  And I can't say for sure how generally this is in use, but I think a competently-designed ECC system will use the regular refresh cycles to "sweep" for correctable single-bit errors, and correct virtually all of them, before they turn into double-bit errors.
>The hacker may be able to achieve this with enough tries. Remember: the>hacker's code can keep retrying this until it succeeds, even if that>takes hours.
However, the profusion of corrected single-bit can be used to alert, and uncorrectable double-bit errors will probably cause  a system exception that will inform the system operator that something is going on.
Remember, it is likely that different manufacturer's DRAM designs might differ in sensitivity to rowhammer (or other deliberate failure mode) by a factor of 10:1, 100:1, or even 1000:1.   The word can, and will, quickly get out what manufacturers sensitivity is, and the market will quickly result in improvement for designs and thus, new systems.           Jim Bell





  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 4465 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20150917/f5f9eaca/attachment-0002.txt>