Intel's Downfall Mitigations Drop Performance Up to 39%, Tests Show

10th Gen Intel processors
(Image credit: Shutterstock)

Intel recently disclosed Downfall, a security vulnerability that affects multiple generations of Intel processors - some of which used to be the best CPUs on the market. The chipmaker has rolled out an updated software-level microcode with a fix for the flaw. However, it has caused some alarms since there's a potential claimed performance impact of up to 50% on AVX2 and AVX-512 workloads involving the Gather instruction.

As a quick recap, Downfall (CVE-2022-40982) is associated with the memory optimization feature inside Intel processors. Downfall exploits the Gather instruction, which speeds up the processor where Intel chips fetch data scattered in different places in the memory. The Gather instruction inadvertently exposes internal hardware registers to software, allowing the latter to tap into data kept by other software. Downfall affects Intel mainstream and server processors, spanning from the Skylake to the Rocket Lake microarchitecture. Therefore, you're likely affected unless you own one of Intel's more recent processors, such as Alder Lake, Raptor Lake, or Sapphire Rapids. Intel has put up an extensive list of all the affected chips.

The main concern is how the mitigation will affect the performance of Intel processors. Leading Linux publication Phoronix has evaluated the impact of the Downfall mitigations on Linux. The news outlet tested a pair of Xeon Platinum 8380 (Ice Lake) processors, a Xeon Gold 6226R (Cascade Lake) chip, and a Core i7-1165G7 (Tiger Lake) part. Phoronix utilized diverse real-world software packages that form part of the Intel oneAPI software.

The two Xeon Platinum 8380 were around 6% slower in OpenVKL 1.3.1. With OSPRay 2.12, Phoronix recorded performance hits of up to 34%. The mitigations caused significant decreases in AI workloads, such as Neural Magic DeepSparse 1.5, Tencent NCNN, and QMCPACK, with up to 17% reductions.

The Xeon Gold 6226R benchmark results revealed similar performance deterioration. The Cascade Lake chip lost up to 33% in OSPRay 2.12 and up to 20% in Neural Magic DeepSparse 1.5.

As for the Core i7-1165G7, Phoronix only ran three benchmarks on it, but they were enough to show the performance degradation from the Downfall mitigations. For example, the Core i7-1165G7 delivered 11% lower performance in OpenVLK 1.3.1. On OSPRay 2.12, the mitigations shaved off between 19% to 39% of performance from the Core i7-1165G7.

The good news from Phoronix's initial set of results is that the performance decrease from the Downfall mitigation was lower than Intel's forecasted 50% overhead. However, the bad news is that the performance penalty is still significant. AVX instructions aren't limited to AI or HPC workload tests, either. You can find them in other workloads, such as video encoding or transcoding. Logically, it would be interesting to see which workloads are negatively impacted by the Downfall mitigations. From Phoronix's preliminary tests, HPC workloads are the most affected.

The microcode update isn't mandatory. If you want to turn off the mitigation, Intel offers an opt-out mechanism to restore your processor's performance in vectorization-heavy workloads. Then there is the debate on the complexity of successfully carrying out a Downfall attack. The exploit sounds like a difficult feat overall, but ultimately, it depends on whether you value your security more than performance or vice versa.

Zhiye Liu
News Editor and Memory Reviewer

Zhiye Liu is a news editor and memory reviewer at Tom’s Hardware. Although he loves everything that’s hardware, he has a soft spot for CPUs, GPUs, and RAM.

  • ikjadoon
    Admin said:
    Linux publication Phoronix evaluates the performance impact of Downfall mitigations on different Intel processors.

    Intel's Downfall Mitigations Drop Performance Up to 39%, Tests Show : Read more
    Damn. So why did Intel need a year for these mitigations?

    Luckily, we can send Intel more money with updated CPUs that don’t need these mitigations (but maybe we’ll get other mitigations next year at this pace).

    Good that Intel finally shipped Sapphire Rapids. Had this embargo expired last year, it’d mean Intel had nothing to sell.

    Will be curious to see consumer workloads that might use GATHER.
    Reply
  • rluker5
    ikjadoon said:
    Damn. So why did Intel need a year for these mitigations?

    Luckily, we can send Intel more money with updated CPUs that don’t need these mitigations (but maybe we’ll get other mitigations next year at this pace).

    Good that Intel finally shipped Sapphire Rapids. Had this embargo expired last year, it’d mean Intel had nothing to sell.

    Will be curious to see consumer workloads that might use GATHER.
    Intel had the fix available at the time the vulnerability was published.

    Perhaps you should ask AMD why it has been a year and they haven't come up with a mitigation for SQUIP. Which affects all Zen (at least through Zen 3, but I haven't heard that the root cause, the scheduler design, has been changed with Zen 4), is very similar to Downfall in that you need to have the attack occur on the same core as the victim and that it can bypass conventional security.

    Where it is different is that basically all programs make use of what is vulnerable in SQUIP's case: the CPU scheduler.

    Actually there are mitigations for SQUIP: turn off SMT, keep other programs from sharing a core that is running a secure operation, and don't do operations that need to be secure. Just not some microcode update like Intel has provided. With SQUIP you have to trust that the system administrators of affected hardware are fixing the security hole themselves. What is the performance penalty? That depends on the fix implemented and is hard to test. If my relatively ignorant butt were to fix it I would just shut down SMT which could have a performance penalty of up to 50% depending on the workload. But some system administrators (or their bosses) aren't much better.

    Both Downfall and SQUIP are side channel attacks that aren't much of a threat for the typical home user. More of a threat for businesses or gov agencies that work on shared servers.

    All chips have some security flaws. It would be nice if AMD were as quick to patch them as Intel is.

    And it does suck that mitigations generally come with performance penalties.
    Reply
  • bit_user
    As I said in the comments of the last article about Downfall, those benchmarks (which I linked at the time) don't cover CPUs without AVX-512. So, we don't know what's the impact on just AVX2.
    Reply
  • vehekos
    I wonder what is the accumulated effect of all "mitigation" patches that cover for security flaws.

    There should be a map somewhere.
    Reply
  • bit_user
    vehekos said:
    I wonder what is the accumulated effect of all "mitigation" patches that cover for security flaws.
    Funny enough, current CPU models actually perform a little better with most of the mitigations that existed at the time they were released. There are some theories about why this is.

    vehekos said:
    There should be a map somewhere.
    You can find benchmark articles which test this proposition, here and there.
    Reply
  • ikjadoon
    rluker5 said:
    Intel had the fix available at the time the vulnerability was published.

    When was the fix released, though? The vuln was reported to Intel ~11 months ago.

    How long was this vulberability under embargo?
    Almost one year. I reported this vulnerability to Intel August 24, 2022.
    Reply
  • rluker5
    ikjadoon said:
    When was the fix released, though? The vuln was reported to Intel ~11 months ago.
    And how long has the patch been out?
    They don't report a vulnerability as soon as it has been discovered unless it is being exploited. They give the affected companies some time to mitigate it.
    Apparently they were waiting for the BlackHat USA conference on August 9 and USENIX Security Symposium on August 11 to announce it after giving Intel some time to patch it. With SQUIP, AMD was notified in late 2021 and it was published 8/9/22 during the time Black Hat USA 2022 was going on.
    Reply
  • NinoPino
    rluker5 said:
    Intel had the fix available at the time the vulnerability was published.

    Perhaps you should ask AMD why it has been a year and they haven't come up with a mitigation for SQUIP. Which affects all Zen (at least through Zen 3, but I haven't heard that the root cause, the scheduler design, has been changed with Zen 4), is very similar to Downfall in that you need to have the attack occur on the same core as the victim and that it can bypass conventional security.

    Where it is different is that basically all programs make use of what is vulnerable in SQUIP's case: the CPU scheduler.

    Actually there are mitigations for SQUIP: turn off SMT, keep other programs from sharing a core that is running a secure operation, and don't do operations that need to be secure. Just not some microcode update like Intel has provided. With SQUIP you have to trust that the system administrators of affected hardware are fixing the security hole themselves. What is the performance penalty? That depends on the fix implemented and is hard to test. If my relatively ignorant butt were to fix it I would just shut down SMT which could have a performance penalty of up to 50% depending on the workload. But some system administrators (or their bosses) aren't much better.

    Both Downfall and SQUIP are side channel attacks that aren't much of a threat for the typical home user. More of a threat for businesses or gov agencies that work on shared servers.

    All chips have some security flaws. It would be nice if AMD were as quick to patch them as Intel is.

    And it does suck that mitigations generally come with performance penalties.
    Not all comments that critics Intel are pro AMD, your reply instead...
    Reply
  • NinoPino
    bit_user said:
    As I said in the comments of the last article about Downfall, those benchmarks (which I linked at the time) don't cover CPUs without AVX-512. So, we don't know what's the impact on just AVX2.
    It is a preliminary round of tests. I bet Michael will do very soon the usual comprehensive series of tests.
    I'm also curious for dbms, compilation, rendering and so on.
    Reply
  • bit_user
    NinoPino said:
    It is a preliminary round of tests. I bet Michael will do very soon the usual comprehensive series of tests.
    I'm also curious for dbms, compilation, rendering and so on.
    Rendering is already pretty well-covered: Embree, OSPRay, and OpenVKL. I don't know if Blender uses much AVX-512 for CPU rendering, but my guess is probably not, given that he didn't include it. Even if it does, it shouldn't be worse affected than the others.

    The other classes of programs you mentioned should be largely unaffected. I mean, given that simdjson wasn't even measurably affected should tell you something - specifically, that even heavy users of AVX-512 aren't hampered if they don't use gather instructions.
    Reply