965
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 13 Aug 2023
965 points (100.0% liked)
Technology
60151 readers
1495 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 2 years ago
MODERATORS
Every article is a copy paste of the same bullshit talking about the vulnerability and pointing to the stupid cryptic list of processors that requires you to jump through hoops to read it. You can't just search for your processor in a database I mean fuck that would take them at least an a couple hours of their precious time to set up and they have only had a year. How do you fix it? Why with a microcode update of course!!...from where you ask? Well don't worry just look at the cryptic list it will tell you if you need a microcode update!!
Fuck every article about this shit. Anyone wanna bust an Eli5 on how to fix this problem for people? (I was assuming it's a BIOS update but the articles have only confused me further)
ELI5, or ELIAFYCSS (Explain like I'm a first year CS student): modern x86 CPUs have lots of optimized instructions for specific functionality. One of these is "vector instructions", where the instruction is optimized for running the same function (e.g. matrix multiply add) on lots of data (e.g. 32 rows or 512 rows). These instructions were slowly added over time, so there are multiple "sets" of vector instructions like MMX, AVX, AVX-2, AVX-512, AMX...
While the names all sound different, the way how all these vector instructions work is similar: they store internal state in hidden registers that the programmer cannot access. So to the user (application programmer or compiler designer) it looks like a simple function that does what you need without having to micromanage registers. Neat, right?
Well, problem is somewhere along the lines someone found a bug: when using instructions from the AVX-2/AVX-512 sets, if you combine it with an incorrect ordering of branch instructions (aka JX, basically the if/else of assembly) you get to see what's inside these hidden registers, including from different programs. Oops. So Charlie's "Up, Up, Down, Down, Left, Right, Left, Right, B, B, A, A" using AVX/JX allows him to see what Alice's "encrypt this zip file with this password" program is doing. Uh oh.
So, that sounds bad. But lets take a step back: how bad would this affect existing consumer devices (e.g. Non-Xeon, non-Epyc CPUs)?
Well good news: AVX-512 is not available on most Intel/AMD consumer CPUs until recently (13th gen/zen 4, and zen 4 isn't affected). So 1) your CPU most likely doesn't support it and 2) even if your CPU supports it most pre-compiled programs won't use it because the program would crash on everyone else's computer that doesn't have AVX-512. AVX-512 is a non-issue unless you're running Finite Element Analysis programs (LS-DYNA) for fun.
AVX-2 has a similar problem: while released in 2013, some low end CPUs (e.g. Intel Atom) didn't have them for a long time (this year I think?). So most compiled programs wouldn't compile with AVX-2 enabled. This means whatever game you are running now, you probably won't see a performance drop after patching since your computer/program was never using the optimized vector instructions in the first place.
So, the affect on consumer devices is minimal. But what do you need to do to ensure that your PC is secure?
Three different ideas off the top of my head:
BIOS update. The CPU has a some low level firmware code called microcode which is included in the BIOS. The new patched version adds additional checks to ensure no data is leaked.
Update the microcode package in Linux. The microcode can also be loaded from the OS. If you have an up-to-date version of Intel-microcode here this would achieve the same as (1)
Re-compile everything without AVX-2/AVX-512. If you're running something like Gentoo, you can simply tell GCC to not use AVX-2/AVX-512 regardless of whether your CPU supports it. As mentioned earlier the performance loss is probably going to be fine unless you're doing some serious math (FEA/AI/etc) on your machine.
This page tells you how to get your CPUID: https://www.intel.com/content/www/us/en/support/articles/000006831/processors/processor-utilities-and-programs.html
Then search for the CPUID here: https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
I figured out how to do it fairly quickly but it would be a hell of a lot easier if people could just type in "11700K" in a box on a web page or something and it could just tell them. Or they could have added a little bit of code to their CPU ID utility that says "yupp your processor is effected by the flaw". I am mostly annoyed at all this not for me but for all the people who would read those pages and the contents would seem like an insane foreign language to them all while articles are telling them it's a major security flaw that would allow people to steal their encryption keys.
That is a fair point.
Are you using Windows or macOS? If so you don’t have to do anything. You can just wait and a new update will be available to you soon.
And, just FYI, the fix is already out for Linux.
It'll probably just be something that happens through ordinary OS updates tbh (though I understand you'd rather know one way or another.)
I just found this on the page where they list effected models:
"Note The latest software can be obtained through operating system or VMM vendors"