News Sicherheitslücke in Zen 3: Predictive Store Forwarding birgt Risiken wie Spectre

[deineMudda]

Alle im Zuge der Bearbeitung in den Cache geladenen Daten invalidieren, um Timing-Attacken zu unterbinden². Und so weiter.

Theoretisch funktioniert dein Ansatz. Warum hat dann aber kein Hersteller so eine Lösung implementiert? Oft wird mit den langen Vorlaufzeiten für neue Mikroarchitekturen argumentiert. Das Argument ist aber nicht stichhaltig, die Intel Sicherheitslücken sind schon lange bekannt und trotzdem nicht alle hardwareseitig behoben. Es muss also andere Gründe geben. Die Hersteller schweigen sich zu dem Thema aus, aber ich habe mal darüber nachgedacht, warum das so ist und bin zu folgender Schlussfolgerung gekommen:

Ein Prozessor arbeitet in der Sekunde mehrere Milliarden Operationen ab. Natürlich könnte man nun erst mal alle Ergebnisse, die von out of order Ausführungen stammen zwischenspeichern und später prüfen, ob alle Bedingungen eingehalten wurden und der Befehl überhaupt zur Ausführung kommen sollte.

Das würde aber bedeuten, dass man jede Sekunde Milliarden von Ergebnissen zwischenspeichern muss. Doch nicht nur dass, man muss anschließend ebenfalls milliardenfach prüfen, ob der Befehl zur Ausführung kam. Dazu muss man wiederum so lange warten, bis der vorherige Befehl endgültig (also nicht out of order) ausgeführt wurde. Wenn der vorherige Befehl eine Bedingung mit Sprungbefehl enthält, muss zusätzlich wieder geprüft werden, ob der aktuelle Befehl nicht übersprungen worden ist. Letztendlich wartet man damit wieder auf den vorherigen Befehl. Der Sinn und Zweck von out of order ist aber, dass man die Befehle parallel ausführen kann.

Wenn der Befehl dann tatsächlich ausgeführt wurde, muss das Ergebnis vom Zwischenspeicher in den endgültigen Cache kopiert werden.

Das alles kostet wahrscheinlich soviel Energie, dass sich die Sache dann nicht mehr so richtig lohnen würde. Das ist zumindest das Ergebnis zu dem ich gekommen bin. Wenn man für eine simple Operation wie zum Beispiel eine Addition erstmal eine Bedingung prüfen und einen Zwischenspeicher befüllen muss, dann hat man von der Sache keinen Vorteil mehr.

 

[Teralios]

Ich (als Laie) verstehe das so, dass man durch Out-of-Order, spekulative Befehlsausführung und Speicheroperationen usw. potentielle Angriffsmöglichkeiten schafft, die es bei simpleren In-Order-CPUs erst gar nicht existieren würden

Wobei man dawohl etwas schauen muss.

Ich denke, das Problem ist nicht direkt Out-of-Order, spekulative Befehlsausführung oder Speicheroperationen - ich würde auch noch die Sprungvorhersage mit rein nehmen, sondern viel eher, dass neben diesen Techniken auch die "Gleichzeitigkeit" von viele Threads pro CPU-Kern hier eine Rolle spielt.

Die Probleme bestehen ja darin, die Threads durcheinander gewürfelt werden und daher ein Thread auf die Daten des anderen Zugreifen kann. Die Hauptlösung für fast alle Probleme ist eine saubere Trennung der Register von einander.

Aber hier genau meine Frage.
Wenn es kaum was bringt, warum geht man dann so ein Risiko ein?

Es kann sein, dass es aktuell noch nicht so viel bringt, weil die Architekturen darauf noch nicht ganz ausgelegt sind.

Es gibt aber durchaus Szenarien, in denen so etwas durchaus was bringen kann, weil man Load/Store auf die AGUs besser verteilen kann.

Ja, das ganze ist etwas abgeflaut.

Na ja, das ganze ist auch primär in den Foren hochgekocht und etwas aufgebauscht worden, gerade was den Ottonormal-Anwender angeht.

Die Gefahren bestanden, aber die Probleme wurden ja in Browsern und Co recht fix geschlossen und die primären Probleme bestehen da bis heute eher für VM-Host-Systemen.

 

[mibbio]

Doch nicht nur dass, man muss anschließend ebenfalls milliardenfach prüfen, ob der Befehl zur Ausführung kam. Dazu muss man wiederum so lange warten, bis der vorherige Befehl endgültig (also nicht out of order) ausgeführt wurde. Wenn der vorherige Befehl eine Bedingung mit Sprungbefehl enthält, muss zusätzlich wieder geprüft werden, ob der aktuelle Befehl nicht übersprungen worden ist. Letztendlich wartet man damit wieder auf den vorherigen Befehl. Der Sinn und Zweck von out of order ist aber, dass man die Befehle parallel ausführen kann.

Kurz gesagt, man kann vorausberechnet immer erst validieren bzw. verwerfen, wenn der da hin führende Befehl abgearbeitet ist und hat dadurch das finale Ergebnis der Berechnung im Endeffekt auch nicht wirklich schneller als wenn man es gleich in order gemacht hätte.

 

[deineMudda]

In vielen Spielen ist ein Upgrade von 8600K auf 9900K weniger wert, als diese Lücken an Leistung vernichten.

Das kommt auf den Typ der Anwedung an. Leute mit diesen Prozessoren nutzen diese meist zum daddeln. Und dort sind die Auswirkungen nicht so groß. Ein 7700k ist zum Beispiel immer noch brauchbar. Der Phoronix Parkour ist denke ich nicht unbedingt repräsentativ für die tatsächliche Nutzung.

 

[Teralios]

Ach ja, ist das so ?

Es ist so: Jeder anständige Ingenieur möchte ein möglichst fehlerfreies Produkt abliefern, dass ist bei der Komplexität nur quasi unmöglich und auch nicht mehr beweisbar.

Für eine absichtlich eingebaute Sicherheitslücke ist das hier auch zu Plump - wie fast alle CPU-Sicherheitslücken der Art Meltdown und Spectre, da sie entweder zu zufällig sind oder zu viel Beifang produzieren, als dass man sie gezielt einsetzten kann.

Absichtliche Sicherheitslücken sind in der Regel besser versteckt und dazu auch wesentlich gezielter.

 

[lokon]

2) Ein relevanter Unterschied zwischen den verschiedenen Marktteilnehmern ist, dass AMD dieses Whitepaper ohne jede Not öffentlich gemacht hat. Genauso gut hätten sie es unter Verschluss halten können, einen Schutz dagegen bauen können und diesen erst dann veröffentlichen, wenn es einen Exploit bzw. eine Veröffentlichtung von unabhängigen Forschern gibt.
Hier wird aber absichtlich Transparenz geschaffen, bevor irgendjemand externes danach fragt.

Wenn https://www.amd.com/en/support/tech-docs aufgerufen wird, dann "fehlen" zB recht viele "neue" Spezifikationen / Guides / Datenblätter bei AMD.
zB AM4 Socket Design Specification, Fam 17h (Zen, Zen+...) BIOS and Kernel Developers Guide

Bei BIOS/UEFI unterstützte AMDs Lösung /AGESA lt Coreboot Projekt keine freien Tools zur Erstellung (gcc, llvm/clang) - code ist wohl "MS Visual Studio 2010" kompatibel.
Vermutlich deshalb gibt es erst seit ~Okt 2020 bis heute gerade mal 4 AMD Picasso/Dali Chromebooks (src)

AMD hat im Gegensatz zu Intel afaik auch keine öffentliche PCN Änderungsdatenbank (https://qdms.intel.com/).

Die Firmware der CPUs selbst (Microcode) bzw. andere CPU nahe Komponenten wie PSP , MEI sind bei beiden "geheim" / NDA.

 

[GrumpyCat]

Das würde aber bedeuten, dass man jede Sekunde Milliarden von Ergebnissen zwischenspeichern muss.

Genau das passiert doch bei Speculative Execution. Es werden Befehle spekulativ ausgeführt und deren Ergebnisse in Schattenregistern etc. vorgehalten. Stellt sich heraus, dass der Kontrollfluss aber tatsächlich anders verläuft, wird das alles verworfen. Cache Lines invalidieren wären da nur ein paar mehr Infos mehr zu verwalten.

Siehe Wikipedia https://de.m.wikipedia.org/wiki/Speculative_execution
"Die zwischengespeicherten Ergebnisse werden ausgelesen und das Passende ausgeführt, die Anderen werden verworfen."

Irrer Aufwand das Alles...

 

[deineMudda]

@GrumpyCat Bewerb dich doch bei ARM, Appel, Intel, AMD oder einem anderen Chipdesigner deiner Wahl. Die suchen solche Spezialisten wie dich und zahlen dir ein fürstliches Gehalt wenn du das Problem lösen kannst.

 

[Shoryuken94]

Wenn es kaum was bringt, warum geht man dann so ein Risiko ein?

10 Kleinigkeiten die alleine kaum was bringen summieren sich am Ende halt doch ziemlich. Deshalb hat man viele Kleine Verbesserungen von Architektur zu Architektur, die für sich alleine wenig bringen, im gesamten aber viel ausmachen. Zudem sollte man auch 0,5 Prozent nicht vernachlässigen. gerechnet auf ganze Großrechenzentren mit Millionen von von Rechenkernen ist das insgesamt jede Menge Rechenzeit, die da zusammenkommt.

 

[GrumpyCat]

Bewerb dich doch bei ARM, Appel, Intel, AMD oder einem anderen Chipdesigner deiner Wahl.

Tatsächlich habe ich bereits gefragt, wieso das nicht so gemacht wird, wie ich naiv beschrieben habe, denn vermutlich wird's einen Grund dafür geben, und wie ich auch schon gesagt habe, gibt es ja noch andere Seitenkanäle als den Cache. Ich würde tatsächlich gerne Infos dazu bekommen, und vielleicht weiß ja hier jemand mehr, und die, die es nicht tun, können sich das Kommentieren einfach verkneifen.

 

[atlas77]

11400 Rocket Lake ist bestellt...bye AMD,

 

[.Ake]

11400 Rocket Lake ist bestellt...bye AMD,

🤨
Ach.

 

[Rockstar85]

Soweit ich das verstanden habe, wird der Fehler nur für VMs schlagend.

Ich denke auch gerade hier wird PSF dann auch in Leistung sichtbar sein. (das "Holding" der Daten für Datenbanken zb, würde da das neue Abarbeiten des Task verhindern)
Ärgerlich für AMD, dass nun Spectra V4 theoretisch möglich ist. Aber gut, dass man hier öffentliche Dokumente raushaut. Alles besser als, dass SAP oder Oracle plötzlich so ein Paper darlegen.

Und wegen der 25% Spekulativ und AMD würde das zurückhalten.. Leute, setzt den Aluhut ab. Das wäre ein Imageschaden, wogegen Bulli ein feuchter Witz wäre. Und auch schon die Haltung Intels wundert als Unternehmen. Aber die haben ja die Konsequenzen bekommen bezüglich Insiderhandel.

 

[der Unzensierte]

Ist wie im richtigen Leben. Da schließt alles was mit "spekulativ" zu tun hat Sicherheit ja auch per se aus. Liegt schon im Ursprung des Begriffs - über die Grenzen der gesicherten Erkenntnis hinaus denkend.
Und dann hoffe ich mal Intel lernt was aus dem Umgang von AMD mit der Sache. Aber das ist auch schon wieder spekulativ.

 

[andi_sco]

Mutwillig Sicherheitslücken einzubauen, sollte man sicher weder AMD noch Intel in solchen Situationen unterstellen.

Genau 👍🏽

Wichtiger ist, wie die Hersteller damit umgehen, nachdem der Fehler bekannt geworden ist.

Trifft es auf den Kern

 

[daknoll]

11400 Rocket Lake ist bestellt...bye AMD,

😘

 

[Nagilum99]

Frage mich eher warum das solange bei Intel gedauert hat, das man hier was findet. Bei AMD ist der CPU erst kurz auf dem Markt und schwupps findet man was.

Du verwechselst "auf dem Markt" mit "das Design ist final und erste Exemplare lauffähig". Für die Analysten ist letzteres völlig ausreichend.

 

[mae]

Eine Lösung für das Problem hat noch kein Hersteller gefunden, daher halte ich es für wahrscheinlich, dass es auch keine Lösung mehr geben wird.

Eine Loesung fuer das Problem wurde in comp.arch ein paar Tage nach Bekanntwerden von Spectre diskutiert. Ich gehe einmal davon aus, dass die Leute bei Intel, AMD und ARM da auch draufgekommen sind. Nur dauert es von da, bis das in Silizium vorliegt, dem Vernehmen nach 5 Jahre; das waere dann irgendwann nach Juni 2022 (5 Jahre, nachdem Spectre an Intel und AMD gemeldet wurde). Wenn sie's noch in ein schon laufendes Projekt einbauen konneten, schon frueher, wenn sie's am Anfang nicht ernst genommen haben, und da nicht die Koepfe haben rauchen lassen, spaeter. Ich hoffe aber, dass sie da die Loesungen doch einbauen. Die Vorgehensweise "Ignorieren, bis keiner mehr daran denkt" wurde offenbar bei Rowhammer gewaehlt, und leider scheint sie zu wirken.

Ergänzung (6. April 2021)

Ein Prozessor arbeitet in der Sekunde mehrere Milliarden Operationen ab. Natürlich könnte man nun erst mal alle Ergebnisse, die von out of order Ausführungen stammen zwischenspeichern und später prüfen, ob alle Bedingungen eingehalten wurden und der Befehl überhaupt zur Ausführung kommen sollte.

Das würde aber bedeuten, dass man jede Sekunde Milliarden von Ergebnissen zwischenspeichern muss. Doch nicht nur dass, man muss anschließend ebenfalls milliardenfach prüfen, ob der Befehl zur Ausführung kam. Dazu muss man wiederum so lange warten, bis der vorherige Befehl endgültig (also nicht out of order) ausgeführt wurde.

Ja, das wird bei OoO-Prozessoren tatsaechlich so gemacht: Am Ende werden die Befehle alle in der Commit/Retire-Unit in-order verarbeitet und die architekturellen Aenderungen (Registerinhalte, Speicherinhalte) dauerhaft sichtbar. Um Spectre zu loesen, muss man microarchitekturelle Aenderungen (z.B. Cache-Inhalte) genauso handhaben.

Wenn der vorherige Befehl eine Bedingung mit Sprungbefehl enthält, muss zusätzlich wieder geprüft werden, ob der aktuelle Befehl nicht übersprungen worden ist. Letztendlich wartet man damit wieder auf den vorherigen Befehl. Der Sinn und Zweck von out of order ist aber, dass man die Befehle parallel ausführen kann.

Bei Spruengen wird nur ueberprueft, ob die Vorhersage korrekt war. Wenn nicht (branch misprediction), wird alles hinter dem Sprung weggeschmissen. Die Commit-Stufe arbeitet die Befehle zwar nach der Reihe ab, aber kann mehrere Befehle pro Zyklus verarbeiten und muss nichts mehr berechnen. Die wartet nur, bis die Berechnungen fertig sind, und macht dann ein commit/retire von allen Befehlen, die vor dem ersten liegen, der noch nicht fertig ist.

Das alles kostet wahrscheinlich soviel Energie, dass sich die Sache dann nicht mehr so richtig lohnen würde.

Also zumindest fuer den architekturellen Zustand haben einige Firmen viel Geld in Deine Theorie investiert (Intel mit IA-64 und dem urspruenglichen Atom, Transmeta mit dem Efficeon). Letztendlich hat sich herausgestellt, dass sich OoO performancemaessig auf jeden Fall auszahlt und auch von der Effizienz her ok ist; so wurde seit Silvermont (2013) auch die Atom-Reihe mit OoO-Mikroarchitekturen implementiert, IA-64 und Efficeon eingestampft. Da sind jetzt noch nicht die Spectre-Workarounds dabei, die das gleiche beim mikroarchitekturellen Zustand machen, aber ich denke, dass das jetzt auch nicht so viel mehr an Daten ist, die man dann spekulativ mitfuehren muss.

 

[Miuwa]

Ich komme mehr und mehr zu der Schlussfolgerung, dass im Grunde die komplette spekulative out of order Vorhersage sicherheitstechnisch nicht so geil ist..

Nitpick:
"Out of Order" und "speculative execution" sind zwei paar Schuhe. Ich kann Instruktionen OoO ausführen ohne zu spekulieren wohin ein Jump führt bzw. welcher branch genommen wird und ich kann branches spekulativ ausführen ohne die Instruktionen out of Order auszuführen.
In der Praxis können die beiden Techniken aber nur gemeinsam ihre Vorteile so richtig ausspielen, weil sonst das OoO window viel zu klein wäre (im Prinzip hat ja schon jeder Load Befehl nen impliziten branch, weil er ja ne pagefault/access violation triggern könnte).

 

[PuscHELL76]

Ist der 1. Link in der News.

https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf
Nur für Linux.

Ok. Darum hab ich es wohl überlesen. Gibt es einen link für Windows 10?