Linux kernel Spectre V2 defense fingered for massively slowing down unlucky apps on Intel Hyper-Thread CPUs

Linux supremo Linus Torvalds has voiced support for a kernel patch that limits a previously deployed defense against Spectre Variant 2, a data-leaking vulnerability in modern processors.

Specifically, the proposed patch disables a particular Spectre V2 defense mechanism by default, rather than switching it on automatically. And here's the reason for that suggested change: code runs up to 50 per cent slower on Intel CPUs that use Hyper-Threading with the security defense enabled.

For those not in the know, Hyper-Threading is Chipzilla's implementation of simultaneous multi-threading (SMT), which splits individual CPU cores into two hardware threads. Thus, each core can mostly run two strands of software at the same time. That means a, say, 12-core processor would have 24 hardware threads, effectively presenting itself as a 24-core chip to the operating system and software.

Some applications benefit from SMT, and some suffer, depending on what they're trying to achieve and how. It's been known, and mitigated for a while, that code running in one hardware thread can potentially snoop on another app running on its sibling thread within their shared CPU core. The Spectre family of vulnerabilities has reopened this Pandora's box of security headaches, though, in that SMT and some Spectre kernel mitigations don't mix well, resulting in a performance hit.

STIBP THBIS NONBSEPNSE

The specific Spectre V2 mitigation in this case was added to Linux 4.20 and backported to Linux 4.19.2. It's called STIBP (Single Thread Indirect Branch Predictors), and prevents the processor's branch prediction engine from being exploited by malware on a computer to steal passwords, encryption keys, and other secrets out of memory it shouldn't have access to.

The defense mechanism turns out to be such a drag on performance that Torvalds believes it should not be enabled by default in all cases.

"When performance goes down by 50 per cent on some loads, people need to start asking themselves whether it was worth it," Torvalds wrote in a message to the Linux kernel mailing list on Sunday. "It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway."

In response to a suggestion by Jiri Kosina, director of the Core Kernel team at SUSE Labs, that a practical Spectre Variant 2 attack might involve JavaScript in one browser tab targeting private data in a separate tab, Torvalds expressed skepticism, arguing that's far more theoretical than the Meltdown vulnerability.

For one thing, browsers have built in their own defenses against tabs exploiting Spectre to steal information, and to date, there's no word on malware or spyware in the wild exploiting any of the Meltdown or Spectre processor flaws. Depending on the type of applications used, and the environment running them, the performance slowdown caused by Spectre security defenses may outweigh the risk of being hacked.

"Have you seen any actual realistic attacks for normal human users?" as Torvalds put it. "Things where the *kernel* should actually care? The JavaScript thing is for the browser to fix up, not for the kernel to say 'now everything should run up to 50 per cent slower.'"

Not everyone characterizes the impact of STIBP as seriously. Tim Chen, an engineer at Intel's Open Source Technology Center, said that running perlbench with STIBP using the SpecInt Rate 2006 test suite shows a 21 per cent reduction in throughput. Your mileage may vary – real-world slowdown metrics depend on the workload and hardware involved.

Torvalds doesn't see the need to undo the patch that enabled STIBP, but agrees with others that the default behavior should not be to enable it unconditionally in all cases because STIBP "was clearly way more expensive than people were told."

So a patch in progress will allow admins to turn on STIBP if needed, but not by default, just like the mitigations for Intel's L1 Terminal Fault (L1TF) flaws. Students of the Linux leader's ways may yet recall that in January, Torvalds – before he repudiated tantrums – was apoplectic about the quality of Intel's initial Spectre and Meltdown patches.

Arjan van de Ven, an Intel Fellow and Linux kernel dev, added his voice to the mix of people opposed to enabling STIBP by default.

"In the documentation, AMD officially recommends against this by default, and I can speak for Intel that our position is that as well: this really must not be on by default," he said. "...Using these tools much more surgically is fine, if a paranoid task wants it for example, or when you know you are doing a hard core security transition. But always on? Yikes." ®

PS: A reminder that OpenBSD recommends disabling Intel Hyper-Threading for security reasons.