Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Meltdown und Spectre: "Dann sind wir…

Specre lässt sich in Hardware lösen

  1. Thema

Neues Thema Ansicht wechseln


  1. Specre lässt sich in Hardware lösen

    Autor: /mecki78 18.01.18 - 14:45

    Das Problem von Spectre ist doch letztlich folgendes:

    Die CPU führt Befehle aus, von denen sie noch gar nicht weiß, ob sie diese überhaupt ausführen muss. Dabei wird der Inhalt des Caches verändert. Stellt die CPU hinterher fest, dass sie die Befehle hätte gar nicht ausführen müssen, dann verwirft sie alle Ergebnisse, aber die Änderungen im Cache bleiben bestehen. Indem man jetzt ermittelt, welche Daten aktuell im Cache stehen und welchen nicht, kommt man so indirekt an die Information heran, welche Befehle die CPU ausgeführt hat (das Cache verrät es) und wenn das wiederum von Werten an bestimmten Speicherstellen abhängt, dann weiß man welche Werte diese Speicherstellen haben, ohne jemals direkt auf so eine Stelle zugegriffen zu haben.

    Oder um es mit Kochen zu erklären:

    Die CPU brät Rindfleisch an, weiß aber gar nicht, ob sie für das Rezept Rindfleisch braucht. Das Rindfleisch lagert sie in einer Schüssel zwischen. Etwas später stellt sie fest, die braucht gar kein Rindfleisch und wirft es einfach weg. Dennoch ist die Schüssel jetzt dreckig und dort befinden sich Rückstände vom Fleisch (z.B. etwas Fleischsaft). Alleine indem ich analysiere, was das für Rückstände sind, weiß ich ob die CPU mal Rindfleisch, Schweinefleisch, Geflügel oder Fisch angebraten hat, auch wenn ich das gebratene Fleisch selber nie zu Gesicht bekommen habe.

    Wie würde man das verhindern? Entweder man legt das Fleisch nur dann in die Schüssel, wenn sicher ist, das man es auch braucht, oder aber man macht die Schüssel hinterher wieder sauber.

    Und das geht in Hardware genauso:

    - Entweder man lässt Cache-Änderungen nicht sofort durchschlagen, sondern lagert sie zwischen. Erst wenn sichergestellt ist, dass der Befehl, der diese Änderungen bewirkt hat, auch wirklich hätte ausgeführt werden sollen, erst dann darf die Änderung in's Cache durchschlagen. Natürlich heißt das, sollte Spekulativer Code zweimal auf den gleichen Speicher zugreifen, dann ist es beim zweiten Mal genauso langsam wie beim ersten mal, weil hier eben noch nichts am Cache gemacht wurde. Außerdem ist es relativ komplex später die Cache Änderungen nur selektiv in den Cachespeicher "einzupflegen". Diese Lösung braucht also viel Operationslogik, ggf. viel oder komplexen Mikrocode, sie wird generell die Performance leicht verschlechtern, sie braucht aber wenig zusätzlichen Speicher in der CPU und der Performanceverlust hängt nicht maßgeblich davon ab, ob die CPU richtig spekuliert oder nicht.

    - Oder aber man lässt Cache-Änderungen wie jetzt einfach sofort durchschlagen, räumt dann aber hinterher das Cache wieder auf, wenn diese Änderungen nicht hätten passieren sollen. Hierfür braucht es so eine Art Cache History und die Möglichkeit so einen Art Rollback zu machen, um den Cache wieder in einen vorherigen Zustand zu überführen. Dies Lösung braucht viel zusätzlichen Speicher in der CPU, dafür weniger bzw. weniger komplexe Logik. Was die Performance angeht, so hat diese Lösung keinen Einfluss auf korrekte Vorhersagen der CPU (macht sie etwas spekulativ und das stellt sich als richtig heraus, dann ist die Performance genauso gut wie heute auch), dafür aber wird es umso teurer, wenn die CPU sich irrt (weil dann muss zusätzlich eben ein Cache Clean Up erfolgen, der etwas länger dauern kann und der ggf. nur dann erfolgen kann, wenn solange niemand den Cache verändert bis er durchgelaufen ist).

    In beiden Fällen braucht die CPU mehr Silizium, also mehr Transistoren, in beiden Fällen wird dadurch der Stromverbrauch etwas steigen, die Wärmeentwicklung auch, und in beiden Fällen wird irgendwo mindestens in bestimmten Fällen die Performance etwas nach lassen. Trotzdem wir die CPU in beiden Fällen auch teurer in der Herstellung werden, was bedeutet, das Preis-/Leistungsverhältnis wird sich auf jeden Fall verschlechtern (man zahlt mehr und bekommt dennoch etwas weniger Leistung als bisher). Und es besteht bei beiden Lösungen natürlich die Gefahr, dass man damit zwar die jetzt bekannten Angriffe komplett verhindern kann, ggf. aber eben neue Angriffe ermöglicht, basierend auf der Art wie diese Fixes implementiert wurden oder eben auf Fehlern in ihrer Implementierung, da jede Änderung immer die Gefahr birgt, das dadurch jetzt ein neuer Angriff möglich wird.

    /Mecki

  2. Re: Specre lässt sich in Hardware lösen

    Autor: JohnDoeJersey 18.01.18 - 15:19

    Und woher soll der CPU-Kern wissen, ob nicht inzwischen ein anderer Kern (der L3-Cache ist shared) auf dieselbe Cacheline zugegriffen hat? Ohne diese Information würde der Angriff weiter funktionieren, indem man quasi das Flush+Reload umdreht, also schaut, ob eine Cacheline *nicht* im Cache ist, obwohl sie es eigentlich sein müsste.

    Natürlich kann man diese Informationen zwischen den Kernen austauschen, das wird aber richtig aufwendig, und wahrscheinlich auch performancefressend.

    Und der ganze Aufwand nur, um Meltdown zu fixen, das viel einfacher dadurch gefixt werden kann, dass die CPU die Speicher-Zugriffsrechte prüft, *bevor* das Laden der Cacheline ausgelöst wird (so wie es z.B. AMD schon immer gemacht hat). Für Spectre können dagegen zumindest laut Aussage im Interview auch andere Sidechannel benutzt werden, die nicht auf dem Cache beruhen, daher hilft dein Fix nicht gegen Spectre.

  3. Re: Specre lässt sich in Hardware lösen

    Autor: 0xDEADC0DE 18.01.18 - 17:23

    Ein Cache im Cache? Oder wo lagert der Cache bzw die CPU was zwischen?

  4. Re: Specre lässt sich in Hardware lösen

    Autor: Sarkastius 18.01.18 - 19:29

    0xDEADC0DE schrieb:
    --------------------------------------------------------------------------------
    > Ein Cache im Cache? Oder wo lagert der Cache bzw die CPU was zwischen?

    L1 l2 l3 ram optane memory, hdd cache, hdd

  5. Re: Specre lässt sich in Hardware lösen

    Autor: /mecki78 18.01.18 - 21:59

    JohnDoeJersey schrieb:
    --------------------------------------------------------------------------------
    > Und woher soll der CPU-Kern wissen, ob nicht inzwischen ein anderer Kern
    > (der L3-Cache ist shared) auf dieselbe Cacheline zugegriffen hat?

    Das spielt doch aktuell auch keine Rolle. Wenn mein Kern Befehle derzeit spekulativ ausführt, dann überschreibt er damit ggf. Daten im L3 Cache, die ein anderer Kern dort platziert hatte (ggf. sogar durch das Ausführen von nicht spekulativen Code) oder aber der andere Kern überschreibt das, was mein Kern durch spekulative Ausführung dort ablegt hat, in dem Fall schlägt übrigens ein Spectre Angriff fehl. Deswegen führt Spectre immer den gleichen Angriff gleich mehrfach durch, weil wenn sich zwei Kerne gerade immer gegenseitig den Cache überschreiben, dann sind die Ergebnisse ggf. nicht eindeutig und müssen durch mehrfache Wiederholung erst verifiziert werden.

    Ein CPU Kern kann sich nie drauf verlassen, dass irgend ein Wert noch im Cache ist, auch dann nicht, wenn er ihn gerade erst mit der letzten Operation dorthin kopiert hat. Zwischen der letzten und der aktuellen kann der Wert dort schon wieder überschrieben worden sein, da das Cache ja mehrfach assoziative ist (so nennt man das doch, oder?) Also was für eine Rolle spielt es, ob die Daten, die eine CPU zur Ausführung eines spekulativen Befehls noch vor oder sofort nach dessen Ausführung im Cache stehen oder erst fünf Befehle später? Im schlechtesten Fall überschreiben sie fünf Befehle Später eben Daten, die gerade eine andere Kern mehrfach lesen will und der muss sie dann halt wieder neu in das Cache laden, was ihn kurz ausbremsen wird. Das kann aber aktuell genauso passieren, die Wahrscheinlichkeit dafür steigt nicht durch die Verzögerung (nicht wenn es nur um ein paar Takte geht).

    > Und der ganze Aufwand nur, um Meltdown zu fixen, das viel einfacher dadurch
    > gefixt werden kann, dass die CPU die Speicher-Zugriffsrechte prüft, *bevor*
    > das Laden der Cacheline ausgelöst wird

    Das Problem ist, dass diese Prüfung aber Zeit braucht und während die CPU dann auf das Ergebnis wartet, kann sie nichts anderes tun. Das ist genau das Verhalten, dass eine nicht spekulative CPU an den Tag legen würde und siehe Artikel, würden man bei heutigen CPUs spekulative Ausführung ganz abdrehen, der Performanceverlust wäre drastisch. Und das AMD den Zugriff zuerst prüft ist daher auch falsch, weil dann wären AMD CPUs viel langsamer als Intel CPUs bei jedem Call in den Kernel, da sie hier immer ein paar Microtakte Däumchen drehen müssten. Sie prüfen nicht vorher, sie prüfen nur ganz ers und sind dadurch einen Ticken schneller und das rettet sie in diesem Fall.

    Was man aber bei Meltdown verstehen muss ist folgendes:

    Der spekulative Zugriff auf eine Speicherseite mit höheren Privilegien ist nicht der Angriff. Das ist nur das Vehikel, das überhaupt einen Angriff ermöglicht. Auch das Werte aus dieser Seite im Cache landen ist nicht der Angriff! Das diese Daten im Cache landen ist vollkommen irrelevant.

    Der Angriff ist es einen weiteren, also zweiten spekulativen Befehl auszuführen, dessen Ausführungsergebnis auf dem Ergebnis des ersten spekulativen Befehls basiert und der auch den Cache verändert, aber so, dass man nachher anhand der Veränderung auf das Ergebnis des ersten Befehls schließen kann, DAS ist der Angriff. Und das alles muss mit so wenigen Micro-Ops erfolgen, dass es komplett durchläuft noch bevor der Page Fault zuschlägt, weil der bricht den Codepfad sofort ab.

    Auch AMD führt den ersten Befehle spekulativ aus, auch AMD wartet nicht auf eine Prüfung. Allerdings läuft die Prüfung bei AMD intern anders ab, so dass das Ergebnis der Prüfung immer schon nach dem ersten Befehl bereit steht. Und wenn die sagt, dass hier eine unprivilegierte Seite gerade versucht auf einen privilegierte zuzugreifen, dann bricht die CPU sofort ab, dann wird der zweite Befehl nicht mehr ausgeführt und daher findet auch kein Angriff statt.

    Nicht technisch ausgedrückt: Intel und AMD sind zwei Autos, deren Navi sie auf gut Glück nach links abbiegen lässt, was aber falsch ist, weil da ist ein Fluss. Der Unterschied ist, während AMD den Wage noch rechtzeitig vor dem Wasser zum stehen bekommt und somit kein Schaden entsteht, merkt Intel das Problem erst, wenn das Wasser schon durch die Tür läuft. Trotzdem ist das Grundprobleme beide mal, das hier falsch abgebogen wurde.

    Und daher sind die Entdecker von Meltdown "positiv eingestellt", dass AMD auch betroffen ist. Man muss nur eine andere Kombinationen von Befehlen finden, denn die, mit denen man das gerade bei Intel so gut hinbekommt, die funktioniert wirklich nicht bei AMD. Das heißt aber nicht, dass es nicht eine andere Kombination aus zwei Befehlen gibt die hier funktionieren könnte. Befehle, die die CPU z.B. schneller, paralleler oder spekulativer ausführen kann.

    > Interview auch andere Sidechannel benutzt werden, die nicht auf dem Cache
    > beruhen,

    Theoretisch. Aber Theoretisch ist AMD auch für Meltdown anfällig. Bevor man sich Gedanken macht theoretische Probleme zu fixen, deren Fix man nicht einmal beweisen kann, weil dazu müsste es ein praktisches Problem geben, sollte man sich erst einmal um die praktischen kümmern, denn deren Fix kann man leicht beweisen. Und sowohl Meltdown als auch Spectre als auch tausend artverwandten Probleme, die wir nur noch nicht kennen, basieren am Ende alle auf einer Sidechannel Cache-Timing Attack. Das derartige Cache Timing Angriffe möglich sind, das ist schon lange bekannt, nur hat man nichts dagegen unternommen, weil kein Exploit bekannt war, wie man diese auch sinnvoll ausnutzen kann. Jetzt haben wir einen. Hätte man aber vor 10 Jahren bereits dafür gesorgt, dass Cache Timing Angriffe gar nicht mehr möglich sind (und darauf zielten ja meine Vorschläge ab), dann gäbe es heute weder Spectre noch Meltdown.

    Gäbe es dann vielleicht einen anderen, aber vergleichbaren Angriff? Vielleicht. Aber dann würden wir jetzt hier den diskutieren und wie man den lösen kann. Man hat Cache-Timing Angriffe billigend in Kauf genommen und all die Jahre nichts unternommen diese zu verhindern und das ist jetzt die Rache dafür. Und es lehrt uns: Wenn ein Sicherheitsrisiko besteht, behebe es! Warte nicht erst bis irgendwer dafür einen Exploit findet. Nur weil es derzeit keinen Exploit gibt und auch niemand eine Idee für einen hat heißt das nicht, dass ein Sicherheitsrisiko vernachlässigbar ist. Wenn man nur lange genug wartet, dann kommt der Exploit auch.

    /Mecki



    1 mal bearbeitet, zuletzt am 18.01.18 22:01 durch /mecki78.

  6. Danke

    Autor: Stepinsky 18.01.18 - 22:47

    Danke für die ausführliche Erklärung.

  7. Re: Specre lässt sich in Hardware lösen

    Autor: 0xDEADC0DE 19.01.18 - 12:18

    Damit meinte ich eher, ob die nicht aktuell auch schon betroffen sind. ;)

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. über Hays AG, Stuttgart, München, Bad Homburg
  2. Bosch SoftTec GmbH, Hildesheim
  3. Medienwerft GmbH, Hamburg
  4. MOMENI Gruppe, Hamburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. (u. a. Game of Thrones, Big Bang Theory, The Vampire Diaries, Supernatural)
  2. (u. a. Logan Blu-ray 9,97€, Deadpool Blu-ray 8,97€, Fifty Shades of Grey Blu-ray 11,97€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Age of Empires Definitive Edition Test: Trotz neuem Look zu rückständig
Age of Empires Definitive Edition Test
Trotz neuem Look zu rückständig
  1. Echtzeit-Strategie Definitive Edition von Age of Empires hat neuen Termin
  2. Matt Booty Mr. Minecraft wird neuer Spiele-Chef bei Microsoft
  3. Vorschau Spielejahr 2018 Zwischen Kuhstall und knallrümpfigen Krötern

Homepod im Test: Smarter Lautsprecher für den Apple-affinen Popfan
Homepod im Test
Smarter Lautsprecher für den Apple-affinen Popfan
  1. Rückstände Homepod macht weiße Ringe auf Holzmöbeln
  2. Smarter Lautsprecher Homepod schwer reparierbar
  3. Smarter Lautsprecher Homepod-Reparaturen kosten fast so viel wie ein neues Gerät

HP Omen X VR im Test: VR auf dem Rücken kann nur teils entzücken
HP Omen X VR im Test
VR auf dem Rücken kann nur teils entzücken
  1. 3D Rudder Blackhawk Mehr Frags mit Fußschlaufen
  2. Kreativ-Apps für VR-Headsets Austoben im VR-Atelier
  3. Apps und Games für VR-Headsets Der virtuelle Blade Runner und Sport mit Sparc

  1. VBB Fahrcard: E-Ticket-Kontrolle am Prüfgerät wird in Berlin zur Pflicht
    VBB Fahrcard
    E-Ticket-Kontrolle am Prüfgerät wird in Berlin zur Pflicht

    Rund sechseinhalb Jahre nach dem Beginn des E-Ticket-Projekts in Berlin und Brandenburg wird in der Hauptstadt die Selbstkontrolle in Bussen zur Pflicht. Ohne korrektes Piepen geht es nur noch mit dem Handy-Ticket und Papierfahrausweisen.

  2. Glasfaser: M-net schließt weitere 75.000 Haushalte an
    Glasfaser
    M-net schließt weitere 75.000 Haushalte an

    Bei M-net ist die Winterpause vorbei. Bagger rollen und schließen weitere Haushalte kostenfrei mit FTTB/H an.

  3. Pwned Passwords: Troy Hunt veröffentlicht eine halbe Milliarde Passworthashes
    Pwned Passwords
    Troy Hunt veröffentlicht eine halbe Milliarde Passworthashes

    Bei HaveIBeenPwned können Nutzer aktuell rund eine halbe Milliarde Passwort-Hashes herunterladen. Damit könnten sie Dienste in die Lage versetzen, geleakte Passwörter abzulehnen.


  1. 18:21

  2. 18:09

  3. 18:00

  4. 17:45

  5. 17:37

  6. 17:02

  7. 16:25

  8. 16:15