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

[Brisse]

angrypie I guess it's a way for them to cover their own back in case this causes any damage somewhere in the future. "Hey, we warned you. It's your own fault for not taking proper precaution. Clearly there's no liability on our end."

[AdrianBc]

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".

Actually it seems that on Gentoo this mitigation is enabled by default.

At least on my system it is enabled and when I have compiled the kernel from "gentoo-sources" I have not modified any part of the configuration related to mitigations.

[Guest]

God blees good old in-order-processing. (Well, if you can bear with the "speed" of these machines. But therefore they're quite safe.)

Well, it's okay that AMD announced the news by themselves before others did (as far as it seems). That's a good step. They also seem to have patches ready for upstream. Good, too. However, they estiamate the risk being low. Okay. So everyone can check for him- her- or itself, or whatever you want to be these days, if you want to disable or not. Fine for me.

By the way, my gentoo machines have it already disabled on request by programs (see torisonbar28's explanations).

 grep . /sys/devices/system/cpu/vulnerabilities/*

shows

Mitigation: Speculative Store Bypass disabled via prctl and seccomp

Iirc. I switched this on in the kernels of my machines long ago, shortly after the meltdown horror-news came to the broad public. The only one somehow still showing one vulnerability is my E-350, and I wonder what it missing there. Everything else is not affected (AMD/VIA/in-order-intel-Atom/Geode mostly here) or mitigated (completely or on request). I also don't notice much of any speed drop (Benchmarks only maybe, and Michael's data shows that the drop for AMD was marginal).

These days we waste much more processing power by shoddy programming that involves JavaScript, frameworks, abstraction layers over layers over layers, wrappers, emulations, library obesity and all that kind of stuff that really slows you down.

Most of the time, what causes perceived slowdown for UI is the lack of use of multi-threading (or improper use of it). People love doing disk and network operations on the same thread that's responsible for rendering/reacting to input, so of course it causes lag, jank and hitches