Daniel Moghimi — Downfall Performance Degradation 3 Years Later

September 12, 2025

It’s been almost three years since I reported the Downfall vulnerability (also called Gather Data Sampling) to Intel, and its mitigation is still hurting the performance of real workloads. One of the big concerns with a large, blunt performance hammer like this is that people may eventually disable it because of the cost. Suddenly you’re forced to choose between performance and security — a terrible trade-off.

Intel originally mentioned that the Downfall mitigation could impose up to ~50% overhead on some workloads, and independent testing from Phoronix shows numbers in the same ballpark. Recently, the FFmpeg Twitter account published crude but worrying data showing a severe performance hit for highly optimized FFmpeg builds. Here “hscale” refers to the horizontal scaling stage inside libswscale. It handles image/video scaling and pixel-format conversions.

Interesting patch from @Google showing the effects of Intel security mitigations on the gather assembly language instruction.

A huge performance decrease as a result. pic.twitter.com/dCu9nxAMf2

— FFmpeg (@FFmpeg) September 9, 2025

So what does the mitigation do, and why does it slow things down so much? Essentially, it severely degrades the Gather instruction. Gather (implemented as (v)(vp)gather* on x86) lets CPUs load multiple data elements in parallel. Table lookups are extremely common in many algorithms: compression/decompression, software cryptography, media encoding, and more.

The Downfall fix effectively turns Gather into a serial operation: there’s no longer speculative, parallel data gathering. Imagine an instruction that was designed to efficiently perform 16 memory lookups in parallel—after the mitigation it performs them one-by-one because the mitigation implicitly serializes the Gather micro-operations under the hood.

For some algorithms, that change makes a Gather-based implementation even slower than carefully optimized software table lookups. If Gather used to be faster than a software approach, the mitigation can invert that relationship: a precomputed or software-managed table lookup that used to be inferior can now outrun the hardware Gather. A software-managed table lookup can still runs in paralell and continues to benefit from speculative execution.

I strongly advise against disabling the Downfall/GDS mitigation. Unless a machine is completely air-gapped and used solely for local gaming or offline encoding, disabling the Downfall mitigation carries significant risk. This vulnerability is practically exploitable to leak large amounts of data, as I demonstrated this with live demo at Usenex Security and Blackhat 2023 two years ago. In cloud environments it can be used to exfiltrate data from other tenants. On a desktop connected to the Internet, an untrusted application (for example, from an app store) could leak credentials such as admin passwords, Kerberos to perform privilege escalation.

Mitigations for similar vulnerabiliites have been disabled years after disclosure because engineers judged the performance cost unacceptable or such changes were made by mistake. In some of those cases, later work demonstrated that the unfixed vulnerabilities could indeed be weaponized to leak credentials. A recent example was demonstrated by Google colleagues which they showed how an unfixed Retbleed vulnerability (on AMD hardware) can be used to steal credentials in the Cloud.

Bottom line: The performance hit from Gather mitigation is significant, but disabling it only trades short-term speed for a catastrophic security risk. A better approach is to detect whether the mitigation is enabled and, if so, fall back to a software-optimized implementation that avoids Gather’s performance penalty.