Wie sich Spectre und Meltdown auf künftige CPU-Designs auswirken
Hardware- und Software-Entwickler diskutierten auf dem Symposium Hot Chips, wie sich Sicherheitslücken in Prozessoren künftig vermeiden lassen.
Seitenkanal-Attacken werden bereits seit den 1970er-Jahren gefahren – mit diesen Worten hat Stanford-Uni-Präsident John Hennessy auf dem Symposium Hot Chips in Cupertino die Prozessor-Sicherheitslücken Spectre und Meltdown historisch eingeordnet. Allerdings gebe es einen wichtigen Unterschied: Früher sei Software attackiert worden, nun sei direkt die darunterliegende Hardware betroffen.
Hardware-Löcher ließen sich zwar per Software schließen, doch dies sei aufwändig. Hinzu komme, dass die Performance leidet: Um die Lücken zu umgehen, müssen entweder zusätzliche Abfragen eingebaut oder die spekulative Ausführung von Code unterbunden werden, meinte Hennessy.
Paul Turner von Google Project Zero warnte davor, Spekulation grundsätzlich zu verteufeln. Allerdings sei bislang unter einer falschen Prämisse gearbeitet worden – nämlich der, dass spekulative Codeausführung bei falscher Vorhersage keine Spuren hinterlasse, weil alles verworfen werde. Letzteres gilt nur hinsichtlich der Programmlogik; sprich, es treten keine Rechenfehler auf. Die Zustände im Prozessor sind danach sehr wohl andere als vorher, was Seitenkanal-Attacken gnadenlos ausnutzen.
Hinzu kommt, dass sich Seitenkanal-Attacken immer leichter durchführen lassen: Dank stetig größerer werdender Arbeitsspeicher muss man nicht mehr mit Fenstern arbeiten oder Speicherbereiche umblenden. Alle Daten liegen stattdessen fein säuberlich nebeneinander und direkt adressierbar im Speicher.
Ein Knackpunkt: Während Software und Betriebssystem sehr genau wissen, was wohin gehört und wer worauf Zugriff hat, kümmert sich die Hardware nicht darum: Sie führt aus, was ihr gerade vorliegt und sortiert die Befehle dabei sogar noch nach Belieben um. Künftige Prozessoren müssten also eigentlich bekannte Beschränkungen umzusetzen; und wo noch keine sind, müssten bei Bedarf welche hinzugefügt werden.
Redet miteinander!
Jon Masters von Red Hat stieß in dasselbe Horn und appellierte an Hardware- und Software-Entwickler, nicht mehr wie bislang in den Kategorien "wir" und "die anderen" zu denken. Nahezu alle Performance-Steigerungen von Prozessoren resultieren schließlich aus Methoden wie Out-of-Order-Umsortierung, spekulativer Ausführung und anderen aggressiven Optimierungen. Mit einer sequenziellen Abarbeitung, wie sie ein Code-Kompilat vorsieht, hat das nur noch wenig gemein.
Programmierern ist wiederum häufig nicht klar, wo die Limitierungen sind – Microcode-Updates sind enge Grenzen gesetzt – und sehen Hardware mitunter als das Übel an, das zur Ausführung ihrer Programme nötig ist. Die meisten Anwendungen werden zudem in Hochsprachen geschrieben; hardwarenahe Programmierung à la Assembler ist fast schon verpönt.
Wie Mark Hill von der Universität Wisconsin ausführte, hat die Trennung von Hardware und Software in der Vergangenheit für eine praktische Modularität gesorgt: Anwendungen wurden für einen bestimmten Befehlssatz geschrieben und Prozessorentwickler kümmerten sich darum, den Befehlssatz möglichst schnell auszuführen. Somit waren auf beiden Seiten Fortschritte unabhängig von der jeweils anderen Seite möglich.
Langfristig sieht auch Hill keine andere Möglichkeit als eine neue Computerarchitektur, bei der Hardware und Software wieder näherer aneinanderrücken. Sicherheitslücken sind dabei aber nur ein Aspekt: Da das Moorsche Gesetz auf absehbare Zeit nicht mehr gelten wird, sind künftige größere Performancesteigerungen wohl nur noch durch gemeinsame Hard- und Software-Entwicklung möglich. Entwickler von KI-Beschleunigern merken dies schon jetzt.
Neue Konzepte
Bis sich dieses neue Computermodell durchgesetzt hat, bleibt laut Hill nichts anderes übrig als entdeckte Sicherheitslücken nach und nach zu schließen. Er geht allerdings davon aus, dass es zwischenzeitlich zu Ab- und Aufspaltungen kommen wird.
Je nach Bedarf könnten künftige Prozessoren beispielsweise in einem schnellen oder einem sicheren Modus betrieben werden; in letzterem würde dann weniger stark spekuliert und gecacht. Ebenso sei es denkbar, dass künftige Prozessoren verschiedene Kerne mit unterschiedlichen Sicherheitscharakteristiken vereinen, ähnlich dem bigLITTLE-Konzept moderner ARM-Prozessoren. Schließlich erwartet Hill neue Geschäftsmodelle von Cloud-Betreibern: Wer aus Sicherheitsgründen nicht will, dass seine VM mit zig anderen auf einem Server läuft, bekommt gegen Aufpreis exklusive Server.
Hill geht davon aus, dass die akademische Welt in den nächsten Jahren neue Sicherheitskonzepte an RISC-V-Prozessoren ausprobieren wird: Die gesamte Architektur ist Open Source, was Veröffentlichungen begünstigt. Es bleibt allerdings abzuwarten, ob sich diese Konzepte dann in kommerziellen Prozessoren von AMD, Intel, Qualcomm & Co. umsetzen lassen, da diese hinsichtlich Performance wie Komplexität in ganz anderen Ligen spielen.
Wird alles noch viel schlimmer?
So unangenehm Prozessor-Sicherheitslücken wie Spectre, Meltdown, ForeShadow & Co. auch sind: Bislang beschränken sich ihre Auswirkungen allesamt darauf, dass Daten entweichen, die nicht entweichen sollen. Es sind allerdings auch schlimmere Angriffe denkbar, die entweder Daten im Speicher unbemerkt manipulieren oder – nochmals etliche Komplexitätslevel höher – sogar Code zur Ausführung einschleusen.
Auf Nachfrage gaben die Experten zu Protokoll, dass diese theoretischen Szenarien zwar diskutiert werden, aber glücklicherweise noch nicht praktisch nachgewiesen wurden. Da bleibt nur zu hoffen, dass das auch so bleibt … (mue)
