Mikroarchitektonische Sicherheit von AWS Firecracker VMM: Hintergrund

Linktabelle

• Zusammenfassung und Einleitung
• Hintergrund
• Bedrohungsmodelle
• Analyse der Eindämmungssysteme von Feuerwerkskörpern
• Analyse von mikroarchitektonischen Angriffen und Abwehrmaßnahmen in Firecracker-Mikro-VMs
• Schlussfolgerung, Danksagungen und Referenzen

2. HINTERGRUND

2.1 KVM

Die Linux kernel-based virtual machine (KVM) [29] bietet eine Abstraktion der hardwaregestützten Virtualisierungsfunktionen wie Intel VT-x oder AMD-V, die in modernen CPUs verfügbar sind. Um eine nahezu native Ausführung zu unterstützen, wird dem Linux-Kernel zusätzlich zum bestehenden Kernelmodus und Benutzermodus ein Gastmodus hinzugefügt. Im Linux-Gastmodus versetzt KVM die Hardware in den Hardwarevirtualisierungsmodus, der die Berechtigungen von Ring 0 und Ring 3 repliziert.[1]

Bei KVM wird die I/O-Virtualisierung größtenteils im Benutzerbereich durch den Prozess durchgeführt, der die VM erstellt hat, der als VMM oder Hypervisor bezeichnet wird. Im Gegensatz zu früheren Hypervisoren, die normalerweise einen separaten Hypervisor-Prozess erforderten [41]. Ein KVM-Hypervisor stellt jedem VM-Gast seinen eigenen Speicherbereich zur Verfügung, der von dem Speicherbereich des Prozesses getrennt ist, der den Gast erstellt hat. Dies gilt sowohl für Gäste, die aus dem Kernelbereich als auch aus dem Benutzerbereich erstellt werden. Jede VM wird einem Prozess auf dem Linux-Host zugeordnet und jede dem Gast zugewiesene virtuelle CPU ist ein Thread in diesem Host-Prozess. Der Hypervisor-Prozess im Benutzerbereich der VM führt nur dann Systemaufrufe an KVM durch, wenn eine privilegierte Ausführung erforderlich ist. Dadurch werden Kontextwechsel minimiert und die Angriffsfläche von der VM zum Kernel reduziert. Neben Leistungsverbesserungen bei allen möglichen Anwendungen hat dieses Design die Entwicklung von leichtgewichtigen Hypervisoren ermöglicht, die besonders nützlich sind, um einzelne Programme in einer Sandbox auszuführen und Cloud-Umgebungen zu unterstützen, in denen viele VMs gleichzeitig ausgeführt werden.

2.2 Serverloses Cloud Computing

Ein zunehmend beliebtes Modell für Cloud-Computing ist Serverless Computing, bei dem der CSP die Skalierbarkeit und Verfügbarkeit der Server verwaltet, auf denen der Code des Benutzers ausgeführt wird. Eine Implementierung von Serverless Computing wird Function-as-a-Service (FaaS) genannt. In diesem Modell definiert ein Cloud-Benutzer Funktionen, die bei Bedarf über die Anwendungsprogrammierschnittstelle (API) des Dienstanbieters aufgerufen werden (daher der Name „Function-as-a-Service“), und der CSP verwaltet die Ressourcenzuweisung auf dem Server, der die Funktion des Benutzers ausführt (daher der Name „Serverless Computing“ – der Benutzer übernimmt keine Serververwaltung). Ähnlich verhält es sich mit Container-as-a-Service (CaaS) Computing, bei dem Container, portable Runtime-Pakete, bei Bedarf ausgeführt werden. Die zentralisierte Serververwaltung von FaaS und CaaS ist sowohl für CSPs als auch für Benutzer wirtschaftlich attraktiv. Der CSP kann die Arbeitslasten seiner Benutzer nach Belieben verwalten, die Betriebskosten so gering wie möglich halten und flexible Preise implementieren, bei denen Benutzer für die von ihnen genutzte Ausführungszeit zahlen. Der Benutzer muss sich nicht um die Gestaltung oder Verwaltung der Serverinfrastruktur kümmern und kann so die Entwicklungskosten senken und die Wartungskosten zu einem relativ geringen und vorhersehbaren Preis an den CSP auslagern.

2.3 MicroVMs und AWS Firecracker

FaaS- und CaaS-Anbieter verwenden eine Vielzahl von Systemen, um laufende Funktionen und Container zu verwalten. Containersysteme wie Docker, Podman und LXD bieten eine bequeme und einfache Möglichkeit, Sandbox-Anwendungen in jeder Umgebung zu verpacken und auszuführen. Im Vergleich zu den virtuellen Maschinen, die für viele traditionellere Formen des Cloud-Computing verwendet werden, bieten Container jedoch weniger Isolation und daher weniger Sicherheit. In den letzten Jahren haben große CSPs Mikro-VMs eingeführt, die traditionelle Container mit leichter Virtualisierung für zusätzliche Sicherheit unterstützen. [1, 55] Die Effizienz der Hardware-Virtualisierung mit KVM und das leichte Design von Mikro-VMs bedeuten, dass Code in virtualisierten, containerisierten oder containerähnlichen Systemen fast so schnell wie nicht virtualisierter Code und mit vergleichbarem Overhead wie ein traditioneller Container ausgeführt werden kann.

Firecracker [1] ist eine von AWS entwickelte MicroVM, die jede der AWS Lambda FaaS- und AWS Fargate CaaS-Workloads in einer separaten VM isoliert. Es unterstützt nur Linux-Gäste auf x86- oder ARM Linux-KVM-Hosts und bietet eine begrenzte Anzahl von Geräten, die Gastsystemen zur Verfügung stehen. Diese Einschränkungen ermöglichen es Firecracker, in Bezug auf die Größe seiner Codebasis und den Speicheraufwand für eine laufende VM sehr leicht zu sein und sich sehr schnell starten oder herunterfahren zu lassen. Darüber hinaus verringert die Verwendung von KVM die Anforderungen an Firecracker, da einige Virtualisierungsfunktionen durch Kernel-Systemaufrufe ausgeführt werden und das Host-Betriebssystem VMs als Standardprozesse verwaltet. Aufgrund seiner kleinen, in Rust geschriebenen Codebasis gilt Firecracker als sehr sicher, auch wenn in früheren Versionen Sicherheitslücken festgestellt wurden (siehe CVE-2019-18960). Interessanterweise erklärt das Firecracker-Whitepaper mikroarchitektonische Angriffe zum Anwendungsbereich seines Angreifermodells [1], es fehlt jedoch eine detaillierte Sicherheitsanalyse oder spezielle Gegenmaßnahmen gegen mikroarchitektonische Angriffe, die über allgemeine Empfehlungen zur sicheren Systemkonfiguration für den Gast- und Host-Kernel hinausgehen. Die Firecracker-Dokumentation bietet Systemsicherheitsempfehlungen [8], die eine spezifische Liste von Gegenmaßnahmen enthalten, die wir in Abschnitt 2.6.1 behandeln.

2.4 Meltdown und MDS

Im Jahr 2018 zeigte der Meltdown-Angriff [32], dass spekulativ abgerufene Daten über Sicherheitsgrenzen hinweg exfiltriert werden konnten, indem man sie in einen Cache-Seitenkanal kodierte. Dies führte bald zu einer ganzen Klasse ähnlicher Angriffe, die als Microarchitectural Data Sampling (MDS) bekannt sind, darunter Fallout [14], Rogue In-flight Data Load (RIDL) [50], TSX Asynchronous Abort (TAA) [50] und Zombieload [46]. Diese Angriffe folgen alle dem gleichen allgemeinen Muster, um spekulative Ausführung auszunutzen:

(1) Das Opfer führt ein Programm aus, das geheime Daten verarbeitet, und die geheimen Daten durchlaufen einen Cache oder CPU-Puffer.

(2) Der Angreifer führt einen gezielt ausgewählten Befehl aus, der die CPU fälschlicherweise vermuten lässt, dass die geheimen Daten benötigt werden. Die CPU leitet die geheimen Daten an den Befehl des Angreifers weiter.

(3) Die weitergeleiteten geheimen Daten werden als Index für einen Speicherlesevorgang in einem Array verwendet, auf das der Angreifer Zugriff hat, wodurch eine bestimmte Zeile dieses Arrays zwischengespeichert wird.

(4) Die CPU schließt die Datenprüfung ab und entscheidet, dass die geheimen Daten falsch weitergeleitet wurden. Sie setzt den Ausführungszustand auf den Zustand vor der Weiterleitung zurück, der Cache-Zustand wird jedoch nicht zurückgesetzt. (5) Der Angreifer prüft das gesamte Array, um zu sehen, welche Zeile zwischengespeichert wurde. Der Index dieser Zeile ist der Wert der geheimen Daten.

Die ursprüngliche Meltdown-Sicherheitslücke zielte auf die Cache-Weiterleitung ab und ermöglichte auf diese Weise die Datenextraktion aus jeder im Cache vorhandenen Speicheradresse. MDS-Angriffe zielen auf kleinere und spezifischere Puffer in der On-Core-Mikroarchitektur ab und bilden daher eine verwandte, aber eigenständige Angriffsklasse, die auf deutlich andere Weise abgeschwächt wird. Während Meltdown auf den Hauptspeicher abzielt, der relativ selten aktualisiert und von allen Kernen, Threads und Prozessen gemeinsam genutzt wird, zielen MDS-Angriffe eher auf Puffer ab, die lokal für Kerne sind (obwohl sie manchmal von mehreren Threads gemeinsam genutzt werden) und während der Ausführung häufiger aktualisiert werden.

2.4.1 Grundlegende MDS-Varianten . Abbildung 1 zeigt die wichtigsten bekannten MDS-Angriffspfade auf Intel-CPUs und die Namen, die Intel und die Forscher, die sie gemeldet haben, den verschiedenen Varianten gegeben haben. Im weitesten Sinne kategorisiert Intel MDS-Schwachstellen in seinen CPUs nach dem spezifischen Puffer, aus dem Daten spekulativ weitergeleitet werden, da diese Puffer in der Regel für eine Reihe verschiedener Operationen verwendet werden. RIDL-MDS-Schwachstellen können als Microarchitectural Load Port Data Sampling (MLPDS) für Varianten kategorisiert werden, die aus dem Ladeport der CPU auslaufen, und Microarchitectural Fill Buffer Data Sampling (MFBDS) für Varianten, die aus dem LFB der CPU auslaufen. In ähnlicher Weise nennt Intel die Fallout-Schwachstelle Microarchitectural Store Buffer Data Sampling (MSBDS), da es sich um ein Leck aus dem Speicherpuffer handelt. Vector Register Sampling (VRS) ist eine Variante von MSBDS, die auf Daten abzielt, die von Vektoroperationen verarbeitet werden, während sie durch den Speicherpuffer laufen. Der VERW-Bypass nutzt einen Fehler in der

Mikrocode-Fixes für MFBDS, die veraltete und möglicherweise geheime Daten in den LFB laden. Der grundlegende Mechanismus des Lecks ist derselbe, und die VERW-Umgehung kann als Sonderfall von MFBDS betrachtet werden. L1 Data Eviction Sampling (L1DES) ist ein weiterer Sonderfall von MFBDS, bei dem Daten, die aus dem L1-Datencache verdrängt werden, durch den LFB laufen und für einen MDS-Angriff anfällig werden. Insbesondere ist L1DES ein Fall, in dem der Angreifer tatsächlich die Anwesenheit der geheimen Daten in der CPU auslösen kann (indem er sie verdrängt), während andere MDS-Angriffe direkt darauf angewiesen sind, dass der Opferprozess auf die geheimen Daten zugreift, um sie in den richtigen CPU-Puffer zu bringen.

2.4.2 Medusa. Medusa [37] ist eine Kategorie von MDS-Angriffen, die von Intel als MLPDS-Varianten klassifiziert werden [25]. Die Medusa-Schwachstellen nutzen die unvollkommenen Mustervergleichsalgorithmen aus, die verwendet werden, um Speicher im Write-Combine-Puffer (WC) von Intel-Prozessoren spekulativ zu kombinieren. Intel betrachtet den WC-Puffer als Teil des Ladeports und kategorisiert diese Schwachstelle daher als einen Fall von MLPDS. Es sind drei Medusa-Varianten bekannt, die jeweils eine andere Funktion des Write-Combine-Puffers ausnutzen, um ein spekulatives Leck zu verursachen:

Cache-Indizierung: Eine fehlerhafte Ladung wird spekulativ mit einer früheren Ladung mit einem passenden Cache-Zeilen-Offset kombiniert.

Nicht ausgerichtete Store-to-Load-Weiterleitung: Ein gültiger Store, gefolgt von einem abhängigen Load, der einen Speicherfehler aufgrund einer Fehlausrichtung auslöst, führt dazu, dass zufällige Daten vom WC weitergeleitet werden.

Shadow REP MOV : Ein fehlerhafter REP MOV-Befehl, gefolgt von einer abhängigen Ladung, gibt die Daten eines anderen REP MOV preis.

2.4.3 TSX Asynchronous Abort. Die Hardware-Sicherheitslücke TSX Asynchronous Abort (TAA) [24] bietet einen anderen Spekulationsmechanismus für die Durchführung eines MDS-Angriffs. Während Standard-MDS-Angriffe mit einer standardmäßigen spekulativen Ausführung auf eingeschränkte Daten zugreifen, verwendet TAA eine atomare Speichertransaktion, wie sie von TSX implementiert wird. Wenn eine atomare Speichertransaktion auf einen asynchronen Abbruch stößt, beispielsweise weil ein anderer Prozess eine für die Verwendung durch die Transaktion markierte Cache-Zeile liest oder weil bei der Transaktion ein Fehler auftritt, werden alle Vorgänge in der Transaktion auf den Architekturzustand vor dem Beginn der Transaktion zurückgesetzt. Während dieses Rollbacks können jedoch Anweisungen innerhalb der Transaktion, deren Ausführung bereits begonnen hat, die spekulative Ausführung fortsetzen, wie in den Schritten (2) und (3) anderer MDS-Angriffe. TAA betrifft alle Intel-Prozessoren, die TSX unterstützen, und im Fall bestimmter neuerer Prozessoren, die nicht von anderen MDS-Angriffen betroffen sind, müssen MDS-Abwehrmaßnahmen oder TAA-spezifische Abwehrmaßnahmen (wie das Deaktivieren von TSX) in die Software implementiert werden, um vor TAA zu schützen [24].

2.4.4 Schadensbegrenzung. Obwohl Schwachstellen der Klassen Meltdown und MDS mikroarchitektonische Operationen auf niedriger Ebene ausnutzen , können sie auf den anfälligsten CPUs durch Mikrocode-Firmware-Patches abgeschwächt werden.

Seitentabellenisolation. Historisch wurden Kernel-Seitentabellen in Seitentabellen von Prozessen auf Benutzerebene aufgenommen, damit ein Prozess auf Benutzerebene mit minimalem Aufwand einen Systemaufruf an den Kernel durchführen konnte. Seitentabellenisolation (erstmals von Gruss et al. als KAISER [19] vorgeschlagen) bildet nur den absolut notwendigen Kernelspeicher in der Benutzerseitentabelle ab und führt eine zweite Seitentabelle ein, auf die nur der Kernel zugreifen kann. Da der Benutzerprozess nicht auf die Kernel-Seitentabelle zugreifen kann, werden Zugriffe auf den gesamten Kernelspeicher außer einem kleinen und speziell ausgewählten Teil davon gestoppt, bevor sie die Caches auf niedrigerer Ebene erreichen, wo ein Meltdown-Angriff beginnt.

Pufferüberschreibung. MDS-Angriffe, die auf CPU-Puffer im Kern abzielen, erfordern eine niedrigere und gezieltere Verteidigung. Intel hat ein Mikrocode-Update eingeführt, das anfällige Puffer überschreibt, wenn der First-Level-Data-Cache (L1d) (ein häufiges Ziel von Cache-Timing-Sidechannel-Angriffen) geleert oder die VERW-Anweisung ausgeführt wird [25]. Der Kernel kann sich dann vor MDS-Angriffen schützen, indem er beim Wechsel zu einem nicht vertrauenswürdigen Prozess eine Pufferüberschreibung auslöst.

Die Pufferüberschreibungsminderung zielt auf MDS-Angriffe an ihrer Quelle ab, ist aber, gelinde gesagt, unvollkommen. Prozesse bleiben anfällig für Angriffe von gleichzeitig laufenden Threads auf demselben Kern, wenn SMT aktiviert ist (da beide Threads anfällige Puffer gemeinsam nutzen, ohne dass sich der aktive Prozess auf einem der Threads tatsächlich ändert). Darüber hinaus stellte das RIDL-Team kurz nach dem ursprünglichen Pufferüberschreibungs-Mikrocode-Update fest, dass auf einigen Skylake-CPUs Puffer mit veralteten und möglicherweise sensiblen Daten überschrieben wurden [50] und auch bei aktivierten Minderungen und deaktiviertem SMT anfällig blieben. Wieder andere Prozessoren sind anfällig für TAA-, aber nicht für Nicht-TAA-MDS-Angriffe und haben kein Pufferüberschreibungs-Mikrocode-Update erhalten. Daher muss TSX vollständig deaktiviert werden, um MDS-Angriffe zu verhindern [20, 24].

2.5 Gespenst

Im Jahr 2018 berichteten Jan Horn und Paul Kocher [30] unabhängig voneinander über die ersten Spectre-Varianten. Seitdem wurden viele verschiedene Spectre-Varianten [22, 30, 31, 33] und Untervarianten [10, 13, 16, 28, 52] entdeckt. Spectre-Angriffe zwingen die CPU dazu, spekulativ auf Speicher zuzugreifen, der architektonisch nicht zugänglich ist, und die Daten in den architektonischen Zustand zu übertragen. Daher bestehen alle Spectre-Varianten aus drei Komponenten [27]:

Die erste Komponente ist das Spectre-Gadget, das spekulativ ausgeführt wird. Spectre-Varianten werden normalerweise nach der Quelle der Fehlvorhersage unterschieden, die sie ausnutzen. Das Ergebnis eines bedingten direkten Sprungs wird beispielsweise durch die Pattern History Table (PHT) vorhergesagt. Fehlvorhersagen der PHT können zu einer spekulativen Umgehung der Grenzwertprüfung für Lade- und Speicheranweisungen führen [13, 28, 30]. Das Sprungziel eines indirekten Sprungs wird durch den Branch Target Buffer (BTB) vorhergesagt. Wenn ein Angreifer das Ergebnis einer Fehlvorhersage des BTB beeinflussen kann, sind spekulative Angriffe mit Return-Oriented Programming möglich [10, 13, 16, 30]. Gleiches gilt für Vorhersagen, die vom Return Stack Buffer (RSB) bereitgestellt werden, der Rücksprungadressen während der Ausführung von Rücksprunganweisungen vorhersagt [13, 31, 33]. Jüngste Ergebnisse haben gezeigt, dass einige moderne CPUs den BTB für ihre Rücksprungadressenvorhersagen verwenden, wenn der RSB unterläuft [52]. Eine weitere Quelle von Spectre-Angriffen ist die Vorhersage von Abhängigkeiten zwischen Store und Load. Wenn fälschlicherweise vorhergesagt wird, dass ein Load nicht von einem vorherigen Store abhängt, wird er spekulativ auf veralteten Daten ausgeführt, was zu einem spekulativen Store-Bypass führen kann [22]. Alle diese Gadgets sind standardmäßig nicht ausnutzbar, sondern hängen von den beiden anderen, jetzt besprochenen Komponenten ab.

Die zweite Komponente ist, wie ein Angreifer die Eingaben in die oben genannten Gadgets steuert. Angreifer können die Eingabewerte des Gadgets möglicherweise direkt durch Benutzereingaben, Dateiinhalte, Netzwerkpakete oder andere Architekturmechanismen definieren. Andererseits können Angreifer möglicherweise Daten vorübergehend in das Gadget einspeisen, indem sie Ladewerte [12] oder Gleitkommawerte [42] einspeisen. Angreifer können die Gadget-Eingaben erfolgreich steuern, wenn sie beeinflussen können, auf welche Daten oder Anweisungen während des Spekulationsfensters zugegriffen oder welche ausgeführt werden.

Die dritte Komponente ist der verdeckte Kanal, der verwendet wird, um den spekulativen mikroarchitektonischen Zustand in einen architektonischen Zustand zu überführen und so die spekulativ abgerufenen Daten in eine persistente Umgebung zu exfiltrieren. Cache-verdeckte Kanäle [39, 40, 54] sind anwendbar, wenn der Opfercode einen flüchtigen Speicherzugriff abhängig von spekulativ abgerufenen geheimen Daten durchführt [30]. Wenn auf ein Geheimnis spekulativ zugegriffen und es in einen On-Core-Puffer geladen wird, kann sich ein Angreifer auf einen MDS-basierten Kanal [14, 46, 50] verlassen, um die exfiltrierten Daten flüchtig an den Angreifer-Thread zu übertragen, wo die Daten z. B. über einen Cache-verdeckten Kanal in den architektonischen Zustand übertragen werden. Und nicht zuletzt kann der Angreifer das Geheimnis erfahren, indem er Port-Konflikte beobachtet [3, 11, 18, 43, 44], wenn das Opfer Code abhängig von geheimen Daten ausführt.

2.5.1 Schadensbegrenzung. Es wurden viele Gegenmaßnahmen entwickelt, um die verschiedenen Spectre-Varianten abzuschwächen. Eine bestimmte Spectre-Variante wird effektiv deaktiviert, wenn eine der drei erforderlichen Komponenten entfernt wird. Ein Angreifer ohne Kontrolle über die Eingaben in Spectre-Geräte wird wahrscheinlich keinen erfolgreichen Angriff starten. Dasselbe gilt, wenn ein verdeckter Kanal zur Umwandlung des spekulativen Zustands in einen architektonischen Zustand nicht verfügbar ist. Da dies jedoch normalerweise schwer zu garantieren ist, konzentrieren sich die Spectre-Gegenmaßnahmen hauptsächlich darauf, Fehlvorhersagen zu verhindern. Das Einfügen von lfence-Anweisungen vor kritischen Codeabschnitten deaktiviert die spekulative Ausführung über diesen Punkt hinaus und kann daher als allgemeine Gegenmaßnahme verwendet werden. Aufgrund des hohen Leistungsaufwands wurden jedoch spezifischere Gegenmaßnahmen entwickelt. Zu den Spectre-BTB-Gegenmaßnahmen gehören Retpoline [48] und Mikrocode-Updates wie IBRS, STIBP oder IBPB [23]. Spectre-RSB und Spectre-BTB-via-RSB können abgeschwächt werden, indem der RSB mit Werten gefüllt wird, um bösartige Einträge zu überschreiben und einen Unterlauf des RSB zu verhindern, oder indem IBRS-Mikrocode-Updates installiert werden. Spectre-STL kann durch das SSBD-Mikrocode-Update abgeschwächt werden [23]. Eine weitere drastische Möglichkeit, einen Angreifer daran zu hindern, gemeinsam genutzte Verzweigungsvorhersagepuffer zu manipulieren, besteht darin, SMT zu deaktivieren. Durch das Deaktivieren von SMT werden die Hardwareressourcen für die Verzweigungsvorhersage effektiv zwischen gleichzeitigen Mandanten aufgeteilt, was jedoch zu einem erheblichen Leistungsverlust führt.

2.6 Das Isolationsmodell von AWS

Firecracker wurde speziell für Serverless- und Container-Anwendungen entwickelt [1] und wird derzeit von AWS‘ Fargate CaaS und Lambda FaaS verwendet. In beiden dieser Servicemodelle ist Firecracker das primäre Isolationssystem, das jede einzelne Fargate-Aufgabe oder jedes Lambda-Ereignis unterstützt. Beide dieser Servicemodelle sind auch für die Ausführung einer sehr großen Anzahl relativ kleiner und kurzlebiger Aufgaben ausgelegt. AWS schlüsselt die Designanforderungen für das Isolationssystem, aus dem schließlich Firecracker wurde, wie folgt auf:

Isolierung : Mehrere Funktionen müssen sicher auf derselben Hardware ausgeführt werden können und vor Rechteausweitung, Informationsoffenlegung, verdeckten Kanälen und anderen Risiken geschützt sein.

Overhead und Dichte: Es muss möglich sein, Tausende von Funktionen mit minimalem Aufwand auf einer einzigen Maschine auszuführen.

Leistung: Die Leistung der Funktionen muss der nativen Ausführung ähnlich sein. Die Leistung muss außerdem konsistent und vom Verhalten benachbarter Funktionen auf derselben Hardware isoliert sein.

Kompatibilität : Lambda ermöglicht es Funktionen, beliebige Linux-Binärdateien und -Bibliotheken zu enthalten. Diese müssen ohne Codeänderungen oder Neukompilierung unterstützt werden.

Schnelles Umschalten: Es muss möglich sein, neue Funktionen schnell zu starten und alte Funktionen schnell zu bereinigen.

Soft Allocation: Es muss möglich sein, CPU, Speicher und andere Ressourcen übermäßig zu beanspruchen, wobei jede Funktion nur die Ressourcen verbraucht, die sie benötigt, und nicht die Ressourcen, auf die sie Anspruch hat. [1]

Wir sind besonders an der Isolationsanforderung interessiert und betonen, dass mikroarchitektonische Angriffe als in den Geltungsbereich des Firecracker-Bedrohungsmodells fallend erklärt werden. Die „Design“-Seite im öffentlichen Firecracker-Git-Repository von AWS erläutert das Isolationsmodell und bietet ein nützliches Diagramm, das wir in Abbildung 2 reproduzieren. Dieses Diagramm bezieht sich hauptsächlich auf den Schutz vor Privilegienausweitung. Die äußerste Schutzschicht ist der Jailer, der Containerisolationstechniken verwendet, um den Zugriff des Firecrackers auf den Host-Kernel zu beschränken, während der VMM und andere Verwaltungskomponenten ausgeführt werden.

von Firecracker als Threads eines einzelnen Prozesses im Host-Benutzerbereich. Innerhalb des Firecracker-Prozesses wird die Arbeitslast des Benutzers auf anderen Threads ausgeführt. Die Arbeitslast-Threads führen das Gastbetriebssystem der virtuellen Maschine und alle im Gast laufenden Programme aus. Das Ausführen des Codes des Benutzers im Gast der virtuellen Maschine beschränkt seine direkte Interaktion mit dem Host auf vorab vereinbarte Interaktionen mit KVM und bestimmten Teilen der Firecracker-Verwaltungsthreads. Aus der Sicht des Host-Kernels werden also das VMM und die VM einschließlich des Codes des Benutzers im selben Prozess ausgeführt. Aus diesem Grund gibt AWS an, dass sich jede VM in einem einzelnen Prozess befindet. Da die VM jedoch über Hardwarevirtualisierungstechniken isoliert ist, arbeiten der Code des Benutzers, der Gastkernel und das VMM in getrennten Adressräumen. Daher kann der Code des Gastes weder architektonisch noch vorübergehend auf Speicheradressen des VMM oder des Gastkernels zugreifen, da diese nicht im Adressraum des Gastes abgebildet sind. Die verbleibende mikroarchitektonische Angriffsfläche beschränkt sich auf MDS-Angriffe, bei denen unter Missachtung der Adressraumgrenzen Informationen aus den internen Puffern der CPU verloren gehen, sowie auf Spectre-Angriffe, bei denen ein Angreifer die Verzweigungsvorhersage anderer Prozesse manipuliert, um selbst Informationen preiszugeben.

Nicht in Abbildung 2 dargestellt, aber ebenso wichtig für das Bedrohungsmodell von AWS ist die Isolierung von Funktionen voneinander bei gemeinsam genutzter Hardware, insbesondere im Hinblick auf die Anforderung der Soft-Allokation . Abgesehen davon, dass eine Kompromittierung des Host-Kernels die Sicherheit aller Gäste gefährden könnte, können mikroarchitektonische Angriffe, die auf die Host-Hardware abzielen, auch den Benutzercode direkt bedrohen. Da ein einzelner Firecracker-Prozess alle notwendigen Threads enthält, um eine virtuelle Maschine mit der Funktion eines Benutzers auszuführen, kann die Soft-Allokation einfach vom Host-Betriebssystem durchgeführt werden [1]. Dies bedeutet, dass zusätzlich zur Isolierung der virtuellen Maschine standardmäßige Linux-Prozessisolationssysteme vorhanden sind.

2.6.1 Sicherheitsempfehlungen für Firecracker. Die Firecracker-Dokumentation empfiehlt außerdem die folgenden Vorkehrungen zum Schutz vor mikroarchitektonischen Seitenkanälen [8]:

• SMT deaktivieren

• Aktivieren Sie die Seitentabellenisolation des Kernels

• Deaktivieren Sie die Kernel-Kamé-Page-Zusammenführung

• Verwenden Sie einen Kernel, der mit Spectre-BTB-Minderung kompiliert wurde (z. B. IBRS und IBPB auf x86).

• Überprüfen Sie die Spectre-PHT-Minderung

• L1TF-Minderung aktivieren • Spectre-STL-Minderung aktivieren

• Verwenden Sie Speicher mit Rowhammer-Minderung

• Deaktivieren Sie Swap oder verwenden Sie Secure Swap

[1] Die virtualisierten Ringe 0 und 3 sind einer der Hauptgründe für die nahezu native Codeausführung.