Menü
Avatar von /mecki78
  • /mecki78

mehr als 1000 Beiträge seit 03.07.2004

Das Spectre Problem lässt sich nicht per Patch beheben!

Ich finde es lustig, dass hier immer wieder von der falschen Annahme ausgegangen wird, dass es einen echten Patch gibt, den man einfach nur einspielen muss und dann ist Spectre vom Tisch. Man kann Spectre nicht beheben! Das ist rein technisch nicht machbar.

Der Patch bringt der CPU lediglich ein paar neue Befehle (CPU Instruktionen) bei. Wenn (und das ist ein ganz dickes kausales wenn, also im Sinne von "Falls") ein Compiler beim übersetzen von Code eine Stelle erkennt, die man wahrscheinlich mit Spectre angreifen kann und er dann dort diese neuen Befehle verwendet, dann wird der Code zwar dadurch langsamer bei der Ausführung, aber ein Spectre Angriff wird dann unmöglich.

D.h. aber auch...

1) ...der Patch nützt gar nichts bei Bestandscode, weil der ja nie diese neuen Anweisungen benutzt. Bestehende Code ist nach dem Patch genauso angreifbar wie vor dem Patch. Nur wenn man den Code neu baut und mit einem brandneuen Compiler, der bereits das Spectre Problem kennt, nur dann bekommt man Code, der ggf. nicht mehr angreifbar ist.

2) ...der Patch ist nur so gut wie die Compiler Erkennung für Spectre Probleme ist, denn nur wenn der Compiler das Problem erkennt und entsprechend umgeht, nur dann bringt der Patch ja überhaupt etwas. Und hier zeigen aber Tests, dass die Erkennung alles andere als gut ist. Oft werden nur ganz bestimmte, häufig genutzte Muster erkannt, weicht man aber nur ganz leicht vom Muster ab, erkennt der Compiler schon kein Problem mehr, obwohl dieser Code genauso durch Spectre angreifbar ist. Das der Compiler alle meine mit Spectre Angreifbaren stellen im Code findet, dass ist bestenfalls Glück.

Der Spectre Patch ist so wie das Software Update für Diesel VW, es bringt nur ioe bisschen Verbesserung mit, denn der einzig echte Fix wäre in beiden Fällen neue Hardware. Und eine Intel CPU, die grundsätzlich nicht mit Spectre Angreifbar ist, die gibt es nicht, die steht noch nicht einmal als Prototyp irgendwo rum, die muss überhaupt erstmal erfunden werden. Experten gehen davon aus, dass selbst die CPUs, die erst dieses Jahr neu auf den Markt kommen, immer noch mit Spectre Angreifbar sein werden. Lediglich gegen Meltdown werden sie wohl einen Schutz mitbringen. Genau dieser ist aber gar nicht mehr nötig, denn Meltdown lässt sich tatsächlich problemlos in Software beheben, dazu ist nur ein kleiner Umbau am Betriebssystem notwendig (von denen Apps direkt nicht einmal etwas mitbekommen, die müssen daher also auch nicht neu gebaut werden) und diesen Umbau haben bereits alle großen Hersteller vollzogen (egal ob Windows, Linux, macOS, Android oder iOS, die neusten Versionen diese Systeme sind alle gegen Meltdown geschützt).

Aber um Spectre zu verhindern ist ein massiver Umbau der CPU Architektur nötig und das kommt zu spät, so kurzfristig kann man das nicht mehr umbauen, CPUs werden langfristig geplant und entwickelt. Es ist sogar fraglich ob man bis Ende 2019 eine gegen Spectre gesicherte CPU hinbekommt. Man muss künftig das Cache aktiv im CPU Core Managen. Hat bisher die CPU gemacht was auch immer sie wollte und das Cache lief dabei halt so automatisch nebenher (als mehr oder weniger transparenter Puffer zwischen CPU und RAM), ohne z.B. zu wissen ob die CPU gerade etwas spekulativ ausführt oder ob sie sich sicher ist, so spielt das künftig eine Rolle.

Entweder bekommt das Cache in Zukunft so einen Art Rollback verpasst, d.h. das Cache hat eine Art Historie und diese kann zur Not "rückabgewickelt werden", sprich, ich kann damit den Cache Zustand vor einer bestimmten Anzahl von Operationen wieder herstellen, solange halt meine Historie zurück reicht. Vorteil ist, dass das Cache ganz normal arbeiten kann davor und danach, Nachteil ist das so sein Rollback dann besonders teuer ist.

Oder aber die CPU schaltet das Cache in einen Spekulativ-Modus, wann immer sie Operationen auf Verdacht ausführt und vor das echte Cache tritt dann so eine Art "Schattencache", dem man dann irgendwann sagen muss, ob diese Operationen jetzt als gesetzt gelten (erst dann schlagen diese Änderungen wirklich auf das darunterliegenden Cache durch) oder aber verworfen wurden (dann werden diese Änderungen auch verworfen und tauchen somit nie im echten Cache auf). Vorteil ist, dass es egal ist ob die Vorhersage falsch war oder nicht, die Abwicklung des Caches ist in beiden Fällen in etwa gleich teuer, Nachteil ist, dass der Cache in zwei alternativen Modi arbeiten können muss.

Beide Lösungen verlangen auf jeden Fall nach zusätzlichen Cachespeicher und die Größe des zusätzlichen Cachespeichers limitiert dabei wie viel eine CPU spekulativ ausführen kann, denn wenn der zusätzliche Speicher aufgebraucht ist, dann muss die CPU entscheiden, ob sie jetzt diesen Spekulativen Code Pfad nicht-Spekulativ machen oder ihn verwerfen will. Kann sie das in dem Moment nicht sagen, dann muss sie solange warten bis sie es kann und kann solange nichts weiter spekulativ ausführen, da sie sonst die Cacheänderungen nicht mehr Rückgängig machen könnte. Wählt man den Speicher aber groß genug, dann wird dieser Fall nie eintreten. Und was die Performance angeht, die Sprungvorhersagen von CPUs sind zu weit über 80% richtig (je nach Code sogar weit über 90%), d.h. der "Aufräumfall" ist sowieso die Ausnahme und nicht die Regel. Ansonsten ist das Aufräumen auch jetzt schon sehr teuer in der CPU (die dort ja auch alles mögliche Rückabwickeln muss), so dass sich das neue Cache Handling kaum spürbar auf die Gesamtleistung auswirken würde (ganz im Gegenteil zu den ganzen aktuellen Patches!)

/Mecki

Bewerten
- +
Anzeige