uvm32 – Ultrakleine VM-Sandbox in C mit Unterstützung für Rust-, C- und Zig-Apps

 (github.com/ringtailsoftware)
11 Punkte von GN⁺ 2025-12-15 | 3 Kommentare | Auf WhatsApp teilen
  • uvm32 ist eine minimale Virtual-Machine-Sandbox für ressourcenbeschränkte Umgebungen wie Mikrocontroller, besteht aus einer einzigen C-Datei und arbeitet ohne dynamische Speicherallokation
  • Auf Basis eines RISC-V-Emulators führt sie Bytecode-Apps aus, die in C, Zig, Rust oder Assembler geschrieben wurden, und verhindert durch ihr asynchrones Design ein Blockieren des Hosts
  • Der Betrieb ist mit unter 3 KB Flash und unter 1 KB RAM möglich; Sicherheit hat Priorität, sodass fehlerhafter Code den Host nicht zum Absturz bringt
  • Es werden verschiedene VM-Host-Beispiele und sprachspezifische Beispiel-Apps bereitgestellt, wodurch eine Integration in Umgebungen wie Embedded, Spiele oder Plugins möglich ist
  • Veröffentlicht unter der MIT-Lizenz, frei nutzbar für Forschung, Produkte und Embedded-Geräte

Überblick über uvm32

  • uvm32 ist eine abhängigskeitsfreie leichtgewichtige Virtual-Machine-Sandbox, die für Mikrocontroller und Geräte mit begrenzten Ressourcen entwickelt wurde
    • Aufbau aus einer einzelnen C-Datei, auf dem C99-Standard basierend, asynchrones Design, keine dynamische Speicherallokation
    • Läuft auf einem STM32L0 (ARM Cortex-M0+) mit weniger als 3 KB Flash / 1 KB RAM
  • Sie basiert auf einem RISC-V-Emulator und enthält eine Verwaltungsoberfläche sowie effiziente Tools zum Erstellen von Code

Wichtige Einsatzbereiche

  • Ersatz für eingebettete Skript-Engines wie Lua, Duktape, MicroPython
  • Isolierung von nicht vertrauenswürdigem Code durch eine Sandbox-Umgebung
  • Unterstützung der Entwicklung mit modernen Systemsprachen wie Rust und Zig
  • Minimierter Wartungsaufwand für mehrere Plattformen nach dem Prinzip „Write once, run anywhere“

Zentrale Merkmale

  • Enthält Bytecode-Beispiele, geschrieben in C, Zig, Rust und Assembler
  • Non-Blocking-Design, damit fehlerhafter Code den Host nicht anhält
  • Keine Annahmen über Host-I/O, einfaches und konsistentes Ausführungsmodell
  • Bietet eine sichere minimale FFI
  • Kann von kleinen Skripten bis zu komplexen Anwendungen alles ausführen
  • Sicherheitsorientiertes Design, bei dem Fehler innerhalb der VM den Host nicht beschädigen
  • Basiert auf einem vollständigen CPU-Emulator, ist jedoch nicht für Hardware-Simulation gedacht

Vergleich mit Alternativen

  • Kleinerer Speicher-Footprint als bestehende Embedded-Skript-Engines
  • Unterstützung verbreiteter Sprachen wie C, Rust und Zig
  • Einfache Integration in bestehende Software
  • Unterstützung verschiedener Paradigmen wie ereignisbasiert, Polling und Multiprozessor
  • Hohe Robustheit gegenüber fehlerhaftem VM-Code
  • Dagegen sind direkte FFI-Aufrufe, maximale Effizienz, eine einfache Skripting-Erfahrung und eine eingebaute Standardbibliothek nicht das Ziel

Build und Ausführung (Docker)

  • Kann allein mit einem C-Compiler gebaut werden, Docker-Umgebung wird bereitgestellt
    • Umgebung einrichten mit den Befehlen make dockerbuild und make dockershell
    • Nach Ausführung von make innerhalb der Docker-Shell kann
      ./hosts/host/host apps/helloworld/helloworld.bin ausgeführt werden
  • Mit dem Befehl host -h lassen sich alle Optionen anzeigen

Lizenz

  • Unter der MIT License veröffentlicht
  • Frei verwendbar in Forschung, Produkten und Embedded-Geräten

Verwandte Beiträge

3 Kommentare

 
GN⁺ 2025-12-15
Hacker-News-Kommentare

  • Beim Blick in den Code fiel auf, wie kompakt die Struktur wirklich ist.
    Ich habe es zwar nicht selbst kompiliert oder ausgeführt, aber es unterstützt die RISC-V-32-Bit-Erweiterungen für Integer-, Multiplikations- und atomare Instruktionen.
    Gleitkommaoperationen werden nicht vom Emulator, sondern vom Compiler (gcc usw.) über Softwarefunktionen emuliert.
    Dass dies von mehreren Compilern unterstützt wird, wirkt wie ein sehr cleveres Design.
    Das zugrunde liegende Projekt, das den eigentlichen Befehlssatz implementiert, ist mini-rv32ima.

  • Dieses Projekt scheint in einem ähnlichen Bereich zu liegen wie Versuche, eine gemeinsame Laufzeitumgebung wie WASM zu schaffen.
    Der Unterschied ist allerdings, dass es auf RISC-V basiert.
    Ich würde gern mehr über die Grenzen und Vorteile der jeweiligen Ansätze wissen, aber es wirkt auf jeden Fall so, als gingen wir in eine Zukunft, in der Anwendungen auf einer gemeinsamen VM laufen.
    Das moderne Web ist dafür vermutlich das naheliegendste Beispiel.

    • Ich habe früher einmal kurz WASM und libriscv verglichen und mich wegen der Browser-Kompatibilität für WASM entschieden.
      libriscv ist aber ebenfalls ein cooles und beeindruckendes Projekt.
      Der zugehörige Diskussionslink ist hier.
    • Im Wasefire-Beitrag im Google Open Source Blog wirkt der Code-Footprint kleiner.
      Allerdings ist RISC-V für solche Einsatzzwecke womöglich nicht ideal.
      Wenn man zum Beispiel die Immediate-Dekodierung in Software verarbeitet, ist das langsam, in Hardware aber schnell.
      Trotzdem ist RISC-V ein stabiles Ziel, das sich einfach halten lässt.

  • Der Code ist wirklich sauber, und die Single-C-File-Struktur gefällt mir.
    Auch der Einsatz von Docker zum Ausführen der Beispiele ist in Embedded-Umgebungen sehr praktisch.
    Die Testabdeckung sieht ebenfalls gut aus, und es wäre interessant, sich die Metriken anzusehen.
    Wenn man Medizingeräten Scripting-Funktionen hinzufügt, könnte das den Vorteil haben, dass man den Kerncode nicht jedes Mal neu validieren muss.
    Ein Vergleich mit einem Embedded-WASM-Interpreter wie WASM Micro Runtime wäre interessant.
    Auf einem Cortex M4F ist dieser mit 56.3K deutlich größer.
    Vermutlich liegt das daran, dass WASM im Vergleich zu einem minimalen RISC-V-Profil ein komplexerer Instruktionssatz ist.

  • Mit „Just add rats“ wurde das Beispiel ZigDoom vorgestellt.

  • Das Timing ist perfekt.
    Ich war gerade auf der Suche nach einem leichten Emulator für Embedded-Firmware-Tests, aber die meisten Alternativen waren zu schwergewichtig oder instabil.
    Falls Memory-Mapped-IO-Simulation unterstützt wird, könnte das für Tests von IoT- oder Mikrocontroller-Treibern ohne echte Hardware nützlich sein.

    • Das lässt sich leicht umsetzen.
      Der Emulator-Kern unterstützt bereits Memory-Mapped IO, aber uvm32 nutzt das nur als zusätzliche RAM-Blöcke auf dem Host (Framebuffer oder separater Heap usw.).
      Write-Traps lassen sich hier, Read-Traps hier behandeln.
 
balthasar 2025-12-15

Ich weiß ehrlich gesagt nicht, aus welchem Kommentar am Ende plötzlich dieses Gerede über Phishing stammt.
 
xguru 2025-12-15

Der Kommentar wurde wohl als Spam markiert und ist verschwunden, sodass nur die Antwort übrig blieb und es deshalb merkwürdig wirkte. Ich werde ihn entfernen.