Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

91–100 of 103 posts

Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

#91

Post by rodgerd »

sliverstorm wrote: post #83
rodgerd wrote: post #49

Earlier quoted context omitted.

> Intel doesn't even ship a consumer CPU (i.e., a non-Xeon) that supports ECC. Not true - there are some Atoms that do, but they're targeted at NAS type uses. It is the case you can't get Core-series processors with ECC. AMD used to offer very broad support for ECC, but data integrity clearly didn't win market share.

data integrity clearly didn't win market share It requires more expensive, compatible DRAM right? Knowing that, it shouldn't really be super surprising. Enabling it on die is just one piece of the equation.

The problem is that if you say "fast, cheap, reliable, pick two" people will pick "fast" and "cheap". Even people who might ordinarily worry about whether their workstation is silently corrupting their data.

Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

#92

Post by geococcyxc »

lostmsu wrote: post #74
ChuckMcM wrote: post #21

Once again, I pine for ECC memory on my Laptop. I know you can get ECC SODIMMS, I got 16GB worth for a Supermicro ITX motherboard. And while the paper talks about multi-bit errors getting through ECC (which is certainly possible with enough flips) single flips causing alerts and double flips causing halts would really get your attention that something bad was happening. As opposed to silently sitting there while my m…

I don't think ECC will help. Where you can flip one memory bit, you can flip two consequently.

It will help, two bit errors are not corrected, though. The system will be rebooted and and an error should be logged.

Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

#93

Post by yuhong »

AaronFriel wrote: post #73
MichaelGG wrote: post #51

Earlier quoted context omitted.

Not just laptops! SQL Azure doesn't use ECC memory[1], which might suggest the rest of the Azure platform doesn't, either. I haven't found citations for AWS using ECC, so perhaps they don't. Maybe this could be used to break out of VMs on those platforms. 1: https://social.msdn.microsoft.com/Forums/azure/en-us/84000f7... (I remember I asked about Windows Azure, but my posting clearly says SQL Azure, so perhaps it's a…

This may be just speculation, as the memory density in cloud hosts is rarely possible with non-ECC memory. I've found that when purchasing RAM for systems, it's fairly common for server and multi-rank to imply ECC, although I've had to look at product sheets to verify that. Now, I could be wrong, but it would be quite a surprise to find out that any of the cloud services are not using ECC. I suspect they all are, but…

SQL Azure probably need less RAM than Windows Azure VMs on the other hand.

Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

#94

Post by thomasdullien »

userbinator wrote: post #88
acveilleux wrote: post #35

Earlier quoted context omitted.

They also don't want to say "DellappLenoHP" laptops could not be attacked and turn out to be wrong. Or maybe they're right but only with factory 2GB modules used between May '11 and July '13. Way too many variables to make any claims that is ethically defensible.

They could specify the detailed system configuration with the CPU, chipset, and DRAM part numbers (including date codes) so others can compare. It's much better than leaving things in the dark completely.

Remember that there is a github repo with code you can use to test your specific Hardware. Why not run it & post results?

Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

#95

Post by hannob »

AceJohnny2 wrote: post #65
tenfingers wrote: post #59

Earlier quoted context omitted.

memtest86 has this feature in beta, and it's already generating some heat. I would be personally more interested in this test on memtest86+ though.

What's the difference between memtest86 and memtest86+? OK, from WP [1]: "Memtest86 was developed by Chris Brady. After Memtest86 remained at v3.0 (2002 release) for two years, the Memtest86+ fork was created by Samuel Demeulemeester to add support for newer CPUs and chipsets. As of November 2013 the latest version of Memtest86+ is 5.01." And the original has become a commercial program by PassMark. So I think at thi…

There is a github repo with a rowhammer test based on memtest86+: https://github.com/CMU-SAFARI/rowhammer

Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

#96

Post by p1mrx »

On my desktop (DH87RL / i7-4770 / 2x8GB Crucial DDR3L-1600), rowhammer_test reported errors after ~20 iterations (less than a minute).

I went into the BIOS and tried lowering the tREFI value from 6300 to 3150 (not sure what the units are). So far, it's gone 1000 iterations with no problems detected.

Edit: Actually, the units are probably multiples of the cycle time, just like CAS latency. So, for DDR3-1600, that would mean 6300x1.25ns=7.8μs, and 3150x1.25ns=3.9μs

http://en.wikipedia.org/wiki/CAS_latency

Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

#97

Post by thomasdullien »

p1mrx wrote: post #96

On my desktop (DH87RL / i7-4770 / 2x8GB Crucial DDR3L-1600), rowhammer_test reported errors after ~20 iterations (less than a minute). I went into the BIOS and tried lowering the tREFI value from 6300 to 3150 (not sure what the units are). So far, it's gone 1000 iterations with no problems detected. Edit: Actually, the units are probably multiples of the cycle time, just like CAS latency. So, for DDR3-1600, that woul…

Single-sided or double-sided hammering?

Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

#98

Post by p1mrx »

thomasdullien wrote: post #97
p1mrx wrote: post #96

On my desktop (DH87RL / i7-4770 / 2x8GB Crucial DDR3L-1600), rowhammer_test reported errors after ~20 iterations (less than a minute). I went into the BIOS and tried lowering the tREFI value from 6300 to 3150 (not sure what the units are). So far, it's gone 1000 iterations with no problems detected. Edit: Actually, the units are probably multiples of the cycle time, just like CAS latency. So, for DDR3-1600, that woul…

Single-sided or double-sided hammering?

I used rowhammer_test.cc, which I think is single-sided.

Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

#99

Post by thomasdullien »

tux3 wrote: post #54
aselzer wrote: post #8

Earlier quoted context omitted.

Seems like my Macbook Air 2014 is not affected (with a high probability) here's the test: https://github.com/google/rowhammer-test

Thanks for the link. I haven't seen anything after 375 iterations (600s). So I may still be exploitable, but that means you'd have to keep something running at 100% CPU for > 600s and somehow have me not notice the laptop fans going crazy.

You may wish to try both single- and double-sided hammering. If you hit the right row size it is significantly more effective:

https://github.com/google/rowhammer-test/blob/master/double_...

Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

#100

Post by throwaway41597 »

p1mrx wrote: post #96

On my desktop (DH87RL / i7-4770 / 2x8GB Crucial DDR3L-1600), rowhammer_test reported errors after ~20 iterations (less than a minute). I went into the BIOS and tried lowering the tREFI value from 6300 to 3150 (not sure what the units are). So far, it's gone 1000 iterations with no problems detected. Edit: Actually, the units are probably multiples of the cycle time, just like CAS latency. So, for DDR3-1600, that woul…

I tried and it reported one error under a second. I had to reboot because gcc started to make bash crash, it seems. Then I saw the README (duh!):

  Be careful not to run this test on machines that contain important
  data.  On machines that are susceptible to the rowhammer problem, this
  test could cause bit flips that crash the machine, or worse, cause bit
  flips in data that gets written back to disc.

  **Warning #2:** If you find that a computer is susceptible to the
  rowhammer problem, you may want to avoid using it as a multi-user
  system.  Bit flips caused by row hammering breach the CPU's memory
  protection.  On a machine that is susceptible to the rowhammer
  problem, one process can corrupt pages used by other processes or by
  the kernel.
(Mine is Kingston Hyper X 2x8GB DDR3 1600MHz)
Post reply on HN