AMD Admits Their Zen 3 CPUs Are Vulnerable To Spectre-STL Attacks
The American chip-designer AMD has published a long report where they admit that the Predictive Store Forwarding (PSF) technology in their Zen 3 processors make them vulnerable to Spectre-STL attacks. The Linux kernel does not, as of today's git tree, provide any protection against those kinds of attacks.
AMD has released a document titled "SECURITY ANALYSIS OF AMD PREDICTIVE STORE FORWARDING" (PDF) where they admit that their Zen 3 processors are vulnerable to a class of side-channel attacks called Spectre-STL. Spectre-STL is a variant of the already-known Spectre V4 class of attacks. AMD document was created by David Kaplan using Microsoft Windows 365 on March 25th. It has been available on AMD's website on March 26th. In it, AMD admits that:
"In the assembly code, there is a store at offset 0xa6a and a load at offset 0xa74. If idx=0 then this store and load are to the same address and STLF will occur. However, if idx=1 then they are no longer to the same address. For AMD Zen3 processors with PSF, it is possible that the CPU could incorrectly predict that the store at offset 0xa6a will forward to the load at 0xa74 even if idx=1. This may occur if the function was called many times with idx=0 first, and then later called with idx=1. If this incorrect prediction occurs, the CPU will speculatively forward the store data (4096) to the load at offset 0xa74. The CPU will then multiply this value by idx (1) and attempt a load of array.
Predictive Store Forwarding is a new feature in AMD Zen3 CPUs which may improve application performance but also has security implications. While AMD is not currently aware of any code that would be considered vulnerable due to PSF behavior, this whitepaper examines the potential security implications of PSF, in general, as well as mechanisms that are designed to disable the feature if desired. AMD believes that for most applications, the security risk of PSF is likely low and where isolation is required, techniques such as address space isolation are preferred over software sandboxing."
AMD has proposed a series of Linux kernel patches that would allow Linux users to enable security mitigations against Spectre-STL. Their proposal is to introduce two new kernel parameters:
nopsfd. These new settings would give users the ability to change hardware control bit (MSR 48h bit 7) that allow the Predictive Store Forwarding Disable (PSFD) feature in Zen 3 processors to be enabled (default) or disabled. Adding
psfd=on would, very oddly, set the PSFD bit to one and disable this feature while
nopsfd would set the PSFD bit to zero and enable the feature. This seems a bit backwards; it would not be unreasonable to assume that
nopsfd would result in ..
psfd. That is, apparently, not how AMD would like those parameters to work.
It does not currently matter what parameters AMD may get into the Linux kernel in the future because a close-up inspection of
grep -R psfd . in the current linus.git kernel tree reveal no mention of, or even hint of, any
psfd kernel parameter today. There is no such parameter in any of the current kernels code, and there is no mention of it in
AMD document story is that:
"MD has recently proposed Linux patches that enable control of the PSFD bit in MSR 48h."
There are no such patches publicly proposed on the Linux Kernel Mailing List, there is none in the linus.git or linux-next trees or any other Linux three we are aware of for that matter. Perhaps AMD sent it in a sealed envelope market "only for use opened behind close doors". Perhaps an employee at AMD meant to send them and forgot. We do not know, the mystery remains unsolved.
Does the lack of Spectre LTS mitigations in the Linux kernel mean that you should worry? Probably not. From the way we read the code examples in "SECURITY ANALYSIS OF AMD PREDICTIVE STORE FORWARDING" it's very unlikely that anyone will be able to mount a practical real-world attack. It could, perhaps, be done in a very controlled lab-setting where a dedicated team tries very hard to make some proof of concept work for months before they finally, by a random coincidence, happen to make one of thousands of attempts produce a desired result. That's just not something you can do if you really want to get a few bytes out of a valued targets computer. Bribing the janitor to get physical access to the hardware would be a whole lot simpler.
You may or may not be able to disable the Predictive Store Forwarding feature in Zen3 processors at some point in the future if you really want to. Is likely that the patches that would allow end-users to control MSR 48h bit 7 will get into the mainline kernel sooner or later - if AMD actually sent them.