Linux mit Spectre-Patch bis zu 50 Prozent langsamer - Diskussion über Sinn der Patches
Für Linux gab es einen neuen Kernel, der die Ausnutzung von Spectre V2 verhindern soll. Der aber schlägt mit bis zu 50 Prozent Leistungsverlust zu Buche, wenn SMT aktiviert ist. Daraufhin entbrennt eine Diskussion darüber, was nun besser ist: Patch, deaktiviertes SMT oder alles beim Alten lassen?
Da man die Spectre-Sicherheitslücken in x86-Prozessoren nicht wirklich schließen kann, muss die Ausnutzung über das Betriebssystem erschwert werden. Das ging unter Windows mit mehr oder weniger Leistungsverlust einher und so auch bei Linux. Da aber sind die Verluste deutlich größer, wenn man Linus Torvards Glauben schenken will.
Das Sprachrohr der Linux-Community hatte schon "freundliche Worte" für Nvidia übrig und lässt nun Intel schlecht dastehen. Demnach sorgt ein aktualisierter Kernel, der die Ausnutzung von Spectre V2 erschwert, auf Intel-CPUs mit Hyper Threading für bis zu 50 Prozent Leistungsverlust gegenüber deaktiviertem Hyper Threading. Das ist ein durchaus schmerzhafter Einschnitt und kann für den Nutzer recht bitter sein. HT hat man nämlich bei teureren Modellen mitbezahlt, um es überhaupt zu haben und auf günstigen CPUs ist es teilweise überlebensnotwendig, etwa bei den Skylake-U-Prozessoren.
Da SMT mittlerweile auf einem Großteil der Intel-Prozessoren und allen neuen AMD-Prozessoren verfügbar ist, ist Software oft auch entsprechend optimiert. Und entsprechend schmerzhaft ist der Leistungsverlust bei Software, die Nutzen aus SMT zieht - in beiden Fällen, mit und ohne aktiviertem SMT. Um das Abgreifen der Daten zu unterbinden, die Spectre V2 erlaubt, wurde in Linux 4.20 das Single Thread Indirect Branch Predictors integriert, das massiv auf die Performance schlägt.
Auch lesenswert: Sicherheits-GAU: Spectre & Meltdown - Hintergründe, Tipps und Benchmarks [PCGH Plus]
Linus Torvalds geht daher soweit zu sagen, dass man nicht in jedem Fall den Schutz verwenden sollte. "Wenn die Performance um 50 Prozent runter geht, sollte man sich schon fragen, ob es das wert war", so Torvalds und empfiehlt eher die Deaktivierung von SMT. Ganz einig sind sich die Linux-Entwickler damit aber nicht. Jiri Kosina, der für SUSE Labs am Kernel arbeitet, hält die Empfehlung angesichts des Sicherheitsrisikos für fragwürdig. Dem entgegnet Torvalds, dass die Chance eines Datenabgriffs über Spectre V2 schon sehr viel geringer sei als via Meltdown.
Richtig ist, dass Browser mittlerweile dafür ausgestattet sind, solche Abgriffe zwischen Tabs zu unterbinden. Torvalrds fragt zudem, ob jemand irgendwelche realistischen Attacken vorzuweisen habe. Und auch Intel hat noch was dazu zu sagen, denn da misst man nur 21 Prozent Leistungsrückgang. Für die Testszenarien gilt aber auch: "your milage may vary". Was der Nutzer dann bevorzugt, hängt wohl vom Einzelfall ab.
Quelle: via The Register
nicht die Summe der vom Prozessor zur Verfügung gestellten Befehle. Ein Prozessor mit RISC-Architektur kann einen sehr viel größeren Satz an Befehlen haben, als einer mit CISC.
RISC steht für Reduced Instruction Set, also folglich hat er weniger verschiedene Befehle in Hardware implementiert. Solche Prozessoren gab es mal in Form von ARM aber die haben mittlerweile eine ähnlichen Umfang wie auch die x86-64-Architektur, weil man den einfach braucht, wenn man performant und energiearm Mainstream-Aufgaben lösen will.
Außerdem ist auch ARM von Spectre betroffen.
Das Problem bei ARM ist die Leistung. Es tauchen zwar langsam ein paar ARM-Chips in Servern auf, aber das ist mehr für Low-Power-Aufgaben. Vorherrschen tun dort x86_64 und PPC64.
Nunja, es ist jetzt darauf hinaus gelaufen, dass ein neuer Patch eingereicht wurde, der nur noch in bestimmten Fällen diesen STIBP-Schutz aktiviert. Ich finde das natürlich weiterhin nicht gut, weil man am besten standardmäßig HT abstellen sollte aber was bleibt einem übrig - der Wirtschaft ist eventuell Sicherheit nicht mehr als 0,5% ihres Umsatzes wert...
Oder so ähnlich!
Ein Risc Prozessor kann im selben Aufgabengebiet schneller sein da er mehr (einfache) Befehle pro Takt schafft. Dafür aber insgesamt weniger Befehle als Cisc.
Oder so ähnlich!