Rowhammer: Beating DRAM into Submission

Way back in 2014, a DRAM vulnerability called Rowhammer was revealed. This is a silicon vulnerability. As the capacity of DRAMs has gone up, the size of the capacitor that holds each bit has shrunk, and as a result each bit is represented by fewer and fewer electrons. Not only that, each row in the memory array is closer to its neighbor and so more electrically coupled. The original Rowhammer showed that by "hammering" one row of the memory by intensively writing values to it, it was possible to cause bits to flip on an adjacent row. When it was first announced, it was a bit of a theoretical vulnerability since it required physical access to the computer, and it was hard to target a useful bit to flip to cause something bad to happen (or good, if you are looking at it from the point of view of the bad guy). Back in 2014, I was still at Semiwiki and I thought I wrote about it, but I can't find the post anymore.

Various approaches to mitigation have been tried. The most obvious is to use an error-correcting code (ECC) to correct the flipped bit. Increasingly, DRAM has ECC to handle the fact that smaller bit capacitors have more single-bit errors. But some Rowhammer attacks flip more than one bit. A better approach is to notice that a row is getting hammered, and force an early DRAM refresh of that row. DRAM does not hold its value forever, and as a result, every few milliseconds each row needs to be read and re-written to make sure the memory doesn't forget. This is called target-row-refresh or TRR. Even just refreshing all the rows at double the normal frequency seems to provide a lot of defense against Rowhammer. Other approaches watch out for extremely high numbers of cache misses. By its nature, Rowhammer has to cause cache misses otherwise its memory accesses never make it to the DRAM chips to cause trouble.

But that was seven years ago.

A month ago, Google's Project Zero, which looks for security vulnerabilities, hoping to identify them before the bad guys find them, announced a new version of the attack called "half-double". Google has been working in this area since the original Rowhammer. As it says in its security blog:

Rowhammer was first discussed in a paper in 2014 for what was then the mainstream generation of DRAM: DDR3. The following year, Google’s Project Zero released a working privilege-escalation exploit. In response, DRAM manufacturers implemented proprietary logic inside their chips that attempted to track frequently accessed addresses and reactively mitigate when necessary.

As DDR4 became widely adopted, it appeared as though Rowhammer had faded away thanks in part to these built-in defense mechanisms. However, in 2020, the TRRespass paper showed how to reverse-engineer and neutralize the defense by distributing accesses, demonstrating that Rowhammer techniques are still viable. Earlier this year, the SMASH research went one step further and demonstrated exploitation from JavaScript, without invoking cache-management primitives or system calls.

The original Rowhammer causes bits to flip by hammering the adjacent row. Half-double causes bits to flip the second row away, by hammering one row, then writing the intermediate row, and flipping bits in the row after that. Google gives a bit more detail in their blog post:

Given three consecutive rows A, B, and C, we were able to attack C by directing a very large number of accesses to A, along with just a handful (~dozens) to B. Based on our experiments, accesses to B have a non-linear gating effect, in which they appear to “transport” the Rowhammer effect of A onto C. ... Half-Double is an intrinsic property of the underlying silicon substrate. This is likely an indication that the electrical coupling responsible for Rowhammer is a property of distance, effectively becoming stronger and longer-ranged as cell geometries shrink down. Distances greater than two are conceivable.

The organization that deals with all things DRAM is called JEDEC. It is responsible for things like DDR4 and LPDDR5 (and all the older standards). The original Rowhammer was disclosed in 2014, and standards since then have included mitigation for Rowhammer. As Google said in the paragraph above "it appeared as though Rowhammer had faded away thanks in part to these built-in defense mechanisms". But if there is one truth in security, it is that the attacks built on each other and only get harder to defend against. Once a weakness is found in an encryption algorithm, for example, it never becomes unfound. Google says it has been working with JEDEC to find possible solutions to the Rowhammer (and the Half-Double Rowhammer) problems. JEDEC has published two documents on Rowhammer (not Half-Double though) here and here, but you have to be a JEDEC member to read them. Wikipedia has an extensive entry on Rowhammer.

Spectre and Meltdown

Google also says in its post:

Much like speculative execution vulnerabilities in CPUs, Rowhammer is a breach of the security guarantees made by the underlying hardware.

Spectre and Meltdown burst onto the scene in the first few days of 2017, having been hiding in plain sight inside any processor with speculative execution for about twenty years. The actual mechanism of the vulnerability is also around memory, but the way it works is totally different. The memory is not corrupted, instead a byte that should be unreadable is used to access a cache location, and this can be detected and so the value of the byte determined. For details, see my posts:

• Spectre/Meltdown & What It Means for Future Design 1
• Spectre/Meltdown & What It Means for Future Design 2
• Spectre/Meltdown & What It Means for Future Design 3

When Dave Patterson first heard about these vulnerabilities, he said he expected the data could be extracted at "like five hundred bits per century". It turned out to be more like 500K bits per second. These vulnerabilities have proved very difficult to mitigate without killing the performance of modern processors, and much worse to try and mitigate in existing processors already in the field.

In the same way, we can hardly increase the space between rows in DRAM without killing the increase in capacity that modern computers and smartphones depend on. The vulnerability will only get worse with each new generation of DRAM without proper mitigation.

Learn More

Read the Google security blog post Introducing Half-Double: New hammering technique for DRAM Rowhammer bug.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.

.