Hyperlight WASM: schnell, sicher und OS-frei

• Hyperlight Wasm ist die neueste Erweiterung von Hyperlight, der von Microsoft an die CNCF gespendeten ultraleichten Virtual-Machine-(VM)-Technologie, und führt WebAssembly-Workloads (auf Basis des Component Model) schnell und sicher aus
• Anders als herkömmliche VMs werden ohne OS oder virtuelle Geräte nur Memory-Slices und CPU exponiert, was schnelle Startzeiten von 1–2 ms ermöglicht
• In verschiedenen Sprachen (C, Rust, Go, Python, JS usw.) geschriebene Wasm-Komponenten können unter Hypervisor-Schutz ausgeführt werden

Hauptmerkmale von Hyperlight Wasm

• Schnellere Performance als herkömmliche VMs

  • Herkömmliche VM: Geräteinitialisierung → Kernel laden → OS booten → Anwendung ausführen (ca. 125 ms)
  • Hyperlight Wasm: Ausführung nur mit Erzeugen eines Memory-Slices + Laden von Wasm möglich (1–2 ms, künftig Ziel: <1 ms)
  • Die schnelle Ausführung ist vorteilhaft für On-Demand-Serverless-Ausführung oder minimal konfigurierte Warm Pools

• Verschiedene Sprachen auch ohne Betriebssystem ausführen

  • Auf Basis des Standards WASI und des WebAssembly Component Model können in den meisten Sprachen geschriebene Komponenten ausgeführt werden
  • Mit integrierter wasmtime-Runtime können auch Interpretersprachen wie Python, JavaScript und C# samt Runtime ausgeführt werden
  • Aus Entwicklersicht reicht es, einfach für das Target wasm32-wasip2 zu kompilieren, um in Hyperlight zu laufen

• Verbesserte Sicherheit (doppelte Sandbox)

  • Doppelte Schutzstruktur aus Wasm-Sandbox + Hypervisor-basierter VM-Sandbox
  • Selbst wenn ein Angreifer aus Wasm ausbricht, muss zusätzlich noch die VM-Sandbox umgangen werden

Entwicklungsbeispiel: Ausführen eines UDP-Echo-Servers auf Rust-Basis

• Download und Kompilierung des Wasm-Binärprogramms mit der wkg-CLI
• Umwandlung der WASI-Interface-Definitionsdatei (.wit) in Binärdateien zur Erzeugung von Bindings
• Mit hyperlight_component_macro und host_bindgen! werden Bindings für die Import-/Export-Schnittstellen von Wasm automatisch erzeugt
• Die Echo-Server-Logik wird durch Implementierung der UdpSocket-Schnittstelle definiert
• Erzeugen der hyperlight-wasm-Sandbox zum Laden und Ausführen der Wasm-Komponente

• Ahead-of-Time-Kompilierung

  • Mit dem Tool hyperlight-wasm-aot wird Wasm AOT-kompiliert, um die Laufzeit zu verkürzen
  • Der Server kann mit cargo run gestartet und per nc -u als UDP-Test geprüft werden

Skalierbarkeit und weitere Pläne

• Hyperlight Wasm soll nicht nur x86, sondern auch die Arm64-Architektur unterstützen
• Derzeit müssen WASI-Schnittstellen noch direkt implementiert werden, künftig sollen jedoch Standard-Bindings bereitgestellt werden
• Geplant ist, einfache Dienste wie HTTP-Server schnell sandboxen zu können

Hinweise zur Beteiligung an der Open-Source-Community

• Hyperlight ist ein von Microsoft als Open-Source-Projekt unter der Apache-2.0-Lizenz veröffentlichtes Projekt und im CNCF Sandbox registriert
• Hyperlight Wasm zielt darauf ab, eine schnelle und sichere Laufzeitumgebung zu bieten, die sich für Cloud-native Computing eignet
• Über das GitHub-Repository können Code eingesehen und Beiträge geleistet werden

👉 GitHub-Repository: hyperlight-wasm

[galadbran]

Hyperlight – leichter Virtual Machine Manager (VMM) | GeekNews

[GN⁺]

Hacker-News-Kommentare

• Ich habe vor ein paar Monaten angefangen, WebAssembly ernsthaft zu nutzen, um eine Backend-Authentifizierungsbibliothek zu bauen, die in mehreren Sprachen funktioniert

  • Basierend auf Extism wurde die Komplexität der Schnittstellen reduziert
  • Es war eine fast magische Erfahrung
  • WASM befindet sich an einem interessanten Punkt
  • Mit einer minimalen Kernspezifikation hat es seinen Wert bewiesen
  • Jetzt gibt es einen großen Vorstoß, eine größere API-Oberfläche für WASI und das Component Model zu implementieren
  • Viele in der Community sind über diese Richtung besorgt
  • Ich persönlich hoffe, dass WASM nicht so komplex wird, dass es denselben Weg geht wie Webbrowser, bei denen nur große Tech-Konzerne Implementierung und Experimente stemmen können

• Vor ein paar Monaten haben wir Hyperlight angekündigt, ein leichtgewichtiges VMM

  • Neue VMs können in etwa 1 Millisekunde erzeugt werden
  • Heute freuen wir uns, den Hyperlight-Wasm-Gast auf Basis der Wasmtime-Runtime vorzustellen
  • Damit können Wasm-Component-Binärdateien über die WASI-Schnittstelle ohne ein Gast-OS in der VM ausgeführt werden
  • In diesem Beitrag wird erklärt, wie es funktioniert, und es wird anhand von Beispielen gezeigt

• Ich bin sehr gespannt

  • Ich hoffe, dass WASM/WASI zu dem Traum heranwächst, den die JVM in den 90ern verkörperte
  • Es könnte ein speichersicheres Entwicklungsziel werden, das sich leicht auf viele Plattformen portieren und testen lässt
  • Ich hoffe, dass WASM für viel mehr als nur Browser genutzt werden kann

• Sieht interessant aus

  • Ist das ein Anwendungsfall dafür, wenn man so etwas wie Cloudflare Workers oder Lambda direkt mit WASM implementieren möchte?

• Cool

  • Ich versuche zu verstehen, worin hier der zusätzliche Nutzen liegt
  • Wie unterscheidet sich das davon, es einfach über wasmtime auszuführen?

• Bei all diesen coolen und interessanten Projekten wirkt es so, als sei WASM überall außer im Browser erfolgreich

  • Vielleicht sollte man das Web aus WebAssembly streichen und ihm einen anderen Namen geben

• Hat jemand eine Idee, wie man das in ein Proxmox-Setup integrieren könnte?

  • Ich verstehe es so, dass das dafür gedacht ist, auf Bare Metal zu laufen
  • Ich habe keine freie Bare-Metal-x86-Hardware herumliegen, daher ist das etwas umständlich
  • Wahrscheinlich müsste ich es einfach in eine VM packen und Nested Virtualization in Kauf nehmen

• Wie werden Instanzen gestartet und verwaltet?

  • Über welche API läuft das?
  • Könnte man damit einen Baum von mit einer Wasm-Component-Binärdatei verbundenen Wasm Components ausführen, Fähigkeiten delegieren und den Lebenszyklus verwalten?

• Im Grunde gibt es eine VM (Wasm), um Programme in einer Hardware-VM zu sandboxen, die wiederum eine Abstraktion ist, um Programme in einem User-Space-Prozess (Linux-Prozess) zu isolieren

  • Habt ihr darüber nachgedacht, einfach Unix-Prozesse zur Isolation von Programmen zu verwenden?

• Ist das ein Unikernel/ein Library-OS?