Construire un unikernel capable d’exécuter WebAssembly - Partie 1

• Article sur le projet de l’auteur pendant la Hackweek 22 de SUSE : il a construit un unikernel capable d’exécuter WebAssembly.
• L’auteur a choisi ce projet pour plusieurs raisons, notamment les avantages potentiels de la combinaison des unikernels et de WebAssembly.
• Du point de vue des développeurs d’applications, il peut être difficile de porter ou d’écrire une application pour un unikernel, car l’application et ses dépendances doivent être prises en charge par l’unikernel cible.
• Les mainteneurs d’unikernels ont eux aussi du mal à garantir qu’une application puisse s’exécuter sans accroc sur leur plateforme, en raison de primitives système méconnues pouvant être exploitées par les applications utilisateur.
• En revanche, lorsqu’on cible la plateforme WebAssembly, les applications disposent d’un ensemble clair de fonctionnalités qui doivent être fournies par le runtime WebAssembly.
• L’auteur a utilisé le projet RustyHermit, un unikernel écrit en Rust, comme base de l’application unikernel.
• L’auteur a également rencontré des difficultés liées au runtime WebAssembly, car Wasmtime, son runtime de prédilection, n’est pas conçu pour fonctionner sur RustyHermit. Il a finalement trouvé puis utilisé wasmi, un runtime WebAssembly entièrement écrit en Rust.
• L’auteur évoque aussi l’utilisation de la proposition WebAssembly Component Model dans Spiderlightning, qui permet de fournir des fonctionnalités aux invités WebAssembly et au host d’utiliser les fonctionnalités fournies par les invités WebAssembly.
• L’auteur a dû étendre wit-bindgen, un outil CLI qui génère du code host/invité à partir de fichiers .wit, afin de prendre en charge le runtime WebAssembly wasmi.
• L’auteur conclut son billet avec un enregistrement d’une application unikernel exécutant la démo http-server de Spiderlightning, et promet d’aborder ensuite Rust async, Redis et quelques erreurs dans la suite de son parcours.

[GN⁺]

Avis Hacker News

• Des utilisateurs le rapprochent de la conférence « la naissance et la mort de JavaScript »
• Discussion sur la meilleure façon, pour un hacker non spécialisé OS, d’aborder les unikernels, avec plusieurs options proposées : construire une application comme module du noyau Linux, bidouiller Linux et y injecter du code, ou utiliser un projet d’unikernel sur GitHub
• Proposition et discussion autour de l’idée d’une machine x64 exécutant des VM connectées à une carte réseau comme ressource de calcul générale
• Enthousiasme pour WebAssembly (WASM), dont les utilisateurs saluent le sandboxing et la portabilité, certains regrettant qu’il n’ait pas été inventé à la place de JavaScript dans les années 1990
• Des utilisateurs espèrent la pérennité de WASM à long terme, voyant comme problème son incapacité à exécuter de nombreux anciens programmes et souhaitant que WASM puisse y remédier
• Interrogations sur le potentiel d’un matériel WASM dédié, signe d’un intérêt pour les évolutions futures de la technologie
• Curiosité des utilisateurs concernant les cas d’usage des unikernels et de WASM, reflétant un désir d’applications pratiques de la technologie
• Discussion autour de l’idée d’un unikernel exécutant un runtime à ramasse-miettes sûr dans l’espace noyau, avec l’hypothèse que cela pourrait supprimer le besoin de la prise en charge du mappage de mémoire virtuelle dans le CPU et ainsi le rendre plus rapide
• Un commentaire signalé, « Molto interessante, complimenti », signifie en italien « Très intéressant, félicitations »