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%

#102
Nhonho
Od1sseas13th Gen :cool:
Don't worry. They will publish the 13th generation security flaw only next year to you buy new CPU and motherboard too.
Posted on Reply
#103
Mussels
Freshwater Moderator
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?

These news are way more important for businesses than for us, imo.
They're relevant in a few ways, but rarely effect home users directly - it's more than home users are not worth the effort to develop malware that byte steal a few bytes of a code at a time, while a cloud server running a dozen instances of sensitive data those few bytes could strike gold

Common hardware (as desktops are more or less cut down enterprise hardware these days) means we're vulnerable too
lexluthermiesterNo they are not. And if you really believe that, I have a bridge in Brooklyn NYC I'd like to sell you...
Theres been some pretty big updates along the way, but also several small ones that had little change
Posted on Reply
#104
lexluthermiester
MusselsTheres been some pretty big updates along the way
True, but that's not what I was saying. They were saying that every single update was critical, which is just as silly as it is wrong.
Posted on Reply
#105
AnotherReader
efikkan: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)


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.
Both AMD and Intel have much higher standards than most software makers. Despite their extensive validation, as you said, the CPU is a vastly complex state machine and verifying every possible state is impossible. However, there are things both could do to decrease the vulnerability of their CPUs to errors like these. Rather than sharing structures dynamically in SMT, they could define a static split, i.e. 1/2 of each structure for a thread. This wouldn't be ideal for performance, but would mitigate Downfall. In addition, fast zeroing of registers upon a context switch would kill exploits like this completely.
PatriotIt's not just a different customer issue, its a about pivoting from a useless VM of one customer to a more useful VM of the same customer. Being able to pivot across VMs is highly useful for a hacker "going deep" (shrugs)
If the attacker is already within your VM, then you have bigger fish to fry than Downfall as there are far easier exploits available at that point.
Posted on Reply
#106
lexluthermiester
AnotherReaderIn addition, fast zeroing of registers upon a context switch would kill exploits like this completely.
You know, that would actually work. Nice thinking! Let's see if they do anything near that logical.
AnotherReaderIf the attacker is already within your VM, then you have bigger fish to fry than Downfall as there are far easier exploits available at that point.
Again, very true!
Posted on Reply
#107
Mussels
Freshwater Moderator
lexluthermiesterTrue, but that's not what I was saying. They were saying that every single update was critical, which is just as silly as it is wrong.
That's where some confusion sets in, because of how you interpret the updates

Every major release had major changes - entire ranges of CPUs added in, new features like ReBar, default settings changes for windows 11, and so on.

Beta and test releases can count or not count depending on your perspective - they're both major in that they had the big improvements first, but minor in that they weren't the final release of that feature.
Then board makers could put out 20 BIOS updates on the same AGESA code fixing their own shit which is a different metric again


I do agree that not every update was critical by the way, just saying that depending how you view it it can seem that way - check Asus BIOS lists for the boards and the only remaining visible files are those major updates with the minor ones removed from view
Posted on Reply
#108
AusWolf
MusselsThey're relevant in a few ways, but rarely effect home users directly - it's more than home users are not worth the effort to develop malware that byte steal a few bytes of a code at a time, while a cloud server running a dozen instances of sensitive data those few bytes could strike gold

Common hardware (as desktops are more or less cut down enterprise hardware these days) means we're vulnerable too
Yes, we're vulnerable, but what's the likelihood of actually being hacked?

I mean, we're all vulnerable against bullets, but who's gonna shoot me doing my normal things in the English Midlands? Buying a bulletproof vest to do my weekly shopping wouldn't be too practical.

If the microcode update comes through Windows Update, then sure, whatever. I just don't want to worry about something that has near zero chance to affect me.
MusselsThat's where some confusion sets in, because of how you interpret the updates

Every major release had major changes - entire ranges of CPUs added in, new features like ReBar, default settings changes for windows 11, and so on.

Beta and test releases can count or not count depending on your perspective - they're both major in that they had the big improvements first, but minor in that they weren't the final release of that feature.
Then board makers could put out 20 BIOS updates on the same AGESA code fixing their own shit which is a different metric again


I do agree that not every update was critical by the way, just saying that depending how you view it it can seem that way - check Asus BIOS lists for the boards and the only remaining visible files are those major updates with the minor ones removed from view
That's why one should read the release notes and decide whether upgrading is necessary or not. There's been quite a few BIOS updates for my board (Pro B650M-A Wifi) with the same AGESA code as the last one and only "memory compatibility improved" in the release notes. If my system is already running fine, I don't bother with such updates at all.
Posted on Reply
#109
Mussels
Freshwater Moderator
AusWolfYes, we're vulnerable, but what's the likelihood of actually being hacked?
Wrong question - if we're hacked what's the likelihood of it retrieving any useful data (extremely, extremely low)
Therefore, no ones going to hack home users and leave it running 24/7 and manually sniff the data to find out if anything useful was found

These hacks are only useful against something that's crunching high value data every day, so that eventually with even a low chance of success you get something useful.

Country vs country espionage, not steal a netbanking login cookie with one chance of success for one random second of one day a month, with no guarantees the user will be using the netbanking in that second, or that it'll be ran off an SMT thread where the vulnerability occured
Posted on Reply
#110
A Computer Guy
AusWolfYes, we're vulnerable, but what's the likelihood of actually being hacked?
Might depend if your a high valued target. For example a non-Twitter (oops I mean fancy X) employee that now works from home (since the new *cough* was introduced to the world) that happens to work in a cloud based environment that likely has various credentials to open gates to sensitive stuff.
Posted on Reply
#111
Wye
This sounds like a very old issue that existed 10 years ago, or similar. And it has the same caveat: zero impact on desktop users.
Posted on Reply
#112
Mussels
Freshwater Moderator
WyeThis sounds like a very old issue that existed 10 years ago, or similar. And it has the same caveat: zero impact on desktop users.
All CPU vulnerabilities sound the same in the end - and the solution is usually a software update with a hardware fix a generation or two later
Posted on Reply
#113
Od1sseas
NhonhoDon't worry. They will publish the 13th generation security flaw only next year to you buy new CPU and motherboard too.
I will just install an antivirus
Posted on Reply
#114
ToxicTaZ
I didn't notice anything with my old 9900KS yet, I'm getting ready to upgrade to the new 14900KS. A huge leap of performance with updated security.

My 9900KS misted the last Vulnerability attacks. That pledged most SkyLake lines. Intel added hardware the fix to 9900KS line.

Glad this Vulnerable attack doesn't effect any of the LGA 1700 socket lineups 12th, 13th, 14th Generations.

Cheers
Posted on Reply
#115
chrcoluk
R-T-BThere 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.


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 documented all the keys I know off in my post install script, which I got from Microsoft's documentation, not all mitigations can be turned on and off, the ones that were deemed of actual reasonable risk of being in the wild for client exploitation and have low impact are not optional. Some of the later one's that are optional are off by default though.

Note downfall isnt listed on this link and is also some older one's not listed here, there is probably a newer article for downfall.

support.microsoft.com/en-au/topic/kb4072698-windows-server-and-azure-stack-hci-guidance-to-protect-against-silicon-based-microarchitectural-and-speculative-execution-side-channel-vulnerabilities-2f965763-00e2-8f98-b632-0d96f30c8c8e
Posted on Reply
#116
Mussels
Freshwater Moderator
Od1sseasI will just install an antivirus
That wont change how mitigations work
Posted on Reply
#117
Od1sseas
MusselsThat wont change how mitigations work
Antivirus has anti-exploit protection
Posted on Reply
#118
MarsM4N
Solid State Soul ( SSS )Planned obsolescence at its finest ladies and gentlemen
Tbh. Microsoft did way more harm with their ridiculous Windows 11 hardware requirements. :shadedshu: The amount of PC's that end up in landfills because of that will be monumental.
Posted on Reply
#119
Prima.Vera
Sometimes I feel paranoid and think maybe Intel is doing those things on purpose, just for companies to start replacing "old" hardware much faster. Who knows what are they cooking for 13th and 12th gen CPUs in 1 or 2 years from now ;)
Posted on Reply
#120
AusWolf
MarsM4NTbh. Microsoft did way more harm with their ridiculous Windows 11 hardware requirements. :shadedshu: The amount of PC's that end up in landfills because of that will be monumental.
Thank god nobody forces me to upgrade to that abomination!
Posted on Reply
#121
Mussels
Freshwater Moderator
Od1sseasAntivirus has anti-exploit protection
But they can't turn off something already active - that defeats the purpose of the mitigations because then a virus can just turn them off, too.
Prima.VeraSometimes I feel paranoid and think maybe Intel is doing those things on purpose, just for companies to start replacing "old" hardware much faster. Who knows what are they cooking for 13th and 12th gen CPUs in 1 or 2 years from now ;)
They certainly held onto news of this so they had another year of sales of products with a known flaw, knowing those consumers will need to replace them
Posted on Reply
#122
Od1sseas
MusselsBut they can't turn off something already active - that defeats the purpose of the mitigations because then a virus can just turn them off, too.


They certainly held onto news of this so they had another year of sales of products with a known flaw, knowing those consumers will need to replace them
Because your CPU has some kind of an exploit that doesn't mean there is an active virus running on your system. Viruses must be created to take advantage of those kind of exploits. Antivirus software protects you from viruses in real time, they have anti-exploit mechanisms, heuristics engines to protect from 0-day viruses and they can absolutely prevent/delete/disinfect something already running on your system.

usa.kaspersky.com/resource-center/definitions/heuristic-analysis

www.kaspersky.com/enterprise-security/wiki-section/products/exploit-prevention

support.kaspersky.com/KSVLA/5.0/en-US/74649.htm
Posted on Reply
#123
ncrs
ncrsThe comments here also imply some performance impact, but again - we'll need to wait for Phoronix benchmarks.
The AMD Inception Linux mitigations benchmarks have been published.

Interestingly Linux mitigations do not require new microcode on Zen 3 and 4, but have slightly decreased performance penalty with it present (available currently only on server EPYC line).

There are two gaming-related benchmarks on desktop Zen 4 (3DMark Wild Life Extreme and VKMark) showing minimal impact, so one can reasonably assume that pure gaming won't be affected either. However to be sure it has to be tested. Windows mitigations might also have different result.

Most affected workloads are heavy I/O users like databases and web servers, so it looks like context switching is penalized.
Posted on Reply
#124
mkdr
Just amazing. Ryzen also being hit up to 50% performance loss in some workflow with Inception mitigations. This is a catastrophe. Could also have huge impact on SSD I/O, especially small file access. Upcoming direct storage under Windows for gaming. Lets hope you can disable the mitigations under Windows.
Posted on Reply
#125
ncrs
mkdrLets hope you can disable the mitigations under Windows.
Microsoft's documentation for client Windows version is not good. It lists 2 recent AMD vulnerabilities and registry keys to enable mitigations for them, but no statement whether the mitigation is enabled by default. The Microsoft CVE page for Inception suggests that some mitigations are enabled by default and you can enable more for "intra-process disclosure vectors". This would mirror what Linux has implemented with default "light" mode and heavier modes for when you have untrusted users or VMs.

The registry keys are, as far as I understand, also mutually exclusive since they toggle different bits in the FeatureSettingsOverride value.
Their PowerShell module doesn't support AMD vulnerabilities either.

I hope that I'm interpreting this wrong, otherwise it's quite disappointing.
Posted on Reply
Add your own comment
May 14th, 2024 21:30 EDT change timezone

New Forum Posts

Popular Reviews

Controversial News Posts