In brief: AMD has confirmed that a microarchitecture optimization inside Zen 3 CPUs can be exploited in a similar fashion to the Spectre vulnerabilities that plagued Intel CPUs a few generations ago. Disabling the optimization is possible, but will carry a performance penalty that AMD doesn’t believe is worth it for all but the most critical deployments of the processors.

Update (April 5): Even though AMD was confident enough in not recommending a majority of their customers to disable Predictive Store Forwarding (PSF) for security reasons, Phoronix ran dozens of tests during the weekend using a Ryzen 7 5800X especifically benchmarking for the Zen 3 PSF vulnerability. They conclude that "the geometric mean of all those results was less than a half percent performance loss when disabling this new Zen 3 feature," or in other words, the performance impact is negligible.

In a recently published whitepaper, titled "Security Analysis of AMD Predictive Store Forwarding," AMD describes the nature of the vulnerability and discusses the associated complications. In simple terms, the implementation of Predictive Store Forwarding (PSF) reopens the lines of attack previously threatened by Spectre v1, v2, and v4, because of its speculative nature.

AMD describes PSF as a hardware optimization "designed to improve the performance of code execution by predicting dependencies between loads and stores." Like branch prediction, a feature that enabled some previous Spectre attacks, PSF makes predictions to allow the processor to execute subsequent instructions faster. PSF creates a vulnerability when it makes an incorrect prediction.

Incorrect predictions can be the result of two scenarios, says AMD. "First, it is possible that the store/load pair had a dependency for a while but later stops having a dependency." This happens naturally as stores and loads change during a program’s execution. The second scenario occurs "if there is an alias in the PSF predictor structure," and the alias is used when it shouldn’t have been. Both scenarios can be triggered by malicious code as desired, at least theoretically.

AMD writes, "because PSF speculation is limited to the current program context, the impact of bad PSF speculation is similar to that of speculative store bypass (Spectre v4)."

Like Spectre v4, the vulnerability occurs when one of the processor’s security measures is bypassed by the incorrect speculation. In combination with other attacks; AMD uses Spectre v1 as an example, the incorrect prediction can result in data leakage. "This is similar to the security risk of other Spectre-type attacks," says AMD.

Programs that depend on software sandboxing for security are the most vulnerable to PSF attacks. Programs that use hardware isolation "may be considered safe" from PSF attacks because PSF speculation doesn’t occur across address spaces. It also doesn’t occur across privilege domains.

AMD has found that techniques like address space isolation are sufficient to stop PSF attacks, however, they’ve provided the means to disable PSF, even on a per-thread basis, if desired. But because the security risk is "low," and because "AMD is not currently aware of any code that would be considered vulnerable due to PSF behavior," they universally recommend leaving the PSF feature enabled as the default setting, even when protections aren’t available.