Intels neuer Meltdown: Anti-MDS-Kernel macht Linux langsamer

Jetzt ist Ihre Meinung gefragt zu Intels neuer Meltdown: Anti-MDS-Kernel macht Linux langsamer

Anfang der Woche wurden mit Zombieload, RIDL und Fallout neue Sicherheitslücken in Intel-Prozessoren entdeckt. Linux hat bereits kurz nach Bekanntwerden der als Microarchitectural Data Sampling (MDS) zusammengefassten Gruppe mit einem neuen Kernel reagiert. Benchmarks zeigen, dass die CPU dadurch langsamer wird.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Intels neuer Meltdown: Anti-MDS-Kernel macht Linux langsamer

Beleibt wohl nur ein Wechsel auf Zen2 als Ausweg.

Wenn das so weitergeht, dann ist Ryzen 2000 bald schneller als die aktuellen Core i7/i9.

<windows chauvinism mode>
Ist halt so bei einem OS für lau welches von Amateuren als Hobby entwickelt/gepflegt wird. Kein Wunder dass sich das nicht durchsetzt
</windows chauvinism mode>

Bei Windows sieht es nicht besser aus. Gibt es da überhaupt schon einen Patch?

Ja und wurde schon vor 2-3 Tagen bei mir eingespielt.

DKK007 schrieb:

Beleibt wohl nur ein Wechsel auf Zen2 als Ausweg.

Zum Vergrößern anklicken....

Eher auf Epyc2, wer setzt schon eine Desktop-CPU in einen öffentlich genutzten Server?

Wenn Du zu Hause deinen Mitbewohnern so wenig traust und ihnen totzdem Zugriff (per RDP oder VM) auf deinen Homeserver gibst, liegt das Problem für mich an einer ganz anderen Stelle.

Immerhin scheint die AdHoc-Lösung für Linux besser zu sein wie die von Googlöe für Chrome OS.

An der Stelle sollte man dann auch nicht unerwähnt lassen, dass man gegen die neu entdeckten Schwachstellen erst den vollen Schutz genießt, wenn man Hyperthreading entweder im BIOS oder einem der Kernel-Parameter deaktiviert.

Zum Vergrößern anklicken....

Sehr schöner Beitrag. Endlich mal Klartext geschrieben und kein wichtiges Detail ausgelassen.

Mal deutlich ausgesprochen:
HyperThreading ist tot! ZombieLoad ist ein weiterer von mehreren offenen Angriffspunkten, die nicht geschlossen wurden, weil die Performance darunter leidet.

FreeBSD und Chrome OS (Google) haben HT schon zum Schutz der Kunden deaktiviert.
Praktisch alle Hersteller von Betriebssystemen empfehlen die Deaktivierung von HT, wenn einem die Sicherheit lieb ist.

Intel schrieb:

Once these updates are applied, it may be appropriate for some customers to consider additional steps.

Zum Vergrößern anklicken....

Die weiteren Schritte können ja nur die Deaktivierung von HT sein, weil der Kunde sonst gar keinen Einfluss auf irgendetwas hat. Das will Intel zwar offiziel so nicht sagen: "Because these factors will vary considerably by customer, Intel is not recommending that Intel® HT be disabled, and it’s important to understand that doing so does not alone provide protection against MDS."
Aber offensichtlich haben sie durch die Blume genau das getan, was alle anderen auch von sich gegeben haben: Wenn man möchte, dass der Rechner noch sicher ist, sollte man zusätzlich zu den Software-Updates auch HT deaktivieren.

Da HT/SMT für die Spieleleistung sowieso schlecht sind, kann ich nur empfehlen: Schaltet es einfach im Bios ab und sorgt dafür, dass ihr möglichst viele echte Kerne habt!

Es muss nur ein laues Lüftchen wehen und diejenigen, die jetzt in ihren Betriebssystemen noch dem Kunden die Verantwortung übertragen, ob er HT anlassen möchte, werden mit Sicherheit umknicken und es auch standardmäßig abschalten!
Edit: Es gibt schon Linux-Programme, die ein deaktiviertes HT by Default vorsehen und eine Möglichkeit bieten, durch Eingabe des Root-Passworts kurzzeitig HT anzuschalten.

Ein Update, dass beinahe ausschließlich Sicherheitsrisiken von SMT bekämpft, verlangsamt das System besonders stark, wenn SMT deaktiviert ist?
Irgendwas sagt mir, dass da noch Optimierungspotenzial in der Software schlummert.

Lol, erst macht intel HT softlocks noch selber und jetzt müssen die user HT schon selbst soflocken, das nenn ich mal effizient.

Arkintosz schrieb:

Mal deutlich ausgesprochen:
HyperThreading ist tot! ZombieLoad ist ein weiterer von mehreren offenen Angriffspunkten, die nicht geschlossen wurden, weil die Performance darunter leidet.

Zum Vergrößern anklicken....

Die Implementierung, die Intel für HT gewählt hat, scheint es für sicherheitskritische Dinge zu sein. Wobei zumindest mir nicht bekannt ist, was Intel bei den Microcode-Updates oder gar bei den neuen HW-Steppings geändert hat und in wie weit es die aktuell bekannten MDS Angriffsmöglichkeiten nur lindert oder solche Angriffe gar unterbindet.

Arkintosz schrieb:

Da HT/SMT für die Spieleleistung sowieso schlecht sind, kann ich nur empfehlen: Schaltet es einfach im Bios ab und sorgt dafür, dass ihr möglichst viele echte Kerne habt!

Zum Vergrößern anklicken....

Spielst Du in der Cloud? Weisst Du zu 1000% (nein, keine 0 zuviel) was auf Deinen PC so alles an Programmen, Diensten, Browser-AddOns oder gar (aber sicher nicht bei Dir) Spiele-Mods so läuft und was die tun.

Arkintosz schrieb:

Edit: Es gibt schon Linux-Programme, die ein deaktiviertes HT by Default vorsehen und eine Möglichkeit bieten, durch Eingabe des Root-Passworts kurzzeitig HT anzuschalten.

Zum Vergrößern anklicken....

Das wäre für mich dann ein Grund, solche Distributionen auf meinen privaten Heimserver sofort zu löschen. Ich kann selber abschätzen, wie hoch mein Risiko ist und was ich dafür opfern möchte.

Ich warte immer noch auf den ersten PoC für so einen MDS-Angriff als WebAssembly, dann könnte das ganze doch noch interessant werden für Heimanwender mit einen Webbrowser im Auslieferzustand.

fotoman schrieb:

Ich warte immer noch auf den ersten PoC für so einen MDS-Angriff als WebAssembly, dann könnte das ganze doch noch interessant werden für Heimanwender mit einen Webbrowser im Auslieferzustand.

Zum Vergrößern anklicken....

Soweit ich das überschauen kann, sollte ein einfacher JavaScript-Code ausreichen, wie auch bei Spectre - Dazu braucht man kein Web Assembly können.:
Software-Schutz vor Spectre-Angriffen ist weitestgehend nutzlos - Heise Online

Und was nun die Angriffe angeht, kann ich mich tatsächlich nicht erinnern, gelesen zu haben, dass jemand so einen Angriff durchgeführt hätte.
Allerdings finden tächlich riesige Mengen an Angriffen statt, viele fallen nicht auf, die meisten werden verschwiegen und die wenigsten von Profis rekonstruiert.
Wenn also bei 1.000 Leuten über so einen Weg eingebrochen worden wäre, müsste man erst mal davon erfahren. Und wenn es bei 1.000.000 Firmen über Cloud-Server gemacht wurde, ebenfalls. Denn da man dann nicht mal den Einbruchs-Code irgendwo lesen kann, ist es absolut nicht feststellbar. Nur wenn Daten irgendwo auftauchen würden, wo sie nicht hingehören, könnte man anfangen, zu mutmaßen, ob es so ein Angriff gewesen sein könnte.

Arkintosz schrieb:

Soweit ich das überschauen kann, sollte ein einfacher JavaScript-Code ausreichen, wie auch bei Spectre - Dazu braucht man kein Web Assembly können.:
Software-Schutz vor Spectre-Angriffen ist weitestgehend nutzlos - Heise Online

Zum Vergrößern anklicken....

Wenn das so ist/wäre, dann ist man mit Firefox ab FF54 schon "sicher" vor Spectre. das nutzt je Tab einen Prozess.

Es gibt immerhin mittlerweile ein Video, in dem ein RIDL Angriff mit JS, WebAssembly und der SpiderMonkey Engine demonstriert wird (waum macht man sowas nicht im Browser, wenn man nicht nur Wissenschaftler erreichen möchte)
RIDL and Fallout: MDS attacks
Der PoC dazu ist bisher aber wohl nicht öffentlich, im Gegensatz zu dem für Zombieload. Damit bleibt es für mich leider fraglich, was ich in FF abschalten müsste (nur WebAssembly oder JS komplett) und ob nur FF oder auch Chromium betroffen ist.

Arkintosz schrieb:

Allerdings finden tächlich riesige Mengen an Angriffen statt, viele fallen nicht auf, die meisten werden verschwiegen und die wenigsten von Profis rekonstruiert.

Zum Vergrößern anklicken....

Richtig, Angriffe. Die Frage für mich ist, wie muss für die MDS-Bugs ein Angriff aussehen und was kann damit abgegriffen werden.

Du hast von Spiele-Rechnern gesprochen, was in D überwiegend Einzelplatzerechner mit Internetzugriff sein dürften. Bei Cloud- oder Multi-User Servern bin ich direkt bei Dir, da ist das Risiko ungleich höher zu bewerten.

Auf einem Single-User PC muss irgendwer die Sachen ausführen. Entweder unbemerkt per JS (MDS kennt dabei keine Prozessgrenzen, dafür aber auch keine vorgebbaren Adressbereiche) oder als lokale Applikkation/Service. Schafft es jemand, eine lokale Applikation unbemerkt zu starten, hat er ganz andere Möglichkeiten wie in zufällig im Cache befindlichen Daten nach bekannten Mustern zu suchen.

Auf meinem Linux-Server/NAS surfe ich noch nicht einmal, er verbindet sich nur automatisch mit dem Linux Update-Server. Was dieser mir aufspielt, weiss ich nicht, den Updates von Linux Mint/Ubuntu vertraue ich genaus blind wie denen von MS (inkl. dem hoffetnlich nicht manipiulierten Übertragungsweg).

Für mich sind die Angriffsszenarien im Heimbereich bisher so gering, dass ich dafür kein HT abschalten würde. Um die (ESX-)Server in der Firma kümmern sich zum Glück andere Leute.

fotoman schrieb:

Eher auf Epyc2, wer setzt schon eine Desktop-CPU in einen öffentlich genutzten Server?

[ ... ]

Zum Vergrößern anklicken....

Wesentlich mehr als man denken/hoffen würde. Und nein, ich rede hier nicht von ein paar Bastelkisten irgendwo im Keller eines Startups, sondern von halben Rechenzentren voll davon. Teilweise echt gruselig, wenn man weiß was da mitunter rumsteht, und wofür die genutzt werden.

fotoman schrieb:

Für mich sind die Angriffsszenarien im Heimbereich bisher so gering, dass ich dafür kein HT abschalten würde. Um die (ESX-)Server in der Firma kümmern sich zum Glück andere Leute.

Zum Vergrößern anklicken....

Ich respektiere die Meinung, sehe es selbst aber anders:
HT (und auch SMT - in meinem Fall habe ich ja eine AMD-CPU, die kaum von irgendwas betroffen ist) bringt mir im Gaming-Rechner im Schnitt mehr Nachteile als Vorteile in Form von inkonsistenteren Frameraten und im Schnitt auch etwas weniger FPS.
Auch zu über 95% der Zeit, die ich am Rechner verbringe, bringt mit HT absolut null. Der einzige Punkt wo es was bringen kann, ist bei Volllast.
Selbst wenn ich ein Volllast-Szenario habe, bringt es mir im Schnitt geschätzt vielleicht zwischen 10% und 30% Mehr Leistung.

Warum soll ich also die ganze Zeit Lücken halb offen lassen und sogar mit einem schlechteren Spielerlebnis leben, wenn ich so wenige Vorteile daraus ziehe?
Stattdessen habe ich, wenn ich es abschalte sogar die Sicherheit vor Lücken die noch gar nicht entdeckt wurden. Man kann nicht immer davon ausgehen, dass die Lücken irgendwelche gutmütigen Forscher zuerst entdecken.

Auch wenn man einen Server betreibt, hat man in der Regel Lastspitzen und die sind normalerweise immer zu einer bestimmten Tageszeit im Höhepunkt. Es geht also auch da nur darum, den kurzen Zeitraum besser zu überstehen und das kann HT auch nur minimal herauszögern.
Wenn man eine riesige Serverfarm mit Clustern hat, ist das was anderes, weil man da immer mehr oder weniger Volllast fährt. Wenn man da dynamisch Rechner hinzuschaltet, wenn es brenzlig wird, muss man ohne HT 10-30% mehr Rechner anschmeißen und das wird dann natürlich teurer.

Ich finde HT also gerade im Bereich wo nur ein einziges System betrieben wird, in der Regel völlig problemlos abschaltbar, ohne irgendwelche echten Nachteile zu bekommen. Stattdessen hat man viel mehr Sicherheit und einige Sicherheitsmechanismen z.B. im Linux-Kernel werden sich dann auch deaktivieren, weil sie ohne HT nicht mehr gebraucht werden.

Hat sich schon gelohnt auf den 9700K statt den 9900K zu setzen. Bis die Spiele wirklich mit "nur" acht Kernen ohne SMT nicht mehr zufriedenstellend laufen, dauert es wohl noch eine ganze Weile und bis dahin hat man damit mehr Ärger als Vorteile. Ich denke mal im Heimbetrieb ist man mit einem Intel keinem Wahnsinnsrisiko ausgesetzt und von Cloudcomputing war ich noch nie ein Fan. Mal sehen, wie sich das alles über die nächsten fünf Jahre entwickelt, wenn der nächste CPU-Wechsel geplant ist.

Wie kann man angesichts all dieser Lücken und deren Auswirkungen auch nur im Entferntesten von "lohnen" sprechen? Mag sein, dass du mit dem 9700K für Intel-Verhältnisse eine klügere Entscheidung getroffen hast.

Trotzdem stehst du mit den im Schnitt 16 Prozent Leistungseinbußen (Meltdown, Spectre, etc) verglichen mit AMD richtig schlecht da. Nehmen wir den hohen Preis dazu, dann landen wir im Bodenlosen.

Der_Unbekannte schrieb:

Trotzdem stehst du mit den im Schnitt 16 Prozent Leistungseinbußen (Meltdown, Spectre, etc) verglichen mit AMD richtig schlecht da. Nehmen wir den hohen Preis dazu, dann landen wir im Bodenlosen.

Zum Vergrößern anklicken....

Preis-Leistung war eher nebensächlich und Single-Thread-Performance wichtig, soll eine Weile halten und sowohl im Systempreis als auch über die Zeit relativiert sich der Aufpreis. Frage ist, ob die Tests für den Index mit den entsprechenden Patches nochmal wiederholt wurden.