Benchmarking The Linux Mitigated Performance For Retbleed: It's Painful
Yesterday Retbleed was made public as a new speculative execution attack exploiting return instructions. While the "good" news is Retbleed only impacts prior generations of AMD and Intel processors, the bad news is the mitigated performance impact on Linux is quite severe. Since yesterday I have been benchmarking the newly-merged Linux patches on various Intel and AMD processors affected by Retbleed. It's very bad if you are on an affected processor.
The default mitigations for Retbleed are painful on affected Intel/AMD CPUs...Before anyone gets too triggered by the image, the pictured CPUs were dead of natural causes long before tossing them in 80% isopropyl alcohol.
The Linux mitigation for Retbleed is invasive at nearly two thousand lines of new code and nearly 400 lines removed, across dozens of files. In the Retbleed whitepaper by ETH Zurich COMSEC researchers, they characterized the mitigations as result in 14~39% overhead. I've been testing the Linux patches out on various systems locally and indeed it's quite severe. The Retbleed mitigations are some of the most performance-wrenching mitigations I've seen in a few years going back to the early Spectre/Meltdown days.
Researchers and the the hardware vendors believe Retbleed affects AMD Zen 1, Zen 1+, and Zen 2 processors -- but not the latest Zen 3 CPUs. When trying out the patched Linux kernel on Zen 3 hardware, there are no Retbleed mitigations applied. Over on the Intel side, Core 6th Generation through Core 8th Generation CPUs are impacted -- Skylake through Coffee Lake.
The new Linux mitigation controls for Retbleed.
The Retbleed mitigations were merged to Linux 5.19 Git as of yesterday and working their way currently to the various stable/supported Linux series right now. Those Linux stable point releases will be out shortly. When running on a patched Linux kernel, the Retbleed mitigations are applied automatically by default on the affected AMD/Intel CPUs as mentioned.
For those wondering, booting the Linux kernel with "mitigations=off" as the universal flag for disabling the mitigations will indeed disable Retbleed mitigations. Or there is now the "retbleed=" kernel parameter where "retbleed=off" can be set if just wanting to disable the new mitigations. The default behavior is "retbleed=auto" for applying the appropriate mitigation based on the CPU. There is also the ability to force certain mitigation behavior too or disabling SMT. For AMD Zen 1 CPUs specifically, disabling SMT is needed for full mitigation but isn't the default behavior.
In this article are benchmarks of a patched Linux 5.19 kernel with the default behavior (retbleed=auto) and then rebooting the same kernel and hardware but with "retbleed=off" for showing the unpatched performance. Follow-up articles will look more at the different tunables and AMD Zen 1 impact with "auto,nosmt", etc. This article are just the benchmarks I've completed over the past day.
First up in this article is looking at the mitigated performance for the Intel Core i7 8700K, Intel Xeon E3-1260L v5, and AMD Ryzen Threadripper 3960X systems. Following those desktop/workstation-oriented tests are a number of benchmarks on an AMD Zen 2 server with the prior flagship EPYC 7742 2P.