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

[ncrs]

Lets 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.

 

[lexluthermiester]

Antivirus 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.

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.

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?

 

[AnotherReader]

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.

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.

 

[R-T-B]

Ryzen 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.

 

[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.

 

[lexluthermiester]

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.

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.

 

[ncrs]

One 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.

 

[Why_Me]

Seems to be a thing with both companies.

AMD's Inception Fix Causes Up to 54% Performance Drop

Tests on wide variety of workloads completed on an Epyc / Linux system show up to 54% drop in performance.

www.tomshardware.com

 

[R-T-B]

Seems to be a thing with both companies.

AMD's Inception Fix Causes Up to 54% Performance Drop

Tests on wide variety of workloads completed on an Epyc / Linux system show up to 54% drop in performance.

www.tomshardware.com

The only place I saw close to a 50% drop on amd was running mariadb with both firmware and kernelside mitigations, other dbs were fine ironically.

I don't think its as big a deal as affecting AVX workloads but admitedly its worse than I expected.

 

[efikkan]

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?)

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.

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.

Antivirus has anti-exploit protection

That's not how antivirus works, that's just marketing nonsense.

 

[Patriot]

Seems to be a thing with both companies.

AMD's Inception Fix Causes Up to 54% Performance Drop

Tests on wide variety of workloads completed on an Epyc / Linux system show up to 54% drop in performance.

www.tomshardware.com

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.
https://www.phoronix.com/review/amd-inception-benchmarks/4 see for yourself.

GCC Compiler Adds Software Workaround To Avoid Intel Downfall Performance Hit - Phoronix

www.phoronix.com

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?

 

[Od1sseas]

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?)


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"

 

[lexluthermiester]

I 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.

 

[efikkan]

I 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.

The "theory" @efikkan and others have offered might seem a bit "out there"…

Excuse me, which "theory" did I offer? Did you misread me perhaps?

 

[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.

 

[Daytrader]

I'm still using a 6700K also from my 2015 build, i wont be updating anything.

 

[R0H1T]

nor 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.

 

[Od1sseas]

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.


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.

 

[lexluthermiester]

Excuse me, which "theory" did I offer? Did you misread me perhaps?

No. If you were not implying something then I digress..

 

[efikkan]

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.

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.

Incorrect. 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)

 

[Patriot]

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.


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.

 

[Od1sseas]

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.


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

 

[Solid State Soul ( SSS )]

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?)

Apple is doing it all the time

 

[Od1sseas]

No. 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"

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.

"impossible to pull off" Another claim with no evidence

 

[lexluthermiester]

I like how you "haha"ed my comment without explaining why.

Because it was funny. And no, I'm not going to explain.

Are you a flat earther by any chance?

Really? Personal jabs huh?

Because your "arguments" are the same as flat earther's arguments which is "nuh uh"

Look in a mirror.

"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.