Single Sided Rowhammer Attack

Today, I would like to run through the Rowhammer test code that Google Project Zero posted in its Github repository. This blog post will focus on the single sided Rowhammer using random address selection because it is simple and can be understood without knowledge in the LINUX system side of things. Rowhammering is an exploit in modern DRAMS due to high density of cells that reside in the memory device. More can be read in the Google Project Zero’s blogpost. The intention of this blog post isn’t to analyze the single-sided row hammer attack, but to explain briefly how the program works.

So how does this code work? The program first allocates 1GB of memory. Then, in a tight loop, random eight addresses are chosen from the heap. At one address at a time, the program reads data (should be zero) from the chosen addresses. Google chose to read from a memory to a variable to replicate accessing a memory address. While not as fast as using x86 ‘mov’ assembly, the C instruction is still able to read the data sequentially rapidly. After the eight addresses are read, at one address at a time, they are flushed from the CPU cache. There is no C++ function to flush a CPU’s cache, so ‘clflush’ assembly instruction is inlined within the program.  The above reading and flushing procedure is done 4320000 times, which result in about 20 ns for each memory access. Once the read and flush instructions are done, the program reads the 1GB heap to see if there is any flipped bit in the memory. When the test runs, the program prints the following messages to standard out as shown below. The test will run until it finds a flipped bit.

What makes this test harder to run is that only 1GB memory is allocated. Many computers these days have more than 16GB of RAM. In the case of 32GB memory with 64 banks, the chance of the having the 1GB heap in the same bank reduces significantly. Also depends on how the kernel maps the virtual memory address to the physical address, the heap can be split between different banks of the RAM. Nonetheless, this code is cross-compatible in LINUX and MAC OS. What is neat about this program is that the program runs on the virtual memory addresses and, therefore, the program does not rely on CPU’s memory controller.