Recently the Linux Kernel Development Leader Linus Torvalds proposed to review the mechanism for activating STIBP patches (Single Thread Indirect Branch Predictors), which offer additional protection against Specter v2.
These patches have recently been included in the Linux kernel branch 4.20 under development and have been re-exported to the stable version of Linux kernel 4.19.2.
By using STIBP in its current form, users noticed a significant decrease in performance of some applications when using this simultaneous multithreading technology (SMT or Hyper-Threading).
Given that the performance drop can reach 50%, in the words of Linus Torvalds himself, using STIBP in its current form is meaninglessas it is easier and more reliable to disable SMT / Hyper-Threading completely, which security-conscious people often do.
The biggest slowdown caused by the new Linux 4.20 kernel is due to a mitigation for Specter variant 2 that Linux founder Linus Torvalds now wants to restrict.
This is when the question arises whether it is necessary to enable STIBP by default, when SMT / Hyper-Threading is already disabled for those who really care about security.
While, For normal users, a 50% performance loss is a significant factor that may represent some issues and that it is doubtful that these theoretical vulnerabilities are worth blocking.
Torvalds requires that STIBP is no longer enabled by default
Meanwhile Linus Torvalds considers that practical attacks based on Specter v2 are unlikely to emerge as, on normal user systems.
Linus Torvalds argues that browsers are the main target of attacks, which have already added protection to their level (the threat is for isolated JIT processes for which a selective protection method can be developed).
Se proposes to use by default only the Specter protection methods, which do not lead to a big drop in performance, but instead use additional methods selectively or as an option.
So why does that STIBP slow down by default when people who * really * care already disable SMT?
I think we should use the same logic as for L1TF - by default we cannot remove performance. Give one warning about it and let the crazy people say "I'd rather have a 50% success rate than worry about a theoretical problem." Linus torvalds
The default use of STIBP should be reverted
On the other hand, Intel's Arjan van de Ven said that Intel and AMD do not recommend the use of STIBP by default, as that this functionality can be compared to a very heavy hammer, since it is not used in daily work, but is necessary in certain circumstances.
He argues that the STIBP mechanism proposed in the microcode update allows you to control the shutdown of processor caches by setting a special bit in the CR0 register, which should not be done everywhere, but only in particularly critical situations.
Intel's Tim Chen proposed that selective blocking of sandbox attacks include STIBP only when explicitly requested through prctl or for processes that prohibit the creation of core memory dumps (PR_SET_DUMPABLE), such as sshd.
Regarding the performance drop when using STIBP patches on Linux Kernel 4.20, the result depends largely on the type of load.
For example, tests that have been conducted have shown that the SpecInt Rate 2006 package shows a performance reduction of 21%, while the Phoronix tests show a performance degradation of 3% to 20%.
Ingo Molnar a well-known Linux Kernel developer and author of CFS Task Scheduler, commenting on the situation, suggested adding the performance test information change list when solutions to problems are added.