AMD Details "SQUIP" Side Channel Vulnerability For Zen's Execution Unit Scheduler

[DRanged]

AMD isn’t impacted by performance regressions since they can’t mitigate their vulnerabilities. Everyone made a big deal when Meltdown affected Intel chips then a few years later all of AMD’s CPUs were affected by a similar vulnerability called Transient Execution of Non-canonical Accesses vulnerability.

I expect nothing less from a company that took a year to fix their RX 5000 Windows driver issues while not acknowledging their customers. At least Intel/Nvidia acknowledge/address their issues in a timely manner. Take Intel’s horrible Arc drivers, first week they acknowledged their issue. Explained they tried to take a shortcut by using their iGPU drivers and are now making new drivers for their desktop cards.

Their response to that vulnerability:

“AMD recommends that all software vendors that ship code for its platforms revisit their programs and add mitigations.“

https://www.amd.com/en/corporate/pro...in/amd-sb-1010

Ignoring their issues is the reason why I don’t purchase their products.

Have you owned a RX 5000 series card so if not than shutup. You should also know if there are bugs it can be extremely difficult to reproduce or find them specially as a lot of people have vastly different hardware configurations.

Oh and by the way most issues were resolved within 3 months for the RX 5000 series cards and don't forget it was right at the beginning of the covid outbreak.

[WannaBeOCer]

Have you owned a RX 5000 series card so if not than shutup. You should also know if there are bugs it can be extremely difficult to reproduce or find them specially as a lot of people have vastly different hardware configurations.

Oh and by the way most issues were resolved within 3 months for the RX 5000 series cards and don't forget it was right at the beginning of the covid outbreak.

What a fanboy, getting defensive because AMD can’t communicate or fix software issues. I owned a RX 5700 for 8 days and returned it with-in my return policy because I wasn’t going to get stuck with a non-functional GPU.

AMD’s windows drivers have always been garbage for new architectures. It was a year until they finally acknowledged the issues. They started getting blasted by tech tubers they ignored the issue to sell their cards. Then they finally started releasing proper collection tools in their drivers. Hopefully with the bug collection tools they won't run into this issue again with which ever architecture replaces RDNA. AMD's GCN drivers were so bad, once AMD figured out how to properly optimize them fanboys started calling it "AMD's Fine Wine." That's why Polaris/Vega weren't gaining any major improvements after years aside from game day drivers.

https://youtu.be/pboDbxogSw4

https://youtu.be/1uynVO4ZXl0

The RX 5000 series came out a year and 2 months before Covid.

[Paradigm Shifter]

So, it only works on the same physical machine.

For an RSA key, I would have thought that a single bit error would be enough to give a non-working result ? [/FONT]

Quite. Although I suppose multiple attempts could be used, and then the recovered keys compared... if you're only attacking a few digits of a key, it'll make it a lot easier. A bit like WGS sequencing...?

Higher count SMT would probably work well for things which are fairly uniform in implementation... video encoding?

[CommunityMember]

I am not really loyal to any brand, but I can't resist to point out to the AMD fanboys that we told them it will be just a matter of time before AMD vulnerabilities will be discovered.

Only fools (or those that emulate fools by being fanbios) believed that pretty much all existing real world CPU vendors do not have some side channel vulnerabilities given that (almost) all modem high performance designs include some sort of predictive executions. Now that AMD has competitive offerings (good for AMD) it is now being looked at (when it was the also ran of the also ran no one cared), and, surprise, surprise, it was not immune to all attacks. The reality is that attacks only get better (with more research), so I expect more vulnerabilities will be identified in all architectures and implementations (anyone who thinks Intel, AMD, Arm, Power, S/390, etc. has seen their last CVE is living in fantasy world).

[PublicNuisance]

Looks like switching back to an FX-9590 is paying dividends for me already. Got rid of the PSP and now this.

[Mike Frett]

the most terrifing part is that there is so many AMD fanboys that upvoted you

Everyone is on a team. Amd/Intel, Windows/Linux, Republican/Democrat, Facebook/Twitter. It's part of human nature to join a team. Every now and then you get an oddball that wants to be Rambo.

[BreachScrambler]

Does anyone know what happened to AMD's phantom jmp? It was disclosed at the same time as retbleed and the mitigation was said to be worse than Meltdown.

Did AMD even comment on that? I certainly didn't see any mention of it being patched in the kernel.

[piotrj3]

Have you owned a RX 5000 series card so if not than shutup. You should also know if there are bugs it can be extremely difficult to reproduce or find them specially as a lot of people have vastly different hardware configurations.

Oh and by the way most issues were resolved within 3 months for the RX 5000 series cards and don't forget it was right at the beginning of the covid outbreak.

I didn't own RX 5xxx card, but i know Gamers Nexus made a video on it and were complaining 6 months after launch that they still had issues in REPRODUCABLE test cases. I know longer term they fixed it, but RX5000 series had bad initial support and also had lacking support for certain features like ROCm support for very long time was not existing. This is quite serious issue become by time RX5000 serie was usable, RX6000 serie/Ampere had already leaking benchmarks.

By comparison, Nvidia initial Ampere issues with instability lasted only 2 weeks, and pretty much all features were supported day 1. Same for Turing. And this is legitimate issue, good that RDNA2 didn't have such issues.

[piotrj3]

Everyone is on a team. Amd/Intel, Windows/Linux, Republican/Democrat, Facebook/Twitter. It's part of human nature to join a team. Every now and then you get an oddball that wants to be Rambo.

I strongly disagree with that statement. Ideally all those companies have diffrent intend then you, they are not user friendly. So your intention is to not join any teams and just pick best tool for your job.

Like if you need open source driver for linux with wayland - you know where to go.
If you need scientific/high computation usage with CUDA - you also know where to go.
You need budget modern PC for general usage - you know also where to go.
You need rendering farm - you also know where to go.
You need higher stability platform that won't cause you USB dropout issues, or PCI-E you know who to pick.
You want a platform with better upgrade options long term you also know who to pick.

I had initially Ryzen 3600 (because back then it was good choice), and after I upgraded to Ryzen 5800X3D because it was good upgrade option for my platform. But if i buided PC from scratch I would actually go for something like 12600/12700 CPU.
I also have nvidia GPU because i do use CUDA/computationally intensive stuff.

Literally stop being fanboys. Pick what in right time best fits your usage.

[archkde]

disabling SMT is best practice anyway for paranoid security (which is of course, the best security)
and as phoronix shows -- in some cases SMT being disabled can yield higher performance (but only in edge cases such as when cache is saturated per-core)

Speaking of per-core cache saturation, this may also be a security problem, and in fact I think the cross-hyperthread cache eviction attack against OpenSSL might be the first microarchitectural side channel vulnerability to be discovered (back in 2005!).

i like how we can also disable SMT on a live running system

echo off > /sys/devices/system/cpu/smt/control

Sure, that's actually how I do it myself due to a firmware bug. mitigations=auto,nosmt is simpler in most cases though.