One of Intel’s fixes for the Spectre variant 2 chip flaw (CVE- 2017-5715) appears to have taken a big bite out of the performance of the latest Linux kernel.
The mitigation in question is the Single Thread Indirect Branch Predictors (STIBP), one of three that Intel proposed not long after details of the Meltdown and Spectre flaws were made public in January.
Duly implemented in Linux 4.20, benchmarks run by Phoronix suggest that running it with Intel chips using Intel’s proprietary hyper-threading technology (principally Core i3s, and Core i7s and above) comes at a heavy cost.
Depending on the application, that could be anything from 30% to 50% on a top-of-the-line Core i9, a clearly unacceptable hit – and that’s before factoring in the smaller losses from previous mitigations for Spectre and Meltdown.
When the flaws were made public in January, performance drops were always on the cards, but a consensus emerged that this might be somewhere in the ballpark of a few percent for most users.
Less than a year on from that and anyone running 4.20 (and 4.19.2, which apparently has backported STIBP) is staring down the barrel of something much worse.
Enter the Linuxfather
And so the issue might have bounced around unhappily if Linus Torvalds hadn’t taken a look at numbers and come up with a radical suggestion – disable Intel’s STIBP mitigation.
Wrote the Finnish sage in his reformed no-swearing style:
When performance goes down by 50% on some loads, people need to start asking themselves whether it was worth it. It’s apparently better to just disable SMT entirely, which is what security-conscious people do anyway.
SMT – Simultaneous Multi-Threading – being the technical term for what Intel calls hyper-threading.
Interestingly, Intel has recently been losing interest in hyper-threading, which was introduced as long ago as 2002 as a way of magically turning one core executing one thread into two virtual cores running two threads.
Only now it’s become clear that this offers a theoretical opportunity for side-channel attacks in which one thread can spy on the contents of the other running on the same physical core, as underlined by the recent PortSmash hyper-threading vulnerability.
Where does this leave users?
Regarding Linux, if Torvalds has his way then it’ll choose performance over security in this case, and leave users to turn on Spectre mitigations if they want to. Of course he didn’t put it exactly like that:
I think we should use the same logic as for L1TF: we default to something that doesn’t kill performance. Warn once about it, and let the crazy people say “I’d rather take a 50% performance hit than worry about a theoretical issue”.
For Windows 10, Microsoft thinks it already has Spectre variant 2 under control using Google’s original Retpoline patch.
It’s all a bit nerve-racking even if Torvalds has, for once, managed to be the calmest head in the room.