Boffins find if you torture AMD Zen+, Zen 2 CPUs enough, they are vulnerable to Meltdown-like attack

Chip biz's fix involves performance-inhibiting LFENCE, if warranted

Computer scientists at TU Dresden in Germany have found that AMD's Zen processor family is vulnerable to a data-bothering Meltdown-like attack after all.

Exploiting this weakness is an academic exercise, it seems; there are more practical and easier ways for malware and malicious users to interfere with systems. If anything, it reminds us that modern CPU architectures have all kinds of side-channels, with some probably still left to find.

In a paper [PDF] titled "Transient Execution of Non-Canonical Accesses," released via ArXiv, Saidgani Musaev and Christof Fetzer analyzed AMD Zen+ and Zen 2 chips – namely the Epyc 7262, Ryzen 7 2700X, and the Threadripper 2990WX – and found that they were able to adversely manipulate the operation of the CPU cores.

Meltdown, first disclosed in early 2018, breaks the barrier between user applications and the operating system, allowing malware running on a vulnerable computer – or a rogue logged-in user – to slowly figure out the contents of protected kernel memory and any secrets therein, such as keys and passwords.

When the Meltdown and Spectre flaws were revealed, researchers initially said Meltdown had only been verified on Intel x86 chips. That list later expanded to cover IBM Power parts and an Arm Cortex core, though it was unclear whether AMD processors were vulnerable.

AMD claimed its processors were not affected by Meltdown. The way its chips executed load instructions meant data would not be fetched if architecturally disallowed in the processor's current execution context, it said. In other words, load instructions executed in user mode can't be used to discern the contents of kernel-mode memory, as expected.

Musaev and Fetzer say that's true for classical Meltdown attacks that rely on fetching data from the L1 data cache and for a variant called Microarchitectural Data Sampling (MDS) that targets specific buffers. But they found another way to poison the way in which a CPU core access data in memory "that is very similar to Meltdown-type behavior."

Crucially, their technique cannot be used by one process to read the memory of another process or of the kernel; instead, it can be used by one thread in a program to affect another thread in the same virtual memory space. In other words, it's not as straight forward as a classic Meltdown attack in which, say, a rogue application siphons off keys from kernel memory.

"The violation we report does not lead to cross address space leaks, but it provides a reliable way to force an illegal dataflow between microarchitectural elements," they explain in their paper. "Unlike the previous AMD vulnerabilities, the flaw we report is the first flaw that proves that it is possible to force an illegal data flow between microarchitectural elements."

The TU duo found that in order for a load instruction to be issued into the instruction pipeline, the virtual address for the fetch needs to match an entry in the TLB, which maps virtual to physical memory addresses. However, when the CPU core transiently executes the load instruction – ie, it executes the instruction out of program order in anticipation of it being needed – only the canonical part of the virtual address, ie: bits 47 to 0, is used.

When a non-canonical pointer VA1 is used in a load instruction, if the canonical part of the virtual address matches canonical entry VA2 in the TLB, the contents of memory at VA2 can end up being passed transiently to the load rather than the contents at VA1. That means it's possible for one thread to leak data to another.

However, if you have control of one thread in a program, and you wish to leak information from another thread in the application, you don't need CPU-level flaws: you're in the same address space, you can already access it all. As the duo noted, this weakness is more usefully exploited by injecting arbitrary data into another thread to change its operation. It might be that you've managed to hijack a thread in a program sandbox, but you want to influence another thread and can only do that by injecting data into that other thread as opposed to altering its variables and other state.

The team did admit it could find no vulnerable code sequences in the SpiderMonkey JavaScript engine used in Firefox, nor in the Linux kernel.

"The consequence of having a code snippet vulnerable to such behavior may allow an attacker to poison the transient execution of the AMD CPU from the microarchitectural element," the boffins said. "In addition, this discovery shows that AMD does implement speculation on memory accesses similar to Meltdown-type attacks, suggesting that even more, similar flaws might be yet to unveil."

It may be possible to use this research to "amplify other microarchitectural attacks," as the duo put it.

AMD issued a security advisory for this particular issue earlier this month, for CVE-2020-12965. "When combined with specific software sequences, AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage," the advisory says.

AMD's recommended mitigation is similar to that advised for Intel x86 chips: software vendors are advised to analyze their code for transient execution vulnerabilities and insert an LFENCE instruction, which comes with a performance hit, among other possible interventions [PDF].

The researchers also said that any Intel CPU vulnerable to MDS attacks should also be vulnerable to this technique, though presumably existing LFENCE-based defenses would offer protection. They tested an MDS-resistant Intel Core i7-10510U and found it was unaffected. ®