Initial Benchmarks Of The Intel Downfall Mitigation Performance Impact

[phoronix]

Phoronix: Initial Benchmarks Of The Intel Downfall Mitigation Performance Impact

With yesterday's disclosure of the Intel Downfall speculative execution vulnerability and the updated CPU microcode and Linux kernel patches I have been very busy testing the performance impact of this mitigation. Here are some initial numbers and workloads I have found to be impacted as a result of this security mitigation for Skylake to Icelake/Tigerlake client and server processors.

https://www.phoronix.com/review/intel-downfall-benchmarks

[coder]

Michael thanks for the benchmarks! Given that this is also said to affect AVX2, can you please test a client CPU somewhere between Skylake and Comet Lake (inclusive)? The CPUs you tested all have AVX-512, which makes it hard to tell how much the impact is on AVX2 codepaths.

[coder]

Also, do we think simdjson might use gather operations?

[Michael]

Also, do we think simdjson might use gather operations?

simdjson didn't show any change from the microcode.

[timofonic]

What about AMD Inception benchmarks too?

[Michael]

What about AMD Inception benchmarks too?

I'm working on those still, likely another day or two due to multiple mitigation combinations and not having been briefed on that in advance so taking more time to dig in.

[geearf]

Looking forward to the AMD ones as well!

[sophisticles]

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:

"GDS is highly practical. It took me 2 weeks to develop an end-to-end attack against encryption keys. It only requires the attacker and victim to share the same physical processor core, which frequently happens on modern-day shared computing infrastructure, implementing preemptive multitasking and simultaneous multithreading."

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.

[S.Pam]

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.

It's not how I read it. The attacker can make use of the av instruction and gain access to infirmation leaked from other applications' threads on the same core.

[yump]

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.

One should not make a habit of being confidently wrong.

The gather instruction is used by the exploit thread. On the victim thread, a huge variety of SIMD instructions are affected, including all load instructions and AES-NI.

As for everything you said about scheduling, it is very easy for malware to attempt the attack on as many threads as you have CPU cores, while simultaneously reading sequentially from disk in order to force dm_crypt to make heavy use of AES-NI with your disk encryption key. Similar methods work in any case where the attacker has the ability to cause the victim to do a bunch of computation with the sensitive data. Quoting directly from the paper,

In this attack, our only assumption is that the attacker knows that OpenSSL uses AES-NI for fast encryption; thus, the encryption uses SIMD memory reads. The attacker sends a request to another VM to encrypt random data (from /dev/urandom) with salt and discards the output. [...] In 10 seconds, we steal AES-128 or AES-256 round keys.

An obvious refinement is to run the attack in bursts and spread it out over a much longer time, so it doesn't show up clearly in the CPU utilization metrics.