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. SYNCHRON GmbH, Stuttgart
  2. SAUTER Deutschland, Basel (Schweiz), Freiburg/Elbe
  3. Klinikum Nürnberg, Nürnberg
  4. über duerenhoff GmbH, Raum Mannheim

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 26,99€
  2. 1,29€
  3. 1,25€
  4. 7,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobile-Games-Auslese: Teilzeit-UFOs, Rollenspielgeschichte und Würfelpiraten
Mobile-Games-Auslese
Teilzeit-UFOs, Rollenspielgeschichte und Würfelpiraten
  1. Mobile-Games-Auslese Harry Potter und das Geschäftsmodell des Grauens
  2. Chicken Dinner Pubg erhält Updates an allen Fronten
  3. Mobile-Games-Auslese Abfahrten, Verliebtheit und Kartenkerker

Kryptobibliotheken: Die geheime Kryptosoftware-Studie des BSI
Kryptobibliotheken
Die geheime Kryptosoftware-Studie des BSI
  1. DSGVO EU-Kommission kritisiert "Fake-News" zur Datenschutzreform
  2. Russische IT-Angriffe BSI sieht keine neue Gefahren für Router-Sicherheit
  3. Fluggastdaten Regierung dementiert Hackerangriff auf deutsches PNR-System

Raumfahrt: Die Digitalisierung des Weltraums
Raumfahrt
Die Digitalisierung des Weltraums
  1. SpaceX Rundum verbesserte Falcon 9 fliegt zum ersten Mal
  2. Raumfahrt Mann überprüft mit Rakete, ob die Erde eine Scheibe ist
  3. Raumfahrt Falsch abgebogen wegen Eingabefehler

  1. Oneplus 6 im Test: Neues Design, gleich starkes Preisleistungsverhältnis
    Oneplus 6 im Test
    Neues Design, gleich starkes Preisleistungsverhältnis

    Das neue Oneplus 6 hat einen schnellen Prozessor, eine Dualkamera und ein großes Display - mit einer Einbuchtung am oberen Rand. Der Preis liegt wieder unter dem der meisten Konkurrenzgeräte. Das macht das Smartphone trotz fehlender Innovationen zu einem der aktuell interessantesten am Markt.

  2. Google Duplex: Weitere Details über Googles Anrufassistenten
    Google Duplex
    Weitere Details über Googles Anrufassistenten

    Es gibt weitere Details zu Google Duplex. Sobald Duplex einen Anruf durchführt, soll sich der Google Assistant als solcher identifizieren. Zudem wird der Anrufer darüber informiert, dass das Telefonat mitgeschnitten wird.

  3. Verhaltenskodex: Google verabschiedet sich von "Don't be evil"
    Verhaltenskodex
    Google verabschiedet sich von "Don't be evil"

    Google hat kürzlich das Motto "Don't be evil" aus seinem Verhaltenskodex entfernt. Es war nicht nur intern im Unternehmen umstritten. Immer wieder führte der Leitspruch "Sei nicht böse" zu hitzigen Debatten.


  1. 12:00

  2. 11:43

  3. 11:04

  4. 10:23

  5. 15:31

  6. 15:08

  7. 12:25

  8. 14:28