Clarifications on extended test

[slow_computing]

Hi,
sorry in case i'm asking something stupid.
I got the (probably wrong) impression that when trying the rowhammer test on linux it should be more
efficient to produce bitfilps by using the extended_test version instead of the standard test since this uses
/proc/self/pagemap  for identifying neighboring rows. Was that a misconception?

Also it took me a (long) while to understand that nowadays modern linux kernels (i'm using 4.9 debian testing)
have zeroed out the page frame number field (bits 0-54) for regular users as a (not really perfect but better than nothing)
mitigation against rowhammer. Maybe would be worthwhile to add a check on the kernel version in the code and
warn users if they use the extended_test?

My machine is a slow, passively cooled mintbox mini with 4GB DDR3 by micron running at only 800 MHz.
The refresh rate is the standard 64 ms. The stuff is rather cheap, so i was sure there must be bitflips, but so far i
haven't seen any. Could it be that due to the slow (800 MHz) speed the attack fails because it's not possible
to hammer fast enough?


 


  

[Mark Seaborn]

On 29 March 2017 at 12:43, slow_computing <icey...@gmail.com> wrote:

Hi,
sorry in case i'm asking something stupid.
I got the (probably wrong) impression that when trying the rowhammer test on linux it should be more
efficient to produce bitfilps by using the extended_test version instead of the standard test since this uses
/proc/self/pagemap  for identifying neighboring rows. Was that a misconception?

Yes, I think that is a misconception.

I couldn't remember the exact differences between the basic rowhammer_test.cc and rowhammer_test_ext.cc, but the docs (at https://github.com/google/rowhammer-test/blob/master/extended_test/README.md) say the following:

"rowhammer_test_ext has the following differences from rowhammer_test:

* It reports the physical addresses of victim locations (memory locations where bit flips occur) and aggressor locations (pairs of memory locations which cause the bit flips when accessed).

When rowhammer_test_ext finds that accessing a batch of addresses produces a bit flip, the program tries to narrow down which pair of addresses in the batch will reproduce the bit flip.

* This version is Linux-specific, because it uses /proc/self/pagemap to find the physical addresses of pages.

* This version keeps on running when it finds a bit flip, rather than exiting."

So there's nothing there that says rowhammer_test_ext.cc could be more effective.

Looking at the code, rowhammer_test_ext.cc sets ADDR_COUNT=4, whereas rowhammer_test.cc uses addr_count=8.  That could affect the outcome in either direction.

 

My machine is a slow, passively cooled mintbox mini with 4GB DDR3 by micron running at only 800 MHz.
The refresh rate is the standard 64 ms. The stuff is rather cheap, so i was sure there must be bitflips, but so far i
haven't seen any. Could it be that due to the slow (800 MHz) speed the attack fails because it's not possible
to hammer fast enough?

Yes, it could be that the machine isn't fast enough, or it could be that the DRAM isn't faulty.

Cheers,

Mark

[slow_computing]

Thanks for clarification! Maybe the double_sided_rowhammer test is most efficient for Linux to
produce bitflips? On one hand simply because it's double-sided but also it seems to use the
/proc/self/pagemap (given the kernel allows to read it fully) to actually find a set of neighboring
rows which are then hammered for 1 full hour.