Spectre Mitigation Performance Impact For Intel's Rocket Lake
For those wondering about the state of speculative execution vulnerabilities and what software-based mitigations are required for Intel's new Rocket Lake processors, here is the rundown along with benchmarks when disabling those present Linux kernel mitigations.
With the Intel's 11th Gen "Rocket Lake" processors featuring Cypress Cove cores as the 14nm backport of the Sunny Cove, curiosity got the best of me to look at the Spectre mitigation performance impact. Rocket Lake processors are not affected by Meltdown, MDS, L1TF, iTLB Multihit, SRBDS, or TSX Async Abort. However, on the Spectre front there are software-based mitigations still being applied for Spectre V1, V2, and V4 / Speculative Store Bypass (SSB).
Under the current Linux kernel for Rocket Lake processors with Spectre Variant One there is usercopy/SWAPGS barriers and __user pointer sanitization still applied. Spectre Variant Two protections with Rocket Lake has enhanced IBRS (Indirect Branch Restricted Speculation) and conditional Indirect Branch Prediction Barrier (IBPB), and return stack buffer (RSB) filling. Spectre Variant Four / SSB has speculative store bypass disabled via prctl and SECCOMP.
Booting the Linux kernel with "mitigations=off" allows run-time disabling of those still relevant Spectre V1/V2/V4 mitigations. Again, Rocket Lake doesn't require nor Linux implementing any mitigations for the other speculative execution vulnerabilities to date.
For getting an idea for the default/out-of-the-box overhead with Rocket Lake from the mitigations still necessary, I ran some benchmarks using the default state with those Spectre V1/V2/V4 mitigations in place and then again with "mitigtions=off" for disabling them when booting the same kernel. No other software stack changes were made during testing besides re-booting the system with the mitigations=off override. SMT/HT support was left on throughout the testing.
The newly released Intel Core i9 11900K processor with the Linux 5.12 Git kernel was used for this round of testing. A variety of workloads with exposure/relevance to these mitigations were benchmarked.