AMD Publishes Security Analysis Of Zen 3 "PSF" That Could Possibly Lead To A Side-Channel Attack

[phoronix]

Phoronix: AMD Publishes Security Analysis Of Zen 3 "PSF" That Could Possibly Lead To A Side-Channel Attack

AMD published a security whitepaper this week looking at their Predictive Store Forwarding (PSF) feature that is new to Zen 3 series processors. AMD is going to allow customers to disable this performance feature as they think it may be vulnerable to a Spectre-like attack...

https://www.phoronix.com/scan.php?page=news_item&px=AMD-PSF-Security-Analysis

[Jumbotron]

Wait....are you actually saying that AMD engineered a speculative code part in Zen 3 KNOWING there is a LONGSTANDING speculative attack on something similar with a LOT of Intel CPUs and STILL released it whithiut adequate testing ?? And the ONLY mitigation is the SAME OL' standby Intel gave..."Well...you can always turn it off".

SMH...

[torsionbar28]

Wait....are you actually saying that AMD engineered a speculative code part in Zen 3 KNOWING there is a LONGSTANDING speculative attack on something similar with a LOT of Intel CPUs and STILL released it whithiut adequate testing ?? And the ONLY mitigation is the SAME OL' standby Intel gave..."Well...you can always turn it off".

SMH...

Actually, no, the sky is not falling Chicken Little. Chips you buy at retail today were designed years ago. The Zen CPU architecture was finalized in 2016. That's two years before the first Spectre vulnerability was made public. All these Agile software developers who are used to designing, building, and promoting to prod all within a few weeks time, have no grasp on the timelines involved for creating a CPU. Hint: There are exactly zero x86-64 CPU's on the market today, from any vendor, that have Spectre mitigations in hardware. Nope, not even the newest 11th gen "Rocket Lake" Intel chips that were just released *this week*.

Speculative Store Bypass aka Spectre variant 4 is considered such a low risk that no Linux distro mitigates Spectre v4 by default, for either AMD or Intel. You can mitigate it if you like, but it isn't the default. Even on enterprise distros like RHEL and SLES, the mitigation code is present, but is not enabled by default. Don't take my word for it, check your own machine (cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass). It will most likely say "Vulnerable", instead of "Mitigation".

[CommunityMember]

Wait....are you actually saying that AMD engineered a speculative code part in Zen 3 KNOWING there is a LONGSTANDING speculative attack on something similar with a LOT of Intel CPUs and STILL released it whithiut adequate testing ?? And the ONLY mitigation is the SAME OL' standby Intel gave..."Well...you can always turn it off".

The design of processors has a very very long lead time (many many years), and AMD engineers likely saw the same potential for improved performance as Intel by using a similar (but different) speculative store approach. By the time the various side channel attacks were fully understood the design was likely already too far into the process to be eliminated or mitigated, and disabling PSF entirely likely would have impacted all of those benchmarks which were released at first ship (how much we will not know until some benchmarks (Hi Michael!) are produced).

It would seem highly likely AMD engineering knew about the issue before the paper was released this week. The alternative would be that AMD engineering does not understand the issues in side channel attacks well enough to know what to look for, or protect against.

So, it would seem to be a legitimate question is what did AMD know, and when did they know it, and perhaps who in the C-level of AMD decided to not release the security advisory until after the product announcement (and who sold stock after the announcement bump and before this paper was released ?). Sadly, "we" will almost certainly not know those answers, to protect those involved (unless some C-level execs did, indeed, sell stock, in which case the SEC may have some interest in the precise timeline).

[torsionbar28]

So, it would seem to be a legitimate question is what did AMD know, and when did they know it, and perhaps who in the C-level of AMD decided to not release the security advisory until after the product announcement (and who sold stock after the announcement bump and before this paper was released ?). Sadly, "we" will almost certainly not know those answers, to protect those involved (unless some C-level execs did, indeed, sell stock, in which case the SEC may have some interest in the precise timeline).

Accusations of wrong-doing, with zero evidence of it actually occurring? That is some straight CNN fake news right there.

[r1348]

Actually, no, the sky is not falling Chicken Little. Chips you buy at retail today were designed years ago. The Zen CPU architecture was finalized in 2016. That's two years before the first Spectre vulnerability was made public. All these Agile software developers who are used to designing, building, and promoting to prod all within a few weeks time, have no grasp on the timelines involved for creating a CPU. Hint: There are exactly zero x86-64 CPU's on the market today, from any vendor, that have Spectre mitigations in hardware. Nope, not even the newest 11th gen "Rocket Lake" Intel chips that were just released *this week*.

Speculative Store Bypass aka Spectre variant 4 is considered such a low risk that no Linux distro mitigates Spectre v4 by default, for either AMD or Intel. You can mitigate it if you like, but it isn't the default. Even on enterprise distros like RHEL and SLES, the mitigation code is present, but is not enabled by default. Don't take my word for it, check your own machine (cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass). It will most likely say "Vulnerable", instead of "Mitigation".

$ cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Mitigation: Speculative Store Bypass disabled via prctl and seccomp

Fedora mitigates it by default.

[torsionbar28]

$ cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Mitigation: Speculative Store Bypass disabled via prctl and seccomp

Fedora mitigates it by default.

Edit: Looks like that's not actually the case. The value you report above means mitigations are disabled by default, and only enabled on a per-process basis for certain programs. So it's a partial mitigation.

Disabled via prctl and seccomp meaning:
The mitigation is by default disabled, and can be enabled by user programs using the prctl() system call, and is default enabled for applications using "seccomp" filtering, like openssh, vsftpd and chromium.
From: https://www.suse.com/support/kb/doc/?id=000019189

If you want full global mitigation for Spectre v4, you have to set 'spec_store_bypass_disable=on' and then you'll see this:
Mitigation; Speculative Store Bypass disabled

[coder]

Chips you buy at retail today were designed years ago. The Zen CPU architecture was finalized in 2016. That's two years before the first Spectre vulnerability was made public. All these Agile software developers who are used to designing, building, and promoting to prod all within a few weeks time, have no grasp on the timelines involved for creating a CPU. Hint: There are exactly zero x86-64 CPU's on the market today, from any vendor, that have Spectre mitigations in hardware. Nope, not even the newest 11th gen "Rocket Lake" Intel chips that were just released *this week*.

Rocket Lake seems like a fairly recent effort, though. I'd imagine the reason it doesn't have hardware Spectre mitigations is either that they thought it would unduly hurt performance for markets that prefer to run with mitigations disabled (i.e. gamers)* or that they just didn't consider it worthwhile, given that it's destined only ever to be a consumer-oriented core.

Keep in mind that even hardware mitigations aren't necessarily without performance impacts.

[Peter Fodrek]

Wait....are you actually saying that AMD engineered a speculative code part in Zen 3 KNOWING there is a LONGSTANDING speculative attack on something similar with a LOT of Intel CPUs and STILL released it whithiut adequate testing ?? And the ONLY mitigation is the SAME OL' standby Intel gave..."Well...you can always turn it off".

SMH...

Development od X86 takes years

SUNNYVALE, CA -- (MARKET WIRE) -- 09/07/11 -- Today, AMD (NYSE: AMD) announced revenue shipments of the first processors based on its new x86 "Bulldozer" architecture.

https://ir.amd.com/news-events/press-releases/detail/32/amd-ships-first-bulldozer-processors

SUNNYVALE, CA -- (Marketwired) -- 03/02/17 -- After four years and thousands of hours of development, AMD (NASDAQ: AMD) today released the first three models of its highly anticipated, high-performance AMD Ryzen™ desktop processor.

https://ir.amd.com/news-events/press-releases/detail/753/amd-ryzentm-7-desktop-processors-featuring

It was 5 and half years minus 5 days bettween Bullozer and Zen launch

April, the 11th 2018
Mike T. Clark, Zenu chiefarchict , said in ana interview that he is already working on Zen 5.

https://diit.cz/clanek/architekt-zenu-zminil-vyvoj-zen-5

That means Zen3 development was started before Zen launched.


Spectre vulnerability clas was discovered during 2017 and siclosed on
January 2018;

https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

Zen 3 desing is complete main interest on Zen 4
development
August, the 13th, 2019

https://diit.cz/clanek/navrh-zen-3-byl-dokoncen-pracuje-se-na-zen-4

Manufacturing tuning takes about 420 days for AMD, TSMC and CPU before launch.

AND CPU is complicated at level that there is not possible to test all of its pipeline states during
unvierse existence even at finite machine level, yet


So each CPU has bugs but we do not know vast majority of them. It is possitive that AMD takes public warning when finds out any suspect of bug

[Serafean]

The fun thing is, it seems it already is mitigated by SPEC_STORE_BYPASS.
From the linked PDF:

Note that software that already uses pr_ctl to disable the PR_SPEC_STORE_BYPASS feature will be run with
SSBD=1 which effectively disables PSF.