Tuesday, April 6th 2021

AMD Ryzen 5000 Series CPUs with Zen 3 Cores Could be Vulnerable to Spectre-Like Exploit

AMD Ryzen 5000 series of processors feature the new Zen 3 core design, which uses many techniques to deliver the best possible performance. One of those techniques is called Predictive Store Forwarding (PSF). According to AMD, "PSF is a hardware-based micro-architectural optimization designed to improve the performance of code execution by predicting dependencies between loads and stores." That means that PSF is another "prediction" feature put in a microprocessor that could be exploited. Just like Spectre, the feature could be exploited and it could result in a vulnerability in the new processors. Speculative execution has been a part of much bigger problems in CPU microarchitecture design, showing that each design choice has its flaws.

AMD's CPU architects have discovered that the software that relies upon isolation aka "sandboxing", is highly at risk. PSF predictions can sometimes miss, and it is exactly these applications that are at risk. It is reported that a mispredicted dependency between load and store can lead to a vulnerability similar to Spectre v4. So what a solution to it would be? You could simply turn it off and be safe. Phoronix conducted a suite of tests on Linux and concluded that turning the feature off is taking between half a percent to one percent hit, which is very low. You can see more of that testing here, and read AMD's whitepaper describing PSF.
Source: AMD Blog
Add your own comment

65 Comments on AMD Ryzen 5000 Series CPUs with Zen 3 Cores Could be Vulnerable to Spectre-Like Exploit

#51
thesmokingman
HD64G
Everyone should deactivate that feature. Less than 1% effect on performance isn't something to discuss about.
Why? There's not even a real exploit yet.
Posted on Reply
#52
lynx29
R-T-B
Makes me wonder why it's enabled at all...
How do I disable it? I don't see how to do it.
Posted on Reply
#53
1d10t
HD64G
Everyone should deactivate that feature. Less than 1% effect on performance isn't something to discuss about.
Where's the button?
Ah yes only in Linux , and with patches.
Another funny thing, I couldn't find this Vulnerability on CVE list :rolleyes:
Posted on Reply
#54
Chrispy_
efikkan
Then that's a product of bias, a bias which unfortunately has become widespread. I've not seen any evidence of Intel taking "security shortcuts".

A shortcut would imply a conscious decision, while the Spectre family is caused by an oversight, an oversight done by numerous companies implementing their own microarchitectures.
Not bias, I'm just presuming that AMD pass a minium low bar for common sense and business survival, the same low bar I'd apply to Intel, Nvidia, Microsoft, Apple, or Google.

If you understand Spec-ex attacks then you know it affects Intel because they skipped privilege checks on stuff that had passed checks earlier in the pipeline as implied trust, in order to speed up the pipeline. Call it a shortcut, call it an optimisation - it doesn't matter. AMD checks privileges at every stage rather than assuming implied trust. That's a gross oversimplification but the TL;DR is that Intel chose speed over security, and AMD chose security over speed.

AMD's decision to choose security over speed has been vindicated publicly and presumably ratified internally at AMD, possibly making them even more security-cautious than they were previously. That basic decision of security over speed saved their bacon and they got to see what might have happened if they'd made the same shortcut/optimisations as Intel. Call it a free lesson at Intel's expense. That's not bias, that's just how any competent company should be run.

So no, presuming AMD won't take shortcuts isn't pro-AMD bias. It's based on historic empirical data.
I am now assuming that everyone takes spec-ex and pipeline privilege checks more seriously, not just Intel.
Posted on Reply
#55
evernessince
las
Yes, because people actually cared about finding them. So they can collect money. Logic, yeah.
You fail to understand what an assumption is I see. You made the assumption that Intel has more known vulnerabilities and assumed that AMD has equal or more undisclosed ones based on the assumption that Intel's bug payment program encourages people to find more bugs. This is funny for two reasons:

1) Google Project Zero found Spectre and Meltdown, not someone encouraged by the bug program. They are employed by google to find zero day vulnerabilities regardless of the existence of a bug payout program. Therefore your initial assumption that your stacked house of assumptions is based on is in fact false. Again, you assumed but it's irrelevant as your unproven argument basis has already been disproven despite no requirement for me to do so as you failed to provide evidence to support it to begin with.

2) You provided no evidence to support the idea that AMD has an equal or greater amount of vulnerabilities as Intel, assumptions are not supporting evidence. You first make the assumption that Intel's bug bounty program is the reason they have so many vulnerabilities (disproven above) and again assume on top of that false logic that AMD has at least that many unknown vulnerabilities. AMD has 16, Intel has over 240. Think about that. You are in essence assuming AMD has 15 times the unkown vulnerabilities as known and assuming, without evidence, that they in fact exist. That's not something a bug bounty program alone is going to make up.
Posted on Reply
#56
First Strike
R-T-B
But they know this one individual feature constitutes a security risk. So I repeat the question.
No they don't.

Short version: to find a bug is a non-computable problem.

Long version: All security/correctness properties can only be proven under an assumption, and only works under that assumption, e.g., eventual correctness of execution result, etc. "Side channel attacks" just means they found some new ways of invalidating your assumptions and can thus only be handled on a case-by-case basis. Being in the same category does not mean they are the same bug. If you are not an omnipotent god, then you simply don't know it in advance.

Yes, you can have a vague sense of vulnerability based on your human instinct. But it takes engineering genuity to prove the vulnerability. (invulnerability, as I previous said, is not provable by any means).
[/HR]

A good example is the cache microtag generator for zen/zen+. For an outsider, that microtag generator design would freak them out because it may appears too insecure for an untrained engineer. But after all these years, no one actually found an attack vector for it. Proving invulnerability is impossible, but proving vulnerability is also hard.
Posted on Reply
#57
marios15
Intel didn't take any shortcuts?

Spectre is a side-effect of out-of-order execution engines that might allow you to take a glimpse of code running on a computer, as long as you have sufficient privileges, only in-order CPUs are safe from it.

Meltdown was intel (and others) not doing any security checks which allowed kernel access.
Easily exploitable since you know what to look for(kernel), could be done blindly and massively through websites because everyone had the same kernel(windows)
The only things stopping it were kernel memory randomization and flushing caches for every kernel call which tanks performance.

Imagine the period before patches....and the researchers having the power to snoop around every pc on the internet that had "intel inside", without leaving any traces.

Yeah, zero shortcuts...and then there's Intel Management Engine, a webserver inside your cpu.
Posted on Reply
#58
B-Real
las
This is the reason why most vulberabilies were found in Intel CPUs; www.intel.com/content/www/us/en/security-center/bug-bounty-program.html

Intel actually pays people for finding them. "Intel’s bug bounty awards range from $500 up to $100,000."

AMD had plenty of vulnerabilies, even tho they don't pay people for finding them. Meaning, very few people will spend time trying to find them. Logic 101.

It's sad that AMD does not pay people for finding bugs, when tons of big tech companies do; www.guru99.com/bug-bounty-programs.html
So you are simply LYING? AMD had plenty of vulnerabilities? Try to read up all the news about back to those days when they were found: most of them were Intel-related and affected more generations of Intel CPUs. Shame on you.
Posted on Reply
#59
bogmali
In Orbe Terrum Non Visi
If you cannot have a discussion without trolling and baiting, I suggest you refrain from posting. Thread bans issued
Posted on Reply
#60
RJARRRPCGP
Honestly looks like nothing to panic about, as a Ryzen user. I'm going on with business-as-usual.
Posted on Reply
#61
freeagent
*Swivels head to look at Band-Aid covered Intel rigs*

Wake me when its serious.
Posted on Reply
#62
las
B-Real
So you are simply LYING? AMD had plenty of vulnerabilities? Try to read up all the news about back to those days when they were found: most of them were Intel-related and affected more generations of Intel CPUs. Shame on you.
Lying? Haha. AMD had many vulnerabilies, feel free to Google, YET no bug bounty program to make people even wanna go look for them.

If Intel did not have their bug bounty program, you can be sure that many of the vulnerabilies were never found to begin with. STILL Intel continue to have it.
Posted on Reply
#63
efikkan
las
If Intel did not have their bug bounty program, you can be sure that many of the vulnerabilies were never found to begin with. STILL Intel continue to have it.
The bug bounty program certainly contributes, but the main reason is Intel's close collaboration with researchers and data-center customers. Ice Lake-SP which launched the other day, has been deployed as engineering samples with partners at least since 2017, and has over the past year shipped over 100.000 units of the final product prior to the "public launch", so when it finally launched it was a very mature product. Their next-gen Sapphire Rapids (presumably launching sometime next year or so), has had engineering samples for over a year already. A lot of errors are found and resolved long before the general public gets their hands on the products, and helps avoid problems like waiting for months for stable BIOSes, or failing to boot Linux, or compile correctly with GCC etc. Bugs like Meltdown and Spectre which were found long after product launches are rare exceptions.

AMD would be well served by allowing their partners access to engineering samples much earlier, and probably extending their development cycle by at least 6-12 months.
Posted on Reply
Add your own comment