The new Downfall vulnerability is a big one. This impacts Intel’s desktop CPUs up to Alder Lake and Intel’s server CPUs up to Ice Lake, the generation that was still top-of-the-line on the first day of 2023. Found by Daniel Moghimi, now at Google, the vulnerability targets AVX2 and AVX-512 pipelines in what Intel is calling a Gather Data Sampling (GDS) attack.
Intel Downfall is a Big Deal
The new transient vector speculative execution vulnerability targets vector processing pipelines in AVX2 and AVX-512 paths during a gather data process. There are a few caveats. First, like many side-channel attacks, this is something that is easiest to reproduce in a lab. Also, an attacker cannot specifically target any data sitting in memory. Instead, they are limited to what happens to be available in their context.
Intel and Daniel have been working for some time on this before its disclosure today. Intel and its firmware and OS partners have been coordinating a microcode update that will mitigate the vulnerability. This is an important enough vulnerability that the default will be “ON” for the mitigation. Administrators will be able to turn the mitigations off if they wish.
Here is Intel’s statement to STH on this:
“The security researcher, working within the controlled conditions of a research environment, demonstrated the GDS issue which relies on software using Gather instructions. While this attack would be very complex to pull off outside of such controlled conditions, affected platforms have an available mitigation via a microcode update. Recent Intel processors, including Alder Lake, Raptor Lake and Sapphire Rapids, are not affected. Many customers, after reviewing Intel’s risk assessment guidance, may determine to disable the mitigation via switches made available through Windows and Linux operating systems as well as VMMs. In public cloud environments, customers should check with their provider on the feasibility of these switches.” (Source: Intel)
From what we have heard, the mitigations for the vulnerability have some significant impact on AVX2/ AVX-512 workloads. Intel sent us this statement on the potential performance impacts:
For most workloads, Intel has not observed reduced performance due to this mitigation. However, certain vectorization-heavy workloads may see some impact. Intel encourages customers to review our technical documentation to understand options available to reduce or eliminate any performance impact. (Source: Intel)
It is interesting that Intel uses features like AVX-512 as a key competitive differentiator, but says here that “most workloads” do not heavily use the feature and thus do not suffer performance loss. AVX2 and AVX-512 are most common in high-performance computing (HPC) computing environments. Intel told us the vulnerability is only present when another user is on the same core at the target process. In theory, many HPC workloads dedicate cores to users so this would not be an issue and the mitigation can be turned off to increase performance to pre-mitigation levels.
For STH readers, if you have AVX-512 or AVX2 heavy pipelines, then we would advise looking at the pre/post mitigation performance and doing a risk assessment based on the likelihood that an attack can occur in your environment.
One area where we would be particularly concerned is at the edge. Intel’s last two edge P-core architectures the Skylake-D and Ice Lake-D are both impacted by this. Intel has been pushing AVX-512 as a workload accelerator at the edge without needing a PCIe accelerator. Hopefully, our readers who work in that space take some time to evaluate the impacts of the vulnerability and mitigation. Unlike HPC clusters that typically have local management teams and have an upgrade path to Sapphire Rapids, Xeon Max, or AMD’s Genoa/ Genoa-X, there is no replacement architecture from either Intel or AMD for the edge. Even if there was a replacement architecture, edge deployments can be very costly to upgrade as we saw with the Intel Atom C2000 AVR54 bug.
Which CPUs are Impacted by Downfall?
Intel told us that the following CPU architectures are impacted:
- Skylake family (Skylake, Cascade Lake, Cooper Lake, Amber Lake, Kaby Lake, Coffee Lake, Whiskey Lake, Comet Lake)
- Tiger Lake family
- Ice Lake family (Ice Lake, Rocket Lake)
Those are both desktop and server parts. Intel also said that the latest generation Sapphire Rapids chips are not impacted by the vulnerability.
Final Words
To the best of our knowledge, AMD CPUs are not impacted by this. Still, a large portion of STH readers will need to evaluate the vulnerability and the impacts of the mitigation for this one. We do not cover every security vulnerability, but this one seems like it is going to be a big deal for a large portion of our readers.
You can learn more about this under INTEL-SA-00828.
Between this and Zenbleed I’m starting to think that they leave this stuff in the product line and know that it can be used to push upgrades in the future.
I’ve got 3970x and 3950x systems I’m replacing for workstations in budget for next year. The call from management is, see we should use Intel. We could, and we might, but I reminded him of older intel flaws, and now this…
Maybe those devs will get their M2/M3 Mac’s next year…I think most want x86 though.
In Intel’s documentation they described a lot of ways to reduce the impact to performance, some even including changing source code. The key idea is to reduce the usage of certain impacted AVX instructions. Some source claimed up to 50% performance penalty for enabling the mitigation and that’s probably why Intel is offering such strategies.
I do like how both this and Zenbleed were so begrudgingly thrown the, “we can’t really be bothered with such things Medium,” label. Especially with Zenbleed, you could really feel the desire to protect their clients. I’m sorry, I meant to say force that upgrade, and that’s even when you had the single processor type they deigned to toss some microcode at before next year.
It is important to note that the Skylake desktop variants (Skylake-S) and Xeons using the same desktop socket are NOT going to get fixes for this vulnerability. Both are out End of Servicing Lifetime. The proper Skylake Xeons and worksation CPUs have received the microcode update.
Patrick
BS like this is why you don’t get anything from Intel.
“ultra scary”? LMAO.
All of these attacks, including the ones on AMD are only exploitable in a lab setting. If you give someone complete physical access to your machine – then you get what you deserve.
Stop the Hype BS already – you disdain for all things Intel is well known.
Give the people back the money for each CPU speed penalty that the patches are going to cause, because we didn’t pay extra for top of the line hardware to have it butchered to lower tier.
Such a great way to depreciate the codebase and tell everyone that AVX10 is now the way to go. Some of the new instruction sets seem to access data and memory directly in ways that may be open for exploitation that traditional instruction sets. Hardening of X86 and X64 has happened for a long time, but do we know if newer less used sets have had the same effort put in for them?
It’s one registry setting to disable all the BS mitigations (Spectre was an indirectly documented side effect in Intel Arch manuals dating back to when they first started describing branch prediction, I was discussing ways to use it for less stupid crap with people at work 4 years before the “HORRIBLE SECURITY BREACH OMG” and knew about it something like 17 years ago.
Then after that they just kept on coming. It reminds me of when the anti-viruses had no legitimate reason for anyone to purchase them because actual viruses were so rare so AV companies started doing things like counting every possible variant a pseudo-random polymorphic engine produced as another virus to inflate the counts, and kept stuff in their databases that couldn’t possibly run on a modern machine. Like when Windows Defender zero’d half my collection of extremely old viruses before I could stop it because copying a zip file triggered it to scan a non-excluded location. The last one I saw before I killed the scan was the original stoned virus, which IIRC contained a POP CS instruction which didn’t exist after the 8088 and only infected 360Kb floppy disks… but yeah, thanks for protecting me from that non-executable that I was trying to keep archived for history’s sake.