Rowhammer without CLFLUSH

[zaw...@umich.edu]

Greetings, I am Zelalem Birhanu Aweke, a PhD student at University of Michigan.  I have successfully implemented a Rowhammer attack on a DDR3-based memory system attached to a Intel sandybridge-based multiprocessor.  My attack does not use the CLFLUSH instruction, instead it creates carefully crafted memory access streams that force frequent L3 cache misses to specific DRAM rows.  Matthew Hicks, a hardware security researcher here at Michigan, has inspected my code, verified that it successfully implements the Rowhammer attack without CLFLUSH, and used it to flips DRAM bits on a Lenovo laptop.  I will be disclosing the details of the attack in a article that I am currently preparing.  Also, I want to say "thanks" to the Google security researchers that published the Intel L3 cache interleaving hash function details, the hash function on my Intel processor was very similar, and their discovery was quite useful in getting my attack to work -- thank you!

[Mark Seaborn]

On 10 May 2015 at 19:55, <zaw...@umich.edu> wrote:

Greetings, I am Zelalem Birhanu Aweke, a PhD student at University of Michigan.  I have successfully implemented a Rowhammer attack on a DDR3-based memory system attached to a Intel sandybridge-based multiprocessor.  My attack does not use the CLFLUSH instruction, instead it creates carefully crafted memory access streams that force frequent L3 cache misses to specific DRAM rows.  Matthew Hicks, a hardware security researcher here at Michigan, has inspected my code, verified that it successfully implements the Rowhammer attack without CLFLUSH, and used it to flips DRAM bits on a Lenovo laptop.  I will be disclosing the details of the attack in a article that I am currently preparing.  Also, I want to say "thanks" to the Google security researchers that published the Intel L3 cache interleaving hash function details, the hash function on my Intel processor was very similar, and their discovery was quite useful in getting my attack to work -- thank you!

Ah, very interesting!  Thanks for sharing.

I have been working on doing the same thing, which is why I published that description of the L3 cache mapping function [1].  When you say that your machine uses a mapping that's similar, do you mean that it's similar but different to the mapping I described?

Is your test implemented in C/C++?  Are you using knowledge of physical addresses (e.g. /proc/self/pagemap) to pick addresses that map to the same cache set, or are you finding such addresses by other means (e.g. by timing memory accesses)?  There is an algorithm for doing the latter which was described fairly recently in the paper "The Spy in the Sandbox -- Practical Cache Attacks in Javascript" [2].  I mention that in case you weren't aware of it already.

I also found that I could get a bit flip on my test machine (the machine from [1]) using cached memory accesses, without CLFLUSH.  So far, though, I took a short cut to doing that, as follows:

 1) Find the physical addresses of aggressor locations that cause repeatable bit flips (using rowhammer_test_ext, which uses /proc/self/pagemap).

 2) For each such aggressor address:

   * Find 13 other addresses that map to the same cache set (using /proc/self/pagemap again).

   * Repeatedly read from those 14 addresses (i.e. the aggressor + 13 other addresses) [3].

   * Check memory for bit flips.

So far I haven't tried hooking this up to the cache profiling algorithm from [2] in order to try this using random address selection, without using /proc/self/pagemap.  Have you tried that?

Cheers,

Mark

[1] http://lackingrhoticity.blogspot.com/2015/04/l3-cache-mapping-on-sandy-bridge-cpus.html

[2] http://arxiv.org/abs/1502.07373

[3] Note that having 13 addresses in total should be enough if the L3 cache's eviction policy is LRU or Pseudo-LRU, though some experiments that I've done suggest that the policy is something other than LRU.  Adding a 14th address doesn't slow down the access rate very much, but I'm not yet sure how much it's necessary.

[Mark Seaborn]

On 10 May 2015 at 20:57, Mark Seaborn <msea...@chromium.org> wrote:

On 10 May 2015 at 19:55, <zaw...@umich.edu> wrote:

Greetings, I am Zelalem Birhanu Aweke, a PhD student at University of Michigan.  I have successfully implemented a Rowhammer attack on a DDR3-based memory system attached to a Intel sandybridge-based multiprocessor.  My attack does not use the CLFLUSH instruction, instead it creates carefully crafted memory access streams that force frequent L3 cache misses to specific DRAM rows.  Matthew Hicks, a hardware security researcher here at Michigan, has inspected my code, verified that it successfully implements the Rowhammer attack without CLFLUSH, and used it to flips DRAM bits on a Lenovo laptop.  I will be disclosing the details of the attack in a article that I am currently preparing.  Also, I want to say "thanks" to the Google security researchers that published the Intel L3 cache interleaving hash function details, the hash function on my Intel processor was very similar, and their discovery was quite useful in getting my attack to work -- thank you!

Ah, very interesting!  Thanks for sharing.

I have been working on doing the same thing, which is why I published that description of the L3 cache mapping function [1].  When you say that your machine uses a mapping that's similar, do you mean that it's similar but different to the mapping I described?

On that point:  If it's possible to induce bit flips by row hammering via cached memory accesses, this raises the question of whether it's also possible to do double-sided row hammering this way.

I've written up an analysis of that:

http://lackingrhoticity.blogspot.com/2015/05/can-cached-memory-accesses-do-double.html

My answer is no, cached accesses can't do double-sided hammering.  However, the analysis only applies if the L3/DRAM mappings that I've deduced are correct.  The analysis would need to be redone for other machines or if I've got those mappings wrong.

Cheers,

Mark

[pablo rojas]

ho El domingo, 10 de mayo de 2015, 22:55:00 (UTC-4), zaw ... @ umich.edu escribio:me encanto la informacion de Rowhammer. me gustaria saber si se podria aplicar a scene de la PS3? gracias.

Saludos, soy Zelalem Birhanu Aweke, un estudiante de doctorado en la Universidad de Michigan. He implementado con éxito un ataque Rowhammer en un sistema de memoria basada en DDR3 unida a un multiprocesador basado SandyBridge en Intel. Mi ataque no utiliza la instrucción CLFLUSH, sino que crea cuidadosamente elaborado flujos de acceso a memoria que obligan a frecuentes fallos de caché L3 a filas DRAM específicos.   Mateo Hicks, un investigador de seguridad de hardware  aquí en Michigan, ha inspeccionado mi código, verificó que con éxito  implementa el ataque Rowhammer sin CLFLUSH, y lo utilizó para voltea DRAM  trozos en un portátil Lenovo.   Voy a revelar los detalles del ataque en un artículo que actualmente estoy preparando. Además, quiero decir "gracias" a los investigadores de seguridad de Google que publican los detalles de la función Intel L3 cache intercalación de hash, la función hash en mi procesador Intel era muy similar, y su descubrimiento fue bastante útil para obtener mi ataque de trabajar - gracias!

[daniel...@iaik.tugraz.at]

   * Repeatedly read from those 14 addresses (i.e. the aggressor + 13 other addresses) [3].

Did you access them in a specific order which tries to put more pressure on the aggressor?

[Mark Seaborn]

On 19 May 2015 at 08:30, <daniel...@iaik.tugraz.at> wrote:

   * Repeatedly read from those 14 addresses (i.e. the aggressor + 13 other addresses) [3].

Did you access them in a specific order which tries to put more pressure on the aggressor?

No, the code I wrote just accesses the same-cache-set addresses in order.  It doesn't do any clever ordering of the memory accesses.

Here is the code:

https://github.com/google/rowhammer-test/blob/c1d2bd9f629281402c10bb10e52bc1f1faf59cc4/cached_rowhammer/cached_rowhammer.cc

I am prompted to share the code by the fact that you wrote, in your draft "Rowhammer.js" paper (http://arxiv.org/abs/1507.06955v1), "Seaborn and Birhanu have reported to be able to flip bits on Sandy Bridge CPUs by means of cache eviction, without providing any implementation details".  I should have shared the code earlier. :-)

Cheers,

Mark