AMD's Zen 3 CPUs Are Susceptible To Spectre-Like Vulnerability (Updated)

News
By Zhiye Liu
published

Zen 3's weak spot

Ryzen 5000 Processor
Ryzen 5000 Processor (Image credit: AMD)

Update 5/4/2020 8:30am PT: Linux publication Phoronix has carried out preliminary testing on the impact of disabling Predictive Store Forwarding. AMD hasn't provided any patches, therefore, the author compiled his own kernel with the feature disabled.

Phoronix's results revealed a negligible performance hit when disabling Predictive Store Forwarding. Across a suite of 100 tests, the geometric mean was less than a half percent in terms of performance loss.

We've reached out to AMD for comment and will update the story accordingly when the chipmaker gets back to us.

Original Story:

AMD has published a whitepaper on a potential security vulnerability that affects the company's latest Zen 3 processors. The side-channel exploit is similar to Spectre that affected a plethora of Intel processors three years ago.

With Zen 3, AMD introduced a new technology called Predictive Store Forwarding (PSF), which helps improve code execution performance by predicting the relationship between loads and stores. In the majority of the cases, PSF's predictions are on the spot. However, there is still a slim chance that the prediction may not be accurate, which results in an incorrect CPU speculation.

AMD's CPU architects have discovered that bad PSF speculation is equivalent to Spectre v4. Software that relies on isolation or "sandboxing" is highly at risk when it comes to incorrect speculation. AMD provided two scenarios where an incorrect PSF prediction can occur.

"First, it is possible that the store/load pair had a dependency for a while but later stops having a dependency. This can occur if the address of either the store or load changes during the execution of the program."

"The second source of incorrect PSF predictions can occur if there is an alias in the PSF predictor structure. The PSF predictor is designed to track stores/load pairs based on portions of their RIP. It is possible that a store/load pair which does have a dependency may alias in the predictor with another store/load pair which does not. This may result in incorrect speculation when the second store/load pair is executed."

AMD concludes that Predictive Store Forwarding helps improve application performance, but also comes with security complications. Nevertheless, the chipmaker hasn't seen any code that's considered vulnerable to PSF misprediction nor are there any reported cases of such exploit. The security risk of Predictive Store Forwarding is low for most applications.

The official recommendation from AMD is to leave the Predictive Store Forwarding enabled. Since it's a performance enhancement feature, we suspect that disabling PSF could bring a performance hit.

Consumers who work with software that employs sandboxing and are alarmed about PSF have the choice to disable the PSF functionality. AMD recently proposed Linux patches that would disable Predictive Store Forwarding as well.

Zhiye Liu
Zhiye Liu
RAM Reviewer and News Editor

Zhiye Liu is a Freelance News Writer at Tom’s Hardware US. Although he loves everything that’s hardware, he has a soft spot for CPUs, GPUs, and RAM.

See more CPUs News
15 Comments Comment from the forums
  • Kamen Rider Blade
    Good on AMD for disclosing the security vulnerability instead of relying on outside 3rd parties to do it.

    I'm sure their security team is hard at work figuring out a micro-code solution to solve it.
    Reply
  • So you're probably safe to leave Predictive Store Forwarding on, but if you're worried turn it off and maybe loose some performance.
    Reply
  • thGe17
    Kamen Rider Blade said:
    Good on AMD for disclosing the security vulnerability instead of relying on outside 3rd parties to do it.

    I'm sure their security team is hard at work figuring out a micro-code solution to solve it.

    Why should this be "good"? Whoever comes first ... if AMD found it (or stumbled upon it first), they must disclose it, otherwise it would be a very questionable practice.

    And again, there's currently no "real/final solution" or "fix" for this Spectre-v4-like problems. They all use a combination of some HW-assisted optimizations and OS/VMM adjustments and pointing to coding standards to build some kind of mitigation.
    This has been already shown in a Zen2 release-sheet and for Zen3 AMD avoided to publish such a sheet again, because nothing has changed. And now, they've additionally implemented a new way of Spectre-v4-like attacks with this new feature.
    Nowadays, CPUs are so complex that security is really difficult to achieve and additionally, these are sometimes conflictive goals: you wanna implement a more powerful, faster architecture (to be more competitive) and you wanna keep or even increase security ...
    Reply
  • InvalidError
    thGe17 said:
    Nowadays, CPUs are so complex that security is really difficult to achieve and additionally, these are sometimes conflictive goals: you wanna implement a more powerful, faster architecture (to be more competitive) and you wanna keep or even increase security ...
    Every speculative feature opens the door to hypothetical side-channel leaks (no practical exploit actually exists) from detecting speculation changes. If your code requires the highest level of security, don't run it on a shared machine where unknown processes may be eavesdropping. Maybe even go a step further and seclude the absolutely critical parts like root keys and certificates on FPGAs that will handle all manipulations involving them.
    Reply
  • macgeek
    I noticed that there's one tidbit missing from both the article and AMD's whitepaper: Whether this bug be exploited remotely or if physical access would be required.
    Reply
  • macgeek said:
    I noticed that there's one tidbit missing from both the article and AMD's whitepaper: Whether this bug be exploited remotely or if physical access would be required.
    I don't see anything in the article suggesting physical access is required for this exploit so the safer assumption if you're worried is that (hypothetical) remotely executed code might exploit the vulnerability. All pretty speculative :) at the moment.
    Reply
  • Gomez Addams
    thGe17 said:
    Why should this be "good"? Whoever comes first ... if AMD found it (or stumbled upon it first), they must disclose it, otherwise it would be a very questionable practice.

    And again, there's currently no "real/final solution" or "fix" for this Spectre-v4-like problems. They all use a combination of some HW-assisted optimizations and OS/VMM adjustments and pointing to coding standards to build some kind of mitigation.
    This has been already shown in a Zen2 release-sheet and for Zen3 AMD avoided to publish such a sheet again, because nothing has changed. And now, they've additionally implemented a new way of Spectre-v4-like attacks with this new feature.
    Nowadays, CPUs are so complex that security is really difficult to achieve and additionally, these are sometimes conflictive goals: you wanna implement a more powerful, faster architecture (to be more competitive) and you wanna keep or even increase security ...
    Yes, there is. The fact is you can eliminate all possibility of any of these attacks occurring by NOT allowing malicious software on your machine in the first place. Problem solved!
    Reply
  • GenericUser
    thGe17 said:
    Why should this be "good"? Whoever comes first ... if AMD found it (or stumbled upon it first), they must disclose it, otherwise it would be a very questionable practice.

    It's "good" in the sense that they are being upfront and working towards a solution, as opposed to what some other companies will do, which is sit on internally discovered vulnerabilities and decide they just aren't going to fix them, or get notified by a third party of a discovered vulnerability, then that third party has to disclose the vulnerability publicly to force the company's hand because they also decided in that case they weren't going to fix it. Sure it's a questionable practice like you say, yet several companies decided to do exactly that: nothing.
    Reply
  • macgeek
    randomWalk said:
    I don't see anything in the article suggesting physical access is required for this exploit so the safer assumption if you're worried is that (hypothetical) remotely executed code might exploit the vulnerability. All pretty speculative :) at the moment.
    The reason I mention it is because they've had vulnerabilities like this in the last few years, but most of them could only be exploited locally.
    Reply
  • Kamen Rider Blade
    thGe17 said:
    Why should this be "good"? Whoever comes first ... if AMD found it (or stumbled upon it first), they must disclose it, otherwise it would be a very questionable practice.

    And again, there's currently no "real/final solution" or "fix" for this Spectre-v4-like problems. They all use a combination of some HW-assisted optimizations and OS/VMM adjustments and pointing to coding standards to build some kind of mitigation.
    This has been already shown in a Zen2 release-sheet and for Zen3 AMD avoided to publish such a sheet again, because nothing has changed. And now, they've additionally implemented a new way of Spectre-v4-like attacks with this new feature.
    Nowadays, CPUs are so complex that security is really difficult to achieve and additionally, these are sometimes conflictive goals: you wanna implement a more powerful, faster architecture (to be more competitive) and you wanna keep or even increase security ...
    You should've seen how Intel dragged their feet and initially denied the exist of Spectre/MeltDown until it became too obvious that they had to admit to it.
    Reply