Pour rappel, WebAssembly a été présenté comme une architecture de jeu d’instructions virtuel avec de nombreux cas d’utilisation capable de prendre du code écrit dans des langages de programmation autres que JavaScript et d’exécuter ce code sur une plateforme spécifique – du moins à l’origine -, un navigateur en l’occurrence. Cette solution devrait également permettre aux applications complexes - telles que les jeux vidéo immersifs en 3D, le design informatisé ou l’édition d’images et de vidéos - de fonctionner de façon optimale sur les plateformes cibles. Grâce à WebAssembly, des développeurs seraient par exemple en mesure de coder leurs applications en C, C++ ou en Rust et de faire exécuter ces programmes à la vitesse native sur un navigateur Web, sans avoir à repasser par JavaScript avec les contraintes que cela impose.
Selon les promoteurs l’initiative, la montée en puissance du Cloud et des périphériques IoT fait que les développeurs exécutent du code non fiable dans de nouveaux environnements, ce qui soulève de nouveaux problèmes, notamment en matière de sécurité et de portabilité. L’Alliance Bytecode devra fournir une base permettant aux développeurs d’exécuter en toute confiance du code non fiable sur n’importe quelle infrastructure, système d’exploitation et périphérique. Cette communauté open source se focalisera sur la mise en place d’un environnement d’exécution et de chaînes d’outils linguistiques associées – incluant cargo-wasi, wat et wasmparser – qui offrent sécurité, efficacité et modularité sur une large gamme d’architectures et de périphériques. Le projet devrait s’appuyer sur les normes existantes telles que WebAssembly et WebAssembly System Interface (WASI).
Les nanoprocessus de WebAssembly
WebAssembly peut fournir le type d’isolation qui permet d’exécuter en toute sécurité du code non fiable, grâce à une architecture similaire aux nombreux petits processus d’Unix, ou aux conteneurs et aux microservices. Toutefois, cet isolement est beaucoup plus léger et la communication entre les nanoprocessus de WebAssembly ne souffre d’aucune réduction de performance, au contraire. Cela signifie que vous pouvez les utiliser pour empaqueter une seule instance de module WebAssembly ou une petite collection d’instances de module qui veulent partager des choses comme la mémoire entre eux. De plus, vous n’avez pas besoin d’abandonner le langage de programmation, comme les signatures de fonctions et le contrôle de type statique.
Cette propriété est due au fait que chaque module WebAssembly est sandboxé par défaut ainsi qu’à la particularité de l’architecture mémoire. En effet, chaque module WebAssembly n’a pas accès à la totalité de la mémoire dans son processus - uniquement au bloc de mémoire qui lui a été assigné et qui est isolé du reste du pool -. En parallèle, grâce à une fonctionnalité introduite en aout dernier sur WebAssembly - les types d’interfaces -, il est facile pour deux modules d’échanger des données, mais toujours de façon sécurisée et rapide, et le moteur de WebAssembly permet d’effectuer des copies directes au niveau de la mémoire. Ces opérations fonctionnent même si les deux modules ne sont pas compilés à partir du même langage.
Malheureusement, la façon dont la plupart des systèmes d’exploitation gèrent l’accès au système de fichiers n’offre pas forcément un niveau de sécurité optimal et il ne suffit pas de prendre des précautions vis-à-vis de la gestion mémoire entre les modules WabAssembly pour que tout soit parfaitement sécurisé. Il faut aller encore plus loin et s’intéresser aux API et aux appels système qui intègrent « ;le concept de permission ;», de sorte qu’ils puissent octroyer différentes permissions à différents modules et différentes ressources. C’est là qu’intervient la fonctionnalité baptisée WASI (WebAssembly system interface) qui permet d’isoler ces différents modules les uns des autres, de leur octroyer avec précision des permissions bien spécifiques et de verrouiller le système.
Malgré tout, le système n’est pas encore au point, les développeurs en charge du projet ayant eux-mêmes reconnu que pour l’instant, ils n’ont trouvé aucun moyen de faire passer les clés de contrôle du système par l’arbre des dépendances. À ce sujet, ils ont confié : « ;Nous avons besoin d’un moyen pour permettre aux modules parents de donner ces clés à leurs dépendances. De cette façon, ils peuvent donner à leurs dépendances exactement les clés dont ils ont besoin et aucune autre. Et puis, ces dépendances peuvent faire la même chose pour leurs enfants, jusqu’au bout de l’arbre ;». Mais ils comptent bien s’attaquer à cet ultime défi. Sur le plan technique, ils prévoient d’utiliser une forme de virtualisation granulaire par module. L’idée est de fournir un écosystème WebAssembly sécurisé par défaut pour toutes les plateformes qui pourra protéger efficacement contre les codes malveillants ou les vulnérabilités inhérentes au code, par exemple.
L’avis des promoteurs du projet
Luke Wagner, un ingénieur chez Mozilla, a expliqué à ce propos : « ;Le standard WebAssembly est en train de transformer le Web et nous pensons qu’il peut jouer un rôle encore plus important au sein de l’écosystème des logiciels, en se développant au-delà des navigateurs. C’est un moment unique pour cette nouvelle technologie, car nous avons l’occasion de réparer ce qui est obsolète et d’établir, pour un développement natif, de nouvelles fondations sécurisées par défaut, mobiles et évolutives. Nous devons toutefois prendre des mesures réfléchies et à travers l’industrie pour nous assurer que ces mesures sont bien appliquées ;».
De son côté Mark Skarpness, vice-président de la division Architecture, Graphiques et Logiciels d’Intel a déclaré : « ;Intel rejoint l’Alliance Bytecode en tant que membre fondateur afin d’offrir à un large éventail d’applications et de serveurs de meilleures performances et une sécurité renforcée de l’environnement WebAssembly, en allant au-delà du navigateur. Les technologies de l’alliance Bytecode peuvent aider les développeurs à faire évoluer les logiciels en utilisant une multitude de langages et en s’appuyant sur toutes les capacités des plateformes de calcul de dernière génération ;».
Chris Wright, Senior Vice-President et Chief Technology Officer chez Red Hat, estime quant à lui que « ;les technologies Open Source jouent un rôle important dans la mise en place des fondations informatiques, du système d’exploitation au navigateur en passant par des clouds hybrides ouverts ;». Il a ajouté : « ;Nous sommes heureux de participer avec nos partenaires à son évolution vers un projet mature et entièrement communautaire ;».
Un certain nombre de projets open source ont été apportés à ce projet par les différents membres. Il s’agit notamment de :
- Wasmtime, un environnement d’exécution léger et performant pour WebAssembly et WASI ;;
- Lucet, un environnement d’exécution avec compilation hors ligne pour WebAssembly et WASI axé sur les applications à faible latence et à haute concurrence ;;
- WebAssembly Micro Runtime (WAMR), un environnement d’exécution WebAssembly basé sur un interpréteur pour les périphériques embarqués ;;
- Cranelift, un générateur de code multiplateforme qui met l’accent sur la sécurité et la performance, écrit en Rust.
Source : Mozilla, Alliance ByteCode
Et vous ?
Que pensez-vous de cette initiative ?
Voir aussi
Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude
50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig
RustPython, un interpréteur Python écrit en Rust et compatible avec WebAssembly, est disponible, pourrait-il rivaliser avec CPython ?
Mozilla finance un portage de Julia en WebAssembly afin d'effectuer des calculs lourds au sein du navigateur