Personal computing discussed

Moderators: renee, Flying Fox, Thresher

 
just brew it!
Administrator
Topic Author
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Rowhammer - The Sequel

Tue Aug 04, 2015 9:58 am

Looks like someone has figured out how to trigger DRAM bit flips from Javascript running in a web browser. This is pretty scary stuff; just because it hasn't been turned into a viable security exploit yet doesn't mean it can't be, and no amount of browser or OS patching can close this hole since the underlying mechanism is baked into the hardware.

I blame the DRAM industry and Intel in equal measure for this. The former for designing chips that are susceptible to this type of attack in the first place, and Intel for their stupid "ECC is only for workstations/servers" market segmentation strategy. :evil:
Nostalgia isn't what it used to be.
 
Glorious
Gerbilus Supremus
Posts: 12343
Joined: Tue Aug 27, 2002 6:35 pm

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 10:27 am

There's no way that anyone javascript's engine incorporates clflush, so this has got to be some strategy relying on an exact combination of software/hardware.
 
just brew it!
Administrator
Topic Author
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 10:32 am

Article says they figured out how to do it without clflush, by (it sounds like) exploiting a feature of the Ivy Bridge / Haswell architecture. So yes, hardware specific; but it's pretty common hardware.
Nostalgia isn't what it used to be.
 
the
Gerbil Elite
Posts: 941
Joined: Tue Jun 29, 2010 2:26 am

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 11:36 am

Most of the operations to continually read/write to the same location in memory would benefit from caching and thus side step the Rowhammer exploit. This is the reason why cflush was crucial as it ensure a real/write from memory.

The scripted attack has to exploit some sort of predictability in how the Java script engine allocates and handles memory to avoid using a CPU's cache. For example, the rapid creation/destruction of objects where they're de-allocated in the script but the engine recycled the address after clearing contents. The problem with this method is avoiding cachable operations while doing so at the speeds necessary to utilize the scripting engines pre-generated objects. Using multiple threads to invoke some coherency problems could help but that means that the caching would move primarily to the shared L3 cache and not the L1 and L2 of an individual core.

Regardless, the report reads like some changes to the scripting engine could prevent this, though I'd bet the change comes with a performance cost.
Dual Opteron 6376, 96 GB DDR3, Asus KGPE-D16, GTX 970
Mac Pro Dual Xeon E5645, 48 GB DDR3, GTX 770
Core i7 [email protected] Ghz, 32 GB DDR3, GA-X79-UP5-Wifi
Core i7 [email protected] Ghz, 16 GB DDR3, GTX 970, GA-X68XP-UD4
 
I.S.T.
Gerbil XP
Posts: 486
Joined: Wed Sep 14, 2005 5:18 am

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 12:11 pm

Thank god I barely use Java and have it set to ask to activate...
 
SuperSpy
Minister of Gerbil Affairs
Posts: 2403
Joined: Thu Sep 12, 2002 9:34 pm
Location: TR Forums

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 12:32 pm

I.S.T. wrote:
Thank god I barely use Java and have it set to ask to activate...

Javascript, not Java.
Desktop: i7-4790K @4.8 GHz | 32 GB | EVGA Gefore 1060 | Windows 10 x64
Laptop: MacBook Pro 2017 2.9GHz | 16 GB | Radeon Pro 560
 
just brew it!
Administrator
Topic Author
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 12:48 pm

SuperSpy wrote:
I.S.T. wrote:
Thank god I barely use Java and have it set to ask to activate...

Javascript, not Java.

Yup. Just to clarify further: Javascript and Java are completely different things, and have almost nothing in common, other than the name. Javascript is not a plugin; it is part of the base install of all modern web browsers. Disabling it isn't really an option if you want the Web to remain functional, as doing so will break the vast majority of web sites in various ways unless you restrict your web browsing habits to sites which were developed back in the 1990s.
Nostalgia isn't what it used to be.
 
Kougar
Minister of Gerbil Affairs
Posts: 2306
Joined: Tue Dec 02, 2008 2:12 am
Location: Texas

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 1:13 pm

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. :P
 
I.S.T.
Gerbil XP
Posts: 486
Joined: Wed Sep 14, 2005 5:18 am

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 1:14 pm

SuperSpy wrote:
I.S.T. wrote:
Thank god I barely use Java and have it set to ask to activate...

Javascript, not Java.


Well, I very clearly misread the original post!
 
just brew it!
Administrator
Topic Author
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 1:15 pm

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. :P

I'm good, my desktop uses ECC RAM. :wink:
Nostalgia isn't what it used to be.
 
Glorious
Gerbilus Supremus
Posts: 12343
Joined: Tue Aug 27, 2002 6:35 pm

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 1:23 pm

Interesting.

Reading the paper, they start out by detailing how they've developed an algorithm for determining an optimal page eviction strategy for any cache size. They used that to build a native code prototype that they verified would work without clflush (though it doesn't quite work as well...), and then translated that into javascript. They claim that javascript engines now map so well to the underlying architecture that they can get near-native enough performance to trigger still this, and thus the last remaining piece is being able to pick relevant addresses.

Javascript is high-level with no such concept, but again it maps very well to the underlying architecture. They just build arrays which will inevitably match the 2MB page size and then use offsets within that array as the addresses to hammer to try and flip the adjacent rows.

http://arxiv.org/pdf/1507.06955v1.pdf

It's hilarious that their proposed countermeasure is literally making javascript engines perform worse.

Makes you wonder just how much performance is lying around at this point for something like webassembly to pick up. :wink:
 
anotherengineer
Gerbil Jedi
Posts: 1688
Joined: Fri Sep 25, 2009 1:53 pm
Location: Northern, ON Canada, Yes I know, Up in the sticks

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 1:50 pm

Wonder if that will work on my old DDR1-400 90nm ram with no java PC that my mom is using?? :)

I would probably get a call.

*the computer is slow*

I know it's 10 years old it's really slow

*no it's slow than normal, can you come look at it*

..........I guess so......................
Life doesn't change after marriage, it changes after children!
 
Kougar
Minister of Gerbil Affairs
Posts: 2306
Joined: Tue Dec 02, 2008 2:12 am
Location: Texas

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 3:47 pm

just brew it! wrote:
I'm good, my desktop uses ECC RAM. :wink:


I've read some reports that said ECC can't offer protection from rowhammering when it flips multiple bits at once.
 
Topinio
Gerbil Jedi
Posts: 1839
Joined: Mon Jan 12, 2015 9:28 am
Location: London

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 4:02 pm

Yeah, the Kim et al paper (CMU and Intel researchedrs) concluded that SECDED is not enough, as 3 bits can be flipped in a row.
Desktop: 750W Snow Silent, X11SAT-F, E3-1270 v5, 32GB ECC, RX 5700 XT, 500GB P1 + 250GB BX100 + 250GB BX100 + 4TB 7E8, XL2730Z + L22e-20
HTPC: X-650, DH67GD, i5-2500K, 4GB, GT 1030, 250GB MX500 + 1.5TB ST1500DL003, KD-43XH9196 + KA220HQ
Laptop: MBP15,2
 
The Egg
Minister of Gerbil Affairs
Posts: 2938
Joined: Sun Apr 06, 2008 4:46 pm

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 4:57 pm

Does this only happen with RAM manufactured at or smaller than a certain node size? Does the RAM need to be running at a specific speed or latency? More info needed.
 
Ryu Connor
Global Moderator
Posts: 4369
Joined: Thu Dec 27, 2001 7:00 pm
Location: Marietta, GA
Contact:

Re: Rowhammer - The Sequel

Tue Aug 04, 2015 5:52 pm

All of my written content here on TR does not represent or reflect the views of my employer or any reasonable human being. All content and actions are my own.
 
just brew it!
Administrator
Topic Author
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Rowhammer - The Sequel

Wed Aug 05, 2015 5:54 am

Kougar wrote:
just brew it! wrote:
I'm good, my desktop uses ECC RAM. :wink:

I've read some reports that said ECC can't offer protection from rowhammering when it flips multiple bits at once.

Well, in that case it'll still "protect" you in the sense that it'll at least detect the corruption in most cases and throw a hardware exception. (And a BSOD or kernel panic, while very annoying, is still preferable to a security breach.)
Nostalgia isn't what it used to be.
 
Glorious
Gerbilus Supremus
Posts: 12343
Joined: Tue Aug 27, 2002 6:35 pm

Re: Rowhammer - The Sequel

Wed Aug 05, 2015 6:01 am

JBI wrote:
I'm good, my desktop uses ECC RAM.


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.

If you read the original paper (Kim et al) they had some demo code that they said would work on Intel/AMD systems with the same DIMM as an example. They didn't really elaborate on that, virtually all of the testing that showed the pervasiveness of the problem among DIMM manufacturers was done with FPGAs doing this to DIMMs directly.

The google one (seaborn et al) that really popularized this (because they focused on real world systems) was done exclusively on laptops. They said that the workstations they tried it on didn't work; they all had ECC. They didn't elaborate on that either, much less look to see if they were logging any errors from EDAC on those systems. There was hardly any mention of it.

This latest thing was done with a particular laptop as well, the only one of the three mentioned they managed to get to work without clflush.

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.

I have to imagine that running ECC, which has a high probability of having looser timings and scrubbing, might make the hammering impossible even before we get the correction/detection side of things. If even regular desktops with DDR3 were highly likely to be vulnerable I'm sure someone would have used one as an example at this point.
 
just brew it!
Administrator
Topic Author
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Rowhammer - The Sequel

Wed Aug 05, 2015 6:21 am

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.

I may give it a try sometime. Would be interesting to see if the system logs any EDAC errors.

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.

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.
Nostalgia isn't what it used to be.
 
Glorious
Gerbilus Supremus
Posts: 12343
Joined: Tue Aug 27, 2002 6:35 pm

Re: Rowhammer - The Sequel

Wed Aug 05, 2015 7:34 am

JBI wrote:
I may give it a try sometime. Would be interesting to see if the system logs any EDAC errors.


I was thinking the same thing, but generally those systems are doing something useful so it's not as trivial to just stick a USB drive in them and reboot.

Still, I might give it a try if I get chance later this week.

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.


They imply that, but I don't see how they'd know. Fundamentally I don't think they have to ability to tell, because by looking at their pseudo-code examples for the FPGA they have a tight-loop of hammering and then compare afterwards. That would seem to preclude them from being able to claim that they were flipped at the same time, simply because they'd have no way of actually knowing. I don't think they can do anything differently either, because, much like the observer paradox, looking changes the result! :wink: (if they read the words in the adjacent rows every time they'll be refreshing them thus preventing any flips in the first place).

I would heavily suspect that scrubbing would prevent them from being able to flip any bits at all, simply because it would interrupt their intended access patterns just like in my parenthetical comment above. Supposing we ignored that constraint, adequate scrubbing would still almost certainly defeat it because the odds of simultaneous multi-bit flip in a single word would seem to be astronomical.

Why? Because even when they could trigger multiple bits:

1) They were on the cherry-picked best demonstrator from each of the three manufacturers (out of like 30-50 examples from each)
2) The difference between incidence of single errors to double errors was 2-3 orders of magnitude.
3) Even the best demonstrator from vendor "C" barely triggered any doubles at all.
4) They had a few examples of 3 and 4 flips, but they were extremely sparse, and only with the two vendors on the worst DIMMs.

This would indicate that that the probability of even being able to do anything other than DoS on an ECC system approaches implausibility.

And that was a non-real world setup. In the real world people have seemingly only had success with laptops, and since frequent refreshes have energy efficiency implications, I would not be surprised if they were (mostly) uniquely vulnerable.

EDIT:

Section 7 of the Kim paper has an interesting tidbit. They propose a probabilistic counter-measure where there is some small chance that you will open one or the other of the adjacent rows after each row close. Their scheme requires some knowledge of the underlying memory layout, but the interesting piece is that this method is actually extremely similar to what even low-level ECC scrubbing would be effectively be doing already, albeit randomly.

EDIT2: Here is the paper I keep talking about:

https://users.ece.cmu.edu/~yoonguk/pape ... isca14.pdf
 
just brew it!
Administrator
Topic Author
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Rowhammer - The Sequel

Wed Aug 05, 2015 9:14 am

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.
Nostalgia isn't what it used to be.
 
Glorious
Gerbilus Supremus
Posts: 12343
Joined: Tue Aug 27, 2002 6:35 pm

Re: Rowhammer - The Sequel

Wed Aug 05, 2015 10:23 am

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.


They specified a refresh interval of 64ms.

I agree though, I severely overestimated the likelihood the scrubbing would impede this. It looks like the low scrubbing option is typically a pass a day, which obviously has no chance at all of ever catching this.

I would still tend to think that ECC setups would be immune from this from other factors, and even if scrubbing doesn't touch any of the related rows even the occasional read of memory completely elsewhere would still lessen the impact of the hammering.
 
Kougar
Minister of Gerbil Affairs
Posts: 2306
Joined: Tue Dec 02, 2008 2:12 am
Location: Texas

Re: Rowhammer - The Sequel

Thu Aug 06, 2015 6:55 am

Don't forget that in the original rowhammer info release the researchers stated outright that some consumer DDR3 memory brands showed immunity, while others very much didn't. I would have loved to see the non-anonymized data to learn which brands built the quality memory sticks, but it's something to keep in mind if testing this yourself on desktop systems.
 
fhohj
Gerbil Team Leader
Posts: 232
Joined: Tue Dec 10, 2013 4:10 pm

Re: Rowhammer - The Sequel

Sat Aug 08, 2015 4:53 pm

Me too. I was hoping more information would emerge, but it didn't. Somebody's chips were immune. It's pretty much down to Micron, SK Hynix, and Samsung, and I'm thinking Samsung.

edit: so this thread inspired me to do a little surfing on this. just came across this.

http://forum.corsair.com/v3/showthread.php?p=777033

seems nerfing your CL will solve the problem. pretty big nerf, but it does solve the problem, seemingly. finished reading that thread. it's the top-up timings. tREF that you change.

edit 3. and I'll leave this here

For 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.
 
just brew it!
Administrator
Topic Author
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Rowhammer - The Sequel

Sat Aug 08, 2015 5:28 pm

That makes sense. Setting the refresh to occur more frequently will restore the charge in the DRAM cells to its correct level before it has a chance to drift far enough to cause a bit flip.
Nostalgia isn't what it used to be.
 
fhohj
Gerbil Team Leader
Posts: 232
Joined: Tue Dec 10, 2013 4:10 pm

Re: Rowhammer - The Sequel

Mon Aug 10, 2015 8:31 pm

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.
 
just brew it!
Administrator
Topic Author
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Rowhammer - The Sequel

Mon Aug 10, 2015 11:17 pm

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.

Yeah, it'll add to the power usage of the RAM very slightly. Probably not enough to matter unless you're talking about a mobile device.
Nostalgia isn't what it used to be.

Who is online

Users browsing this forum: No registered users and 1 guest
GZIP: On