Personal computing discussed
Moderators: renee, Flying Fox, Thresher
I.S.T. wrote:Thank god I barely use Java and have it set to ask to activate...
SuperSpy wrote:I.S.T. wrote:Thank god I barely use Java and have it set to ask to activate...
Javascript, not Java.
SuperSpy wrote:I.S.T. wrote:Thank god I barely use Java and have it set to ask to activate...
Javascript, not Java.
Kougar wrote:Guess I shouldn't be surprised someone figured out how to turn it into a software exploit.
Time for everyone to mass upgrade to DDR4 which has additional hardware built-in to the DRAM logic chips that makes rowhammering impossible.
just brew it! wrote:I'm good, my desktop uses ECC RAM.
Kougar wrote:just brew it! wrote:I'm good, my desktop uses ECC RAM.
I've read some reports that said ECC can't offer protection from rowhammering when it flips multiple bits at once.
JBI wrote:I'm good, my desktop uses ECC RAM.
Glorious wrote:Anyone can run the rowhammer.c program over night to see if gets any bit flips (with a linux bootdisk or something if you are worried about integrity of your system). Even with regular memory you very well might not be vulnerable at all. I've tried it on several desktops with regular DDR3, with no success. One was plain-jane OEM, the other was some enthusiast board.
Glorious wrote:As Topinio stated, the Kim paper does say that SECDED is not enough, but that was simply a statement that logically followed from their success at flipping multiple bits at once in some of their tests. Inference, not actual demonstration.
JBI wrote:I may give it a try sometime. Would be interesting to see if the system logs any EDAC errors.
JBI wrote:Furthermore, in the cases where they managed to flip multiple bits in the same word, were they really flipped AT THE SAME TIME or just over a short period of time? Unless the flips were truly simultaneous, ECC (with scrubbing) may still be able to deal with them.
JBI wrote:Yes, depending on how long it takes to induce a flip you might be able to mitigate by simply having something that sweeps through memory, accessing every row periodically. However, on further reflection I tend to think that this may not be practical, given that typical DRAM refresh rate is on the order of tens of milliseconds; that being the case, the rowhammer bit flip must be occurring on a shorter timescale than that. Sweeping through all of your RAM every few tens of milliseconds simply isn't feasible. This also argues against ECC scrubbing being an effective mitigation against multi-bit flips, whether or not they happen "simultaneously". ECC in general should still be able to handle the single-bit flips, and throw a hardware fault on most 2+ bit ones.
Code: Select allFor IntelBurnTest, I ran the test 10 times and set the RAM utilisation to 4096MB. I then took the most often occurring GFlops (IE, the mode) and rounded it to 1 dp.
For Realbench, I ran the benchmark 5 times. Again, I took the most often occurring System Score and rounded it to 3 sf.
Here are the results of the test.
[Config] [Refresh Cycle time (in clocks)] [Refresh Interval (in clocks)] [Intelburntest v2.54 4096MB RAM (Gflops)] [Realbench v2.4 result (system score)]
[Default] [174] [5200] [~112.6] (not sure what went wrong here) [~74100]
[7] [174] [3000] [~113.1] [~73500]
Conclusion: There is no performance difference that can be observed from the test, which is good news because it means I achieved stability seemingly without having to sacrifice performance.
fhohj wrote:Might this cause the RAM to use more power and run hotter? Heat isn't a problem for RAM generally but it is getting close to double the refreshing.