Par Marco Fioretti

le Format binaire WebAssembly (Wasm) a été développé pour permettre aux logiciels écrits dans n’importe quel langage de « compiler une fois, s’exécuter partout », à l’intérieur de navigateurs Web ou de machines virtuelles autonomes (durées d’exécution) disponible pour n’importe quelle plate-forme, presque aussi vite que le code directement compilé pour ces plates-formes. Les modules Wasm peuvent interagir avec n’importe quel environnement hôte dans lequel ils fonctionnent de manière vraiment portable, grâce à la Interface système WebAssembly (WASI).

Cela ne suffit pas, cependant. Afin d’être réellement utilisable sans surprise dans autant de scénarios que possible, les fichiers exécutables Wasm ont besoin d’au moins deux autres éléments. L’un est la capacité d’interagir directement non seulement avec le système d’exploitation, mais avec tout autre programme du même genre. La façon de faire cela avec Wasm s’appelle « liaison de modules », et sera le sujet du prochain article de cette série. L’autre caractéristique, qui est une condition préalable pour que la liaison de modules soit utile, est la capacité d’échanger structures de données de quelque nature que ce soit, sans malentendu ni perte de données.

Que se passe-t-il lorsque les modules Wasm échangent des données ?

Puisqu’il ne s’agit que d’une cible de compilation, le format WebAssembly ne fournit que des types de données de bas niveau qui visent à être aussi proches que possible de la machine sous-jacente. C’est ce choix qui fournit des modules hautement portables et hautement performants, tout en laissant aux programmeurs le soin d’écrire des logiciels dans le langage de leur choix. La charge de mapper des structures de données complexes dans ce langage aux types de données Wasm natifs est laissée aux bibliothèques de logiciels et aux compilateurs qui les utilisent.

Le problème ici est que pour être efficace, la première génération de syntaxe Wasm et WASI ne prennent pas en charge nativement les chaînes et autres types de données tout aussi basiques. Par conséquent, il n’y a aucune garantie intrinsèque que, par exemple, un module Wasm compilé à partir de sources Python et un autre à partir de sources Rust auront exactement le même concept de « chaîne » dans toutes les circonstances où la chaîne peut être utilisée.

La conséquence est que, si les modules Wasm compilés à partir de différents langages veulent échanger des structures de données plus complexes, quelque chose d’important peut être, pour ainsi dire, « perdu dans la traduction » à chaque fois qu’une donnée passe d’un module à un autre. Concrètement, cela empêche à la fois l’intégration directe des modules Wasm dans des applications génériques et les appels directs des modules Wasm vers des logiciels externes.

Afin de comprendre la nature du problème, il est utile d’examiner comment ces données sont transmises dans les modules Wasm et WASI de première génération.

La façon originale pour WebAssembly de communiquer avec les programmes JavaScript et C est de simuler des choses comme des chaînes en gestion manuelle morceaux de mémoire.

Par exemple, dans la fonction chemin_ouvert, une chaîne est transmise sous la forme d’une paire de nombres entiers (i32) qui représentent le décalage et, respectivement, la longueur de cette chaîne dans la mémoire linéaire réservée à un module Wasm. Ce serait déjà assez grave quand, pour ne citer que les cas les plus simples et les plus fréquents, des codages de caractères différents ou Collecte des ordures (GC) sont utilisés. Pour aggraver les choses, les modules WASI qui échangent des chaînes seraient obligés d’accéder à la mémoire des autres, ce qui rend cette façon de travailler loin d’être optimale pour des raisons de performances et de sécurité.

Théoriquement, les modules Wasm qui souhaitent échanger des données peuvent également utiliser des mécanismes de transmission de données traditionnels compatibles avec JavaScript tels que WebIDL. C’est le langage de description d’interface utilisé pour décrire tous les composants, y compris bien sûr Types de données pour toute interface de programmation d’applications Web (API).

En pratique cependant, cela ne résoudrait rien. D’abord parce que les fonctions Web IDL peuvent accepter, c’est-à-dire passer au module Wasm qui les a appelées, constructions de niveau supérieur que WebAssembly comprendrait. Deuxièmement parce que l’utilisation de WebAssembly signifie échanger des données non pas directement mais via Liaisons ECMAScript, qui ont leurs propres complexités et pénalités de performance. En résumé, certaines astuces fonctionnent aujourd’hui, mais pas dans tous les cas, et ne sont en aucun cas à l’épreuve du temps.

La solution : Types d’interface et de référence

La vraie solution à tous les problèmes mentionnés ci-dessus consiste à étendre à la fois le format binaire Wasm et WASI de manière à :

prend en charge directement des structures de données plus complexes comme des chaînes ou des listes
permettent aux modules Wasm de vérifier de manière statique les variables correspondantes, et de les échanger directement, mais sans avoir à partager leur mémoire linéaire interne.

Deux spécifications sont déployées uniquement à cette fin. Le principal s’appelle simplement Types d’interfaces et son compagnon Types de référence.

Les deux types reposent sur des fonctionnalités de niveau inférieur déjà ajoutées au noyau Wasm d’origine, à savoir « multi-valeur » et prise en charge multi-mémoire. La première extension permet aux fonctions Wasm de renvoyer un nombre arbitraire de valeurs, au lieu d’une seule comme auparavant, et aux séquences d’instructions Wasm de gérer un nombre arbitraire de valeurs de pile. L’autre permet à un module Wasm entier, ou à des fonctions uniques, d’utiliser plusieurs mémoires en même temps, ce qui est bon pour tout un tas de raisons en plus d’échanger des variables.

En s’appuyant sur ces fonctionnalités, les types d’interface définissent des chaînes et d’autres structures de données « de haut niveau », d’une manière que n’importe quel non modifié Le runtime Wasm peut utiliser. Les types de référence complètent le tableau, en spécifiant comment les applications Wasm doivent réellement échanger ces structures de données avec des applications externes.

Les spécifications ne sont pas encore complètement terminées. Les types d’interface peuvent échanger des valeurs, mais pas gère les ressources et tampons, qui serait nécessaire, par exemple, pour « lire un fichier et écrire directement dans un tampon ».

Cependant, en travaillant ensemble, toutes les fonctionnalités décrites ici permettent déjà aux modules Wasm et aux interfaces WASI de gérer et d’échanger efficacement les structures de données les plus complexes, sans les corrompre et quelle que soit la langue dans laquelle ils ont été utilisés, avant la compilation vers Wasm.

La poste Comment les modules WebAssembly échangent des données en toute sécurité est apparu en premier sur Fondation Linux – Formation.