- Eine Single-Process-Sandbox auf KVM-Basis
- Kann gewöhnliche Linux-Programme oder Programme ausführen, die eine bestimmte API verwenden, innerhalb der Sandbox
- Bietet mithilfe von Hardware-Virtualisierung native Performance
- Verwendet nur einen Teil der KVM-API → dadurch ist die Codebasis klein und effizient
Design von TinyKVM
- Unterstützt die Ausführung statischer Linux-ELF-Programme
- Unterstützung für dynamische Executables soll später ergänzt werden
- Kann auch zu einer API erweitert werden, um Zugriff auf externe HTTP-Server oder Caches bereitzustellen
- Läuft derzeit auf AMD64 (
x86_64), eine Portierung auf AArch64 (64-Bit-ARM) ist geplant
- Hugepage-Unterstützung
- Kann Hugepages für Gastseiten erzeugen
- Hugepages können auch auf dem Host verwendet werden → verbessert die Performance
- Beispiel: Bei der Zuweisung von 2MB-Seiten wurde eine um 5 % bessere LLVM-Kompilierungsleistung bestätigt
- Schnelle Funktionsaufrufe
- Der Overhead bei Funktionsaufrufen aus dem Gast beträgt 2μs
- Ohne Timer sinkt der Overhead auf 1,2μs
- Unterstützt Remote-Debugging
- Remote-Debugging mit GDB ist möglich
- Nach dem Debugging kann das Programm normal fortgesetzt werden
- Copy-on-Write-Unterstützung
- Unterstützt eine eigene Fork-Funktion → minimiert das Kopieren von Speicher
- Beispiel: Beim Duplizieren eines 6GB-Modells werden nur 260MB Speicher pro Instanz benötigt
- Schnelle Initialisierung des Zustands
- Der Gastzustand kann schnell zurückgesetzt werden → erhöht die Sicherheit
- Ein Reset pro Request verringert das Risiko, dass Zustände offengelegt werden
- Vereinfachte Codebasis
- Nutzt etwa 42k LOC der KVM-API
- Die TinyKVM-Codebasis selbst umfasst etwa 9k LOC → deutlich kleiner als konkurrierende Lösungen
- Beispiel: Wasmtime 350k LOC, FireCracker 165k LOC
- Statische Erstellung von Seitentabellen
- Seitentabellen können zur Laufzeit nicht verändert werden → erhöht die Sicherheit
- Führt Integritätsprüfungen der Seitentabellen durch
- Getrennter Prozesskontext
- KVM-Gäste verwenden separate PCID/ASID → widerstandsfähiger gegen spekulative Ausführungsangriffe wie Spectre
- Sicherheitsgehärteter Kernel
- SMEP und SMAP sind aktiviert
- CPU-Ausnahmen können im User-Mode behandelt werden
Behandlung von System Calls
- API-Verbindung zum Host
- System Calls werden über
SYSCALL/SYSRET oder die OUT-Instruktion ausgeführt
- Beim Ausführen eines System Calls tritt ein VM-Exit auf → dauert etwa 1μs
- Empfohlen wird ein API-Design mit wenigen kleinen Aufrufen und größeren I/O-Einheiten
Benchmarks
- Overhead bei VM-Aufrufen
- Gemessen wurde die Tail Latency beim Reset der VM
- Bei einfachen Aufrufen ohne Reset ist der Overhead gering
- Speicher-Performance
- Die Speicherleistung liegt im normalen Bereich
- Beispiel: Im HTTP-Benchmark sind 1500 AVIF-Kodierungen pro Sekunde möglich
- JPEG → AVIF-Konvertierungsleistung
- Etwa 1582 Bilder pro Sekunde können konvertiert werden
- Verlustfreie Konvertierung ist über den YUV-Konvertierungspfad möglich
Warum die Sandbox so schnell ist
- Kein I/O und keine Treiber
- Kein I/O, keine Treiber, keine virtuellen Geräte → verhindert Performance-Verluste
- Verwendet nur CPU-Ressourcen → kommt nativer Geschwindigkeit sehr nahe
- Hugepage-Optimierung
- Hugepages reduzieren Page Walks → verbessert die Performance
- Erreicht bei großen LLM-Workloads 99,7 % der nativen Performance
- Schnelle VM-Aufrufe
- Minimaler Overhead bei Funktionsaufrufen aus dem Gast
- Datenverarbeitung mit nativer CPU-Geschwindigkeit möglich
Einschränkungen
- Anzahl der vCPUs kann nicht reduziert werden
- Über die KVM-API kann die Anzahl der vCPUs nicht verringert werden
- Multiprocessing lässt sich stattdessen durch parallele Ausführung mehrerer VMs lösen
- Problem mit sinkender Reset-Performance
- Beim Zurücksetzen des VM-Zustands kann es zu Performance-Einbußen kommen
- Das lässt sich jedoch durch geteilten Zustand und Duplizierung lösen
Nächste Aufgaben
- Unterstützung für Intel TDX und AMD SEV hinzufügen
- Portierung auf AArch64
- Funktion zum Sperren von Speicher (
KVM_MEM_READONLY) hinzufügen → erhöht die Sicherheit
- Benutzerfreundlichere API verbessern
- Unterstützung für dynamisches Laden von Links ergänzen → stärkere Integration mit Varnish
Fazit
- TinyKVM ist eine der kleinsten und schnellsten Sandbox-Lösungen
- Erreicht sowohl mehr Sicherheit als auch Performance-Optimierung
- Die kleine Codebasis erleichtert die Wartung
- Wird als Open-Source-Bibliothek bereitgestellt → bei Interesse kann das Code-Repository angesehen werden
TinyKVM-Repository
2 Kommentare
Interessant.
Hacker-News-Kommentare
Ich mag das wirklich sehr. Hoffentlich macht ihr einfach weiter mit dem, woran ihr gerade arbeitet
Ähnlich wie Firecracker, aber viel schneller
Ursprünglicher Beitrag: Link
Wirklich interessant. Die Snapshot-Wiederherstellungsleistung von 2,5us ist vergleichbar mit Wasmtime, hat aber den großen Vorteil, nativen Code ausführen zu können. Allerdings ist die Interoperabilität deutlich langsamer, wenn auch immer noch im Mikrosekundenbereich
Ist das im Grunde nicht so etwas wie libkrun? Link
Das ist wohl nicht genau der vorgesehene Einsatzzweck, aber hat jemand Erfahrung damit, einen X-Server (oder Wayland) darauf auszuführen?
Interessant, aber ich habe Schwierigkeiten, das große Ganze zu verstehen. Führt man Benutzerprozesse in einer VM ohne Kernel aus? Führt jeder Systemaufruf zum Beenden der VM und wird dann an den Host weitergereicht? Oder gibt es keine Systemaufrufe?
Wenn es zum Anwendungsfall passt, ist das wirklich großartig
Wirklich cool
Im Artikel steht nicht, dass es auf Varnish läuft, und tatsächlich sagt der Autor, dass es nicht dafür gedacht ist, Varnish auszuführen