Par Marco Fioretti

WebAssembly (Wasm) est un format de logiciel binaire que tous les navigateurs peuvent exécuter directement, sans encombre et à des vitesses quasi-natives, sur n’importe quel système d’exploitation (OS). Sa plus grande promesse, cependant, est de travailler éventuellement de la même manière partout, des appareils IoT et des serveurs de périphérie aux appareils mobiles et aux postes de travail traditionnels. Cet article présente l’interface principale qui devrait y parvenir. Le prochain article de cette série décrira certaines des implémentations et applications déjà disponibles dans le monde réel de la même interface.

Qu’est-ce que la portabilité, encore une fois?

Pour être sûr et portable, le code logiciel doit au minimum:

1. garantit que les utilisateurs et les programmes ne peuvent faire que ce qu’ils avoir le droit de le faire et de le faire uniquement sans créer de problèmes pour d’autres programmes ou utilisateurs
2. méthodes standard et indépendantes de la plate-forme pour déclarer et appliquer ces garanties

Traditionnellement, ces services sont fournis par des bibliothèques «d’appels système» pour chaque langage, c’est-à-dire des fonctions avec lesquelles un programme logiciel peut demander à son système d’exploitation hôte d’effectuer une tâche de bas niveau ou sensible. Lorsque ces bibliothèques respectent des normes telles que POSIX, tout compilateur peut les combiner automatiquement avec le code source, pour produire un fichier binaire qui peut fonctionner sur quelque combinaison de systèmes d’exploitation et de processeurs.

Le niveau suivant: la compatibilité BINAIRE

Les appels système ne font que code source portable sur toutes les plates-formes. Aussi utiles soient-ils, ils obligent toujours les développeurs à générer des fichiers exécutables spécifiques à la plateforme, trop souvent à partir de combinaisons plus ou moins différentes de code source.

WebAssembly vise plutôt à passer au niveau suivant: utilisez le langage de votre choix, puis compilez-le une fois, pour produire un fichier binaire qui cours juste, en toute sécurité, dans tout environnement qui reconnaît WebAssembly.

Ce dont Wasm n’a pas besoin pour fonctionner en dehors des navigateurs

Étant donné que WebAssembly «compile déjà une fois» pour tous les principaux navigateurs, le moyen le plus simple d’étendre sa portée peut sembler créer, pour chaque environnement cible, une machine virtuelle complète (runtime) qui fournit tout ce qu’un module Wasm attend de Firefox ou Chrome.

Travailler comme ça serait cependant vraiment complexe, et surtout simplement inutile, voire impossible, dans de nombreux cas (par exemple sur les appareils IoT). En outre, il existe de meilleures façons de sécuriser les modules Wasm que de les vider dans des bacs à sable à taille unique, comme le font les navigateurs aujourd’hui.

La solution? Un système d’exploitation et un runtime virtuels

Les modules Wasm entièrement portables ne peuvent pas se produire tant que, pour donner un exemple pratique, les accès aux webcams ou aux sites Web ne peuvent être écrits qu’avec des appels système qui génèrent un code machine dépendant de la plate-forme.

Par conséquent, le moyen le plus pratique d’avoir de tels modules, à partir de quelconque langage de programmation, semble être celui du Projet d’interface WebAssembly System (WASI): écrire et compiler du code pour seulement un, évidemment virtuel, mais système d’exploitation complet.

D’une part, WASI donne à tous les développeurs de Temps d’exécution de Wasm un seul OS à émuler. D’autre part, WASI donne à tous les langages de programmation un ensemble d’appels système pour parler à ce même système d’exploitation.

De cette façon, même si vous l’avez chargé sur dix plates-formes différentes, un binaire Le module Wasm appelant une certaine fonction WASI obtiendrait toujours – du runtime qui l’a lancé – un objet binaire différent à chaque fois. Mais puisque tous ces objets interagiraient avec ce seul module Wasm exactement de la même manière, cela n’aurait pas d’importance!

Cette approche fonctionnerait également dans le premier cas d’utilisation de WebAssembly, c’est-à-dire avec les machines virtuelles JavaScript à l’intérieur des navigateurs Web. Pour exécuter des modules Wasm qui utilisent des appels WASI, ces machines ne doivent charger que les versions JavaScript des bibliothèques correspondantes.

Cette émulation au niveau du système d’exploitation est également plus sécurisée que le simple sandboxing. Avec WASI, n’importe quel environnement d’exécution peut implémenter différentes versions de chaque appel système – avec des privilèges de sécurité différents – à condition qu’elles respectent toutes les spécifications. Ensuite, ce runtime pourrait placer chaque instance de chaque module Wasm qu’il lance dans un bac à sable séparé, contenant uniquement la combinaison de fonctions la plus petite et la moins privilégiée dont cette instance spécifique a vraiment besoin.

Ce «principe du moindre privilège», ou «modèle de sécurité basé sur les capacités«, Est partout dans WASI. Un runtime WASI peut transmettre dans un bac à sable une instance de l’appel système «ouvert» qui n’est capable d’ouvrir que les fichiers ou dossiers spécifiques qui étaient présélectionné par le runtime lui-même. Il s’agit d’un contrôle plus robuste, beaucoup plus granulaire sur ce que les programmes peuvent faire qu’il ne serait possible avec les autorisations de fichiers traditionnelles, ou même avec les systèmes chroot.

Du point de vue du codage, des fonctions telles que la gestion de base des fichiers, des dossiers, des connexions réseau ou du temps sont nécessaires à presque tous les programmes. Par conséquent, les interfaces WASI correspondantes sont conçues aussi similaires que possible à leurs équivalents POSIX, et toutes regroupées dans un module «wasi-core», que chaque runtime compatible WASI doit contenir.

Une version du libc bibliothèque C standard, réécrite avec les fonctions wasi-core, est déjà disponible et, selon ses développeurs, déjà «suffisamment stable et utilisable à de nombreuses fins».

Toutes les autres interfaces virtuelles que WASI inclut, ou inclura au fil du temps, sont standardisées et conditionnées sous forme de modules séparés, sans forcer aucun moteur d’exécution à les prendre en charge tous. Dans le prochain article, nous verrons comment certains de ces composants WASI sont déjà utilisés aujourd’hui.

La poste WASI, apportant WebAssembly bien au-delà des navigateurs est apparu en premier le Linux Foundation – Formation.