News Intel 'Downfall' Bug Steals Encryption Keys, Data From Years of CPUs

[Admin]

A Google researcher has found a speculative execution vulnerability in several generations of Intel processors.

Intel 'Downfall' Bug Steals Encryption Keys, Data From Years of CPUs : Read more

 

[hotaru251]

holy crap potential impact of 50%? thats a crazy high impact.

 

[bit_user]

holy crap potential impact of 50%? thats a crazy high impact.

Only for AVX2/AVX-512 workloads, I think. And ones which use the Gather instruction, at that.

I'm going to reserve judgement until detailed benchmarks are in. Phoronix is running them now.

 

[spoidz]

you can load it from the operating system.

I hope that means we won't have to hope for very old Motherboard support to provide them, my Z390 Dark is well past support.

 

[bit_user]

I hope that means we won't have to hope for very old Motherboard support to provide them, my Z390 Dark is well past support.

Operating systems usually apply the latest microcode during boot-up. Of course, that assumes you're regularly installing your security patches (Windows Updates, etc.).

 

[rluker5]

Operating systems usually apply the latest microcode during boot-up. Of course, that assumes you're regularly installing your security patches (Windows Updates, etc.).

Hopefully this is the case. It will help all of those who update then.
And I hope this story is big enough that most people that manage servers get it.

Not good news for Intel server chips. Ice lake is pretty recent.

 

[bit_user]

Not good news for Intel server chips. Ice lake is pretty recent.

Agreed, but mostly for workloads like AI, software video codecs, HPC, etc. That's a minority of what's running on those CPUs, I'd bet.

 

[Findecanor]

Only for AVX2/AVX-512 workloads, I think. And ones which use the Gather instruction, at that.

It's the opposite. The Gather-instruction is used for the exploit, because it is the circuitry for that instruction that has the bug.

Any data that is ever loaded into vector registers could potentially leak. And vectors are used not just for parallelised operations but also for floating point maths, encryption, bulk memory copy and context switches.

 

[bit_user]

It's the opposite. The Gather-instruction is used for the exploit, because it is the circuitry for that instruction that has the bug.

I was talking about what the microcode fix targets. Maybe you know more about it than I do, but I assumed that since the gather instructions were used in the exploit, that the microcode fix (and therefore its performance impact) would affect primarily that instruction. I'm still waiting to see detailed benchmarks, so we can get more insight.

Any data that is ever loaded into vector registers could potentially leak. And vectors are used not just for parallelised operations but also for floating point maths, encryption, bulk memory copy and context switches.

Floating point and encryption, yes. You can't really get around that, because ever since SSE came onto the scene, x87 math has received very little focus or attention from CPU designers. So, even for scalar arithmetic, you're still probably using the vector registers.

Memory copy is an easy one to disable. That's mainly libc, and it still has a fallback path for using non-vector copies.

Context switches? Aside from the mere fact of saving vector registers as part of the context, why? Is it again something that's done as an optimized memory copy?

For me, a key question is whether information-leakage happens across context switches (i.e. with SMT disabled). That would mean that simply disabling or limiting SMT would be an incomplete mitigation of this exploit.

 

[rluker5]

It's the opposite. The Gather-instruction is used for the exploit, because it is the circuitry for that instruction that has the bug.

Any data that is ever loaded into vector registers could potentially leak. And vectors are used not just for parallelised operations but also for floating point maths, encryption, bulk memory copy and context switches.

But this exploit only exists with the use of Gather data sampling. Is there another way to read the data of other users on a shared system? The article does specifically state that gather is responsible for leaking the data.

There is lots of data sitting in places in a CPU. Unless it is read and made leakable it is safe. I'm reading that Gather is a low level instruction set authorized to do this. You can't just use file explorer to read vector registers.

 

[RichardtST]

No surprise, really. System complexity has gone through the roof in the last decade or so and it has become impossible to make anything secure. It is a well-known fact that security is a losing battle at this point. Good news is that CPUs are cheap enough that no one should be sharing them. If you have something that is actually important then dedicate a machine to it. And for heaven's sake get it off the cloud. We've only been warning of things like this for years. Now it is officially here. One more thing.... "I told you so".

 

[bit_user]

I'm reading that Gather is a low level instruction set authorized to do this. You can't just use file explorer to read vector registers.

Gather instructions aren't authorized, in the sense that they're meant to do this. It's indeed a bug.

Some background: a CPU has only a pool of unnamed registers. When you put data in a register called YMM7, there's no fixed register on the chip that corresponds to YMM7. Instead, the CPU finds a register which is available, and establishes a temporary mapping. Then reads and writes to YMM7, from your thread, get applied to that hardware register.

So, what seems to be the case is that a bug in the gather instructions somehow let you see the contents of the physical register that a gather instruction is writing to, before the data comes in from memory and ovewrites its contents. Because hardware registers are shared between SMT threads (and possibly preserved across context switches), this is what enables the information leakage.

 

[kerberos_20]

Performance on Client​

Heavily optimized applications that rely on vectorization and gather instructions to achieve the highest performance may see an impact with the GDS mitigation update. These are applications like graphical libraries, binaries, and video editing software that might use gather instructions. Our analysis has identified some specialized cases where client applications may see a performance impact. For example, certain digital art application add-ons have shown some performance impact. However, most client applications are not expected to be noticeably impacted because gather instructions are not typically used in the hot path.

so no big deal for typical consumer

 

[rluker5]

Gather instructions aren't authorized, in the sense that they're meant to do this. It's indeed a bug.

Some background: a CPU has only a pool of unnamed registers. When you put data in a register called YMM7, there's no fixed register on the chip that corresponds to YMM7. Instead, the CPU finds a register which is available, and establishes a temporary mapping. Then reads and writes to YMM7, from your thread, get applied to that hardware register.

So, what seems to be the case is that a bug in the gather instructions somehow let you see the contents of the physical register that the gather instruction you're writing to, before the data comes in from memory and ovewrites its contents. Because hardware registers are shared between SMT threads (and possibly preserved across context switches), this is what enables the information leakage.

Thank you.
Your explanation compelled me to read more and understand better.

From the exploit description page -downfall.page: "It only requires the attacker and victim to share the same physical processor core, which frequently happens on modern-day computers, implementing preemptive multitasking and simultaneous multithreading."

SMT just seems full of potential exploits.

 

[kerberos_20]

Thank you.
Your explanation compelled me to read more and understand better.

From the exploit description page -downfall.page: "It only requires the attacker and victim to share the same physical processor core, which frequently happens on modern-day computers, implementing preemptive multitasking and simultaneous multithreading."

SMT just seems full of potential exploits.

acording to intel disabling SMT incurs 30% performance hit and leaks across context switching would still ocur

 

[bit_user]

acording to intel disabling SMT incurs 30% performance hit

This figure is highly workload-dependent.

However, I prefer to use "core scheduling", where only threads from the same process are allowed to share a core.

leaks across context switching would still ocur

This could be mitigated by the kernel, when it context-switches from kernel -> userspace or between userspace threads of different processes.

 

[bit_user]

holy crap potential impact of 50%? thats a crazy high impact.

Phoronix' benchmarks are out, and I don't see any as bad as 50%. The worst is an OSPRay scene that takes a 34% hit, but that's an outlier. OSPRay is an Open Source Portable Raytracer written by Intel. It shouldn't come as a surprise that it makes heavy use of AVX-512. However, the typical impact on AVX-heavy applications seems more in the realm of 10%. It varies a lot, however.

Initial Benchmarks Of The Intel Downfall Mitigation Performance Impact - Phoronix

www.phoronix.com

What we still don't know is how much it affects specifically AVX2.

 

[delfaveri]

A Google researcher has found a speculative execution vulnerability in several generations of Intel processors.

Intel 'Downfall' Bug Steals Encryption Keys, Data From Years of CPUs : Read more

Linus tovards said those instructions are meaninless, only used to benchmark intel C.P.U, could well pass that, and not be attacked.

 

[bit_user]

Linus tovards said those instructions are meaninless, only used to benchmark intel C.P.U, could well pass that, and not be attacked.

They're used in deep learning/AI, HPC/scientific, imaging, graphics, and video codecs, among other things. They might not benefit the kinds of workloads Linus is principally interested in, but I wouldn't call them meaningless.

 

[domih]

Side-channel attack is a (bad) gift that keeps on giving. Security experts predicted it would be the case back in 2018, when Spectre and Meltdown burst onto the scene.

Depending on the attack "flavor" it affects INTEL, AMD or ARM or two or the three of them.

New ones will be coming.

For Downfall and Inception, the INTEL and AMD mitigation firmware updates have been released and will percolate into the Linux stable releases in the next few days. Same thing for Windows I guess.

Just yet another day at the office, as long as you apply the security patches on a regular basis.

 

[bit_user]

Just yet another day at the office, as long as you apply the security patches on a regular basis.

Yeah, but the big news is usually what impact the mitigations have.

 

[bikemanI7]

Does this affect my Comet Lake S Intel 10700 Processor? i looked at the Intel Affected list from another Computer news site, and did see Comet Lake S listed on there. So will i see a 50 Percent performance hit once the Micro Code is applied?

Typically use System for light video editing at times, Gaming, Music Listening, Word Processing, Email, Music Listening, Light Djing in Secondlife at times.

 

[domih]

Yeah, but the big news is usually what impact the mitigations have.

The initial benchmarks from Phoronix (whose URL you posted above) show that it is not the "ultra-scary"(*) 50%, far from it. Plus, the users who should be actually concerned are heavy AVX2/512 users, like AI guys, professional digital creators providers, scientists(**) who will know how to change their code to avoid the most impacted instructions. The regular low-life users, like me, won't see a difference.

(*) Click baiting term used in the article title on STH, yesterday.
(**) Plus data centers still providing INTEL SGX solutions.

Each time there is a new speculative side-channel exploit found, the discoverer chooses a nefarious name (Downfall, really?) and the main stream computer news sites publish alarming articles. Meh.

My suggestion for the next discovery names: Implosion Factor, Utter Destruction, Final Destination, Annihilation X, iDoomsday, MAGATRON, Balls Vice Villain.

 

[domih]

Does this affect my Comet Lake S Intel 10700 Processor? i looked at the Intel Affected list from another Computer news site, and did see Comet Lake S listed on there. So will i see a 50 Percent performance hit once the Micro Code is applied?

Typically use System for light video editing at times, Gaming, Music Listening, Word Processing, Email, Music Listening, Light Djing in Secondlife at times.

Yes to first question(*). No to second question. You'll probably see no significant difference.

(*) Go to the reference source:

INTEL-SA-00828

INTEL-SA-00828

www.intel.com

Affected Processors: Transient Execution Attacks & Related Security...

Review the impact of transient execution attacks and select security issues on currently supported Intel products.

www.intel.com

Gather Data Sampling

In some situations, it may be possible to infer stale data using the speculative execution side channel vulnerability Gather Data Sampling (GDS). Intel is providing a microcode update to mitigate GDS.

www.intel.com

 

[bit_user]

The initial benchmarks from Phoronix (whose URL you posted above) show that it is not the "ultra-scary"

In this case, it's much less bad than the headline numbers.

My statement was a generalization about the drumbeat of vulnerabilities, in line with the way you seemed to be talking. I just wanted to point out that it's not always as simple as "apply security patches & go on about your day", if I may paraphrase it as such.

Performance matters to some users. Let's say I have a realtime product which relies on AVX2. If the CPU can no longer process it as fast, then the product can no longer offer the performance my customers paid for and has to be de-rated in some way. We'll have to see how this goes over, with them.

the users who should be actually concerned are heavy AVX2/512 users, like AI guys, professional digital creators providers, scientists(**) who will know how to change their code to avoid the most impacted instructions.

The affected instructions were added for performance reasons. Whether developers take the hit of their reduced performance or change their code not to use them, some performance impact is virtually unavoidable, such as it is.

(**) Plus data centers still providing INTEL SGX solutions.

I don't think SGX helps, in this case, unless you specifically know otherwise. SGX works by providing memory encryption. But, by the time data gets into the CPU registers, it's been decrypted (probably by the memory controller, I'd assume). That's how SGX remains virtually transparent to application code.