News Meltdown & Spectre: Details und Bench­marks zu den Sicherheits­lücken in CPUs

Krautmaster schrieb:
alle außer AMD sind betroffen, zumindest dem Linux Commit nach. Da is ja nur "if Vendor == AMD dann false". Mag sein dass man das noch weiter eingrenzen wird.

Würde mich nach der aktuellen Informationslage wundern, aber wie geschrieben hat PTI auch andere Vorteile.
Die Kernelentwickler gehen nur mal auf Nummer sicher und aktivieren die Funktion für alle x86-Prozessoren (also nicht auf ARM o.ä.): https://git.kernel.org/pub/scm/linu...c?id=a89f040fa34ec9cd682aed98b8f04e3c47d998bd
Der Commit der die AMD-Prozessoren davon ausnimmt wurde meines Wissens noch nicht gemerged.
 
Fortatus schrieb:
Davon mal abgesehen bin ich gespannt, wie schnell Intel und AMD auf diese Kernel-Patches reagieren. Ein großer Teil scheint ja auch zu sein, dass es so zwei Page-Tables gibt: Eine mit dem gesamten Kernel-Speicher und eine reduzierte. So könnte man bei der nächsten Architektur aus der Not eine Tugend machen und per Befehlssatz sowas in Hardware unterstützen.
Also den Fix hardwarebeschleunigen, statt ihn überflüssig zu machen, so dass die sicherere Variante zum neuen Standard wird. Ob AMD das noch in Ryzen2 reinkriegen kann? Ich befürchte ja, dass sowas erst in Ryzen3 kommt.

Je nachdem, wie lange Intel schon vorher davon weiß, wird das noch eine Weile dauern. Die nächste Architektur wird erst Ice-Lake. Da sich der Shrink in Form von CannonLake verspätet, kommt IceLake wohl erst 2020.
 
Wie gesagt, es geht mir nicht so sehr darum, wann Intel den Bug fixt, dass man (wahrscheinlich) aufgrund fehlerhafter Implementierung des TLB (hängt vllt. mit spekulativer Ausführung zusammen) bei jedem Wechsel zwischen Kernel<->Userprozess den TLB leeren muss.

Es macht ja bisher den Anschein, dass Sie nicht nur den Bug notfallmäßig patchen, sondern diesen Prozess direkt nutzen, um die Architektur zu verbessern. Dazu dem Link zu "Kernel Page-Table Isolation" im dritten Abschnitt des Artikels folgen. Es gibt jetzt zwei "page global directories" (PGDs), eines mit vollem Kernel-Mapping und eines mit minimiertem Kernel-Mapping. Wenn jetzt in neue Architekturen zwei TLBs implementiert würden, könnte man vllt. auch ohne Bug sogar ein paar Flushes sparen.

Farbleere:
Rot: Änderung mit Fix für Hardware-Bug, mit Performance-Verschlechterung
Grün: Änderung (Verbesserung) der Kernel-Architektur, keine Performance-Änderung
Blau: theoretische Hardware-Änderung, die die grüne Änderung nutzt zur Performance-Verbesserung

Bisher ohne Bug:
Kernelprozess wird ausgeführt
Wechsel zu Userprozess = TLB flushen
Prozess wird ausgeführt...
Wechsel zu Kernel = TLB flushen
Kernel wird ausgeführt

Ab jetzt mit Bug:
Kernelprozess wird ausgeführt (Haupt-PGD nutzen)
Wechsel zu Userprozess = TLB flushen
Prozess wird ausgeführt... (gesicherten PGD nutzen)
Interrupt = 2xTLB flushen
Prozess wird ausgeführt...(gesicherten PGD nutzen)
Interrupt = 2xTLB flushen
Prozess wird ausgeführt...(gesicherten PGD nutzen)
Interrupt = 2xTLB flushen
Wechsel zu Kernel = TLB flushen
Kernel wird ausgeführt(Haupt-PGD nutzen)

Mein Gedankenspiel:
Kernelprozess wird ausgeführt (Haupt-PGD nutzen, Haupt-TLB nutzen)
Wechsel zu Userprozess = TLB wechseln (auf "sekundären TLB")
Prozess wird ausgeführt... (gesicherten PGD mit secTLB nutzen)
Wechsel zu Kernel = TLB wechseln (auf Haupt-TLB)
Kernel wird ausgeführt (Haupt-PGD nutzen, Haupt-TLB nutzen)

So müsste nicht dauernd der TLB geleert werden, sondern im Wechsel könnten zwei TLB in der CPU genutzt werden, ein paar Takte reichen, um den genutzten TLB zu wechseln, der jeweils deaktivierte behält seine Daten und wird vllt. im Hintergrund weiter aktualisiert. Die bessere Isolierung des Kernels bliebe erhalten.

Ich bin kein Ingenieur für Mikroelektronik, aber so habe ich es verstanden, und mein Verständnis weitergedacht könnte man vllt. ein paar Taktzyklen bei jedem Kontextwechsel sparen und somit sogar mehr Performance erhalten, als bisher ohne den Bugfix.
Aber das wäre ein neuer Befehlssatz+Architekturänderung, also natürlich bei Intel frühestens bei Ice Lake. Was ich gerne wüsste ist, wie weit das Design von Zen2 ist. Wahrscheinlich schon zu weit für eine solche Änderung.
 
Zuletzt bearbeitet:
Und AMD patcht alte Spiele kaputt. :rolleyes: Jede CPU hat Fehler, die nach dem Rollout erst festgestellt werden. Sowohl AMD CPU als auch Intel CPU. Die meisten Fehler haben kaum Auswirkungen, manche sind schwerer wie z.B. Fehler im Chipsatz damals zu B2 Stepping Sandy. Unsere Hardware ist voll von schweren Sicherheitslücken und man kann froh sein, dass es in dem Fall gefixt wird.
 
Stellt sich die Frage, ob ich Gewährleistung bei meiner 1. Jahr alten CPU geltend machen könnte.
 
Ich hoffe CB macht dazu dann Realistische Tests um zu sehen was uns die Sicherheitslücke nach dem Patch kostet.
In einigen Foren liest man was zwischen 7%-34% Leistungseinbusen.
 
Zuletzt bearbeitet:
Lass Dir einfach von Windows die Paging Fehler zeigen und multipliziere sie mit ner schön großen Zahl dann kannst Du es abschätzen. Adtesslookups ohne TLB kosten jede Menge Zeit, sonst würde man sich den sparen, kostet nicht gerade wenig so ein TLB weil er mit möglichst vielen Bits parallel angebunden sein muss um schnell zu sein
 
Ojeh, das sieht mal nicht gut aus. Wenn man mal von 5% Einbußen in Datenbankanwendungen ausgeht, dürfte dort dann EPYC schon besser performen. Das ist aber eine vorsichtige und wohlwollende Schätzung.

Den Mainstream Spieler wird dieser Bug wohl keine relevante Performance kosten. Allerdings wird Intel den finanziellen Schaden, den dieser Bug im Serverbereich anrichtet, auf den Konsumenten und die Belegschaft abwälzen.
 
Zuletzt bearbeitet:
Vielleicht ist das ganze aber auch eine Win-Win Situation für den gesamten doch stark gesättigten CPU Markt (für die Hersteller). Zumindest in den kommenden Jahren kann doch so ein Hardwarefehler zu einem beschleunigten Austausch aller CPUs führen.

@Raucherdackel!: Ich glaube nicht das sie das bei der derzeitigen Marktlage 1 zu 1 umwälzen können. Dadurch würden AMD CPUs wieder zu interessant was Preis/Leistung anbelangt.
 
In einer ersten Benchmark-Serie von Phoronix zeigt sich ein gespaltenes Bild. Während Datenbankbenchmarks um 15-20% langsamer sind, gibt es andere Messungen die ohne viele system calls kaum bzw gar keine Verlangsamung zeigen. Das trifft auch auf Spiele zu, unter Linux jedenfalls gibt es keine Leistungseinbrüche.
 
Artikel-Update: Der am späten gestrigen Abend veröffentlichte stabile Linux-Kernel 4.14.11 (Download) enthält erstmals die vollständige PTI-Implementierung (genauso wie Linux 4.15-rc6). Ob Unterstützung für PTI in den laufenden Kernel eingebaut ist, verrät die Ausführung des Befehls [c]zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz[/c]. Falls die Ausgabe „CONFIG_PAGE_TABLE_ISOLATION=y“ lautet, dann unterstützt der laufende Kernel PTI, andernfalls nicht. Ob PTI-Unterstützung nicht nur vorhanden ist sondern auch tatsächlich genutzt wird, verrät der Befehl [c]dmesg | grep isolation[/c]. Falls die Ausgabe „Kernel/User page tables isolation: enabled“ lautet, dann ist PTI aktiv, andernfalls nicht.

In Linux 4.14.11 fehlt noch der oben erwähnte Patch des AMD-Entwicklers, der PTI auf AMD-CPUs standardmäßig deaktiviert. In Linux 4.14.11 ist PTI daher unnötigerweise auch auf AMD-CPUs aktiv. Man kann PTI dann entweder manuell anhand des Kernel-Parameters „pti=off“ deaktivieren oder ein paar Tage auf Linux 4.14.12 warten – darin wird der Patch des AMD-Entwicklers enthalten sein.

App-Benchmarks
In kurzfristig durchgeführten eigenen Benchmarks konnte ComputerBase auf einem Notebook mit Intel Core i7-4600U in spontan lauffähigen einfachen Benchmarks der Phoronix Test Suite keine über die Messungenauigkeit hinausgehenden Leistungseinbußen feststellen (getestet wurden pts/blake2, pts/build-linux-kernel, pts/openssl, pts/phpbench, pts/pybench und pts/sqlite). Bei dem im Tweet in dieser News erwähnten Benchmark „time du -s -x /“ (also dem Aufsummieren der Größe aller Dateien auf dem Hauptdateisystem) konnten aber auch wir einen deutlichen Leistungseinbruch feststellen: Ohne PTI lieferte der Befehl in 0,64 Sekunden ein Ergebnis, mit PTI erst nach 0,82 Sekunden, das entspricht einer Leistungseinbuße von 28 %. Dieser „Benchmark“ ist aber als Worst-Case zu bezeichnen, weil er quasi nur daraus besteht, in einer Schleife für jede Datei den „stat“-Syscall auszuführen.

Die weit verbreitete Datenbank PostgreSQL läuft einem Benchmark zu Folge mit PTI rund 7 Prozent langsamer. Linus Torvalds bezeichnete diese Leistungseinbuße in einer Antwort als „im Rahmen der Erwartungen“, aber natürlich stark abhängig vom konkreten Workload. Derweil gibt es weitere PTI-Benchmarks auf Phoronix, denen zu Folge es bei synthetischen Dateisystem-Benchmarks auf NVMe-SSDs dramatische Einbrüche um Faktor 2 und mehr gibt, deutliche Unterschiede im unteren zweistelligen Prozentbereich bei PostgreSQL- und Redis-Datenbanken und keine messbaren Unterschiede bei Encoding-Benchmarks wie FFmpeg und x264 sowie der Kernel-Kompilierung.

Spiele-Benchmarks
Die Gaming-affinen Leser von ComputerBase wird freuen, dass es in den Spiele-Benchmarks von Phoronix keine messbaren Leistungseinbußen gibt, sodass Gamer sich vermutlich entspannt zurücklehnen können – zumindest unter der Annahme, dass die Ergebnisse der Linux-Benchmarks auf Windows übertragbar sind, wovon man zunächst ausgehen sollte. So wie es aktuell aussieht könnten allenfalls die Ladezeiten durch PTI negativ beeinflusst werden.

Details zu der Sicherheitslücke sollen am morgigen 4. Januar 2018 veröffentlicht werden.
 
dreamy_betty schrieb:
gibt es andere Messungen die ohne viele system calls kaum bzw gar keine Verlangsamung zeigen. Das trifft auch auf Spiele zu, unter Linux jedenfalls gibt es keine ... Leistungseinbrüche

Hallelujah ! :daumen:

Das wollte ich lesen.
Rest is mir egal. :D
 
Yeah, super @Steffen! Sehr gute und schnelle Berichterstattung.

7% in DB, NVME SSDs um Faktor 2. Optane ist wahrscheinlich durch diesen Patch komplett hinfällig.

Das ist sehr bitter für Intel und dürfte massiven Schaden bedeuten. Noch kein GAU, aber doch ziemlich gewaltig.
 
Zuletzt bearbeitet:
Danke für das Update @Steffen

Heise und Golem schweigen immer noch. Gerade bei Heise, würde der Fehler AMD betreffen, würde die Seite mit News um sich feuern....
 
@Steffen

heißt aber im umkehrschluss eine Win Win Situation für AMD da Sie durch diesen BUG im Serverbereich mehr Marktanteile gewinnen können.
 
ich verstehe es nach wie vor auch nicht. Selbst der AMD-Adrenalinfehler mit nicht funktionierenden alten Spielen hat eine größere Verbreitung als das hier.
 
In erster Linie ist der Bug alles andere als erfreulich und wird für alle negative Konsequenzen herbeiführen. Auch für AMD.
 
Bin gespannt ob die Performance auch in praxisnahen Szenarien mit mehreren parallel laufenden Programmen stabil bleibt.
 
Zurück
Oben