The Peculiar State Of CPU Security Mitigation Performance On Intel Tiger Lake

One area not talked about much for Intel's latest Tiger Lake processors are hardened CPU security mitigations against the various speculative execution vulnerabilities to date. What's peculiar about Tiger Lake though is now if disabling the configurable mitigations it can actually result in worse performance than the default mitigated state. At least that's what we are seeing so far with the Core i7 1165G7 on Ubuntu 20.10 Linux is the opposite of what we have been seeing on prior generations of hardware.

For CPU security mitigation differences with Tiger Lake these very latest Intel processors are not affected by the iTLB Multihit "No eXcuses" vulnerability made public in November 2019 but known to Intel since at least 2018. Mitigations were required through Ice Lake with the KVM hypervisor to mark huge pages in the extended page tables as non-executable but no longer relevant for Tiger Lake.

The Spectre V4 mitigation of speculative store bypass disable via prctl and SECCOMP remains in place with Tiger Lake. Also still present for Spectre V1 is the mitigation of usercopy/swapgs barriers and __user pointer sanitization. For Spectre V2, like Ice Lake, there is enhanced IBRS IBPB and conditional RSB filling. Tiger Lake is "not affected" by L1TF, MDS, Meltdown, SRBDS, and TAA vulnerabilities.

That is the default state of Tiger Lake on Linux at the moment as reported from an Intel Core i7 1165G7 running Ubuntu 20.10 with the Linux 5.8 kernel. But as with any relevant processor, the mitigations can be disabled with the "mitigations=off" kernel option to outright disable the security mitigations at boot time.

But it's with that mitigation disabling is where the situation is now odd on Tiger Lake: for reasons yet to be explained, disabling the mitigations actually hurts the performance in many areas rather than enhances it in going to the pre-mitigation performance levels... I.e. with Tiger Lake leaving mitigations active is now the fastest.

It's unclear at the moment if something is going awry with the Intel microcode or Linux kernel or what architectural change was made where disabling the still relevant mitigations with "mitigations=0ff" hurts the performance rather than trying to recover lost performance. On four Dell XPS notebooks spanning Kaby Lake Refresh, Whiskey Lake, Ice Lake, and Tiger Lake I ran some benchmarks following clean installs of Ubuntu 20.10 on each system to show the difference.

On each of these Dell XPS notebooks were clean installs of Ubuntu 20.10 with security / stable release updates of the time and on their default Linux 5.8 kernel. The out-of-the-box / default mitigation performance was tested on each notebook followed by re-testing the same laptop and software stack after booting with mitigations=off.

Here is the geometric mean of all the results before digging into the individual data points, but as you can see mitigations=off was of noticeably help to the older Kaby Lake R and Whiskey Lake processors, previous-generation Ice Lake was of some help but less given more hardware mitigations, and now with Tiger Lake the tables have turned where disabling the mitigations actually hurt the performance.