Zunaechst einmal die Grundbegriffe:
Architektur: Der Befehlssatz und der darin beschriebene architekturelle Zustand: Register, Flags, Speicher.
Mikroarchitektur: Wie die Architektur implementiert wird, z.B. mit caches, pipelines, branch prediction, in-order oder OoO, register renaming, und dabei gibt es noch viele Entwurfsentscheidungen. Wobei man niedriglevelige Dinge wie den Fab-Prozess nicht dazuzaehlt.
Dieselbe Architektur kann mit verschiedenen Mikroarchitekturen implementiert werden, und gerade bei der AMD64-Architektur gibt es ja sehr viele verschiedene Mikroarchitekturen (z.B. Haswell, Skylake, Ice Lake, Zen, Zen 2, Zen 3). Das heisst aber auch, dass die Mikroarchitektur fuer den Befehlssatz nicht sichtbar ist, sondern sich nur in der Laufzeit auswirkt.
Mikroarchitektureller Zustand ist z.B., was sich in Caches, oder im Branch predictor befindet, aber z.B. auch der Power-Zustand der AVX-Einheit auf dem Skylake. Das ist, wie gesagt, fuer die Architektur eigentlich unsichtbar, aber es wirkt sich auf das Timing aus, und daher kann Code mit Hilfe von Zeitmessungen etwas ueber diesen Zustand herausfinden.
fdsonne schrieb:
Ich kann dir ehrlich gesagt nicht wirklich folgen, was "mikroarchitekturellem Zustand" sein soll, technisch gesehen führt das Rechenwerk eine Operation aus und muss irgendwo die Daten her haben und diese müssen auch dann irgendwo hin, also das Ergebnis.
Der spekulative architekturelle Zustand wird schon seit den ersten modernen OoO-Prozessoren in Zwischenpuffern gespeichert, und dann erst in der commit/retirement-Stufe der Pipeline, die die Befehle in-order verarbeitet, in dauerhaften architekturellen Zustand uebergefuehrt. Wenn das nicht so waere, wuerden OoO-Prozessoren nicht die Architektur implementieren.
Bisher wurden solche Zwischenpuffer bei mikroarchitekturellem Zustand oft nicht verwendet, weil's ja nur Mikroarchitektur war und architekturell nicht sichtbar: Wenn eine andere Cache line im Cache liegt, dann wirkt sich das auf die Performance aus, aber nicht auf die architekturell korrekte Ausfuehrung. Und
das macht sich Spectre zu nutze: es gibt dadurch einen Side channel von der spekulativen Ausfuehrung in die nicht-spekulative Ausfuehrung.
Wenn man jetzt fuer z.B. Cache-updates oder Branch predictor updates solche Zwischenpuffer verwenden wuerde, und den dauerhaften Cache erst beim commit aendert, gaebe es diesen Seitenkanal nicht mehr, und damit kein Spectre.
Das funktioniert so aber nicht, weil das Kind im Brunnen ersoffen ist, wenn das Rechenwerk die eine Operation schon durchgeführt hat. Es weis in dem Zustand noch überhaupt nichts davon, dass da im nachfolgenden Schritt eine Exception geworfen wird. Wie soll das für die Zukunft Hellsehen?? -> technisch nicht möglich.
Deswegen wird das Ergebnis der Operation zwischengespeichert statt gleich z.B. das architekturelle Register zu ueberschreiben. Und das mit den Zwischenspeichern funktioniert: Es gibt keine Spectre-Variante, die versucht, spekulative architekturelle Daten direkt auszulesen. Stattdessen verwendet Spectre mikroarchitekturelle Seitenkanaele, weil dort noch nicht mit Zwischenspeichern gearbeitet wird.
Das Ding ist, es gibt Tonnen von Software Exploits, die nichts mit irgendwelchen Hardware Themen zu tun haben. Teils seit Monaten und Jahren da drin schlummern - irgendwelche sudo Priv. Exc. Themen von jüngst, Paradebeispiel. Lücke seit Jahren! vorhanden.
Klar, gibt es auch, muessen auch gefixt werden. Da kann man auch nicht sagen: Ist doch eh egal, es gibt noch soviele andere Luecken.
Sich da auf die CPU einzuschießen ist klar nicht falsch oder soll auch nicht so verstanden werden. In Relation zum Rest ist das aber einfach hoher Aufwand für einen begrenzten Erfolg. Wer rein will, nutzt viel einfachere Lücken.
Nur wenn sie da sind. Um auf Dein sudo-Beispiel einzugehen:
Code:
> sudo su
-bash: sudo: command not found
Und von Exchange sind wir sowieso nicht betroffen. Von Spectre aber schon.
In welcher Relation dazu steht deiner Ansicht nach das CPU Thema?? Für mich in keiner wirklich greifbaren...
Es nuetzt die sicherste Software nichts, wenn Hardware-Luecken wie Spectre oder Rowhammer nicht gefixt werden. Du gehst davon aus, dass Du sowieso unsichere Software verwendest, daher kaufst Du gerne auch lueckenhafte Hardware. Ich nicht.
