Kürzlich der Linux Kernel Development Leader Linus Torvalds schlug vor, den Mechanismus zur Aktivierung von STIBP-Patches zu überprüfen (Single Thread Indirect Branch Predictors), die zusätzlichen Schutz gegen Spectre v2 bieten.
Diese Patches wurden kürzlich in den Linux-Kernel-Zweig 4.20 aufgenommen in der Entwicklung und wurden in die stabile Version des Linux-Kernels 4.19.2 reexportiert.
Durch die Verwendung von STIBP in seiner aktuellen Form können Benutzer stellte einen signifikanten Leistungsabfall bei einigen Anwendungen fest bei Verwendung dieser simultanen Multithreading-Technologie (SMT oder Hyper-Threading).
Da Der Leistungsabfall kann 50% erreichen, in den Worten von Linus Torvalds selbst, Die Verwendung von STIBP in seiner aktuellen Form ist bedeutungslosda es einfacher und zuverlässiger ist, SMT / Hyper-Threading vollständig zu deaktivieren, was sicherheitsbewusste Personen häufig tun.
Die größte Verlangsamung durch den neuen Linux 4.20-Kernel ist auf eine Abschwächung der Spectre-Variante 2 zurückzuführen dass Linux-Gründer Linus Torvalds jetzt einschränken will.
In diesem Fall stellt sich die Frage, ob STIBP standardmäßig aktiviert werden muss, wenn SMT / Hyper-Threading für diejenigen, die sich wirklich für Sicherheit interessieren, bereits deaktiviert ist.
Während, Für normale Benutzer ist ein Leistungsverlust von 50% ein wesentlicher Faktor, der einige Probleme darstellen kann Es ist zweifelhaft, ob diese theoretischen Schwachstellen es wert sind, blockiert zu werden.
Für Torvalds muss STIBP standardmäßig nicht mehr aktiviert sein
Mittlerweile Linus Torvalds ist der Ansicht, dass praktische Angriffe auf der Basis von Spectre v2 auf normalen Benutzersystemen wahrscheinlich nicht auftreten werden.
Linus Torvalds argumentiert, dass Browser das Hauptziel von Angriffen sind, die ihren Schutz bereits erhöht haben (die Bedrohung besteht für isolierte JIT-Prozesse, für die eine selektive Schutzmethode entwickelt werden kann).
Se schlägt vor, standardmäßig nur die Spectre-Schutzmethoden zu verwenden, die nicht zu einem starken Leistungsabfall führen, sondern zusätzliche Methoden selektiv oder als Option verwenden.
Warum verlangsamt sich dieser STIBP standardmäßig, wenn Leute, die * wirklich * interessiert sind, SMT bereits deaktivieren?
Ich denke, wir sollten die gleiche Logik wie für L1TF verwenden - standardmäßig können wir die Leistung nicht entfernen. Geben Sie einmal Bescheid und lassen Sie die Verrückten sagen: "Ich hätte lieber eine Erfolgsquote von 50%, als mir Sorgen um ein theoretisches Problem zu machen." Linus torvalds
Die Standardverwendung von STIBP sollte zurückgesetzt werden
Ferner Intels Arjan van de Ven sagte, dass Intel und AMD die Verwendung von STIBP standardmäßig nicht als empfehlen dass diese Funktionalität mit einem sehr schweren Hammer verglichen werden kann, da sie nicht in der täglichen Arbeit verwendet wird, sondern unter bestimmten Umständen notwendig ist.
Er argumentiert das Mit dem im Mikrocode-Update vorgeschlagenen STIBP-Mechanismus können Sie das Herunterfahren von Prozessor-Caches steuern durch Setzen eines speziellen Bits im CR0-Register, was nicht überall, sondern nur in besonders kritischen Situationen erfolgen sollte.
Tim Chen von Intel schlug vor, dass das selektive Blockieren von Sandbox-Angriffen STIBP nur dann einschließt, wenn dies explizit über prctl oder für Prozesse angefordert wird, die die Erstellung von Core-Dumps (PR_SET_DUMPABLE) verbieten, wie z. B. sshd.
In Bezug auf den Leistungsabfall bei Verwendung von STIBP-Patches unter Linux Kernel 4.20 hängt das Ergebnis weitgehend von der Art der Auslastung ab.
Beispielsweise haben durchgeführte Tests gezeigt, dass das Paket SpecInt Rate 2006 eine Leistungsreduzierung von 21% aufweist, während die Phoronix-Tests eine Leistungsverschlechterung von 3% bis 20% zeigen.
Ingo Molnar, ein bekannter Linux-Kernel-Entwickler und Autor von CFS Task Scheduler, kommentierte die Situation und schlug vor, die Liste mit Änderungen der Leistungstestinformationen hinzuzufügen, wenn Lösungen für Probleme hinzugefügt werden.