uvm32 - sandbox VM ultra-compact écrite en C, avec prise en charge de l’exécution d’apps Rust, C et Zig

 (github.com/ringtailsoftware)
11 points par GN⁺ 2025-12-15 | 3 commentaires | Partager sur WhatsApp
  • uvm32 est un sandbox de machine virtuelle minimaliste pour les environnements à ressources limitées comme les microcontrôleurs, composé d’un unique fichier C et fonctionnant sans allocation mémoire dynamique
  • Basé sur un émulateur RISC-V, il exécute des applications bytecode écrites en C, Zig, Rust et assembleur, avec une conception asynchrone qui empêche le blocage de l’hôte
  • Il peut fonctionner avec moins de 3 KB de flash et moins de 1 KB de RAM ; la sécurité étant prioritaire, un code incorrect ne fait pas planter l’hôte
  • Il fournit divers exemples d’hôtes VM et des applications d’exemple par langage, ce qui permet une intégration dans des contextes variés comme l’embarqué, le jeu ou les plugins
  • Publié sous licence MIT, il peut être utilisé librement dans la recherche, les produits et les appareils embarqués

Aperçu de uvm32

  • uvm32 est un sandbox de machine virtuelle léger sans dépendances, conçu pour les microcontrôleurs et les appareils aux ressources contraintes
    • Structure en un seul fichier C, basé sur le standard C99, conception asynchrone, sans mémoire dynamique
    • Fonctionne sous le seuil de 3 KB de flash / 1 KB de RAM sur STM32L0 (ARM Cortex-M0+)
  • Il repose sur un émulateur RISC-V et inclut une interface d’administration ainsi que des outils efficaces de build du code

Principaux cas d’usage

  • Remplacer des moteurs de script embarqués comme Lua, Duktape, MicroPython
  • Isoler du code non fiable via un environnement sandbox
  • Permettre le développement avec des langages système modernes comme Rust et Zig
  • Réduire la maintenance multi-plateforme selon le principe “Write once, run anywhere”

Caractéristiques principales

  • Inclut des exemples de bytecode écrits en C, Zig, Rust et assembleur
  • La conception non bloquante empêche un code anormal d’arrêter l’hôte
  • Aucune hypothèse sur les E/S de l’hôte, avec un modèle d’exécution simple et cohérent
  • Fournit une FFI minimale et sûre
  • Peut exécuter aussi bien de petits scripts que des applications complexes
  • Conception orientée sécurité : les erreurs internes à la VM n’endommagent pas l’hôte
  • Basé sur un émulateur CPU complet, mais pas destiné à la simulation matérielle

Comparaison avec les alternatives

  • Empreinte mémoire plus réduite que les moteurs de script embarqués existants
  • Prise en charge de langages largement utilisés comme C, Rust et Zig
  • Intégration facile avec les logiciels existants
  • Prise en charge de divers paradigmes comme event-driven, polling et multiprocesseur
  • Grande robustesse face à du code VM anormal
  • En revanche, les appels FFI directs, l’efficacité maximale, une expérience de scripting simple et l’intégration d’une bibliothèque standard ne sont pas des objectifs

Build et exécution (Docker)

  • Peut être buildé avec un simple compilateur C, avec un environnement Docker fourni
    • Configuration de l’environnement avec les commandes make dockerbuild, make dockershell
    • Après avoir exécuté make dans le shell Docker,
      il est possible de lancer ./hosts/host/host apps/helloworld/helloworld.bin
  • La commande host -h permet de voir toutes les options

Licence

  • Licence MIT
  • Utilisable librement pour la recherche, les produits et les appareils embarqués

À lire aussi

3 commentaires

 
GN⁺ 2025-12-15
Commentaires sur Hacker News

  • En regardant le code, il avait vraiment une structure compacte
    Je ne l’ai ni compilé ni exécuté moi-même, mais il inclut les extensions d’instructions RISC-V 32 bits pour les entiers, la multiplication et les opérations atomiques
    Les opérations en virgule flottante ne sont pas émulées par l’émulateur, mais par le compilateur (gcc, etc.) via des fonctions logicielles
    Le fait que cela soit pris en charge par plusieurs compilateurs me semble être une conception très astucieuse
    Le projet de base qui implémente réellement le jeu d’instructions est mini-rv32ima

  • Ce projet semble se situer dans un espace proche des tentatives visant à créer un environnement d’exécution commun comme WASM
    La différence étant qu’il repose sur RISC-V
    J’aimerais mieux comprendre les limites et les avantages de chaque approche, mais quoi qu’il en soit, on a l’impression d’aller vers un futur où les applications tourneront sur une VM commune
    Le web moderne me semble en être l’exemple le plus proche

    • J’avais déjà comparé rapidement WASM et libriscv, et j’avais choisi WASM à cause de la compatibilité navigateur
      libriscv est aussi un projet sympa et impressionnant
      Pour référence, la discussion correspondante est ici
    • En lisant l’article sur Wasefire du blog open source de Google, l’empreinte du code semble plus petite
      Cela dit, RISC-V n’est peut-être pas adapté à ce type d’usage
      Par exemple, si le décodage des valeurs immédiates est géré en logiciel, cela devient lent, alors qu’en matériel c’est rapide
      Malgré cela, RISC-V reste une cible stable et simple à mettre en place

  • Le code est vraiment propre, et j’aime bien la structure en fichier C unique
    La manière d’utiliser Docker pour exécuter les exemples est aussi très pratique en environnement embarqué
    La couverture de test semble bonne, et il serait intéressant de voir aussi les métriques
    Pour ajouter des capacités de scripting à un dispositif médical, cela pourrait avoir l’avantage d’éviter de revalider à chaque fois le code cœur
    Ce serait intéressant de comparer cela à un interpréteur WASM embarqué comme WASM Micro Runtime
    Sur Cortex M4F, celui-ci est bien plus gros, à 56.3K
    C’est probablement parce que WASM a un jeu d’instructions plus complexe que le profil RISC-V minimal

  • « Just add rats », en présentant l’exemple ZigDoom

  • Le timing est parfait
    Je cherchais justement un émulateur léger pour tester du firmware embarqué, mais la plupart des alternatives étaient soit trop lourdes, soit instables
    S’il prend en charge la simulation d’E/S mappées en mémoire, cela pourrait être utile pour tester des pilotes IoT ou microcontrôleurs sans matériel réel

    • C’est facile à implémenter
      Le cœur de l’émulateur prend déjà en charge les E/S mappées en mémoire, mais uvm32 ne les utilise que comme blocs de RAM supplémentaires côté hôte (framebuffer ou heap séparé, par exemple)
      Les pièges d’écriture peuvent être gérés ici, et les pièges de lecture ici
 
balthasar 2025-12-15

Je ne sais pas de quel commentaire sort cette histoire de phishing à la fin.
 
xguru 2025-12-15

Ce commentaire a été signalé comme spam et a disparu, donc il ne restait que la réponse, ce qui donnait quelque chose d’étrange. Je vais le supprimer.