Initial Benchmarks Of The Intel Downfall Mitigation Performance Impact

[yump]

If skia uses it, I wonder if there's an impact on the web browsers?

[Alexmitter]

"exploit" "researchers" "exploit" .

You really try your hardest to sound like a whole circus, don't you?

You really take "Confidence is key, even if I am confidently wrong" to the next level.

[coder]

Having said this, we really need to keep things in perspective. with this supposed "exploit".

According to the article were Michael first informed us about this, the "researchers" who "discovered" this said the following:

I'm guessing you think 2 weeks means the exploit is difficult to implement? I think they're making the opposite case.

Additionally, as Michael pointed our, this "exploit" only affects a specific subset AVX SIMD instructions, namely GATHER.

So let's assume you have a system with a potentially impacted processor, in order for this to be of any consequence you need to be running an unknown to you attack software AND a victim application that makes use of AVX GATHER instructions

Oops, no. The victim need not use GATHER. The exploit involves the use of GATHER to see the prior contents of the vector register. That's how it can spy on the other process. The other process need only put sensitive data in AVX registers, which happens all the time for encryption/decryption and optimized memcpy operations. simdjson even uses them just for data parsing!

AND on top of that both applications need t be running on the same core at the same time.

This can happen in two ways:

1. If you have SMT enabled and aren't using a feature like core scheduling that prevents threads from different processes from sharing a core.
2. A context switch occurs, running the attacker's thread immediately after the victim thread.

#2 sounds implausible, but there are ways to design your code to make it more likely. You can fiddle with the affinity mask to make your "spy" threads jump around, or just spawn lots of threads and use sched_yield() a lot.

I think it does turn out to be somewhat of a fishing expedition -- you don't know what you're going to get, if you're running this exploit on a VM in the cloud. But, that doesn't make it harmless.

In a nutshell, this is a non-issue.

I'd say it's usually unwise to be dismissive of security exploits, unless you really know what you're talking about. Overconfidence is a trait common among most victims.

[mrg666]

It seems to me Intel knew about this while they were releasing Alder Lake as they have just disabled AVX512 at the time but did not release any fix or warning for earlier generations until now. I remember Linus Torvalds did not like the AVX512 when it was released and now it is a problem. Intel first bloated the kernel with this "feature", now they are adding even more code to mitigate it. Not mentioning loss of performance. Not good at all.

[coder]

It seems to me Intel knew about this while they were releasing Alder Lake as they have just disabled AVX512 at the time

That might be plausible, if the exploit didn't also affect AVX2.

Nice try.
/s

I remember Linus Torvalds did not like the AVX512 when it was released and now it is a problem.

It's hardly fair to use this as a reason to pick on AVX-family ISA extensions. This sort of exploit could've potentially happened anywhere in the ISA.

If it's an indictment of anything, it would be the conceit of using a serial ISA atop a widely-parallel and highly-concurrent processor core. The hardware/software contract needs to be renegotiated, not only for better efficiency and performance, but also better security.

[mrg666]

That might be plausible, if the exploit didn't also affect AVX2.

Nice try.
/s


It's hardly fair to use this as a reason to pick on AVX-family ISA extensions. This sort of exploit could've potentially happened anywhere in the ISA.

If it's an indictment of anything, it would be the conceit of using a serial ISA atop a widely-parallel and highly-concurrent processor core. The hardware/software contract needs to be renegotiated, not only for better efficiency and performance, but also better security.

It is possible that AVX2 was fixed but it was not feasible to fix AVX512, so it was disabled.

These kinds of flaws always appear in the complex features of CPU, such as branch prediction and out-of-order execution. So, no, it is not an equal chance that it can happen anywhere in the ISA. And, Linus Torvalds comment was about complexity of the instruction set. So, no again, it was fair to use his comment.

Nice try
/s

[coder]

It is possible that AVX2 was fixed but it was not feasible to fix AVX512, so it was disabled.

No, the reason AVX-512 was disabled is blindingly obvious: E-cores. Intel didn't want a hybrid-ISA CPU and I don't blame them.

Nice try
/s

Except you're the one reaching for bizarre theories based on incomplete/incorrect information. Why is it so hard to accept the obvious explanations for things?

[L_A_G]

Reading about it I was wondering what kind of performance impact the mitigations would have. Now I know. Good work as always Michael.

Undoubtedly there's going to be a lot of revisions to this as they debate and create new mitigations that don't affect performance as much. I have a strong suspicion Intel's probably going to (again) insist that the fixes don't need to be complete, upstream fixes that don't actually work and then argue with Linus when he refuses to include these instead of the ones with a greater performance effect but actually work.

Also, is it just me or have Intel (and to a lesser extent AMD) seemingly not learned anything from Spectre/Meltdown? You'd think they would be far more rigorous in verifying their speculative execution after that debacle? Apparently this doesn't seem to affect what really drives their decision making; the bottom line.

[coder]

Undoubtedly there's going to be a lot of revisions to this as they debate and create new mitigations that don't affect performance as much. I have a strong suspicion Intel's probably going to (again) insist that the fixes don't need to be complete, upstream fixes that don't actually work and then argue with Linus when he refuses to include these instead of the ones with a greater performance effect but actually work.

Given that this doesn't affect any current model Intel CPUs, I think they don't mind just leaving well-enough alone and telling customers that they can recover lost performance simply by buying a shiny, new Intel CPU.

[AdrianBc]

First off, thanks to Michael for these benchmarks.

Having said this, we really need to keep things in perspective. with this supposed "exploit".

According to the article were Michael first informed us about this, the "researchers" who "discovered" this said the following:



Additionally, as Michael pointed our, this "exploit" only affects a specific subset AVX SIMD instructions, namely GATHER.

So let's assume you have a system with a potentially impacted processor, in order for this to be of any consequence you need to be running an unknown to you attack software AND a victim application that makes use of AVX GATHER instructions AND on top of that both applications need t be running on the same core at the same time.

But since all OSes employ thread scheduling that optimizes thread distribution across cores, in order to maintain frequency, prevent cache collisions, etc, that also means that in addition to the previously mentioned conditions, the user of the system has to also manually set the affinity of both the attack software and the victim software to the same core, otherwise the OS will schedule each application on different cores, especially if they are both using SIMD.

In a nutshell, this is a non-issue.

Not true. The attacker uses "gather" to gain information from the victim, but many instructions used by the victim leak information and they cannot be avoided.

The only defense (if the microcode update is not installed) is to not share CPU cores between processes that do not trust each other. The attack works best between the two SMT threads of a core, but some information is leaked even over context switches.

The following list of affected instructions is quoted from the paper:

• SIMD read. All SIMD operations that read wide data (128/256/512 bits) from memory are affected regardless of their function: e.g., vmov* only read, vpxor** read and compute the xor. These generate-purpose instructions are used everywhere, e.g., compilers spread wide data reads to optimize memory access routines.


• SIMD write. The only SIMD write operations that are affected are the compress ((v)(vp)compress*) instructions.

• Cryptographic extensions. Cryptographic extensions, including AES-NI and SHA-NI (SHA1 and SHA256), when accepting a memory operand, are affected. Data leaks from these instructions expose plaintext data and the secret key, e.g., AES or HMAC-SHA.

• Fast memory copy. Fast memory copies of various data types: byte, word, dword, qword using rep movs* instructions are affected. These are widely used to speed up common memory operations such as memcpy and memove.

• Register context restore. Special instructions to more efficiently store/restore the register context (e.g., xsave/xrstor) are affected. GDS leaks the register context of both standard registers due to xsave/xrstor and wide registers due to fxsave/fxrstor.

• Direct store The direct store is affected. Intel has recently added support for a direct store instruction that can copy a 64 bytes cache line from a source to a destination address.