Die Wette auf fremden Code: Firecracker microVMs und das Ende des Container-VM-Dilemmas

Der Aufhänger: Millionen Fremde auf einer Maschine

Jedes Mal, wenn irgendwo auf der Welt eine serverlose Funktion aufgerufen wird – eine kleine Codeschnipselzeile, die ein hochgeladenes Bild verkleinert, eine Bestellung verbucht oder eine Chat-Nachricht beantwortet –, geschieht im Rechenzentrum etwas, das bei näherem Hinsehen erschreckend kühn ist. Der Betreiber nimmt fremden, ihm völlig unbekannten Code, über dessen Absichten er nichts weiß, und lässt ihn auf derselben physischen Maschine laufen, auf der im Nachbarplatz der Code eines anderen, ebenso unbekannten Kunden läuft. Zwei potenzielle Angreifer, ein gemeinsames Stück Silizium. Und der Betreiber verspricht beiden – und einer Aufsichtsbehörde, die im Zweifel Millionenstrafen verhängt –, dass keiner der beiden den anderen ausspähen, stören oder übernehmen kann.

Das ist keine Randerscheinung, sondern das ökonomische Fundament der gesamten serverlosen Cloud. Ihr entscheidender Trick heißt Mehrmandantenfähigkeit (englisch multitenancy): Ein Server wird nicht an einen Kunden vermietet, sondern gleichzeitig unter Hunderte oder Tausende geteilt, die alle nur für die Millisekunden bezahlen, in denen ihr Code tatsächlich rechnet. Genau diese Bündelung vieler kleiner, sporadischer Lasten auf wenig Hardware ist es, die serverlose Dienste billig macht. Doch sie funktioniert nur, wenn die Wände zwischen den Mandanten absolut dicht sind – und zwar dicht gegen aktiv bösartigen Code, nicht bloß gegen versehentliches Fehlverhalten.

Lange schien es, als müsse man sich hier zwischen zwei Übeln entscheiden. Auf der einen Seite standen Linux-Container (Docker, LXC): federleicht, in Millisekunden gestartet, extrem dicht packbar – aber mit einer beunruhigenden Eigenschaft. Alle Container auf einem Host teilen sich denselben Betriebssystemkern. Ein einziger Fehler in diesem Kern, ausgenutzt von einem einzigen böswilligen Container, kann die Trennwand einreißen und die Kontrolle über den ganzen Rechner geben. Auf der anderen Seite standen klassische virtuelle Maschinen: jede mit eigenem Kern, durch Hardware-Virtualisierung sauber voneinander getrennt, ein bewährtes Bollwerk – aber schwer, langsam startend und mit einem Overhead, der die Dichte und damit das ganze ökonomische Modell der serverlosen Cloud zerstört.

Die verbreitete Meinung lautete: Man kann starke Sicherheit oder geringen Overhead haben, nicht beides. Für einen öffentlichen Cloud-Anbieter, der beliebigen fremden Code annimmt, ist dieser Kompromiss inakzeptabel. Beide Eigenschaften sind nicht verhandelbar. Genau an diesem Punkt setzt Firecracker an, ein bei der USENIX-NSDI-Konferenz 2020 vorgestellter, quelloffener Virtual Machine Monitor von Amazon Web Services. Firecrackers These ist so schlicht wie folgenreich: Das Dilemma ist ein falsches. Man kann die harte Hardware-Isolation einer echten virtuellen Maschine bekommen und die Leichtigkeit eines Containers – wenn man bereit ist, alles wegzuwerfen, was eine virtuelle Maschine schwer macht, und nur das zu behalten, was sie sicher macht.

Für jemanden wie Sven, der mit einem Bein in der Cloud-Architektur und einem in der IT-Sicherheit steht, ist Firecracker ein Musterbeispiel dafür, wie eine kompromisslose Neubewertung der Vertrauensgrenze eine scheinbar eherne Zielkonfliktkurve verschiebt. Dieser Artikel nimmt dich mit auf die ganze Strecke: von der Frage, was Isolation überhaupt bedeutet, über Firecrackers radikalen Minimalismus und seine harten Zahlen bis zur statistischen Wette der Überbuchung, zur Snapshot-Revolution gegen das Kaltstartproblem und zum breiteren Ökosystem konkurrierender Isolationstechniken.

Teil 1: Das Dilemma – Container gegen virtuelle Maschine

Um zu verstehen, warum Firecracker überhaupt gebaut werden musste, muss man das Problem sauber sezieren, das AWS mit seinem eigenen Dienst hatte. Als AWS Lambda 2014 startete, wählte man Linux-Container als Isolationsmechanismus. Container sind kein einzelnes Feature, sondern ein Bündel von Kernel-Mechanismen: cgroups begrenzen den Ressourcenverbrauch (CPU, Speicher), namespaces verstecken Teile des Systems voneinander (eigene Prozess-IDs, eigenes Dateisystem, eigenes Netzwerk), und seccomp-bpf kann einschränken, welche Systemaufrufe ein Prozess überhaupt an den Kern richten darf.

Diese Werkzeuge sind mächtig und effizient. Ihr Problem ist strukturell: Der Container-Prozess ruft weiterhin direkt den gemeinsamen Host-Kern auf. Der Linux-Kern ist ein gewaltiges Stück Software mit einer riesigen Angriffsfläche – Hunderte Systemaufrufe, Dateisysteme, Netzwerkstacks, Treiber. Jeder ausnutzbare Fehler in diesem gemeinsamen Kern ist eine potenzielle Fluchtluke: Gelingt es bösartigem Code in einem Container, den Kern zu kompromittieren, dann ist jede Isolation dahin, denn der Kern steht ja über allen Containern. Die Sicherheitsgemeinde bringt das auf die Formel: Dein Container ist kein Sandkasten. Container wurden ursprünglich erdacht, um kooperierende Arbeitslasten desselben Betreibers gegeneinander abzugrenzen, nicht um feindlichen Code fremder Kunden einzusperren.

Die virtuelle Maschine löst genau dieses Problem – auf Kosten des Gewichts. Bei der Hardware-Virtualisierung mit KVM (der Kernel-based Virtual Machine im Linux-Kern) bekommt jeder Gast seine eigene virtuelle Hardware, seine eigenen Seitentabellen und vor allem seinen eigenen Betriebssystemkern. Der Prozessor selbst erzwingt mit speziellen Virtualisierungsbefehlen die Trennung zwischen Wirt und Gast. Der Gastkern gilt als nicht vertrauenswürdig; selbst wenn böswilliger Code ihn vollständig übernimmt, sitzt er immer noch in seiner virtuellen Maschine gefangen. Die Angriffsfläche, die dem Kunden gegenübersteht, schrumpft von „der ganze Linux-Kern" auf „die schmale Schnittstelle, die der Virtual Machine Monitor dem Gast anbietet".

Der Haken war traditionell die Software, die diese virtuelle Hardware bereitstellt: der Virtual Machine Monitor (VMM), fast immer QEMU. QEMU ist ein Wunderwerk der Flexibilität – es kann beliebige Betriebssysteme booten, unzählige Geräte emulieren, fremde Prozessorarchitekturen nachbilden. Diese Universalität hat einen Preis: QEMU umfasste zum Zeitpunkt der Firecracker-Arbeit über 1,4 Millionen Zeilen Code. Das bedeutet einen langsamen Start (bis zum ersten nützlichen Rechenschritt vergehen Sekunden), spürbaren Speicher- und CPU-Overhead pro virtueller Maschine und – ironischerweise – selbst eine beträchtliche Angriffsfläche in ebenjenem Programm, das die Sicherheit garantieren soll. Für einen Dienst, der Tausende winziger, ständig wechselnder Funktionen pro Maschine dicht packen will, ist das untragbar.

Die Kernfrage lautete also nicht „Container oder virtuelle Maschine?", sondern: Kann man die harte Isolationsgrenze der Virtualisierung behalten und gleichzeitig das Gewicht abwerfen, das nur von der Universalität von QEMU herrührt und für den serverlosen Anwendungsfall gar nicht gebraucht wird?

Teil 2: Was Isolation eigentlich bedeutet

Bevor wir zu Firecrackers Antwort kommen, lohnt ein kurzer, aber präziser Blick auf drei Begriffe, die in dieser Debatte alles entscheiden: die Vertrauensgrenze, die Trusted Computing Base und der Seitenkanal.

Die Vertrauensgrenze (trust boundary) ist die gedachte Linie, entlang derer ein System entscheidet: Ab hier vertraue ich dem Code nicht mehr. Bei einem Container verläuft diese Linie am Rand des Prozesses – aber alles, was jenseits liegt, teilt sich denselben Kern, sodass ein Kernbruch die Grenze überspringt. Bei einer virtuellen Maschine verläuft die Linie um den ganzen Gast herum, erzwungen von der Hardware. Der Unterschied ist nicht gradueller, sondern qualitativer Natur: Im ersten Fall muss der Angreifer eine Softwarelücke finden, im zweiten eine Lücke in der von der CPU selbst durchgesetzten Trennung.

Die Trusted Computing Base (TCB) ist die Gesamtheit aller Hard- und Software, der man vertrauen muss, damit die Sicherheitszusage hält. Je kleiner die TCB, desto weniger Code kann Fehler enthalten, die zur Katastrophe führen. Hier liegt Firecrackers zentrale Designphilosophie: Wenn der VMM selbst Teil der TCB ist – und das ist er, denn er stellt die virtuelle Hardware bereit und trennt die Gäste –, dann ist ein VMM mit 50.000 Zeilen Code massiv sicherer als einer mit 1,4 Millionen. Weniger Code heißt weniger Angriffsfläche. Minimalismus ist hier nicht Ästhetik, sondern Sicherheitsstrategie.

Der Seitenkanal (side channel) schließlich ist die unangenehme Erinnerung daran, dass selbst perfekte logische Isolation nicht ausreicht, solange sich Mandanten dieselbe physische Hardware teilen. Angriffe wie Spectre und Meltdown zeigten 2018, dass ein Prozess über gemeinsam genutzte Caches, über die spekulative Ausführung des Prozessors oder über geteilte Rechenkerne Informationen aus einem anderen Sicherheitsbereich abgreifen kann, ohne je die logische Grenze zu durchbrechen (siehe Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung). Deshalb reicht die Virtualisierungsgrenze allein nicht: Firecracker verlangt zusätzlich, dass der Wirt Gegenmaßnahmen aktiviert – etwa das Abschalten von Simultaneous Multithreading (Hyper-Threading), damit sich nie zwei fremde Mandanten denselben physischen Kern teilen, sowie Kernel-Page-Table-Isolation und die einschlägigen Branch-Predictor-Schutzmaßnahmen. Isolation ist also ein Schichtenwerk aus Hardware-Virtualisierung, minimaler Software und mikroarchitektonischer Hygiene – kein einzelner Schalter.

Mit diesen drei Begriffen im Gepäck wird Firecrackers Entwurf lesbar als eine einzige, konsequente Antwort: die Vertrauensgrenze der Virtualisierung behalten, die TCB radikal verkleinern und die Seitenkanäle durch Betriebsregeln schließen.

Teil 3: Firecrackers Wette – KVM behalten, QEMU wegwerfen

Der entscheidende Einfall von Firecracker ist eine saubere Zerlegung. Die Sicherheit der Virtualisierung stammt nicht von QEMU, sondern von KVM, dem Virtualisierungsunterbau im Linux-Kern, der die Hardware-Trennung durchsetzt. QEMU liefert „nur" die Emulation der virtuellen Geräte und das Drumherum. Firecrackers Wette lautet daher: Behalte KVM. Wirf QEMU vollständig weg und ersetze es durch einen winzigen, für den Zweck maßgeschneiderten VMM.

Das Ergebnis ist ein Programm von rund 50.000 Zeilen Rust-Code – etwa 96 Prozent weniger als QEMU. Zwei Dinge an diesem Satz sind bedeutsam. Erstens die Größe: 50.000 statt 1.400.000 Zeilen bedeuten eine dramatisch kleinere TCB und Angriffsfläche. Zweitens die Sprache: Rust ist eine speichersichere Systemsprache, die eine ganze Klasse klassischer Sicherheitslücken – Pufferüberläufe, Use-after-free, Dangling Pointer – bereits zur Übersetzungszeit ausschließt. Für ein Programm, dessen einzige Existenzberechtigung Sicherheit ist, ausgerechnet die Sprache zu wählen, die die häufigsten Sicherheitsfehler strukturell verhindert, ist konsequent. Firecracker teilt sich seinen Rust-Unterbau übrigens über das gemeinschaftliche rust-vmm-Projekt mit anderen minimalen VMMs, etwa crosvm, dem Virtual Machine Monitor von Chrome OS.

Firecracker ist, wie die Autoren selbst betonen, vor allem durch das bemerkenswert, was es nicht kann. Es bietet kein BIOS. Es kann keine beliebigen Kerne booten und würde ohne erhebliche Änderungen etwa Microsoft Windows nicht starten. Es emuliert keine Legacy-Geräte und kein PCI. Es unterstützte zum Zeitpunkt der Veröffentlichung keine Live-Migration virtueller Maschinen. Jede dieser Auslassungen ist eine bewusste Entscheidung: Ein VMM, der nur moderne Linux- (und OSv-)Gäste für Container- und Funktionslasten bedienen muss, braucht all das nicht – und jede weggelassene Funktion ist Code, der nicht geschrieben, nicht gewartet und vor allem nicht angegriffen werden kann. Firecracker ersetzt QEMU also nicht dadurch, dass es QEMU zurechtstutzt, sondern durch eine kompromisslose Neukonstruktion mit einem klar umrissenen Zweck.

Das Modell für die Sicherheitsisolation ist dabei bestechend einfach: Pro microVM läuft genau ein Firecracker-Prozess. Jede Funktion, jeder Container sitzt in seiner eigenen microVM, die von ihrem eigenen Firecracker-Prozess bewacht wird. Fällt eine Funktion aus, muss man nur diesen einen Prozess beenden. Die Angriffsfläche eines Mandanten beschränkt sich auf seine eigene virtuelle Hardware, hinter der KVM und der Wirtskern verborgen liegen.

Teil 4: Der minimalistische Bauplan

Sehen wir uns an, wie dieser Minimalismus konkret aussieht, denn hier steckt die eigentliche Ingenieurskunst.

Das Gerätemodell. Statt hundert emulierter Geräte bietet Firecracker nur eine Handvoll, und diese über virtio – einen schlanken, standardisierten Mechanismus für virtuelle Ein-/Ausgabe, bei dem der Gast weiß, dass er virtualisiert ist, und deshalb auf teure Hardware-Nachahmung verzichten kann. Firecracker stellt im Wesentlichen ein virtio-Blockgerät (für die Festplatte), ein virtio-Netzwerkgerät und eine serielle Konsole bereit. Wie radikal schlank das ist, zeigen die Zeilenzahlen aus der Arbeit: Der eigentliche Blockgerätetreiber im Gast umfasst rund 50 Zeilen Rust, der serielle Treiber etwa 250, und das gesamte virtio-Blockgerät samt Datenstrukturen liegt bei rund 1.400 Zeilen. Wo QEMU flexibel und komplex ist, ist Firecracker eng und einfach.

Der Jailer. Selbst der winzige VMM könnte theoretisch einen Fehler enthalten. Deshalb legt Firecracker eine weitere Verteidigungsschicht darum: den Jailer. Er ist ein Umhüllungsprogramm, das den Firecracker-Prozess in einen restriktiven Sandkasten sperrt, bevor dieser den Gast bootet. Sollte es einem Gast wider Erwarten gelingen, aus der virtuellen Maschine in den VMM-Prozess auszubrechen, sitzt dieser Prozess bereits in einem eng geschnürten Käfig – mit reduzierten Rechten, eigenen Namespaces und beschnittenem Zugriff auf den Wirt. Sicherheit in Schichten (defense in depth): Nicht eine perfekte Wand, sondern mehrere gestaffelte, sodass der Durchbruch durch eine noch lange keinen Zugriff auf das Ganze bedeutet.

seccomp-bpf. Zusätzlich schränkt Firecracker über seccomp-bpf ein, welche Systemaufrufe der VMM-Prozess selbst überhaupt an den Wirtskern richten darf. Damit wird die Schnittstelle zwischen VMM und Wirt – die letzte verbliebene Angriffsfläche – auf ein Minimum verschmälert.

Rate Limiter. Schließlich baut Firecracker in seine virtio-Geräte konfigurierbare Ratenbegrenzer ein. Sie beschränken sowohl den Durchsatz (Bandbreite) als auch die Rate der Operationen (Ein-/Ausgabeoperationen pro Sekunde bei der Platte, Pakete pro Sekunde im Netz). Das dient nicht der Sicherheit im engeren Sinn, sondern der Performance-Isolation: In einem dicht gepackten Wirt darf ein einzelner gieriger Mandant nicht die Platte oder das Netz für alle anderen lahmlegen. Interessant ist ein Detail: Man kann einen einmaligen „Burst" erlauben, um den Bootvorgang zu beschleunigen, und danach die Dauergrenze durchsetzen – ein pragmatischer Kompromiss zwischen schnellem Start und fairer Dauernutzung. Entscheidend ist, dass diese Grenzen im VMM erzwungen werden, weil man dem Gast nicht zutraut, sie selbst einzuhalten.

Zusammengefasst: Firecracker verlässt sich für die harte Trennung auf KVM und die Hardware, für Speicher- und CPU-Fairness auf den Prozess-Scheduler und Speichermanager des Wirtskerns, und legt darüber mit Jailer, seccomp-bpf und Rate Limitern mehrere feine Schichten. Genau diese Arbeitsteilung – die schwere, bewährte Arbeit dem Linux-Kern überlassen, nur das Nötige selbst und minimal implementieren – macht den geringen Overhead möglich.

Teil 5: Die Zahlen, die den Unterschied machen

Ein Entwurf ist nur so gut wie seine messbaren Eigenschaften. Firecrackers Kennzahlen sind der Grund, warum aus einer eleganten Idee eine tragende Säule der weltweiten Cloud-Infrastruktur wurde. Drei Zahlen aus der Originalarbeit ragen heraus:

Erstens der Speicher-Overhead von unter 5 MB pro microVM (mit der bereitgestellten minimalen Linux-Gastkern-Konfiguration). Das ist der Betrag an Wirtsspeicher, den der VMM und sein Drumherum verbrauchen, bevor der Gast überhaupt nützliche Arbeit tut. Bei Lambda-Funktionen, die mit so wenig wie 128 MB Speicher auskommen, ist es der Unterschied zwischen „lächerlicher Prozentsatz" und „ruiniert die Rechnung". Weniger als 5 MB bedeuten, dass man Tausende microVMs auf einer einzigen Maschine unterbringen kann, ohne den Speicher an reinem Verwaltungsaufwand zu verschwenden.

Zweitens die Bootzeit von unter 125 Millisekunden bis zum Anwendungscode. Das ist die Zeit vom Startbefehl bis zu dem Moment, in dem die Funktion tatsächlich rechnet. Eine achtel Sekunde – schnell genug, dass eine serverlose Plattform eine microVM bei Bedarf hochfahren kann, ohne dass der aufrufende Nutzer eine spürbare Verzögerung erlebt. Zum Vergleich: Eine klassische QEMU-basierte virtuelle Maschine mit BIOS und vollem Gerätesatz braucht dafür typischerweise viele Sekunden.

Drittens die Erzeugungsrate von bis zu 150 microVMs pro Sekunde und Host. Weil serverlose Lasten sich ständig ändern – Funktionen kommen und gehen im Sekundentakt –, muss die Plattform microVMs nicht nur schnell einzeln starten, sondern viele davon in rascher Folge. 150 Neustarts pro Sekunde und Maschine geben der Orchestrierung genügend Spielraum, um mit dem Kommen und Gehen der Last Schritt zu halten.

Diese Zahlen sind keine Laborträume. Firecracker läuft seit 2018 in der Produktion von AWS Lambda und trägt dort Millionen von Arbeitslasten; es liegt auch AWS Fargate zugrunde, dem Dienst für serverlose Container. Bemerkenswert ist, dass AWS die bestehenden Lambda-Kunden nahtlos auf die neue Isolationstechnik migrieren konnte, ohne dass diese ihren Code ändern mussten – ein Beleg dafür, dass Firecracker das Kompatibilitätsziel erreicht: Es führt beliebige unveränderte Linux-Binärdateien aus. Und Firecracker ist quelloffen unter der Apache-2.0-Lizenz, sodass die Technik nicht auf AWS beschränkt bleibt, sondern zum Baustein einer ganzen Generation von Sandbox-Plattformen wurde.

Teil 6: Dichte und Überbuchung – die statistische Wette

Warum ist geringer Overhead so existenziell? Weil das gesamte Geschäftsmodell auf Dichte und Überbuchung beruht – und beides ist im Kern eine Wette gegen die Statistik.

Serverlose Funktionen sind winzig und sporadisch. Eine typische Funktion rechnet vielleicht ein paar Dutzend Millisekunden und schläft dann minutenlang. Würde man jeder Funktion dauerhaft eine reservierte Ressource zuweisen, läge die Maschine die meiste Zeit brach. Der Ausweg ist Überbuchung (oversubscription): Man verkauft mehr Kapazität, als physisch vorhanden ist, im Vertrauen darauf, dass nie alle Mandanten gleichzeitig ihr volles Kontingent abrufen. Ein Platz, dessen Funktion gerade schläft, kann kurzzeitig einem anderen dienen. Die Autoren nennen das unumwunden eine statistische Wette: Die Plattform muss die Ressourcen möglichst ausgelastet halten und gleichzeitig sicherstellen, dass jeder Mandant im Bedarfsfall doch das bekommt, was er braucht, ohne spürbare Verdrängung durch die Nachbarn.

Damit diese Wette aufgeht, sind zwei Dinge nötig, die Firecracker liefert. Zum einen echte Performance-Isolation: Ein schlafender Nachbar darf nicht plötzlich, wenn er aufwacht, von einem gierigen Mitmandanten ausgehungert werden – genau dafür sind die Rate Limiter und die Delegation an den Scheduler des Wirtskerns da. Zum anderen hohe Dichte pro Maschine: Nur wenn Tausende microVMs mit minimalem Overhead auf einen Host passen, ist das Gesetz der großen Zahl auf Seiten des Betreibers – je mehr unabhängige, sporadische Lasten auf einer Maschine, desto glatter und vorhersagbarer die aggregierte Auslastung, desto sicherer die Wette. Jedes eingesparte Megabyte Overhead erhöht die Zahl der Mandanten, über die sich das Risiko mittelt.

So schließt sich der Kreis zur Sicherheit: Weil man viele fremde Mandanten dicht packen will, muss die Isolation zwischen ihnen hart sein; und weil die Isolation über einzelne, leichte microVMs läuft, kann man sie überhaupt erst dicht packen. Firecracker ist der Punkt, an dem Sicherheitsanforderung und ökonomischer Zwang zusammenfallen, statt einander zu widersprechen.

Teil 7: Der Kaltstart und die Snapshot-Revolution

So schnell 125 Millisekunden auch klingen: Für manche Arbeitslasten ist selbst das zu viel. Das Problem heißt Kaltstart (cold start). Wenn eine Funktion aufgerufen wird, für die gerade keine warme microVM bereitsteht, muss die Plattform eine neue hochfahren – microVM booten, Laufzeitumgebung starten, Abhängigkeiten laden, Initialisierungscode ausführen. Bei schweren Laufzeiten wie der Java Virtual Machine kann allein die Initialisierung – Klassen laden, den Just-in-Time-Compiler anwerfen – Sekunden verschlingen und den microVM-Boot weit in den Schatten stellen. Für latenzempfindliche Dienste ist das der wunde Punkt der serverlosen Cloud.

Die elegante Antwort heißt Snapshotting. Die Idee: Man bootet eine microVM einmal, lässt sie ihre gesamte teure Initialisierung durchlaufen, und friert dann ihren vollständigen Zustand – Arbeitsspeicher und virtuelle Gerätezustände – als Schnappschuss ein. Wird die Funktion später gebraucht, startet man nicht von null, sondern stellt den Schnappschuss wieder her und setzt genau dort fort, wo die fertig initialisierte Maschine stand. Firecracker unterstützt genau das, und die Wiederherstellung ist verblüffend schnell: In günstigen Fällen kann ein microVM-Schnappschuss in nur rund 4 Millisekunden wiederhergestellt werden, für ein anständig dimensioniertes Linux-System liegt man verlässlich unter zehn Millisekunden. Aus „Sekunden Kaltstart" werden Millisekunden.

Auf dieser Technik beruht AWS Lambda SnapStart, das im November 2022 zunächst für Java eingeführt wurde: Beim Veröffentlichen einer Funktionsversion wird die Funktion einmal aufgewärmt, der gesamte Initialisierungscode ausgeführt, und dann ein verschlüsselter Firecracker-Schnappschuss des fertig initialisierten Zustands persistiert und zwischengespeichert. Jeder spätere Kaltstart lädt diesen Schnappschuss statt neu zu booten – aus Sekunden werden Millisekunden.

Doch Schnappschüsse öffnen eine subtile, sicherheitskritische Büchse der Pandora, die eine eigene Forschungsarbeit beschäftigt hat („Restoring Uniqueness in MicroVM Snapshots"). Wenn ein Schnappschuss als Vorlage dient, aus der viele identische microVMs geklont werden, dann starten all diese Klone mit demselben internen Zustand – einschließlich desselben Vorrats an Zufälligkeit (Entropie). Zwei frisch geklonte Maschinen, die dieselben „Zufallszahlen" ziehen, können identische kryptografische Schlüssel oder Sitzungskennungen erzeugen – ein potenziell katastrophaler Bruch. Der Kaltstart-Trick verlangt daher zusätzliche Vorkehrungen, um die Einzigartigkeit jeder wiederhergestellten Maschine trotz gemeinsamer Vorlage wiederherzustellen. Ein schönes Beispiel dafür, dass jede Optimierung in verteilten Systemen einen Preis an anderer Stelle fordert – hier den, dass „identisch geklont" und „kryptografisch einzigartig" in Spannung stehen.

Teil 8: Das Ökosystem – gVisor, Kata Containers, Cloud Hypervisor

Firecracker ist nicht die einzige Antwort auf das Isolationsproblem, und es lohnt sich, seinen Platz im Spektrum der Ansätze zu verorten. Grob lassen sich drei Familien unterscheiden, die entlang der Achse „Stärke der Isolation gegen Nähe zur nativen Leistung" liegen.

Am einen Ende stehen die klassischen Container (Docker, LXC): geteilter Kern, geringste Isolation, aber praktisch kein Overhead und volle Geschwindigkeit. Geeignet für vertrauenswürdige, kooperierende Lasten – ungeeignet als Sandkasten für feindlichen Fremdcode.

In der Mitte sitzt gVisor von Google. Sein Ansatz ist eigenwillig: Statt eine Hardware-VM aufzuspannen, schiebt gVisor einen im Benutzerraum laufenden Kern zwischen den Gast und den echten Wirtskern. Dieser Zwischenkern fängt die Systemaufrufe des Containers ab und bedient sie selbst, sodass der Container den echten Wirtskern nie direkt berührt. Das verkleinert die Angriffsfläche – der gefährliche echte Kern ist verdeckt –, bietet aber keine Hardware-Isolation; die Trennung ist wieder softwarebasiert, wenn auch mit viel schmalerer Schnittstelle. Der Preis ist ein Leistungsaufwand bei jedem Systemaufruf, der abgefangen und nachgebildet werden muss.

Am anderen Ende liegen die microVM-Ansätze mit echter Hardware-Virtualisierung: Firecracker selbst, das eng verwandte Cloud Hypervisor (ebenfalls auf rust-vmm aufbauend) und Kata Containers. Kata ist dabei kein konkurrierender VMM, sondern eine Integrationsschicht: Es fügt sich in die Container-Standards und in Kubernetes ein und startet unter der Haube für jeden Container transparent eine leichte virtuelle Maschine – wahlweise sogar mit Firecracker als Motor. Die verbreitete Faustregel lautet: Firecracker dominiert die serverlosen Plattformen und die neuen KI-Sandkästen, in denen von KI-Agenten erzeugter, potenziell riskanter Code sicher ausgeführt werden muss; Kata besitzt das mehrmandantenfähige Kubernetes; und die meisten Organisationen fahren am besten, indem sie Firecracker durch Kata nutzen, statt selbst eine microVM-Orchestrierung zu bauen – denn Firecracker ist ein VMM, keine vollständige Orchestrierungslösung.

Der springende Punkt für die Architekturentscheidung: Hardware-Virtualisierung (Firecracker, Kata) stoppt Kernel-Exploits an der Wurzel, weil der Angreifer die von der CPU erzwungene Grenze überwinden müsste. Ein Benutzerraum-Kern (gVisor) verengt die Angriffsfläche, verlässt sich aber weiter auf Software. Ein geteilter Kern (klassische Container) lässt jeden Mandanten für jeden Kernfehler verwundbar. Wer feindlichen Fremdcode isolieren muss, landet fast zwangsläufig bei einer Form der Hardware-Virtualisierung – und Firecracker hat gezeigt, dass diese nicht mehr schwer sein muss.

Grenzen und Schatten

Bei aller Eleganz ist Firecracker kein Allheilmittel, und intellektuelle Redlichkeit verlangt, die Kanten zu benennen.

Erstens ist Firecracker spezialisiert, nicht universell. Was es sicher und leicht macht – kein BIOS, kein PCI, keine Legacy-Geräte, nur moderne Linux-Gäste –, macht es zugleich unbrauchbar für alles, was diese fehlenden Funktionen braucht. Wer Windows, exotische Betriebssysteme oder anspruchsvolle Gerätedurchreichung (etwa GPUs für schweres Rechnen) benötigt, ist mit Firecracker schlecht bedient. Es ist ein Präzisionswerkzeug für einen bestimmten Zweck, kein Ersatz für den Schweizer Taschenmesser-Charakter von QEMU.

Zweitens verschiebt Firecracker die Vertrauensgrenze, es beseitigt sie nicht. Die harte Trennung ruht auf KVM, dem Wirtskern und letztlich der Korrektheit der Prozessor-Virtualisierung. Ein Fehler in KVM oder in der Hardware-Virtualisierung selbst wäre weiterhin verheerend – die TCB ist kleiner, aber nicht null. Und wie oben betont, bleiben Seitenkanäle ein eigenständiges Problem, das die Virtualisierungsgrenze nicht löst und das nur durch betriebliche Disziplin (Hyper-Threading aus, Kern-Mitigationen an, keine geteilten physischen Kerne zwischen Mandanten) eingehegt werden kann. Firecracker macht diese Anforderungen explizit, aber es erlässt sie nicht.

Drittens ist die Netzwerk- und Ein-/Ausgabeleistung von virtio-basierten microVMs nicht in jedem Fall der einer bloßen Container-Lösung ebenbürtig; die Autoren räumen selbst ein, dass ihr Ansatz für Arbeitslasten mit höchsten Durchsatzanforderungen nicht das Optimum liefert. Firecracker ist auf Tausende ephemere, kleine VMs optimiert, nicht auf maximale Einzelleistung.

Ich bin der Meinung, dass gerade diese ehrliche Spezialisierung Firecrackers eigentliche Lehre ist: Der Durchbruch kam nicht durch ein weiteres universelles Werkzeug, sondern durch die Bereitschaft, für einen scharf umrissenen Anwendungsfall radikal zu vereinfachen und alles Überflüssige zu opfern.

Ein Rahmen zum Mitnehmen: Das Isolationsspektrum

Die folgende Tabelle verdichtet die Landschaft. Sie ist bewusst vereinfacht – die reale Leistung hängt stark von Arbeitslast und Konfiguration ab –, aber sie ordnet die Ansätze entlang der entscheidenden Achsen.

Die Leitlinie für die Praxis: Je feindlicher der Code, dem du eine Bühne gibst, desto weiter unten in dieser Tabelle solltest du dich einordnen. Und die frohe Botschaft, die Firecracker gebracht hat, ist, dass „weiter unten" nicht mehr automatisch „viel teurer und langsamer" heißt.

Erkenntnis zum Mitnehmen

Firecrackers eigentliche Lektion ist keine über Virtualisierung, sondern über Ingenieurdenken. Ein scheinbar ehernes Dilemma – Sicherheit oder Leichtigkeit – entpuppte sich als Artefakt einer unpassenden Werkzeugwahl. Nicht die Virtualisierung war schwer, sondern QEMUs Universalität. Sobald man den Anwendungsfall scharf genug umriss („nur moderne Linux-Gäste, nur Container- und Funktionslasten"), fiel fast das gesamte Gewicht als schlicht überflüssig weg – und mit ihm die Angriffsfläche.

Für die eigene Arbeit lässt sich das übersetzen: Wenn du vor einem hartnäckigen Zielkonflikt stehst, frage nicht nur „Wie finde ich den besten Kompromiss auf dieser Kurve?", sondern „Ist die Kurve selbst ein Artefakt einer Annahme, die ich für unverrückbar halte?" Firecracker verschob die Kurve, indem es die Annahme fallen ließ, ein Virtual Machine Monitor müsse universell sein. Der praktische Handlungsanstoß für Sven und jeden Cloud-Architekten lautet daher konkret: Wähle deine Isolationstechnik bewusst nach der Feindseligkeit des Codes, den du ausführst – vertrauenswürdige Lasten in Containern, riskanten oder fremden Code in microVMs –, und behandle Minimalismus nicht als Verzicht, sondern als aktive Sicherheitsstrategie: Jede Zeile Code, die du nicht schreibst, ist eine Zeile, die nicht angegriffen werden kann.

Reflexionsfrage

Firecracker verkleinerte die Trusted Computing Base radikal, indem es alle nicht benötigte Universalität opferte. Wo in deinen eigenen Systemen – in deiner Architektur, deinem Code, deinen Abhängigkeiten – trägst du „Universalität" mit, die du gar nicht brauchst, aber deren Angriffsfläche und Wartungslast du stillschweigend bezahlst? Und was würde es kosten, sie so kompromisslos wegzuschneiden, wie Firecracker QEMU wegschnitt?

Querverweise im Vault

• Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung – warum die Virtualisierungsgrenze allein Seitenkanäle nicht schließt und Firecracker zusätzliche mikroarchitektonische Gegenmaßnahmen verlangt.
• Der Ring, der die Last verteilt: Consistent Hashing und die Kunst des sanften Umzugs – die Orchestrierungsschicht, die entscheidet, welche microVM auf welchem Host landet.
• Elf Neunen: Erasure Coding, Reed-Solomon und wie die Cloud Daten praktisch unverlierbar macht – dasselbe Denken (Redundanz und Zuverlässigkeit aus unzuverlässigen Bauteilen) auf der Speicherebene.
• Uhren, die ihre eigene Unsicherheit kennen: Google Spanner, TrueTime und die Beherrschung der Zeit in der Cloud – ein weiteres Beispiel für ein tiefes technisches Fundament unter einer scheinbar simplen Cloud-Zusage.
• Wie Maschinen sich einig werden: Verteilter Konsens von FLP über Paxos zu Raft – wie die vielen Hosts einer serverlosen Flotte überhaupt zu gemeinsamen Entscheidungen kommen.

Quellen

1. Agache, A., Brooker, M., Florescu, A., Iordache, A., Liguori, A., Neugebauer, R., Piwonka, P., Popa, D. M.: Firecracker: Lightweight Virtualization for Serverless Applications. USENIX NSDI 2020. — https://www.usenix.org/conference/nsdi20/presentation/agache (Volltext: https://www.usenix.org/system/files/nsdi20-paper-agache.pdf)
2. USENIX NSDI '20 Präsentationsseite zu Firecracker. — https://www.usenix.org/conference/nsdi20/presentation/agache
3. „Restoring Uniqueness in MicroVM Snapshots." arXiv:2102.12892. — https://arxiv.org/abs/2102.12892
4. Brooker, M.: Lambda SnapStart, and snapshots as a tool for system builders. — https://brooker.co.za/blog/2022/11/29/snapstart.html
5. Google gVisor – Container runtime sandbox (Projektseite). — https://github.com/google/gvisor
6. Kata Containers – Projektdokumentation. — https://katacontainers.io/

Hinweis zu Sicherheitszahlen: Die Kennzahlen (< 5 MB Overhead, < 125 ms Boot, bis zu 150 microVMs/s/Host, ~50.000 Zeilen Rust, QEMU > 1,4 Mio. Zeilen) stammen aus der begutachteten NSDI-2020-Originalarbeit und beziehen sich auf die dort beschriebene Konfiguration; reale Werte variieren mit Gastkern, Arbeitslast und Hardware.

← All articles