Revisiting Intel CPU bug workarounds with Linux Kernel 5.2

From LinuxReviews
Jump to navigationJump to search
Intel.jpg

The impact of all the workarounds for all the Intel security is not that bad when it comes to every-day workloads like kernel compilation if you risk leaving SMT on. Turning SMT off does have a very real and noticeable impact on performance. Leaving SMT on and sticking with the kernels default settings will only add about a minute to a half-an-hour long compile job compared to turning the workarounds off with mitigations=off

This test was done using a laptop with a Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz which has bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds identified and exposed by the kernel in /proc/cpuinfo

Kernel-compile-on-lenovo-laptop.jpg

This i7-5500U is a dual-core four-thread CPU. It is older Broadwell technology which means that the real difference in seconds is higher and more visible than it would be on a newer and faster CPU. Also, we don't have any newer and faster Intel CPUs anymore.

Timed-5.2-compilation.png

Compiling Linux Kernel 5.2 with GCC 9.1.1 using no kernel parameters and the default kernel settings, which in this kernel is equal to mitigations=auto according to admin-guide/kernel-parameters.txt, results in a compile-time of 28 minutes and 9 seconds.

Turning all mitigations=off for maximum risk, excitement and performance shaves kernel compile time on this system down to 27 minutes and 25 seconds. That's just 43 seconds on a half-an-hour compile job. It really isn't all that noticeable.

Using mitigations=auto and mds=full,nosmt for maximum security on this CPU increases the compile-time to 33 minutes and 16 seconds. That is almost six minutes slower than mitigations=off

The obvious conclusion is that there really isn't that much difference between mitigations=off and the default mitigations=auto setting. But there is a huge difference between leaving SMT on and mds=full,nosmt

The stock kernel defaults are probably fine unless you're a financial institution or a cloud provider. The risks entailed by leaving SMT on are much bigger if random people/customers are able to run whatever they want on a shared CPU. They are not that high on a casually used home laptop or a gaming rig with more RGB lights than a Christmas tree.