1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › LLVM: Google will…

Spectre in Software fixen ist Unfug

  1. Thema

Neues Thema Ansicht wechseln


  1. Spectre in Software fixen ist Unfug

    Autor: /mecki78 17.01.19 - 15:48

    Der beste Compiler der Welt wird nie in der Lage sein alle durch Spectre angreifbare Stellen zu finden. Auch lässt sich nicht jede der gefunden Stellen beheben, ohne dabei teilweise massive Performance-Verluste in Kauf nehmen zu müssen. Außerdem nützt es nichts, wenn ein Angreifer selber Software in das System bringen kann, weil auch ein eigentlich nicht durch Spectre Angreifbares System kann angreifbar werden durch ein Plugin, dass selber angreifbar ist und ein Angreifer wird natürlich derartigen Compilerschutz ausschalten, wenn er sein Plugin baut.

    Spectre lässt sich effektiv und für alle Zeiten nur in Hardware beheben und zwar dadurch, dass eine CPU, die spekulativ Code ausgeführt hat und dann feststellt, dass dieser Code nie hätte laufen sollen, dafür sorgt, dass nicht nur die direkt sichtbaren Effekte rückgängig gemacht werden, so wie das heute ja schon der Fall ist, sondern eben auch die nicht-sichtbaren, aber durchaus messbaren Effekte, wie z.B. Veränderung im CPU Cache.

    Dieses hatte man bis jetzt einfach ignoriert, weil man dachte, ist ja egal was im Cache steht und es kann ja sowieso niemand direkt das Cache auslesen. Letzteres ist zwar richtig, aber man muss das Cache eben nicht auslesen, um zu testen ob dort etwas steht oder nicht, man kann es "messen", denn kann eine Anfrage aus dem Cache beantwortet werden, dann kann sie eben deutlich schneller beantwortet werden als wenn das nicht der Fall ist, weil das ist ja der ganze Sinn hinter so einem Cache. Alle Spectre Angriffe zielen darauf ab, dass man Operationen ausführt, deren Ergebnis man zwar nie bekommen wird, die aber das Cache verändert und man dann durch Testen heraus findet, was dort im Cache steht und somit auch weiß, was das Ergebnis der Operation gewesen wäre.

    Schon heute ist es sehr teuer für CPUs eine spekulative Ausführung rückgängig zu machen, was aber egal ist, weil CPUs wirklich gut darin sind vorherzusagen, welcher Code als nächstes laufen wird. Sie liegen damit deutlich öfters richtig als daneben, so das unter'm Strich spekulative Ausführung viel mehr Performance bringt als sie kostet. Hier im schlechtesten aller Fälle, nämlich dass die CPU sich komplett verschätzt hat, auch das Cache noch mit aufzuräumen, würde diesen Fall nur unwesentlich langsamer und die CPU Fertigung nur unwesentlich teurer machen und hätte auf reguläre Software kaum Einfluss, denn wie gesagt, da liegt die CPU sowieso fast immer richtig.

    Aber Intel hat kein Problem fröhlich weiter neue Modelle auf den Markt zu werfen, die genauso anfällig für Spectre sind wie die bisherigen. Eine Firma mit Gewissen hätte alle Release Pläne sofort gestoppt bis es eine echte Lösung gibt, die sie in alle zukünftigen CPUs verbauen können... aber hätten Firmen noch ein Gewissen, dann gäbe es keinen Abgasskandal, dann müssten wir nicht um den Hambacher Forst bangen und dann würden Firmen kein Pflanzenschutzmittel verkaufen die nachweislich mit Schuld am Bienensterben sind. Warum sollte Intel hier einen Deut besser sein als der Rest der Welt.

    /Mecki

  2. Re: Spectre in Software fixen ist Unfug

    Autor: arthurdont 17.01.19 - 19:25

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Hier im
    > schlechtesten aller Fälle, nämlich dass die CPU sich komplett verschätzt
    > hat, auch das Cache noch mit aufzuräumen, würde diesen Fall nur
    > unwesentlich langsamer und die CPU Fertigung nur unwesentlich teurer machen
    > und hätte auf reguläre Software kaum Einfluss, denn wie gesagt, da liegt
    > die CPU sowieso fast immer richtig.

    "Einfach" den Cache aufräumen, soso. Wie soll das gehen?

  3. Re: Spectre in Software fixen ist Unfug

    Autor: /mecki78 18.01.19 - 11:05

    arthurdont schrieb:
    --------------------------------------------------------------------------------
    > "Einfach" den Cache aufräumen, soso. Wie soll das gehen?

    Genauso wie aktuell die CPU Register und CPU Flags wieder in ihren Ausgangszustand vor der spekulativen Codeausführung versetzt werden und sämtliche anstehende Speicheränderungen durch den spekulativ ausgeführten Code gestoppt werden müssen, sobald die CPU merkt, dass sie falsch spekuliert hat.

    Manche CPUs lösen das für die Register über Shadow Register, also einen zweiten Registersatz auf den der spekulative Code zugreift. Im Normalbetrieb sind beide Sätze gekoppelt, also ein Zugriff auf auf ein Register ändert sowohl den Wert im echten Register als auch im Shadow Register, sobald aber Code spekulativ ausgeführt wird, finden Zugriffe nur noch auf die Shadow Register statt. Stellt die CPU dann fest, dass die Spekulation richtig war, werden die echten Register mit den Shadow Registern getauscht, sprich, die Shadow Register sind jetzt die echten Register, war die Ausführung hingegen falsch, dann wird der Inhalt der Shadow Register einfach verworfen und wieder auf den Wert der echten Register gesetzt. Das geht bei Cache genauso mit einem Shadow Cache, dabei muss nicht einmal das komplette Cache geshadowed werden (das Shadow Cache kann auch deutlich kleiner sein). Ist der Shadow Cache zu klein gewählt, dann wirkt sich das negativ auf die Speicherzugriffsperformance von spekulativen Code aus, hätte aber ansonsten keinerlei Nachteile was die Sicherheit angeht.

    Eine andere Möglichkeit ist Cache Änderungen über eine Pipeline laufen zu lassen und erst wenn die CPU weiß, dass die Spekulation richtig war, schlagen diese auch wirklich auf den Cache durch. So machen das einige CPUs mit Speicheroperationen, wo Schreibzugriffe in einer Pipeline landen und erst dann wirklich auf den Speicher durchschlagen, wenn die CPU weiß, dass sie richtig spekuliert hat, weil ansonsten dürfen diese Änderungen nie im Speicher sichtbar werden und werden in der Pipeline gestoppt und schlagen somit nie auf den echten Speicher durch. Was für RAM geht, das geht für Cache natürlich genauso. Der Vorteil ist, dass das Aufräumen hier am schnellsten geht, der Nachteil ist dass spekulativer Code etwas langsamer wird bei Speicherzugriffen, da er immer zuerst in die Pipeline schauen muss, ob dort Cacheänderungen hängen, die den Speicher betreffen, auf den er zugreifen will bevor er dann in das eigentliche Cache schauen darf. Allerdings lässt sich das auch als O(1) Operation realisieren mit etwas zusätzlichen Speicher.

    Es gibt auch die Möglichkeit eines aktiven Rollbacks, ähnlich wie Journaling Dateisysteme das machen. Hier wird einfach jede Cacheänderung protokolliert und wenn sich herausstellt, dass die spekulative Ausführung falsch war, dann wird ein Rollback durchgeführt. Dabei wird das Protokoll einfach in umgekehrte Reihenfolge abgearbeitet und jede Änderung rückgängig gemacht, so dass das Cache am Ende so aussieht wie es vor beginnt der spekulativen Ausführung aussah. Das bedingt allerdings, dass jeder Kern bzw. auch jeder virtuelle Kern (Hyper Threading) auch ein eigenes 1st Level Cache besitzt und nur nicht nicht spekulative oder bereits gesicherte Codepfade zu Änderungen im 2nd Level Cache führen (letzteres hätte einen leichten Performanceverlust zur Folge, den man aber durch größere 1st Level Caches weitgehend kompensieren kann). Hier limitiert die maximale Protokollgröße (die wiederum durch den dafür vorgesehen Speicher in der CPU begrenzt ist) wie viele Instruktionen eine CPU spekulativ ausführen kann. Droht das Protokoll überlaufen, dann muss die CPU aufhören spekulativ zu arbeiten, weil dann muss sie entscheiden, ob sie jetzt einen Rollback machen muss oder ob alle diese Änderungen so auf den 2nd Level Cache durchschlagen dürfen. Allerdings kann jede heutige CPU nur eine begrenzte Anzahl von Instruktionen spekulativ ausführen und bestimmte Instruktionen verlangen sowieso, dass die CPU aufhört zu spekulieren (z.B. Sync Operationen für Speicher und Locks).

    /Mecki

  4. Spectre in Software fixen ist alternativlos

    Autor: Hello_World 19.01.19 - 02:24

    Unabhängig davon, dass ein Fix in der Hardware wohl zuverlässiger funktionieren wird als in Software, wird man Software-Fixes brauchen, denn die Leute werden nicht anfangen, wegen Spectre ihre funktionierenden Computer wegzuwerfen. Das wäre auch weder ökologisch noch ökonomisch zu verantworten.

    Was Intel angeht, so sind die nicht dem Guten in der Welt verpflichtet, sondern ihren Aktionären. Und wenn die Geschäftsführung jetzt alle Pläne umwerfen würde wegen Spectre, dann wäre das geschäftsschädigend und diese Geschäftsführung deswegen wahrscheinlich schnell weg vom Fenster. Zumal sich das Problem ja nicht auf Intel beschränkt, sondern so ziemlich alle modernen CPUs betrifft.

    Der Vergleich mit VW ist übrigens völlig unpassend. Es macht einen Unterschied, ob jemand bewusst betrügt, um die Behörden zu täuschen, oder ob man beim Versuch, ein besseres Produkt zu schaffen, versehentlich so eine Lücke einbaut. Zumal sich die negativen Konsequenzen für Intel-Kunden sehr in Grenzen halten dürften. Die Sicherheitslücke kommt nur dann überhaupt zum Tragen, wenn der Angreifer Code auf dem angegriffenen System ausführen kann, was schon in vielen Fällen jeden Angriff verhindern dürfte. Nimmt man noch hinzu, dass der Angriff kompliziert auszuführen ist und durch Software-Mitigations zusätzlich erschwert wird, so dürfte die Anzahl der tatsächlich betroffenen Anwender vernachlässigbar gering sein. Soweit ich weiß, gab es “in the wild” bisher keinen nachgewiesenen, erfolgreichen Angriff mit Spectre. Insofern sollte man doch mal die Kirche im Dorf lassen.

  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. ALLPLAN Development Germany GmbH, München
  2. Dievision Agentur für Kommunikation GmbH, Hannover
  3. heroal - Johann Henkenjohann GmbH & Co. KG, Verl
  4. operational services GmbH & Co. KG, Braunschweig, Wolfsburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. ab 30,00€
  2. (aktuell u. a. Xiaomi Mi Note 10 128GB Handy für 499,00€ und HP 25x LED-Monitor für 179,90€)
  3. (u. a. Battlefield V für 21,49€ und Star Wars Jedi: Fallen Order für 52,99€)
  4. (u. a. Quantum Break für 7,99€ und The Flame in the Flood für 2,99€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Star Wars Jedi Fallen Order im Test: Sternenkrieger mit Lichtschwertkrampf
Star Wars Jedi Fallen Order im Test
Sternenkrieger mit Lichtschwertkrampf

Sympathische Hauptfigur plus Star-Wars-Story - da sollte wenig schiefgehen! Nicht ganz: Jedi Fallen Order bietet zwar ein stimmungsvolles Abenteuer. Allerdings kämpfen Sternenkrieger auch mit fragwürdigen Designentscheidungen und verwirrend aufgebauten Umgebungen.
Von Peter Steinlechner

  1. Star Wars Jedi Fallen Order Mächtige und nicht so mächtige Besonderheiten

Indiegames-Rundschau: Der letzte Kampf des alten Cops
Indiegames-Rundschau
Der letzte Kampf des alten Cops

Rollenspiel deluxe mit einem abgehalfterten Polizisten in Disco Elysium, unmöglich-verdrehte Architektur in Manifold Garden und eine höllische Feier in Afterparty: Golem.de stellt die aktuellen Indiegames vor.
Von Rainer Sigl

  1. Indiegames-Rundschau Killer trifft Gans
  2. Indiegames-Rundschau Überleben im Dschungel und tausend Tode im Dunkeln
  3. Indiegames-Rundschau Epische ASCII-Abenteuer und erlebnishungrige Astronauten

Mi Note 10 im Kamera-Test: Der Herausforderer
Mi Note 10 im Kamera-Test
Der Herausforderer

Im ersten Hands on hat Xiaomis Fünf-Kamera-Smartphone Mi Note 10 bereits einen guten ersten Eindruck gemacht, jetzt ist der Vergleich mit anderen Smartphones dran. Dabei zeigt sich, dass es einen neuen, ernstzunehmenden Konkurrenten unter den besten Smartphone-Kameras gibt.
Von Tobias Költzsch

  1. Mi Note 10 im Hands on Fünf Kameras, die sich lohnen
  2. Xiaomi Neues Redmi Note 8T mit Vierfachkamera kostet 200 Euro
  3. Mi Note 10 Xiaomis neues Smartphone mit 108 Megapixeln kostet 550 Euro

  1. Cherry Keys ausprobiert: Cherry stellt Software für Tastatur- und Maus-Remapping vor
    Cherry Keys ausprobiert
    Cherry stellt Software für Tastatur- und Maus-Remapping vor

    Mit Cherry Keys hat der Tastaturhersteller eine einfache Möglichkeit vorgestellt, auf bestimmte Tasten einer Tastatur oder einer Maus neue Funktionen zu programmieren. Nutzer können beispielsweise die F-Tasten mit Systemfunktionen, dem Start von Anwendungen oder Makros belegen.

  2. Linux: Google will Einheits-Kernel für alle Android-Geräte
    Linux
    Google will Einheits-Kernel für alle Android-Geräte

    Bisher nutzen die Android-Geräte verschiedene, speziell angepasste Versionen des Linux-Kernel. Google will stattdessen künftig ein einheitliches Image mit stabiler API für Hardware-Treiber nutzen.

  3. BGH-Urteil: Gericht soll Marktmissbrauch von Adblock Plus überprüfen
    BGH-Urteil
    Gericht soll Marktmissbrauch von Adblock Plus überprüfen

    Missbraucht der Adblock-Plus-Anbieter Eyeo beim Whitelisting von Anzeigen eine marktbeherrschende Stellung? Das Geschäftsmodell von Eyeo könnte nach einem BGH-Urteil nun sehr genau überprüft werden.


  1. 14:47

  2. 14:20

  3. 13:06

  4. 12:40

  5. 12:29

  6. 12:04

  7. 12:00

  8. 11:43