Welp. Thankfully my current AMD desktop PC will be the last one I’ll be using in my whole lifetime – RISC-V 4va. :^)
Planned fix
December 2023
Yikes.
It’s worth noting these are the firmware / microcode fixes.
There’s already a software solution available,
There is a software workaround, you can set the chicken bit DE_CFG[9]. This may have some performance cost, and the microcode update is preferred.
source: https://www.openwall.com/lists/oss-security/2023/07/24/3
AMD has also already released a fix for the big boy - the EPYC processor.
The MSR bit is potentially a large performance loss and AMD recommends their partners not use it. In my tests is was 5-15% on EPYC depending on workload. “Some performance cost” is really hiding the reality of that bit.
Is there any information on the performance impact of the microcode fix or is it too early for that?
So far the word is the microcode fix causes negligible performance impact, but using the MSR fix causes 5-15% loss. In my own testing on EPYC hardware, microcode made no noticable difference to my workloads and benchmarks. Same as random noise in results.
How come branch prediction seems so vulnerable to exploits? Both spectre and meltdown were also caused by branch prediction not working quite right.
The more steps in the instruction pipeline the more ways there are for there to be an error where some result doesn’t get erased when undoing stuff from the wrong branch. It’s basically like telling someone to move into a new house and get settled then stopping them six hours in and trying to make sure you get all their stuff out.
It wasn’t branch prediction alone, it was the cache combined with branch prediction. The problem is that even discarded outcomes fill the cache with data. Those older vulnerabilities also had the problem that the access permissions check was done after the branch prediction. It’s probably too expensive to do when it’s not even clear yet whether the branch is going to be taken (that’s just speculation on my part though).
(that’s just speculation on my part though).
I see what you did there, even if you didn’t :)
The article says it’s exploitable via javascript on a random web page. I don’t see how that could be possible
removed by mod
Here is an alternative Piped link(s): https://piped.video/watch?v=V_9cQP60ZGI
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
I’m just going to pretend I didn’t buy any AMD surface laptops.
Intel had something like this as well (side channel attack?). I remember it because Linus Torvalds (creator of Linux kernel) ripped Intel a new one.
They’ve had a couple. Spectre is the one to which you’re referring, I bet.
Click bait. Alleady fixed on every platform
Why are users on Linux stating the opposite then?
Misled by stupid clickbait? I’m on linux, it’s fixed by microcode update in linux-firmware and kernel mitigation, commit says july 24 22:07:56
So it was patched literally 2 days ago.
You think everyone updates their kernel off source that quickly? This vulnerability is absolutely still out in the wild.
“Could take many months to fix” is bullshit
Nice to know that security researchers are giving AMD some love too. Ill be sure to turn the patch off on my 3600 once it rolls around (can’t be losing any frames for something silly like security)
That’s a very bad idea.
The bad news is that the exploit doesn’t require physical hardware access and can be triggered by loading JavaScript on a malicious website.
I think it was sarcasm.
I want to say that I know, but it’s the internet, so you can never be sure. ¯\_(ツ)_/¯
Hell yeah, brother! 🤙
affects all Zen 2-based Ryzen, Threadripper, and EPYC CPUs
I know they’re probably pretty common, all my stuff ended up being Zen 3. Here’s hoping they don’t find similar issues in later generations.
I’ve got an older 3900X that’s Zen 2, but I’m otherwise clear, too.
It’s kind of hard to figure out which Zen # a CPU falls under, so here’s the Wiki page listing all Zen 2 CPUs.
This is not a back-end at all…
Updated amd64-microcode for EPYC processors appears available for several distributions which has mitigations available. I went ahead and proactively grabbed the microcode update from Debian unstable (not the best practice) and applied it without issue to my Bullseye/EPYC.
This isn’t exactly condoned as it’s not officially a backport, but I’ll take my chances as this is pretty critical.
Date of the updated microcode should be July 19th.
This is pretty bad but it needs local access to a server/workstation as well as pretty sophisticated knowledge/tools to exploit. Even then there’s no guarantee of getting any relevant information out of it. Anything with frequent enough logins/hashes going through the local system is probably a server someplace, and if its important you should have it physically locked away and access controlled.
Exploit is usable via JavaScript. Does not require local access.
Is there any evidence that the exploit works in a browser? A few comments on the article suggested that the Javascript engines in browsers protect against timing attacks like these.
I was hoping there would be a reply to this :(
Why is it that every time there’s drama about hardware, its something I own?
I feel really lucky that it doesn’t affect Zen 3 since that’s what I have lol but I’m sure they will find some similar bug for Zen 3.
Isn’t EPYC just a different name for Zen 3?
Nope, EPYC is their server processors, not their consumer processors.
Oh Nice! Well then I’m lucky too. Got a Ryzen 9
Well, this happens to affect the Ryzen 5 3600, which I’m pretty sure is one of AMD’s most popular processors ever…so you’re certainly not alone.
That’s because of monopolies… There are only two brands of PC CPUs you could own…
Oh how I miss Cyrix
That’s a duopoly and is also not true, there are ARM processors readily available outside of Intel and AMD.
ELI5 how this works?
A CPU performs operations like “read a small bit of thing from the memory into the CPU” and “do a small bit of computation on things inside the CPU” and “put a small bit of thing from the CPU into the memory”.
Doing small bits of computation on things inside the CPU is very fast but moving bits of things from or to the memory is slow in comparison. In order to not be slowed down, CPUs read the code ahead of what is currently being executed, and try to guess what is going to happen and what will need to be moved from the memory into the CPU, so they can do it ahead of time, and have the small bit of thing from the memory already available right there in the CPU when it’s time to do a bit of computation on it. That way, there is no need to wait on slow memory, and the CPU runs much faster overall. That’s a good thing.
In this case, a researcher found a way to make certain CPUs guess what is going to happen with the code wrong, in such a way that the small bits of things that were read from the memory ahead of time do not get properly cleaned up, and can still be found inside the CPU by another program. Those small bits of things might be your password or banking details, so that’s bad.
