Linux has a merged mitigation so when the new kernel comes out Linux users will be safe
Looks like I'm getting the final kick to Linux on my main gaming PC.
Welcome to the club! We're dozens here!
Highly recommend Pop OS! It's been very reliable. I haven't had anything this steady since Mac OS when I was just doing programming. I tried to go from Mac to Alienware for personal computing and it was terrible, windows blue screened almost once a week if not once every four days.
Switched to Pop OS, enabled Proton in steams preferences for gaming, and it was completely steady. Only thing that doesn't work is the hibernate. Which isn't a super big deal to me.
I'd actually say everything has been a better experience than windows. Lutris and pop store have a large variety of games and apps. For example lutris supports GOG and probably epic games. It feels like it's everything I'd want without the shitty user interfaces and lack of crashes.
on my main gaming PC
good luck with that
I know it's not the best, but Proton has come a long, long way. I can play D4, Monster Hunter, factorio, lots of stuff.
I've been testing the waters with my steam deck. There are some hiccups, but almost everything I want to play can be done with proton.
It is really fantastic. With steam almost all the games i bother playing just works. Deleted the windows partition years ago.
Just have to check the community forum how well it works before buying. Or just get a refund if it does not work.
I know it's not the best
Didn't pay thousands for top of the line ryzen and nvidia gear for "not the best" gaming situation.
Linux falls short on two major fronts, less idiot proof, less gamer friendly, and that's Windows' largest market shares, idiots and gamers.
It's almost issue free with the exception of the publishers explicitly blocking it because it doesn't allow them to add a rootkit to your system.
Lmao, most games have better performance on linux so you can't claim it's not the best
There's still the issue of overhead and such. Like I want to ditch windows forever, but Linux is just not 100% there yet with gaming. It's very close though.
Do you know if that works for epic games and heroic launcher as well?
There's another launcher that I'm forgetting the name of that will launch Epic and GoG games. Following that proton guide should make NTFS (windows) drives usable for anything in Linux though. I can boot games downloaded from "alternate sites" if I add them to steam as "non steam games" regardless of how the drive is mounted.
Not sure if you are joking but Linux gaming is great now. I've been gaming for at least the last two years on only Linux. Check out https://www.protondb.com/explore
I have yet to find a game that doesn't run
At this point I don't even check before buying
Pop os on my gaming rig, works fine
There hasn't been a single game I've struggled to run in the last few months on proton. I haven't had a windows PC in like a year ish or more?
I play games heavily too.
Try it out sometime if your setup isn't extremely niche and maybe you'll find it to be accommodating.
The weirdest things I've had to do are click a box in steam to enable proton usage and reinstall something in Lutris for Battle.net on world of warcraft.
when the new kernel comes out Linux users will be safe
It’s going to take a lot longer than that for most distros to move to latest upstream. This specific fix might be pulled in as a hotfix if you’re lucky, but it still takes time. The latest Ubuntu LTS is on 5.15, for example, which was released in October 2021. Debian Bookworm, which just released last month, uses 6.1 from December 2022.
Critical security fixes are backported. There where a lot of kernels released yesterday that had the fix.
For 5.15, 5.15.122 was released with the zenbleed mitigation.
5.15.122 was released with the zen bleed mitigation
But Ubuntu users (for example) won’t get that automatically. Canonical still has to pull the upstream release, run validation, and roll out a patch. It will probably be speedy, but still on the order of several weeks before people see it by default.
This is exactly the kind of thing that gets backported to stable LTS distros tho. The kernel Major.Minor is just the base - it doesn't tell the whole story.
Right - I was just objecting to the suggestion that once upstream has the fix, “Linux users will be safe”.
Thank goodness I'm on arch (btw).
Time to sit back and relax
Which version? I got 6.4.6 a few mins ago in arch.
Sorry, it's 6.4.7. I already have your passwords, thanks
You work fast :)
In seriousness: it's in 6.4.6, 6.1.41 and a bunch of other kernel versions released yesterday.
Why is it that every time there's drama about hardware, its something I own?
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.
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.
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
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! 🤙
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.
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.
How come branch prediction seems so vulnerable to exploits? Both spectre and meltdown were also caused by branch prediction not working quite right.
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 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.
The article says it's exploitable via javascript on a random web page. I don't see how that could be possible
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.
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.
Oh poop.
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.
Well
that's not great
Feeling pretty smudge about my 2400g and RX580 "gaming" rig.
Makes me glad I'm using an ancient CPU from before the vulnerability.
Google has reported that any Intel processor since 1995 with out-of-order execution is potentially vulnerable to the Meltdown vulnerability (this excludes Itanium and pre-2013 Intel Atom CPUs).
A Ryzen 2500U.
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.
I'm just going to pretend I didn't buy any AMD surface laptops.
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.
If so, it's not a fix but a patch.
This is not a back-end at all...
Oh hey look, AMD stock went up 2% today.
Welp. Thankfully my current AMD desktop PC will be the last one I'll be using in my whole lifetime -- RISC-V 4va. :^)
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 :(
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.
Linux has a merged mitigation so when the new kernel comes out Linux users will be safe
Looks like I'm getting the final kick to Linux on my main gaming PC.
Welcome to the club! We're dozens here!
Highly recommend Pop OS! It's been very reliable. I haven't had anything this steady since Mac OS when I was just doing programming. I tried to go from Mac to Alienware for personal computing and it was terrible, windows blue screened almost once a week if not once every four days.
Switched to Pop OS, enabled Proton in steams preferences for gaming, and it was completely steady. Only thing that doesn't work is the hibernate. Which isn't a super big deal to me.
I'd actually say everything has been a better experience than windows. Lutris and pop store have a large variety of games and apps. For example lutris supports GOG and probably epic games. It feels like it's everything I'd want without the shitty user interfaces and lack of crashes.
good luck with that
I know it's not the best, but Proton has come a long, long way. I can play D4, Monster Hunter, factorio, lots of stuff.
I've been testing the waters with my steam deck. There are some hiccups, but almost everything I want to play can be done with proton.
It is really fantastic. With steam almost all the games i bother playing just works. Deleted the windows partition years ago.
Just have to check the community forum how well it works before buying. Or just get a refund if it does not work.
Didn't pay thousands for top of the line ryzen and nvidia gear for "not the best" gaming situation.
Linux falls short on two major fronts, less idiot proof, less gamer friendly, and that's Windows' largest market shares, idiots and gamers.
It's almost issue free with the exception of the publishers explicitly blocking it because it doesn't allow them to add a rootkit to your system.
Lmao, most games have better performance on linux so you can't claim it's not the best
If you use this guide to mount the Windows drives you can run it and Linux side by side. It works just as good as Windows these days for 90% of games. You can add games downloaded from unofficial sites to Steam as a "Non-steam game" and it works. Installing Nvidia drivers on Mint is easier than Windows, there's a built in utility.
There's still the issue of overhead and such. Like I want to ditch windows forever, but Linux is just not 100% there yet with gaming. It's very close though.
Do you know if that works for epic games and heroic launcher as well?
There's another launcher that I'm forgetting the name of that will launch Epic and GoG games. Following that proton guide should make NTFS (windows) drives usable for anything in Linux though. I can boot games downloaded from "alternate sites" if I add them to steam as "non steam games" regardless of how the drive is mounted.
Not sure if you are joking but Linux gaming is great now. I've been gaming for at least the last two years on only Linux. Check out https://www.protondb.com/explore
I have yet to find a game that doesn't run
At this point I don't even check before buying
Pop os on my gaming rig, works fine
There hasn't been a single game I've struggled to run in the last few months on proton. I haven't had a windows PC in like a year ish or more?
I play games heavily too.
Try it out sometime if your setup isn't extremely niche and maybe you'll find it to be accommodating.
The weirdest things I've had to do are click a box in steam to enable proton usage and reinstall something in Lutris for Battle.net on world of warcraft.
It’s going to take a lot longer than that for most distros to move to latest upstream. This specific fix might be pulled in as a hotfix if you’re lucky, but it still takes time. The latest Ubuntu LTS is on 5.15, for example, which was released in October 2021. Debian Bookworm, which just released last month, uses 6.1 from December 2022.
Critical security fixes are backported. There where a lot of kernels released yesterday that had the fix. For 5.15, 5.15.122 was released with the zenbleed mitigation.
But Ubuntu users (for example) won’t get that automatically. Canonical still has to pull the upstream release, run validation, and roll out a patch. It will probably be speedy, but still on the order of several weeks before people see it by default.
This is exactly the kind of thing that gets backported to stable LTS distros tho. The kernel Major.Minor is just the base - it doesn't tell the whole story.
Right - I was just objecting to the suggestion that once upstream has the fix, “Linux users will be safe”.
Thank goodness I'm on arch (btw).
Time to sit back and relax
Which version? I got 6.4.6 a few mins ago in arch.
Sorry, it's 6.4.7. I already have your passwords, thanks
You work fast :)
In seriousness: it's in 6.4.6, 6.1.41 and a bunch of other kernel versions released yesterday.
Why is it that every time there's drama about hardware, its something I own?
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.
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.
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
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.
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! 🤙
Yikes.
It's worth noting these are the firmware / microcode fixes.
There's already a software solution available,
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.
How come branch prediction seems so vulnerable to exploits? Both spectre and meltdown were also caused by branch prediction not working quite right.
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).
I see what you did there, even if you didn't :)
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.
The article says it's exploitable via javascript on a random web page. I don't see how that could be possible
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.
ELI5 how this works?
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.
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.
Oh poop.
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.
Well
that's not great
Feeling pretty smudge about my 2400g and RX580 "gaming" rig.
Makes me glad I'm using an ancient CPU from before the vulnerability.
Which one?
From Wikipedia:
A Ryzen 2500U.
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.
I'm just going to pretend I didn't buy any AMD surface laptops.
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.
If so, it's not a fix but a patch.
This is not a back-end at all...
Oh hey look, AMD stock went up 2% today.
Welp. Thankfully my current AMD desktop PC will be the last one I'll be using in my whole lifetime -- RISC-V 4va. :^)
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 :(
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
AMD lol