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
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.
162 Comments on "Downfall" Intel CPU Vulnerability Can Impact Performance By 50%
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.
The WASM compiler in Firefox is even AVX2-aware, but WASM itself does not support 256-bit vectors. The WASM JIT x86 assembler backend also has AVX support, and it has been enabled by default for a year now. Obviously you can't directly call AVX opcodes from WASM, but I didn't write you can.
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.
"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)
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.
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) 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. 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.
Microcode is harder to skip but also tends to lose far less performance than the OS mitigations. 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. 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.
I don't want that.
Thanks