Spectre, Meltdown und Hana

Ende 1967 wurden die Grundlagen gelegt für das, was wir heute „out-of-order execution“ nennen, zu Parallelisierung auf Ebene des Hauptprozessors und damit zu einer besseren Ausnutzung der verfügbaren Kapazitäten und letztlich einem höheren Durchsatz des Gesamtsystems.

Die Sicherheitslücken stellen diese Errungenschaften zwar nicht infrage, die notwendigen Schutzvorkehrungen schränken ihre praktische Nutzung aber zunächst unter gewissen Voraussetzungen ein, vor allem aber sind Auswirkungen auf den Gesamtdurchsatz des Systems möglich.

Ich möchte mich dem Thema in vier Schritten nähern: Erstens: Was sind ­Spectre und Meltdown, und wer ist betroffen? Zweitens: Was können wir tun? Drittens: Was hat Suse bisher getan, und was planen wir in den nächsten Monaten? Und viertens: Warum nennen einige Hersteller keine konkreten Zahlen zum potenziellen Verlust der Systemleistung?

1. Wen betrifft Spectre und Meltdown?

Die Erweiterung der oben besprochenen „out-of-order execution“ führte dazu, dass CPUs heute alternative Programmteile bereits ausführen können, bevor überhaupt klar ist, welche der Optionen ausgeführt werden soll.

Während dieser „spekulativen“ Ausführung kommt es zu Lücken, in denen die üblicherweise vorhandenen Speicherschutz-Mechanismen zwischen Betriebssystem-Kern und Prozessen oder zwischen Prozessen an sich nicht mehr greifen und es somit zu nicht autorisierten Zugriffen kommen kann (siehe Tabelle 1).

Da der Fehler in der Hardware liegt, bekommt die Software-Ebene (also das Betriebssystem und die Anwendungsprogramme) von diesem Zugriff nicht einmal etwas mit. Jede aktuelle leistungsfähige CPU-Familie ist von einem oder mehreren der möglichen Fehler betroffen (siehe Tabelle 2).

2. Was können wir tun?

Die naheliegendste Lösung – Austausch aller CPUs – ist offenkundig weder wirtschaftlich sinnvoll noch praktisch möglich: Alle aktuellen Server-CPUs (auch weiterer Architekturen und Hersteller als die oben genannten) sind betroffen.

Eine vollständige Lösung der Sicherheitsprobleme ist allein in Software (also auf Basis des Betriebssystems oder der Anwendungsschicht) nicht möglich. Es bleibt also nur, die Lücke so gut wie möglich zu „stopfen“ – im Englischen wird man daher auch vornehmlich den Begriff „Mitigation“ finden, nicht den Begriff „Fix“ –, und zwar durch eine Kombination aus Änderungen an der CPU selbst (sofern sie sich durch sogenannten Microcode verändern lassen) als auch durch Änderungen am Betriebssystem.

Diese Änderungen zielen darauf ab, entweder die „Spekulation“ auf CPU-Ebene ganz zu unterbinden oder wenigstens zu verhindern, dass ein anderer Prozess/eine andere Applikation/eine andere virtuelle Maschine auf fremde Daten im Hauptspeicher zugreifen kann (siehe Tabelle 3).

In Tabelle 3 fällt sicherlich die etwas unklare Formulierung „und/oder“ auf. Diese Formulierung deutet auf eine der grundlegenden Herausforderungen in der Kommunikation durch Software- und insbesondere Betriebssystemhersteller wie Suse hin:

Insbesondere für Spectre Variante 2 lässt sich keine einfache und eindeutige Lösung finden, weil je nach CPU-Hersteller, CPU-Typ und CPU-Generation ein anderer Lösungsweg eingeschlagen werden muss. Wir kommen darauf in Abschnitt 4 zurück.

3. Was hat Suse gemacht und was plant Suse?

Anfang Januar hat Suse für alle gegenwärtig unterstützten Suse-Linux-Enterprise-Versionen, selbstverständlich auch Suse Linux Enterprise Server for SAP Applications, ein erstes Patch-Set veröffentlicht, welches das Risiko von Spectre (Variante 1) einschränkt, den Betriebssystemkern für die beschriebenen Ansätze von Spectre (Variante 2) vorbereitet und zumindest für die x86-64-Architektur Meltdown (Variante 3) behebt.

Basierend auf den Rückmeldungen unserer Hardware- Partner und Kunden bieten wir in einer zweiten Welle von Kernel-Updates seit Mitte Februar einen verbesserten Ansatz für Spectre (Variante 2) für die x86-64- Architektur, die sogenannten „Retpolines“, und verbessern die Performance insbesondere dadurch, dass wir Speicherzugriffe feiner überwachen.

Diese Arbeit des stetigen Verbesserns der Sicherheit wie auch der feineren Abstimmung der Zugriffe und Einschränkungen wird sich noch Monate hinziehen; einige Sicherheitsexperten gehen sogar von Jahren aus.

4. Keine konkreten Zahlen?

Jede Applikation, ja sogar die jeweils spezifische Verwendung einer Applikation und die entsprechenden Daten, trägt dazu bei, ob und wie sich die Sicherheits-Patches auswirken (siehe Tabelle 4).

Aus dem bisher Gesagten ergibt sich schon fast von selbst, dass keine allgemeingültige Aussage über die Auswirkungen der Sicherheits-Updates auf den Gesamtdurchsatz eines Systems gemacht werden kann; denn jede Aussage ist nur für eine spezielle Kombination aus folgenden vier Faktoren gültig:

1. Art der Applikation
2. Daten, auf denen die Applikation operiert
3. CPU/Hardware-Architektur
4. CPU-Typ und CPU-Generation, mit eingeschlossen die Verfügbarkeit von Microcode-Updates, insbesondere in Bezug auf Spectre Variante 2 (siehe oben, Abschnitt 2).

Am ehesten lässt sich noch sagen, dass Applikationen, die sehr lange Berechnungen in der CPU ausführen, ohne auf Speicher zuzugreifen, am wenigsten betroffen sind. Ich hoffe, aus diesen Erläuterungen wird ersichtlich, warum es aus Suses Sicht seriöser ist, keine Zahlen über den Einfluss der gegenwärtigen Sicherheits-Updates auf die Performance zu veröffentlichen, selbst wenn ein solcher Einfluss je nach Gegebenheiten unvermeidlich erscheint.

Dennoch raten wir allen Kunden, im Rahmen ihrer Change-Management-Prozesse möglichst zeitnah und regelmäßig Betriebssystem- und Microcode-Updates einzuspielen und so die Risiken dieser neu gefundenen – und doch überraschend alten – Familie von Sicherheitslücken zu minimieren.