Développer une VM WebAssembly écrite en C

Qu’est-ce que WebAssembly ?

• WebAssembly est un ensemble d’instructions standardisé et un format de bytecode conçus pour exécuter du code client non fiable dans le navigateur web à une vitesse proche du natif.
• Il est issu d’Emscripten, un compilateur de C/C++ vers JavaScript, qui convertissait à l’origine du LLVM IR en JavaScript pour permettre l’exécution de code C et C++ sur le web.
• Avec le temps, les développeurs de navigateurs ont collaboré avec le projet Emscripten pour créer un sous-ensemble simple de JavaScript optimisé pour les performances, qui a été standardisé sous le nom d’asm.js.
• Ensuite, afin d’éviter la surcharge de JavaScript, un format de bytecode indépendant a été conçu : c’est Wasm.
• Récemment, WebAssembly a aussi gagné en popularité en dehors du navigateur, et Fastly comme Shopify ont construit leurs produits Edge Compute et Functions sur des moteurs WebAssembly.
• WebAssembly est une plateforme attrayante pour bâtir un écosystème de plugins grâce à sa capacité à être ciblé depuis divers langages sources.

Pourquoi un interpréteur WebAssembly ?

• Comme beaucoup d’ingénieurs logiciel, l’auteur avait pris l’habitude de lancer de nouveaux side projects puis d’en perdre l’intérêt après quelques semaines.
• Il lui fallait un projet d’envergure dans lequel investir des efforts sur la durée, tout en l’exposant à des couches plus basses de la pile informatique.
• Il s’est intéressé au battage autour de WebAssembly, qui lui semblait être un outil d’ingénierie de plateforme séduisant, permettant de concevoir des appels système personnalisés.

Semblance

• Il a décidé d’écrire un interpréteur WebAssembly afin de se familiariser avec la spécification cœur de WebAssembly.
• Comme l’objectif du projet était l’apprentissage, il n’avait pas prévu d’implémenter tous les opcodes ni de faire passer toute la suite de tests du noyau.
• Pouvoir exécuter un simple "Hello, World!" lui suffirait.

Résultat

• Le projet est considéré comme un grand succès. La couverture des opcodes n’est pas complète, mais il peut exécuter un programme simple de type "Hello, World!".
• Le code est désordonné, lent, présente des fuites mémoire et peut être vulnérable à des modules malveillants, mais il fonctionne.
• Cela lui a permis d’apprendre énormément sur la spécification cœur de WebAssembly et de sortir de sa zone de confort en tant qu’ingénieur.
• Il estime désormais avoir acquis suffisamment de connaissances sur WebAssembly pour pouvoir contribuer à des runtimes industriels comme Wasmtime.

[GN⁺]

Commentaires sur Hacker News

• J’ai déjà eu l’expérience d’écrire un interpréteur Wasm en Scheme, donc cela me fait plaisir de voir d’autres personnes le faire elles-mêmes. Wasm est moins difficile qu’on ne le pense, et je recommande d’essayer juste assez pour y prendre goût, sans forcément implémenter toutes les instructions.

  • Un conseil pour l’auteur : les spec-tests contiennent du wasm textuel sous des formes complexes, mais en utilisant le convertisseur wast2json, on peut obtenir une description JSON plus simple ainsi que des fichiers wasm binaires classiques.

• Question de débutant :

  • Je me demande comment on débogue quand on ne code pas soi-même l’interpréteur.
  • Je me demande à quel point le fuzzing des opcode sous forme de chaînes est efficace.
  • Je me demande quelle est la différence réelle entre un moteur WASM côté serveur et un moteur basé sur le navigateur, et combien de travail il faudrait pour transformer l’un en l’autre.

• J’ai trouvé cet article intéressant sur l’interprétation directe de WASM.

  • En m’appuyant dessus, j’ai créé https://github.com/peterseymour/winter, et j’y ai appris que WASM n’est pas aussi simple qu’il en a l’air.

• Approche intéressante, et excellent travail.

  • L’essentiel se trouve surtout dans ce fichier : https://github.com/irrio/semblance/blob/main/src/wrun.c

• Je pense qu’adopter la Wasm-C-API comme interface standard aurait été une bonne idée.

  • C’est une API adoptée par la plupart des runtimes Wasm (Wasmmer, V8, wasmi, etc.), écrite en C, ce qui permet aux développeurs familiers avec cette API de s’y essayer facilement.
  • Si l’auteur connaît bien Wasm, ses patchs ou améliorations pour Wasmer seraient aussi les bienvenus.

• Point sujet à controverse :

  • Je me demande s’il y a un intérêt à ajouter des instructions initiales de tail call.
  • Les responsables de la spec WASM les ont rejetées en les qualifiant de « haut niveau », mais le comité C avait aussi rejeté la proposition de Dennis Ritchie. Rob Pike semble également soutenir l’orientation de Ritchie. Sinon, pourquoi aurait-il créé Golang ? Les tail calls ne sont de haut niveau que lorsque l’appel lui-même est de haut niveau.

• Je recommande de jeter un œil à Orca. Cela pourrait être une bonne occasion de contribuer : https://orca-app.dev

• C’est vraiment chouette de voir quelqu’un explorer WebAssembly en profondeur et construire un interpréteur depuis zéro.

• Excellent article, qui me redonne envie de me replonger dans une implémentation de WASM.

• Travail vraiment impressionnant.