Firecracker-microVMs einfach erklärt: eine echte VM, die in Sekundenbruchteilen startet

Wer etwas über das sichere Ausführen von KI-generiertem Code gelesen hat, ist dem Wort microVM begegnet, meist neben Firecracker. Erklärt wird es entweder als „leichtgewichtige VM“ (stimmt, hilft nicht) oder mit einem Diagramm von Kernel-Interna. Hier die Version dazwischen.

Zwei ältere Optionen und warum keine passt

Beginnen wir mit den beiden Dingen, zwischen denen eine microVM liegt.

Ein Container ist eine Gruppe gewöhnlicher Prozesse auf Ihrer Maschine, die der Kernel freundlich belügt. Namespaces zeigen ihnen ein eigenes Dateisystem, eine eigene Prozessliste und ein eigenes Netzwerk; cgroups begrenzen, wie viel CPU und Speicher sie nutzen dürfen. Er startet in Millisekunden, weil nichts Neues gebootet wird. Aber jeder Container auf einem Host spricht mit demselben Kernel. Ein aus einem Container erreichbarer Kernel-Bug ist ein Ausweg aus allen.

Eine virtuelle Maschine bringt ihren eigenen Kernel mit. Die CPU des Hosts führt den Gast über Hardware-Virtualisierung (KVM unter Linux) so aus, als hätte er einen eigenen Computer. Die Grenze ist der Hypervisor, der weit weniger preisgibt als die Hunderte Systemaufrufe eines Kernels. Der Preis ist Gewicht. Eine klassische VM emuliert einen ganzen PC: Firmware, einen PCI-Bus, USB-Controller, eine Grafikkarte, manchmal eine Soundkarte. Sie bootet durch all das, braucht Sekunden bis Minuten, und jede Instanz trägt Dutzende oder Hunderte Megabyte Overhead.

Eine Analogie, die ganz gut trägt: Container sind Wohnungen in einem Haus, mit gemeinsamem Fundament, gemeinsamen Leitungen und gemeinsamer Verkabelung. VMs sind getrennte Häuser. Häuser sind die sichereren Nachbarn, aber für einen Besuch von 20 Sekunden baut man keins.

Was Firecracker weglässt

Firecracker ist ein Virtual Machine Monitor (das Programm, das eine VM auf KVM einrichtet und betreibt), geschrieben in Rust und 2018 als Open Source veröffentlicht. Gebaut wurde er für eine Aufgabe: sehr viele kurzlebige, einander misstrauende Lasten auf gemeinsamer Hardware zu betreiben. Dorthin kommt er vor allem durch Weglassen:

• Keine Firmware, keine Hardware-Erkennung. Der Kernel wird direkt in den Speicher geladen und gestartet. Niemand sucht nach Geräten, die es nicht gibt.
• Ein winziges Gerätemodell. Eine Netzwerkkarte, ein Blockgerät, eine serielle Konsole und ein paar weitere, alle virtio (Geräte, die für virtuelle Maschinen entworfen wurden, statt physische nachzuahmen). Kein USB, keine Grafik, kein PCI.
• Eine kleine, speichersichere Codebasis. Weniger Code, der Geräte emuliert, heißt weniger Stellen für einen Bug, über den der Gast den Host erreicht.
• Ein Käfig um den VMM selbst. Jeder Firecracker-Prozess läuft in einem chroot, mit seccomp-Filtern für seine eigenen Systemaufrufe und cgroups für seine Ressourcen. Bräche etwas aus dem Gast aus, landete es in einem Käfig, nicht auf dem Host.

Die vom Projekt selbst veröffentlichten Zahlen: User Space in nur 125 ms und unter 5 MiB Speicher-Overhead pro microVM. Das sind Bestwerte aus dem Labor; eine echte Sandbox braucht zusätzlich eingerichtete Festplatte und Netzwerk sowie einen Agenten darin, der Befehle annimmt, weshalb unsere in etwa einer Sekunde bereit ist. Das ist immer noch nah genug an Container-Tempo, um pro Aufgabe eine anzulegen und sie danach wegzuwerfen.

Container und microVM in der Praxis

Die entscheidende Zeile ist die zweite. Beim Container wird aus der Frage „Kann dieser Code ausbrechen?“ die Frage „Gibt es irgendwo im Host-Kernel einen erreichbaren Bug?“. Bei der microVM wird daraus „Gibt es einen Bug im Hypervisor oder in einer Handvoll virtueller Geräte?“. Die zweite Fläche ist viel kleiner, und genau sie verteidigen Cloud-Plattformen ohnehin für ihr eigenes Mehrmandanten-Hosting.

Was Sie aufgeben

Eine microVM ist kein kostenloses Upgrade.

• Keine GPUs und keine Anzeigen. Sie ist zum Ausführen von Code da, nicht für Desktops oder Grafik.
• Weniger Geräte, weniger Flexibilität. Alles, was echte Hardware oder eine lange Liste von Kernel-Modulen erwartet, fühlt sich nicht zu Hause.
• Grenzen brauchen trotzdem Regeln. Eine microVM mit offenem ausgehenden Traffic kann weiterhin Traffic senden, den Sie nicht wollen; eine mit Ihren API-Schlüsseln darin kann sie weiterhin preisgeben. Isolation schützt den Host vor dem Gast, nicht Ihre Geheimnisse vor dem Code, dem Sie sie gegeben haben.

Wie unsere Sandboxes sie nutzen

Jede EQVPS-Sandbox ist eine Firecracker-microVM mit eigenem Kernel, von 0.25 vCPU und 512 MB bis 8 vCPU und 16 GB. Sie bringt Python 3.12, Node.js 22, bash, git und curl mit, hat ausgehendes Internet und keine eingehenden Ports. Flüchtige Sandboxes werden gelöscht, wenn Sie fertig sind; persistente behalten ihre Festplatte, und das Pausieren schreibt einen Snapshot der microVM auf die Festplatte, sodass sie bis zur Fortsetzung nichts kostet. Pausierte Snapshots werden 14 Tage aufbewahrt. Danach wird die Sandbox gelöscht, und ihre id antwortet mit 410 sandbox_deleted.

Wir haben uns aus einem Grund für microVMs statt Container entschieden: Der Code in einer Sandbox ist per Definition Code, den niemand geprüft hat. Die Ausgabe eines KI-Agenten, der Pull Request eines Fremden, ein Benchmark aus tausend vom Modell geschriebenen Programmen. Dafür ist ein eigener Kernel die Grenze, die den Preis wert ist. Was wir drumherum gebaut haben — Tarife, Kontingente, das 55-Sekunden-Limit für synchrone Befehle —, steht in der Sandbox-Dokumentation.

Wer diese Grenze genauer mit den anderen Optionen vergleichen will, findet in Isolationsstufen für nicht vertrauenswürdigen Code Prozesse, Container, microVMs und vollständige VMs nebeneinander. Und wenn der Sekundenpreis Ihr Interesse geweckt hat, zeigt wie sekundengenaue Abrechnung wirklich funktioniert die Rechnung.