Friday, August 11th 2023

"Downfall" Intel CPU Vulnerability Can Impact Performance By 50%

Intel has recently revealed a security vulnerability named Downfall (CVE-2022-40982) that impacts multiple generations of Intel processors. The vulnerability is linked to Intel's memory optimization feature, exploiting the Gather instruction, a function that accelerates data fetching from scattered memory locations. It inadvertently exposes internal hardware registers, allowing malicious software access to data held by other programs. The flaw affects Intel mainstream and server processors ranging from the Skylake to Rocket Lake microarchitecture. The entire list of affected CPUs is here. Intel has responded by releasing updated software-level microcode to fix the flaw. However, there's concern over the performance impact of the fix, potentially affecting AVX2 and AVX-512 workloads involving the Gather instruction by up to 50%.

Phoronix tested the Downfall mitigations and reported varying performance decreases on different processors. For instance, two Xeon Platinum 8380 processors were around 6% slower in certain tests, while the Core i7-1165G7 faced performance degradation ranging from 11% to 39% in specific benchmarks. While these reductions were less than Intel's forecasted 50% overhead, they remain significant, especially in High-Performance Computing (HPC) workloads. The ramifications of Downfall are not restricted to specialized tasks like AI or HPC but may extend to more common applications such as video encoding. Though the microcode update is not mandatory and Intel provides an opt-out mechanism, users are left with a challenging decision between security and performance. Executing a Downfall attack might seem complex, but the final choice between implementing the mitigation or retaining performance will likely vary depending on individual needs and risk assessments.
Source: Phoronix
Add your own comment

162 Comments on "Downfall" Intel CPU Vulnerability Can Impact Performance By 50%

#76
ncrs
DenverSo do you think it is possible to get these local admin privileges through a js code in the browser, could you show how? Just for curiosity.
I wrote "potentially" in bold for a reason. It has not been demonstrated so far.
I was also referring to the notion that Attack Vector: Local somehow prohibits this ever being the case, it does not.

WebAssembly does support SIMD which can be mapped to AVX (at least in Firefox), but not to AVX2. So this particular vulnerability would be very hard to implement in JS, most likely impossible. However the cleverness of security researchers never ceases to amaze me, so I give myself the leeway of being wrong about that.
Posted on Reply
#77
lexluthermiester
DenverSo do you think it is possible to get these local admin privileges through a js code in the browser, could you show how?
It isn't, ignore them.
ncrsWebAssembly does support SIMD which can be mapped to AVX (at least in Firefox), but not to AVX2.
Sorry, doesn't work that way, ESPECIALLY in Firefox. And even if it did, the level of access to potential data harvesting is very limited and small. As I said earlier, this very nearly nothing-sauce.
Posted on Reply
#78
AusWolf
mkdrYes I need them. AMD AGESA updates are needed, as shown in the last years.
No, they are not. You only need a BIOS update if something is broken in the one you currently have.
Posted on Reply
#79
TumbleGeorge
lexluthermiesterYes, you can
Average Joe can't.
Posted on Reply
#80
lexluthermiester
TumbleGeorgeAverage Joe can't.
Perhaps. However, average Joe's will not be aware to the situation to begin with.
Posted on Reply
#82
Ferrum Master
lexluthermiesterBut I'm not getting into this silly debate/argument.
There is not even a debate mate. That CVE is for Spectre


Posted on Reply
#83
lexluthermiester
Ferrum MasterThere is not even a debate mate. That CVE is for Spectre


Um, "Mate", learn how to read...
lexluthermiesterAnd before anyone says it, there will not be any JS based exploits one can load in a browser page. It's detailed in the description;
CVE - CVE-2022-40982 "Information exposure through microarchitectural state after transient execution in certain vector execution units for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access."
Admin/Root access is required in addition to local(direct physical) access to the system in question. Remote exploitation is not possible without direct user action and interaction.
Thus..

There is this.
downfall.page/
There a "Daniel Moghimi" details a few examples of how an exploit would work. Please note, the demo's are being run on an Intel Mac being accessed with SuperUser authoritives, something most Mac users wouldn't be doing. Additionally, one has to have the admin logins for the target system. This would be the same as physically being there. Without that info, remote exploitation is NOT possible.
Posted on Reply
#84
ncrs
lexluthermiesterThus..
Thus you're repeating the same misinformation as before, based on your flawed interpretation of what "local access" means.
Posted on Reply
#85
Ferrum Master
lexluthermiesterUm, "Mate", learn how to read...
You okay mate? Not sure, but your are talking about the skirt and I am about the wife.
Posted on Reply
#86
ncrs
lexluthermiesterThere is this.
downfall.page/
There a "Daniel Moghimi" details a few examples of how an exploit would work. Please note, the demo's are being run on an Intel Mac being accessed with SuperUser authoritives, something most Mac users wouldn't be doing. Additionally, one has to have the admin logins for the target system. This would be the same as physically being there. Without that info, remote exploitation is NOT possible.
No. Read the FAQ on this site you linked, and read the actual paper. It directly contradicts what you're saying:
[Q] What about web browsers?
[A] In theory, remotely exploiting this vulnerability from the web browser is possible. In practice, demonstrating successful attacks via web browsers requires additional research and engineering efforts.
The demo requires administrative access because it's running in VMs on his Mac. The vulnerability itself does not need it.
Posted on Reply
#87
lexluthermiester
Ferrum MasterYou okay mate? Not sure, but your are talking about the skirt and I am about the wife.
You are talking about nothing and nonsense. Explain in more detail what "you" are talking about. The rest of us are discussing the topic of the article:

"Downfall" Intel CPU Vulnerability Can Impact Performance By 50%

What are you going on about?
(seriously, if you're going to troll, be competent about it)
Posted on Reply
#88
Ferrum Master
lexluthermiesterYou are talking about nothing and nonsense. Explain in more detail what "you" are talking about. The rest of us are discussing the topic of the article:

"Downfall" Intel CPU Vulnerability Can Impact Performance By 50%

What are you going on about?
(seriously, if you're going to troll, be competent about it)
Lex, are you sober?

You quoted me, said not true about the obvious and I showed you a M$ list stating exactly what I said. You cannot disable ALL MITIGATIONS in windows, Microsoft regulates it, not anyone else. You cannot speculate what they will do about the future ones also, that's their decision, including this CVE. So far on the Linux side everything is in your hands. I responded actually to mkdr dude, not you, as he had concerns.

Posted on Reply
#89
mkdr
lexluthermiesterNo they are not.
YES THEY WERE. Every single AGESA of the past years was NECESSARY because they gave dramatic performance boosts, fixed a dramatic bug (Ryzen 7000 soc voltage, core parking, CCX latency, clock boost etc), fixed RAM compatibility (6000+er not booting / issues), fixed BOOT times (from 50 to 20 seconds) and MORE. You dont seem to know anything about it, otherwise you wouldnt claim that. Intel had no issues on their side to worry about it. But for Ryzen, you totally NEEDED every single new AGESA update.
Posted on Reply
#90
lexluthermiester
mkdrYES THEY WERE. Every single AGESA of the past years was NECESSARY because they gave dramatic performance boosts, fixed a dramatic bug (Ryzen 7000 voltage, core parking, CCX latency, clock boost etc), fixed RAM compatibility (6000+er not booting / issues), fixed BOOT times (from 50 to 20 seconds) and MORE. You dont seem to know anything about it, otherwise you wouldnt claim that nonsense. Intel had no issues on their side to worry about it. But for Ryzen, you totally NEEDED every single new AGESA update.
You're talking to me like I'm some ignorant twat that doesn't work with PC's(including Ryzen based systems) every every day of the week. Do hush.
Ferrum MasterYou quoted me, said not true about the obvious and I showed you a M$ list stating exactly what I said.
Execpt that what you said is incorrect.
Ferrum MasterYou cannot disable ALL MITIGATIONS in windows
Yes, you can.
Ferrum MasterMicrosoft regulates it, not anyone else.
Doesn't mean it can't be disabled. Are you seriously THAT oblivious?
Posted on Reply
#91
TheDeeGee
As long as games arn't affected i don't care, otherwise i'll look into disabling the fix.
Posted on Reply
#92
AusWolf
mkdrYES THEY WERE. Every single AGESA of the past years was NECESSARY because they gave dramatic performance boosts, fixed a dramatic bug (Ryzen 7000 soc voltage, core parking, CCX latency, clock boost etc), fixed RAM compatibility (6000+er not booting / issues), fixed BOOT times (from 50 to 20 seconds) and MORE. You dont seem to know anything about it, otherwise you wouldnt claim that. Intel had no issues on their side to worry about it. But for Ryzen, you totally NEEDED every single new AGESA update.
Well, I know all about it because I'm on a Zen 4 system right now, and believe me, not every single BIOS update is necessary. Yes, you need to fix your SoC voltage. Yes, you need an update for normal POST times. But that does not cover every single update by far.
Posted on Reply
#93
Daytrader
Dam, just bought a Intel Core i9-13900K as well, I'm just a gamer thou, will i be affected much guys ?
Posted on Reply
#94
AnotherReader
ncrsIt does not rely on SMT since it works with just context-switching. Disabling SMT is not a mitigation for this vulnerability, from the paper:
Context switching makes it harder since there's no guarantee that the attacker will be scheduled onto the victim's core.
Posted on Reply
#95
efikkan
MarsM4NEngineers are just humans, and humans make errors. Period. ;) I guess the only solution would be chips (and software/firmware) designed by AI. Because machines don't make errors…
:wtf:
So-called "AI" is not currently intelligent at all, it's basically using heuristics to recognize patterns, which in turn can be used to generate new data. So in essence, using "AI" to design CPUs will probably lead to designs with more flaws, since there is no intelligence behind the "decisions".

Using "AI" to help test designs could be interesting though, as it might expose some interesting use cases.

(OT: Using AI to generate text can yield some seriously hilarious results though: link)
MarsM4NThey could bigly reduce such "unforeseen consequences" with proper QA. ;) But they're doing the exact opposite, cutting corners wherever they can to increase profits for shareholders.
<snip>
Also it's not surprising that tech security flaws stay undetected for soo long. There are not many people on the planet who actually have a understanding for the tech, and those who do work either for the tech companies, the GOV or bad actors. And none of them are interested in making security flaws public, two of them even abuse them. That's why most security flaws are reported by private researchers.
I'm a software engineer, not a hardware engineer, but if the corporate culture in companies like Intel, AMD, Nvidia, etc. is anything like what I've experienced in software companies with 1000+ employees (or read about in horror stories), I'm not surprised at all that a lot of serious flaws slip through. I've personally witnessed several cases of even "inexperienced" interns discovering critical flaws which have been completely dismissed. If you have hundreds or thousands of engineers on a project, there is probably a huge hierarchy of middle management, where it's hard to get the right information through the "noise". (Not to mention, engineers are generally stubborn "know-it-alls") And then there is the case of management knowing the issue, but deliberately covering it up to ship a product.
To be clear, I'm explaining it, not excusing it.

To answer your first paragraph, how would you do good enough QA?
CPUs are incredible complex state machines, and verifying every possible combination is impossible.
With every released CPU there is commonly a long errata, containing typically 20-30 flaws discovered during testing. It is actually quite normal that a lot of features are disabled or timings adjusted in the firmware due to bugs, so probably no CPU performs "as they expected", no new architecture anyways.
And it's common that some flaws are not addressed in firmware either, so certain software can be triggering a CPU bug on specific CPUs.
I know of two such examples. The Bulldozer family had some error triggered by compiling (I believe it was gcc), resulting in invalid binaries. Zen(1) had another flaw triggered most easily by gcc and llvm, which AMD never fully acknowledged. And Intel has had plenty too.
AusWolfIt makes me wonder if these vulnerabilities really deserve the attention they get. I mean, sure, someone could potentially hack your PC doing the point-and-click steps you described, but why would they?
You should be much more worried about the crappy firmware of your router, it probably has several easily exploitable vulnerabilities.

For any bug that requires root access to exploit, it's not really a problem for desktop users, as a root can do anything on your computer anyways.

The concern is for cloud providers, as someone in one VM can potentially affect another VM. But even then it's probably mostly theoretical. It is one thing to reproduce a problem in a controlled environment, and something completely different to do it on a server with randomized memory addresses, lots of data churning through constantly, VMs being loaded and unloaded all the time. The chances of someone stealing a continuous piece of data through a randomized and fragmented memory space is minuscule. But sure, an attacker can get lucky and strike a few bytes containing a private key etc.
Posted on Reply
#96
Nhonho
Intel's marketing department has always said that "you should only use Intel CPUs in your servers because only Intel CPUs have reliability, availability, and serviceability (RAS)".



Posted on Reply
#97
Daytrader
Well i just read that Intel’s newer 12th-gen and 13th-gen Core processors are not affected., is this true ?
Posted on Reply
#98
ncrs
DaytraderDam, just bought a Intel Core i9-13900K as well, I'm just a gamer thou, will i be affected much guys ?
DaytraderWell i just read that Intel’s newer 12th-gen and 13th-gen Core processors are not affected., is this true ?
12th and 13th generations are not affected by this.
AnotherReaderContext switching makes it harder since there's no guarantee that the attacker will be scheduled onto the victim's core.
Sure, however if you allow for scheduling variance at all, then relying on SMT is dubious as well since almost every OS tries to fill real cores first before assigning work to SMT ones. In both cases there's techniques for trying to coax the scheduler to fit your needs.
Posted on Reply
#99
R-T-B
mkdryou cant.
There are opt out registry keys for everything trailing all the way back to meltdown for the os side. In that sense you can.

Microcode is harder to skip but also tends to lose far less performance than the OS mitigations.
DenverSo do you think it is possible to get these local admin privileges through a js code in the browser, could you show how? Just for curiosity.
Admin is not needed. People keep saying this but there is no evidence for it that I've seen.

It would be hard, but not impossible to mount such an attack in javascript. It'd probably help if you knew the exact target hardware in advance.
Ferrum MasterYou cannot disable them all in windows, it is baked in kernel. You will not have a choice.
Windows had regkeys to disable every mitigation, just FYI. It's virtually the same as Linux there. Looking them up is far more homework, however.
Posted on Reply
#100
davidm71
So how do you opt out in that will Windows automatically install the Downfall microcode patch and kill performance?

I don't want that.

Thanks
Posted on Reply
Add your own comment
May 15th, 2024 17:30 EDT change timezone

New Forum Posts

Popular Reviews

Controversial News Posts