Our work shows that it is possible to trigger Rowhammer bit flips on DDR4 devices on AMD Zen 2 and Zen 3 systems despite deployed TRR mitigations. This result proves that AMD systems are equally vulnerable to Rowhammer as Intel systems, which greatly increases the attack surface, considering today’s AMD market share of around 36% on x86 desktop CPUs. This poses a significant risk as DRAM devices in the wild cannot easily be fixed, and previous work showed that Rowhammer attacks are practical, for example, in the browser, on smartphones, across VMs, and even over the network. Furthermore, we show that ZenHammer can trigger Rowhammer bit flips on a DDR5 device for the first time.
Our results show a high number of bit flips on Zen 2 and Zen 3 systems. Also, devices are more vulnerable on Zen 3 than Coffee Lake, simplifying exploitation. We can build the page table, RSA public key corruption, and sudo exploits from prior work on 7/6/4 of these devices, taking, on average, just 164/267/209 seconds.
How did you do it?
We reverse-engineered the secret DRAM address functions by adopting the DRAMA technique for AMD systems. We found that the timing routine must be changed for more reliable results. We make the key observation that a physical offset must be applied to physical addresses before recovering the DRAM address functions due to system address remapping (see Figure 1). This allows us to recover the address functions completely. However, using these address functions gives us very few bit flips on 5 and 0 of 10 devices on AMD Zen 2 and Zen 3, respectively, as we show in Table 1.
We started by looking at the refresh synchronization, which previous work (e.g., SMASH, Blacksmith) showed to be important for triggering bit flips. We demonstrate that continuous timing measurements using non-repeating rows are effective for precise and reliable refresh synchronization on AMD. The result in Listing 1 shows our improved refresh synchronization method.
We found out that the activation rate of non-uniform Rowhammer patterns on AMD Zen+/3 systems is significantly lower than on Intel Coffee Lake (see Figure 2). To investigate this, we conducted a series of experiments to find the optimal hammering instruction sequence. Our results showed that regular loads (MOV) with CLFLUSHOPT for flushing aggressors from the cache, issued immediately after accessing an aggressor (“scatter” style), is optimal. It further revealed that, unlike on Zen 2, explicit fencing after flushing is not required on Zen 3.
We further investigated how different fence types and fence scheduling policies affect Rowhammer patterns on AMD Zen systems. For this, we came up with six different pattern-aware and cache-avoiding fence scheduling policies (see Table 2) and tested them on our devices for 6 hours each to determine the device’s optimal policy. We found that on most devices on Zen 2 the policy SP_none is optimal while SP_pair is in most cases better suited on Zen 3.
How bad is it?
For our evaluation, we considered a test pool of 10x DDR4 DRAM devices covering the three major manufacturers (Samsung, Micron, SK Hynix). We let our ZenHammer fuzzer run for 3 hours with each fence type (mfence, sfence) and fence scheduling policy. After each run, the best pattern is determined by using a minisweep over 4 MiB with all found patterns. Thereafter, we swept the best pattern of the best policy over a contiguous memory area of 256 MB and reported the number of bit flips. The results in Table 3 show that our ZenHammer fuzzer is able to trigger bit flips on 7 (Zen 2) and 6 (Zen 3) of 10 DDR4 DRAM devices.
We evaluated the exploitability of these bit flips based on three attacks from previous work: (i) an attack targeting the page frame number of a page table entry (PTE) to pivot it to an attacker-controlled page table page, (ii) an attack on the RSA-2048 public key that allows recovering the associated private key used to authenticate to an SSH host, (iii) and an attack on the password verification logic of the sudoers.so library that enables gaining root privileges. We report the results in Table 4.
What about DDR5?
Finally, we tried ZenHammer on DDR5 by reverse engineering the DRAM functions on AMD Zen 4 and evaluating ten DDR5 devices. Out of these ten devices, ZenHammer could trigger ~42k flips on one device. This is the first public report of DDR5 bit flips on commodity systems in the wild. However, given that ZenHammer could not trigger flips on nine out of ten devices, we conclude that more research is necessary to find more effective patterns for DDR5 devices.
Further Information
For full details and more information about our work, please have a look at our paper, which is to appear at USENIX Security 2024 in August 2024. Our ZenHammer fuzzer is available on Github.
FAQs
Following, we provide answers to the most frequently asked questions about our work.
Why has nobody paid any attention to AMD systems before?
We believe that AMD received little attention as the original work on Rowhammer by Kim et al. showed a much higher number of bit flips on Intel systems and subsequent work also focused primarily on Intel. Further, there is much more known about the microarchitecture of Intel CPUs compared to AMD CPUs.
Are there any DDR4 devices that are safe?
Not likely. We could not trigger any bit flips on 3 and 4 of our 10 devices on Zen 2 and Zen 3, respectively. However, given that we triggered only a few bit flips on them on Intel Coffee Lake as well, we think that tuning the fuzzer further may expose bit flips on these devices too.
Why does your evaluation consider ten devices only?
Because we have a limited number of AMD Zen 2/3 machines in our lab and some of our experiments took a long time, we have decided to reduce the number of devices to ten. We made sure that our randomly chosen subset includes devices from all three major DRAM vendors.
How can I check whether my DRAM is vulnerable?
The code of our ZenHammer fuzzer, which you can use to assess your DRAM device for bit flips on AMD Zen 2/3/4 CPUs, is available on GitHub.
Why has JEDEC not fixed this issue yet?
By now we know, thanks to a better understanding, that solving Rowhammer is hard but not impossible, as we show in our previous work ProTRR and REGA. We believe that there is a lot of bureaucracy inside JEDEC that makes it difficult to properly address Rowhammer.
What about DIMMs with Error Correction Codes (ECC)?
Previous work on DDR3 showed that ECC cannot provide protection against Rowhammer. Due to the even larger number of bit flips in current DDR4 devices, we believe that ECC cannot provide complete protection against Rowhammer but just makes exploitation harder.
What if my system runs with a double refresh rate?
Besides an increased performance overhead and power consumption, previous work (e.g., Mutlu et al. and Frigo et al.) showed that doubling the refresh rate is a weak solution not providing complete protection.
Responsible Disclosure
Rowhammer is a known industry-wide issue, and we did not see a need to go through the typical disclosure process. Nonetheless, we informed AMD on February 26, 2024, and at their request, we did not publicly disclose the issue until March 25, 2024. This page was briefly online by mistake on March 21.
Acknowledgments
This research was supported by the Swiss National Science Foundation (SNSF) under NCCR Automation, grant agreement 51NF40_180545, by the Swiss State Secretariat for Education, Research and Innovation under contract number MB22.00057 (ERC-StG PROMISE), and by a Microsoft Swiss JRC grant.
