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

[jim bell]

From: grarpamp <grarpamp at gmail.com>
>Some ballyhoo about rowhammer was like "look we can flip

>a single bit and get root". Obviously if you're going for
>multibit carnage ECC doesn't help much.
>  https://en.wikipedia.org/wiki/ECC_memory 
> https://en.wikipedia.org/wiki/Hamming_code

Again, I must disagree.  Rowhammer errors are, presumably, exceedingly rare.  But when they do occur, one-bit errors are probably millions of times more common than two-bit errors, which are themselves going too be millions of times more common than three bit errors..  But ECC accesses will automatically correct all one-bit errors, and detect all two-bit errors, and will either log only the 2-bit errors or both single and double-bit errors.  I won't try the math, but I suspect that the vast majority of three-bit errors (for 64-bit words) are also detected.   Wikipedia says   https://en.wikipedia.org/wiki/Dynamic_random-access_memory#Errors%5Fand%5Ferror%5Fcorrection  , "Parity allows the detection of all single-bit errors (actually, any odd number of wrong bits)".    So, the smallest number of error bits that might not be detected would be four.
 Since any serious rowhammer attack will generate millions of correctable single-bit and uncorrectable double- and triple-bit errors, per actual single 4-bit error, any system operator will get a huge amount of warning that the attack is underway before even as many as a single 3-bit error will appear.             Jim Bell
This came from Wikipedia:      https://en.wikipedia.org/wiki/ECC_memory

"Work published between 2007 and 2009 showed widely varying error rates with over 7 orders of magnitude difference, ranging from 10−10–10−17 error/bit·h, roughly one bit error, per hour, per gigabyte of memory to one bit error, per millennium, per gigabyte of memory.[4][5][6] A very large-scale study based on Google's very large number of servers was presented at the SIGMETRICS/Performance’09 conference.[5] The actual error rate found was several orders of magnitude higher than previous small-scale or laboratory studies, with 25,000 to 70,000 errors per billion device hours per megabit (about 2.5–7 × 10−11 error/bit·h) (i.e. about 5 single bit errors in 8 Gigabytes of RAM per hour using the top-end error rate), and more than 8% of DIMM memory modules affected by errors per year.

The consequence of a memory error is system-dependent. In systems without ECC, an error can lead either to a crash or to corruption of data; in large-scale production sites, memory errors are one of the most common hardware causes of machine crashes.[5] Memory errors can cause security vulnerabilities.[5] A memory error can have no consequences if it changes a bit which neither causes observable malfunctioning nor affects data used in calculations or saved. A 2010 simulation study showed that, for a web browser, only a small fraction of memory errors caused data corruption, although, as many memory errors are intermittent and correlated, the effects of memory errors were greater than would be expected for independent soft errors.[7]
Some tests conclude that the isolation of DRAM memory cells can be circumvented by unintended side effects of specially crafted accesses to adjacent cells. Thus, accessing data stored in DRAM causes memory cells to leak their charges and interact electrically, as a result of high cells density in modern memory, altering the content of nearby memory rows that actually were not addressed in the original memory access. This effect is known as row hammer, and it has also been used in some privilege escalation computer security exploits.[8][9]
An example of a single-bit error that would be ignored by a system with no error-checking, would halt a machine with parity checking, or would be invisibly corrected by ECC: a single bit is stuck at 1 due to a faulty chip, or becomes changed to 1 due to background or cosmic radiation; a spreadsheet storing numbers in ASCII format is loaded, and the digit "8" is stored in the byte which contains the stuck bit as its eighth bit; then a change is made to the spreadsheet and it is saved. However, the "8" (00111000 binary) has silently become a "9" (00111001)."
[end of Wikipedia quote]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 5403 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20150918/417a9ad2/attachment-0002.txt>