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%

#126
lexluthermiester
Od1sseasAntivirus has anti-exploit protection
Sadly, not against things like this. For things like this, you can't just fix the software running on the target machine, you must also fix the way the software interacts with that machine. Antivirus suites can't do that.
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.
Then there is this.

However, I would like to remind everyone that this problem is NOT, repeat NOT something the general public needs to worry about. This exploit REQUIRES admin authorities. If you already have admin authorities, you don't need the exploit because you already have complete direct access to the system in question.

So let's have done with the bickering & arguing, eh?
Posted on Reply
#127
AnotherReader
ncrsMicrosoft'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.
One of the pages you linked says
To enable the mitigation for CVE-2023-20569 on AMD processors:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 67108928 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
These seem to be two different registry keys.
Posted on Reply
#128
R-T-B
mkdrRyzen also being hit up to 50% performance loss in some workflow with Inception mitigations. This is a catastrophe.
That isn't really what the benches say, I don't think, but I could have missed a point or two. I'll go reread the phoronix coverage now.
Posted on Reply
#129
chrcoluk
What I do know is when I tested AMD branch confusion mitigation enabled, it was like wow.

Things that were taking a fraction of a second suddenly took over a second, I soon turned it off again. :)

What I have assumed with the registry value is as you pick a higher value it also enables any mitigations for lower values as well, however I havent verified that, it could be using an addition system, where would add the values together if you want to enable multiple mitigations.
Posted on Reply
#130
lexluthermiester
R-T-BThat isn't really what the benches say, I don't think, but I could have missed a point or two. I'll go reread the phoronix coverage now.
It's a good read, but doesn't tell the whole story. The performance hit is only present in certain situations and then it's not as bad as 50%. Like all the other exploits of this type, it's very situational.
Posted on Reply
#131
ncrs
AnotherReaderOne of the pages you linked says

These seem to be two different registry keys.
I meant the registry keys for Phantom Speculation also known as Branch Type Confusion (CVE-2022-23825) and Inception (CVE-2023-20569):

CVE-2022-23825:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 16777280 /f
CVE-2023-20569:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 67108928 /f
Both are modifying the same value and both change different bits:
CVE-2022-23825: 0000001000000000000000001000000
CVE-2023-20569: 0000100000000000000000001000000

I am wondering if enabling both mitigations at the same time requires setting the value to 83886144 instead. The documentation isn't clear about this.
Posted on Reply
#134
efikkan
Solid State Soul ( SSS )Planned obsolescence at its finest ladies and gentlemen
Don't we all wonder that from time to time?
But then I realize that intentionally sabotaging your own product would only drive your customer to the competition.
(And don't many enterprise customers usually switch out hardware regularily anyways? Like when the warranty is expired?)
AnotherReaderHowever, 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.
I've argued for years that we should drop SMT outright. It made a lot of sense back when CPUs had few cores and a lot more pipeline stalls than today. But as the CPUs have become more advanced, the real-world benefits has shrunk, while the complexity to implement it has risen immensely. At this point the engineering effort and transistor budget cost of SMT could probably have been better spent on something else to increase IPC instead. Hopefully the rumors of dropping SMT in Arrow Lake is true.
Od1sseasAntivirus has anti-exploit protection
That's not how antivirus works, that's just marketing nonsense.
Posted on Reply
#135
Patriot
Why_MeSeems to be a thing with both companies.

www.tomshardware.com/news/amds-inception-fix-causes-up-to-54-performance-drop
It is not the default settings and its on 1 database. the other databases are ~13% hit.
Under most workloads there is sub 1% hit, some 5-15% not the sensational 54% wccftech is publishing and everyone is chatterboxing.
As MariaDB was such a huge outlier, I expect there to be an update in the future that will lessen the impact.
www.phoronix.com/review/amd-inception-benchmarks/4 see for yourself.


www.phoronix.com/news/GCC-Workaround-Intel-Downfall
Intel appears to have published a GCC patch to lessen the AVX impact... but disabling the avx path for gather...?
I guess the performance impact decreased it to the point that the non-avx code path was faster? idk.

@rtb how are you reading that?
Posted on Reply
#136
Od1sseas
efikkanDon't we all wonder that from time to time?
But then I realize that intentionally sabotaging your own product would only drive your customer to the competition.
(And don't many enterprise customers usually switch out hardware regularily anyways? Like when the warranty is expired?)


I've argued for years that we should drop SMT outright. It made a lot of sense back when CPUs had few cores and a lot more pipeline stalls than today. But as the CPUs have become more advanced, the real-world benefits has shrunk, while the complexity to implement it has risen immensely. At this point the engineering effort and transistor budget cost of SMT could probably have been better spent on something else to increase IPC instead. Hopefully the rumors of dropping SMT in Arrow Lake is true.


That's not how antivirus works, that's just marketing nonsense.
I want evidence for anti exploit protection being just "marketing nonsense"
Posted on Reply
#137
lexluthermiester
Od1sseasI want evidence for anti exploit protection being just "marketing nonsense"
How about that fact that it's near impossible to pull off? Just throwing it out there. If you has read up on the technical details, you would already had your answer. The "theory" @efikkan and others have offered might seem a bit "out there", however given market conditions and the fact that microsoft KNOWS that systems made in the late 2000's and early 2010's can STILL run Windows well, there is merit to the suggestions made.

I happen to think that there is some merit to the idea that companies, like microsoft, know they're in trouble and want to find a way to force people to upgrade. Finding vulnerabilities like this is one of them. Limiting what hardware Windows can run on while killing off existing fully functional OSes is another. It's a multi-pronged approach, which is almost painfully obvious. Should be, and technically is, illegal.
Posted on Reply
#138
efikkan
Od1sseasI want evidence for anti exploit protection being just "marketing nonsense"
Antivirus works by identifying malware using known signatures. Viruses works by exploiting an underlying vulnerability, until this is fixed there is a potential to create an endless stream of new viruses, which is why every such occurrence is a game of whack-a-mole until the vulnerability is eventually fixed or mitigated in some way. Antivirus can't fix a vulnerability in another piece of software or hardware, nor can it analyze "intent" of unknown software.
lexluthermiesterThe "theory" @efikkan and others have offered might seem a bit "out there"…
Excuse me, which "theory" did I offer? Did you misread me perhaps?
Posted on Reply
#139
Drash
I'm still "rocking" a 6700K, using InSpectre to turn off what I can. They need to be in my house! If the spooks want my Steam library I'm damn sure they can get it whatever, however the local sink estate chavs prolly want my monitor or mouse/kb.
Posted on Reply
#140
Daytrader
I'm still using a 6700K also from my 2015 build, i wont be updating anything.
Posted on Reply
#141
R0H1T
efikkannor can it analyze "intent" of unknown software.
They can, sort of, by running it in a sandbox but not every "malware" can be identified that way & there's quite a few which can detect if they're being run in a sandbox.
Posted on Reply
#142
Od1sseas
efikkanAntivirus works by identifying malware using known signatures. Viruses works by exploiting an underlying vulnerability, until this is fixed there is a potential to create an endless stream of new viruses, which is why every such occurrence is a game of whack-a-mole until the vulnerability is eventually fixed or mitigated in some way. Antivirus can't fix a vulnerability in another piece of software or hardware, nor can it analyze "intent" of unknown software.


Excuse me, which "theory" did I offer? Did you misread me perhaps?
Incorrect. Antivirus also have heuristics that can detect malware without being in signatures. Anti-Exploit also works the same way. Please stop spreading misinformation.
Posted on Reply
#143
lexluthermiester
efikkanExcuse me, which "theory" did I offer? Did you misread me perhaps?
No. If you were not implying something then I digress..
Posted on Reply
#144
efikkan
R0H1TThey can, sort of, by running it in a sandbox but not every "malware" can be identified that way & there's quite a few which can detect if they're being run in a sandbox.
Things like trying to figure out if an executable tries to access a restricted file can be done in a virtual environment, for sure. But most CPU vulnerabilities like Downfall, Meltdown, Spectre and many others require precise conditions to trigger undefined behavior of the CPUs, which is something that you can't emulate this way. Like, for instance, Spectre requires nanosecond timing, and many exploits there needs to retry code thousands if not millions of times to succeed in triggering an erroneous CPU state and extract a few bytes of data. Some bugs, like race conditions, might not happen on all hardware under all conditions, or be affected by clock speed, etc.
Od1sseasIncorrect. Antivirus also have heuristics that can detect malware without being in signatures. Anti-Exploit also works the same way. Please stop spreading misinformation.
This is a misconception. Usage of heuristics still require distinct signatures, known elements or something uniquely malicious to determine malware. To my knowledge, x86 assembly hasn't been extended with "evil" instructions, not yet anyways ;). Most CPU vulnerabilities, like the ones mentioned above, relies completely normal instructions for arithmetic and control flow, like any other piece of software. No programmer worth their salt would claim heuristics could tell you that one sequence of mul, mov, jmp, shr, etc. is evil, while another is completely harmless. (without a database of known evil sequences)
Posted on Reply
#145
Patriot
efikkanThings like trying to figure out if an executable tries to access a restricted file can be done in a virtual environment, for sure. But most CPU vulnerabilities like Downfall, Meltdown, Spectre and many others require precise conditions to trigger undefined behavior of the CPUs, which is something that you can't emulate this way. Like, for instance, Spectre requires nanosecond timing, and many exploits there needs to retry code thousands if not millions of times to succeed in triggering an erroneous CPU state and extract a few bytes of data. Some bugs, like race conditions, might not happen on all hardware under all conditions, or be affected by clock speed, etc.


This is a misconception. Usage of heuristics still require distinct signatures, known elements or something uniquely malicious to determine malware. To my knowledge, x86 assembly hasn't been extended with "evil" instructions, not yet anyways ;). Most CPU vulnerabilities, like the ones mentioned above, relies completely normal instructions for arithmetic and control flow, like any other piece of software. No programmer worth their salt would claim heuristics could tell you that one sequence of mul, mov, jmp, shr, etc. is evil, while another is completely harmless. (without a database of known evil sequences)
Yeah Heuristics is behavior detection, the behavior still has to be in the database.
Posted on Reply
#146
Od1sseas
efikkanThings like trying to figure out if an executable tries to access a restricted file can be done in a virtual environment, for sure. But most CPU vulnerabilities like Downfall, Meltdown, Spectre and many others require precise conditions to trigger undefined behavior of the CPUs, which is something that you can't emulate this way. Like, for instance, Spectre requires nanosecond timing, and many exploits there needs to retry code thousands if not millions of times to succeed in triggering an erroneous CPU state and extract a few bytes of data. Some bugs, like race conditions, might not happen on all hardware under all conditions, or be affected by clock speed, etc.


This is a misconception. Usage of heuristics still require distinct signatures, known elements or something uniquely malicious to determine malware. To my knowledge, x86 assembly hasn't been extended with "evil" instructions, not yet anyways ;). Most CPU vulnerabilities, like the ones mentioned above, relies completely normal instructions for arithmetic and control flow, like any other piece of software. No programmer worth their salt would claim heuristics could tell you that one sequence of mul, mov, jmp, shr, etc. is evil, while another is completely harmless. (without a database of known evil sequences)
Nope.
Malwarebytes:
"These generic malware detections are due to our new automated signature system called BytesTotal and DDS engine that are based on Machine Learning technology with 100% autonomous learning which don’t require any human interaction to correctly identify malware.. These techniques are part of Malwarebytes’ Katana engine and were developed for automated mass detection of wide ranges of malware and adware."

"Malwarebytes detects unknown threats as Malware.AI by using Artificial Intelligence and Machine Learning techniques without any specific detection rules to protect users from malware that has not yet been researched and classified. This helps protect our customers against 0-day malware."

Malware.AI | Malwarebytes Labs
Posted on Reply
#147
Solid State Soul ( SSS )
efikkanDon't we all wonder that from time to time?
But then I realize that intentionally sabotaging your own product would only drive your customer to the competition.
(And don't many enterprise customers usually switch out hardware regularily anyways? Like when the warranty is expired?)
Apple is doing it all the time
Posted on Reply
#148
Od1sseas
lexluthermiesterNo. If you were not implying something then I digress..
I like how you "haha"ed my comment without explaining why. Are you a flat earther by any chance? Because your "arguments" are the same as flat earther's arguments which is "nuh uh"
lexluthermiesterHow about that fact that it's near impossible to pull off? Just throwing it out there. If you has read up on the technical details, you would already had your answer. The "theory" @efikkan and others have offered might seem a bit "out there", however given market conditions and the fact that microsoft KNOWS that systems made in the late 2000's and early 2010's can STILL run Windows well, there is merit to the suggestions made.

I happen to think that there is some merit to the idea that companies, like microsoft, know they're in trouble and want to find a way to force people to upgrade. Finding vulnerabilities like this is one of them. Limiting what hardware Windows can run on while killing off existing fully functional OSes is another. It's a multi-pronged approach, which is almost painfully obvious. Should be, and technically is, illegal.
"impossible to pull off" Another claim with no evidence

Posted on Reply
#149
lexluthermiester
Od1sseasI like how you "haha"ed my comment without explaining why.
Because it was funny. And no, I'm not going to explain.
Od1sseasAre you a flat earther by any chance?
Really? Personal jabs huh?
Od1sseasBecause your "arguments" are the same as flat earther's arguments which is "nuh uh"
Look in a mirror. :slap:
Od1sseas"impossible to pull off" Another claim with no evidence

You seemed have missed something. Go back and read through the thread. Take it slow, no need to rush yourself. Oh and just an FYI, the MalwareBytes example is deeply flawed, which only highlights what you're missing.
Posted on Reply
#150
Od1sseas
lexluthermiesterBecause it was funny. And no, I'm not going to explain.

Really? Personal jabs huh?

Look in a mirror. :slap:

You seemed have missed something. Go back and read through the thread. Take it slow, no need to rush yourself. Oh and just an FYI, the MalwareBytes example is deeply flawed, which only highlights what you're missing.
So your arguments are basically "i don't have to explain because its too obvious" (how convenient) and insults. Congrats.
Yes, i might have missed something, yes, i might be incorrect but i would like to stand corrected with actual arguments and evidence instead of being insulted.
Posted on Reply
Add your own comment
May 17th, 2024 09:08 EDT change timezone

New Forum Posts

Popular Reviews

Controversial News Posts