With AMD Zen 4, It's Surprisingly Not Worthwhile Disabling CPU Security Mitigations

Written by Michael Larabel in AMD on 30 September 2022 at 01:30 PM EDT. 72 Comments
AMD
While some Linux enthusiasts eagerly recommend users boot their systems with the "mitigations=off" kernel parameter for run-time disabling of various relevant CPU security mitigations for Spectre, Meltdown, L1TF, TAA, Retbleed, and friends, with the new AMD Ryzen 7000 "Zen 4" processors while still needing some software mitigations, it's surprisingly faster for the most part leaving the relevant mitigations enabled.



With AMD Zen 4 processors and the currently public security disclosures, Linux 6.0 on the Ryzen 7000 series CPUs has Speculative Store Bypass disabled via prctl for the SSBD / Spectre V4 mitigation and Spectre V1 mitigations of usercopy/SWAPGS barriers and __user pointer sanitization. Then for Spectre V2 there are Retpolines, conditional Indirect Branch Predictor Barriers (IBPB), IBRS firmware, always-on Single Threaded Indirect Branch Predictors (STIBP), and return stack buffer (RSB) filling. Those are the only software security mitigations involved with Zen 4 at this time with the new CPUs not being vulnerable to the assortment of other known vulnerabilities affecting different CPUs.


The Zen 4 mitigation status on Linux 6.0


With Zen 4 you can still boot the kernel with mitigations=off to disable the SSB, Spectre V1, and Spectre V2 mitigations applied while leaving the system in a "vulnerable" state. While many route to the mitigations=off approach to avoid the performance penalties attributed to the different mitigations, in the case of AMD Zen 4 on the Ryzen 9 7950X it's not actually beneficial.
AMD Zen 4 CPU Security Mitigation Benchmarks

To much surprise, the default/out-of-the-box state with the mitigation controls was generally faster than booting with mitigations=off. Here are the benchmarks with a measurable difference either way:
AMD Zen 4 CPU Security Mitigation Benchmarks

Running with mitigations=off was faster for a few synthetic benchmarks like Stress-NG, OSBench, Sockperf, and the other usuals. But keeping to the default mitigation state was surprisingly leading to a noticeable benefit for the web browser benchmarks, Stargate DAW, various OpenJDK workloads, and other workloads that have typically seen performance impacts from the different security mitigations of the past 4+ years.
AMD Zen 4 CPU Security Mitigation Benchmarks

Keeping to the default mitigation state was faster for the majority of the benchmarks tested.
AMD Zen 4 CPU Security Mitigation Benchmarks

Or for the wide span of 190 different benchmarks carried out, keeping to the default mitigations was about 3% faster overall than running with mitigations=off. Basically the opposite of what we normally see with other, older processors. As for why keeping the default mitigations on is leading to the Ryzen 9 7950X faster is a good question (normally it's the opposite!) but one that I hadn't bothered digging into deeper yet with system profiling due to time constraints and ultimately not being too important since for production systems you should really be keeping to the default security recommendations.

Those wanting to dig through all 190 benchmarks in full can find all of my data here. Long story short, with AMD Zen 4 it doesn't look to be worthwhile booting with "mitigations=off" but in fact can negatively impact some real-world workloads.

UPDATE: Follow-up article with more tests and analysis: Disabling Spectre V2 Mitigations Is What Can Impair AMD Ryzen 7000 Series Performance.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week