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)
Encryption-breaking, password-leaking bug in many AMD CPUs could take months to fix
Submitted 1 year ago by Lanky_Pomegranate530@lemmy.world to technology@lemmy.world
Comments
aBundleOfFerrets@sh.itjust.works 1 year ago
LoafyLemon@kbin.social 1 year ago
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.
notthebees@reddthat.com 1 year ago
I think it was sarcasm.
Default_Defect@lemmy.world 1 year ago
Why is it that every time there’s drama about hardware, its something I own?
nan@lemmy.blahaj.zone 1 year ago
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.
FishInABarrel@kbin.social 1 year ago
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.
iByteABit@lemm.ee 1 year ago
ELI5 how this works?
r00ty@kbin.life 1 year ago
The guys themselves made a pretty good write-up. https://lock.cmpxchg8b.com/zenbleed.html
The short version is that the very large registers on the modern CPUs aren't fixed things like they used to be, they're allocated from some register area on the die. When they "zero" the upper portion of one of the large registers it doesn't really clear it. It just releases the block back to available.
Another thing all CPUs need these days to keep fast is branch prediction. CPUs are only fast if they can keep the pipeline of upcoming commands (opcodes) to process full. So they often run both possible routes for a branch and discard the loser.
In this case they "trick" the CPU by asking it to "clear" a block of one of these large registers (the upper half). But then have the branch go the other way. What sometimes happens is that the register space is "released" but it has to take it back. In some specific circumstances they are able to have the register come back, but not with the original contents but with some random contents of maybe another register that was used by another thread (maybe even running on a different VM guest).
I have a server with a 3000 series CPU. I can confirm this definitely works. You'll get all kind of random blocks of memory from processes running as all users (and kernel code). For AMD processors running VM servers it is even worse. Because if you have say a VPS running on an AMD Zen2 CPU, you can login as any user run this and get random data from people on other VPS on the same hardware!
There is a linux workaround, and it seems most CPUs will be fixed by December.
Note: If you have access to a VPS that is vulnerable, do note that in most countries it is illegal to even try to exploit this.
_haha_oh_wow_@sh.itjust.works 1 year ago
Oh poop.
iByteABit@lemm.ee 1 year ago
ELI5 how this works?
Balinares@pawb.social 1 year ago
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. No need to way on slow memory then, so 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.
peopleproblems@lemmy.world 1 year ago
Well
that’s not great
Jane2187@lemmy.world 1 year ago
How come branch prediction seems so vulnerable to exploits? Both spectre and meltdown were also caused by branch prediction not working quite right.
anlumo@feddit.de 1 year ago
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).
wjrii@kbin.social 1 year ago
GustavoM@lemmy.world 1 year ago
Welp. Thankfully my current AMD desktop PC will be the last one I’ll be using in my whole lifetime – RISC-V 4va. :^)
MonkderZweite@feddit.ch 1 year ago
If so, it’s not a fix but a patch.
liara@lemm.ee 1 year ago
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.
Kalkaline@lemmy.one 1 year ago
Oh hey look, AMD stock went up 2% today.
Ocelot@lemmies.world 1 year ago
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.
meat_popsicle@sh.itjust.works 1 year ago
Exploit is usable via JavaScript. Does not require local access.
downpunxx@kbin.social 1 year ago
AMD lol
sadreality@kbin.social 1 year ago
This is not a back-end at all...
I_like_cats@lemmy.one 1 year ago
Linux has a merged mitigation so when the new kernel comes out Linux users will be safe
nul9o9@lemmy.world 1 year ago
Looks like I’m getting the final kick to Linux on my main gaming PC.
Dnn@lemmy.world 1 year ago
Welcome to the club! We’re dozens here!
MooseBoys@lemmy.world 1 year ago
good luck with that
mrmanager@lemmy.today 1 year ago
Which version? I got 6.4.6 a few mins ago in arch.
chameleon@kbin.social 1 year ago
In seriousness: it's in 6.4.6, 6.1.41 and a bunch of other kernel versions released yesterday.
Saneless@lemmy.world 1 year ago
Sorry, it’s 6.4.7. I already have your passwords, thanks