ZenHammer: Rowhammer Attacks on AMD Zen-based Platforms

ZenHammer: Rowhammer Attacks on AMD Zen-based Platforms

Speakers: Patrick Jattke

Conference: USENIX Security '24

YouTube: https://www.youtube.com/watch?v=6XWau2PsuNE

Overview

For over a decade, AMD has steadily increased its market share in the x86 CPU landscape, with roughly one-third of all x86 CPUs sold today originating from the company. Despite this significant presence, academic and industry research into Rowhammer attacks on AMD's Zen-based platforms has been notably scarce since their initial release in 2017. This gap in research left a critical question unanswered: are AMD Zen systems vulnerable to Rowhammer, a pervasive memory disturbance error that has plagued Intel platforms for years?

The ZenHammer project, presented by Patrick Jattke at USENIX Security '24, sought to definitively answer this question. The research comprehensively investigated the susceptibility of AMD Zen 2, Zen 3, and Zen 4 architectures to Rowhammer attacks. The findings reveal a significant vulnerability across these platforms, demonstrating bit flips on a majority of tested DIMMs and, for the first time, on DDR5 DIMMs within a Zen 4 system. Furthermore, ZenHammer showcases an alarmingly high rate of bit flips on Zen 3, exceeding those observed on Intel Coffee Lake by up to 46 times, and successfully culminates in an end-to-end arbitrary read/write exploit.

This work marks a pivotal moment in Rowhammer research, providing the first public disclosure of the previously secret DRAM address mappings for AMD Zen architectures. By overcoming significant technical hurdles related to these mappings and the nuances of AMD's memory controllers, ZenHammer not only confirms AMD's susceptibility but also introduces novel techniques for refresh synchronization and hammering optimization. The implications are far-reaching, underscoring the need for renewed focus on Rowhammer mitigations within AMD's ecosystem and for memory manufacturers developing future DRAM technologies.

Background

▶ Watch: Introduction: Rowhammer research gap on AMD Zen (0:00)

To understand Rowhammer, it's essential to grasp the fundamental architecture of DRAM (Dynamic Random-Access Memory). Multiple DRAM chips are typically mounted on a DIMM (Dual In-line Memory Module). Each DRAM chip is internally organized into several banks, which are further grouped into bank groups. Within each bank, memory is structured as a matrix of rows and columns, with each individual cell storing a single bit of information as an electrical charge.

When data is accessed (read or written) from a specific row in a DRAM bank, the entire row must first be loaded into a temporary storage area known as the row buffer. After modification (for writes) or access (for reads), the data is written back from the row buffer to the original row in the bank. This process is time-consuming. If a different row within the same bank is accessed shortly after another, it causes a measurable delay as the current row buffer content must be flushed and the new row loaded. This timing side channel can be exploited to identify rows belonging to the same bank.

The Rowhammer vulnerability is a memory disturbance error that arises from this repeated access pattern. It occurs when two adjacent rows, known as aggressor rows, are accessed rapidly and repeatedly. The victim row, positioned directly between these two aggressors, experiences charge leakage due to electrical interference from the frequent activations of its neighbors. If this "hammering" is repeated many times over a short period, the charge in the victim row's cells can deplete sufficiently to cause a bit flip – a change from a 0 to a 1, or vice versa. The most common and effective pattern for Rowhammer is the double-sided pattern, where two aggressor rows sandwich a single victim row.

Mounting a successful Rowhammer attack requires an extremely precise ability to address specific physical rows in DRAM. This necessitates knowledge of the DRAM address mappings, which are the complex, often proprietary functions used by the CPU's integrated memory controller to translate a physical memory address (used by the CPU) into a DRAM-specific address (comprising chip, bank group, bank, row, and column identifiers). For Intel systems, these mappings have been extensively reverse-engineered. However, prior to ZenHammer, these critical mappings for AMD Zen-based systems remained undisclosed and un-reverse-engineered since the platform's debut in 2017, representing a significant barrier to Rowhammer research and exploitation on AMD hardware.

Key Findings

▶ Watch: Discovery: Nonlinear DRAM functions require address offset (4:00)

The ZenHammer research yielded several groundbreaking findings that fundamentally alter the understanding of Rowhammer susceptibility on AMD Zen platforms:

• First Disclosure of AMD DRAM Address Mappings: ZenHammer successfully reverse-engineered and publicly disclosed the previously secret DRAM address mappings for AMD Zen 2, Zen 3, and Zen 4 architectures. Crucially, this included the discovery of system-specific address offsets required due to non-linear mapping functions, a unique characteristic not found in prior Intel research.
• Widespread Bit Flips on Zen Platforms: The project demonstrated widespread Rowhammer vulnerability:
• Bit flips were found on 7 out of 10 tested DIMMs on Zen 2 systems.
• Bit flips were found on 6 out of 10 tested DIMMs on Zen 3 systems.
• Bit flips were found on 1 out of 10 tested DDR5 DIMMs on Zen 4, marking the first documented bit flips on DDR5 memory using a Zen platform.
• Significantly Higher Bit Flip Rates on Zen 3: ZenHammer observed a dramatically higher number of bit flips on Zen 3 systems compared to Intel Coffee Lake, with some configurations yielding up to 46 times more bit flips. This indicates a potentially greater susceptibility of certain Zen 3 memory configurations to Rowhammer.
• Novel Refresh Synchronization Technique: The researchers developed a continuous non-repeating refresh synchronization routine. This innovation overcomes limitations of previous synchronization methods, especially on Zen 3 where refresh signals were difficult to detect, by eliminating blind spots and improving precision.
• Optimized Hammering Instruction Sequences: Through systematic testing, ZenHammer identified specific hammering instruction sequences that drastically increase the effective activation rate. Using load instructions with scattered flushing and sfence or no fences proved most effective, significantly improving bit flip likelihood and count.
• Successful End-to-End PTE Attack: The team reproduced an end-to-end Page Table Entry (PTE) attack on AMD Zen 3, demonstrating how the observed bit flips can be exploited to achieve an arbitrary read/write primitive. This exploit could achieve root privileges in as little as 2 seconds on Zen 3 and 6 seconds on Zen 2.

Technical Deep Dive

▶ Watch: Initial ZenHammer results and TRR mitigation challenge (5:00)

The ZenHammer project tackled two primary technical challenges to achieve successful Rowhammer attacks on AMD Zen-based platforms: reverse-engineering the elusive DRAM address mappings and bypassing existing Rowhammer mitigations.

Challenge 1: Reverse Engineering DRAM Address Mappings

The initial hurdle was the lack of public knowledge regarding AMD's DRAM address mappings. The traditional approach, exemplified by tools like Blacksmith, involves a two-step process:

1. Bank Conflict Clusters: Create clusters of physical addresses that are known to map to the same DRAM bank by exploiting the bank conflict timing side channel.
2. Brute-Force Functions: Attempt to brute-force 2-bit functions (e.g., (address >> X) & Y) against these clusters. A valid function should produce a constant value (e.g., 0) for half the cluster and a different constant (e.g., 1) for the other half.

However, applying this established approach to AMD Zen systems proved insufficient. The researchers found that while they could recover mappings, these only worked on limited memory regions. Furthermore, when applying these candidate functions to larger memory blocks, the distribution of function output values (0s and 1s) was unequal, suggesting an underlying complexity not present in Intel systems.

ZenHammer's breakthrough involved hypothesizing a non-linearity in the DRAM functions, specifically requiring an address offset. Through systematic testing, they discovered that by subtracting a specific, system-specific offset (e.g., 768 megabytes in one example) from the physical addresses before applying the mapping functions, they could achieve the expected equal distribution of function values. This non-linearity is attributed to how AMD systems remap certain PCI address ranges within the physical address space. This offset is unique to each system but can be recovered with pseudo-access. A second crucial observation was the necessity of using memory blocks larger than 1 gigabyte to reliably recover these address functions on Zen platforms. With these insights, ZenHammer successfully recovered the correct DRAM address functions, revealing typical staircase patterns similar to those observed on Intel systems, and published results for various DRAM configurations.

Challenge 2: Bypassing DRAM Rowhammer Mitigations

Simply porting the newly discovered DRAM address functions was not enough for effective Rowhammer on Zen. Initial attempts using a Blacksmith fork, dubbed SandHammer, resulted in very few bit flips on Zen 2 and none on Zen 3, despite 6 hours of fuzzing. This suggested that AMD's internal Target Row Refresh (TRR) mitigations were likely effective. These mitigations, often acting in conjunction with periodic DRAM refreshes, aim to detect and preemptively refresh potential victim rows.

To overcome this, ZenHammer addressed two key aspects: refresh synchronization and optimizing the activation rate.

Refresh Synchronization

State-of-the-art Rowhammer attacks, such as those implemented in Blacksmith and Smash, synchronize their hammering patterns with the DRAM refresh command. This is crucial because TRR mitigations might only trigger on a forced refresh, and unsynchronized hammering can allow the mitigation to easily "catch" the aggressor accesses.

The researchers initially measured the time between refreshes on Zen 2 and Zen 3. While Zen 2 allowed for reliable refresh detection, Zen 3 presented an unclear signal, making synchronization difficult. Analyzing the synchronization routine revealed blind spots: if a refresh occurred rapidly between two measurements (T1 and T2) within the synchronization routine, it would go undetected.

ZenHammer proposed a novel continuous non-repeating refresh synchronization routine to address this. This routine incorporates two key improvements:

1. Distinct Rows: It uses distinct rows for synchronization to avoid the need for repeatedly flushing CPU caches, which can introduce timing noise.
2. Continuous Timing Measurement: Instead of discrete measurements, it continuously reuses the last timing measurement as the start of the next round. This eliminates the blind spots by ensuring no gaps in observation.

This new routine dramatically improved refresh synchronization precision, particularly on Zen 3, where using 64 rows (compared to the original 2) yielded significantly more precise results.

Optimizing Activation Rate

Another critical factor is the pattern length, which is limited by the DRAM's refresh window (typically 64 milliseconds). Within this window, the number of effective activations (accesses to aggressor rows that hit DRAM, not the CPU cache) must be sufficient to trigger bit flips and bypass mitigations. Initial tests showed that the original Blacksmith code achieved only about half the number of activations on Zen 2 and Zen 3 compared to Intel Coffee Lake. Assuming a need for at least 18 aggressors to bypass TRR, requiring 36,000 activations, this rate was deemed too low for many devices.

To maximize activations, ZenHammer systematically tested different hammering instruction sequences, exploring:

• Cache flushing instructions: clflush and clflushopt.
• Flushing styles: Gathered (access all aggressors, then flush all) vs. scattered (access, flush, access, flush).
• Memory barriers: Instructions like sfence.
• Access types and vector instructions.

The results indicated that using load instructions with scattered flushing and sfence (or even no fences in some cases) achieved the highest number of activations, approaching the theoretical maximum. Critically, the research also identified specific sequences that resulted in undesirable cache hits, which must be avoided for effective Rowhammer.

Applying these optimizations drastically improved the effectiveness of ZenHammer. On Zen 2, the number of devices exhibiting bit flips increased from 5 to 7. More remarkably, on Zen 3, where no bit flips were initially found, 6 devices now showed vulnerability. Furthermore, four Zen 2 devices and five Zen 3 devices showed a higher number of bit flips than on Coffee Lake, including one Hynix device (H0) that was previously immune.

Demo / Proof of Concept

▶ Watch: Introducing new continuous non-repeating refresh synchronization (7:15)

ZenHammer culminated in a compelling demonstration of an end-to-end Page Table Entry (PTE) attack on an AMD Zen 3 system, showcasing the practical exploitability of the discovered Rowhammer vulnerabilities. The goal of this attack was to achieve an arbitrary read/write primitive, which is a fundamental step towards gaining full system control or root privileges.

The demonstration followed a series of precise steps:

1. Initial State: The system was shown to be operating under regular user privileges, confirming no prior elevated access.
2. Pattern Loading: A specific Rowhammer pattern, previously identified during a templating phase on the Zen 3 machine, was loaded. This pattern is tailored to the DRAM address mappings and mitigation characteristics of the target system.
3. Memory Allocation: Distinct memory regions were allocated for the custom refresh synchronization routine and for the actual hammering operation. This ensures proper isolation and control over the memory accesses.
4. DRAM Address Mapping (Coloring): The crucial step of page coloring was performed. This involves determining the DRAM address mappings for the allocated memory regions, often leveraging techniques like transparent huge pages to manipulate physical memory layout and ensure aggressor and victim pages are positioned correctly in DRAM.
5. Hammering Initiation: The optimized hammering routine was initiated. The system continuously hammers the aggressor rows while monitoring the victim rows for bit flips.
6. Repeatable Bit Flip Detection: Upon detecting a bit flip, the system attempts to verify its repeatability. A pattern was considered viable for exploitation if it reliably produced bit flips five times consecutively.
7. PTE Spraying and Corruption: Once a repeatable bit flip pattern was identified, the system proceeded to "spray" Page Table Entries (PTEs) across memory. PTEs are critical kernel data structures that map virtual memory addresses to physical ones. By strategically placing these PTEs, the researchers aimed to make one of them a victim of the Rowhammer attack. The identified bit flip was then used to corrupt a specific bit within a PTE.
8. Root Shell Acquisition: The corrupted PTE, which now incorrectly maps a memory page, was exploited to gain an arbitrary read/write primitive. This primitive was then used to modify kernel data structures, ultimately leading to the acquisition of a root shell, demonstrating full administrative control over the system.

The demonstration showcased the high reliability and speed of the exploit, achieving root privileges in as little as 2 seconds on Zen 3 and 6 seconds on Zen 2, highlighting the severe implications of these Rowhammer vulnerabilities. The project also demonstrated bit flips on Zen 4 DDR5 DIMMs, although a full end-to-end exploit was not shown for this platform, indicating the need for further research into DDR5 resilience.

Defensive Implications

▶ Watch: Demonstrating improved refresh synchronization on Zen 3 (8:00)

The findings of ZenHammer carry significant implications for both hardware manufacturers and system defenders. The clear demonstration that AMD Zen platforms are not only vulnerable to Rowhammer but, in some cases, exhibit even higher bit flip rates than comparable Intel systems (up to 46x on Zen 3 vs. Coffee Lake) necessitates a re-evaluation of current defensive strategies.

1. Hardware-Level Mitigations are Insufficient: The fact that ZenHammer could consistently trigger bit flips and even achieve an end-to-end exploit on Zen 3, despite AMD's presumed Target Row Refresh (TRR) mitigations, indicates that these hardware-level protections are not robust enough against sophisticated, optimized attacks. Memory manufacturers (e.g., Hynix, Micron, Samsung) and CPU designers (AMD) must invest in more effective and adaptive TRR mechanisms or explore novel hardware designs that inherently resist charge leakage. The observation that DDR5 is generally more resilient but still vulnerable on Zen 4 suggests that while progress has been made, the problem persists in newer memory technologies.
2. Need for AMD-Specific Mitigation Research: Historically, much of the Rowhammer mitigation research has focused on Intel architectures. ZenHammer's discovery of non-linear DRAM address mappings requiring specific offsets and the challenges in refresh synchronization on Zen 3 highlight that AMD's memory controller idiosyncrasies require dedicated research into platform-specific software and hardware mitigations.
3. Software-Based Defenses Remain Challenging: While operating system-level page coloring and memory isolation techniques can theoretically mitigate some Rowhammer attacks by separating aggressor and victim pages, their effectiveness is limited against advanced attacks that can precisely control physical memory allocation and bypass cache mechanisms. Implementing such defenses without significant performance overhead remains a difficult problem. Furthermore, the difficulty of accurately mapping virtual to physical addresses for coloring without kernel-level access makes user-space mitigations highly challenging.
4. Supply Chain Vigilance: The varying susceptibility across different DIMM manufacturers and even within the same manufacturer's product lines underscores the need for purchasers of memory and systems to be aware of the potential for differing levels of Rowhammer resilience. While not a direct "defense," it emphasizes the importance of understanding the security posture of hardware components.
5. Firmware and OS Updates: Although Rowhammer is a hardware vulnerability, microcode updates from AMD and operating system patches can sometimes introduce or improve software-assisted mitigations. Keeping systems updated remains a general best practice, even if a full solution to Rowhammer is not yet available.

In essence, ZenHammer serves as a critical wake-up call, demonstrating that AMD systems are equally, if not more, susceptible to Rowhammer than their Intel counterparts. This necessitates a concerted effort from the entire computing ecosystem to develop more robust, hardware-rooted solutions to this persistent memory security threat.

Key Takeaways

• AMD Zen-based platforms (Zen 2, Zen 3, Zen 4) are demonstrably vulnerable to Rowhammer attacks, challenging the prior assumption of their immunity.
• The secret DRAM address mappings for Zen 2, Zen 3, and Zen 4, including their crucial non-linear offsets, have been successfully reverse-engineered and disclosed.
• Effective Rowhammer on Zen requires sophisticated techniques, including novel continuous non-repeating refresh synchronization and optimized hammering instruction sequences (e.g., load instructions with scattered sfence flushing).
• Zen 3 systems exhibited alarmingly high bit flip rates, up to 46 times greater than Intel Coffee Lake in some cases, highlighting a significant vulnerability.
• The research achieved the first documented bit flips on DDR5 DIMMs (on Zen 4), indicating that while DDR5 may offer increased resilience, it is not immune to Rowhammer.
• An end-to-end Page Table Entry (PTE) attack was successfully reproduced on Zen 3, demonstrating that Rowhammer bit flips can be exploited to gain arbitrary read/write primitives and achieve root privileges in seconds (2s on Zen 3, 6s on Zen 2).

About the Speaker(s)

Patrick Jattke is the researcher who presented the ZenHammer work at USENIX Security '24. His presentation detailed the comprehensive investigation into Rowhammer vulnerabilities on AMD Zen-based platforms, including the methodologies, findings, and implications of the research. The work represents a significant contribution to the understanding of memory security on contemporary x86 architectures.