Mozilla, Fastly, Intel et Red Hat ses efforts dans le développement de technologies qui contribuent à faire de WebAssembly une plate-forme universelle pour l'exécution sécurisée de code sur n'importe quelle infrastructure, système d'exploitation ou appareil. Une communauté a été formée pour le développement conjoint de runtimes et de compilateurs qui permettent d'utiliser WebAssembly non seulement dans les navigateurs Web. .
Pour créer des programmes portables livrés au format WebAssembly pouvant être exécutés en dehors du navigateur, nous vous suggérons d'utiliser l'API (WebAssembly System Interface), qui fournit des interfaces logicielles pour une interaction directe avec le système d'exploitation (API POSIX pour travailler avec des fichiers, des sockets, etc.). Une particularité du modèle d'exécution des applications utilisant WASI est qu'elles s'exécutent dans un environnement sandbox pour s'isoler du système principal et utilisent un mécanisme de sécurité basé sur la gestion des capacités pour les actions avec chacune des ressources (fichiers, répertoires, sockets, appels système). , etc.) l'application doit disposer des autorisations appropriées (seul l'accès à la fonctionnalité déclarée est fourni).
Un des L'alliance créée est une solution au problème de la distribution d'applications modulaires modernes avec un grand nombre de dépendances. Dans de telles applications, chaque dépendance peut être une source potentielle de vulnérabilités ou d’attaques. Prendre le contrôle d’une dépendance permet de prendre le contrôle de toutes les applications qui lui sont associées. La confiance dans l'application implique automatiquement la confiance dans toutes les dépendances, mais les dépendances sont souvent développées et maintenues par des équipes tierces dont les activités ne peuvent être contrôlées. Les membres de Bytecode Alliance ont l'intention de fournir une solution holistique pour l'exécution sécurisée d'applications WebAssembly qui ne sont pas intrinsèquement dignes de confiance.
Pour la protection, il est proposé d'utiliser le concept de nanoprocessus, dans lequel chaque module de dépendance est séparé en un module WebAssembly isolé séparément, dont les pouvoirs sont fixés uniquement par rapport à ce module (par exemple, une bibliothèque de traitement de chaînes ne sera pas être capable d'ouvrir une socket réseau ou un fichier). Contrairement à la séparation des processus, les gestionnaires WebAssembly sont légers et ne nécessitent pratiquement aucune ressource supplémentaire - l'interaction entre les gestionnaires n'est pas beaucoup plus lente que l'appel de fonctions ordinaires. La séparation peut se faire non seulement au niveau des modules individuels, mais également au niveau des groupes de modules qui, par exemple, doivent travailler avec des zones de mémoire communes
Les pouvoirs demandés peuvent être déterminés à la fois au niveau des dépendances elles-mêmes et délégués aux dépendances le long de la chaîne par les modules parents (les ressources dans WASI sont associées à un type spécial de descripteur de fichier - la capacité). Par exemple, un module peut se voir déléguer la possibilité d'accéder à un répertoire spécifique et à des appels système, et si l'infrastructure de développement du module est compromise ou qu'une vulnérabilité est identifiée, lors d'une attaque, l'accès sera limité uniquement à ces ressources. Les déclarations de ressources par les créateurs de modules peuvent être un indicateur d'activité suspecte, par exemple lorsqu'un module de traitement de texte demande l'autorisation d'ouvrir une connexion réseau. Les autorisations initialement définies sont vérifiées et si elles changent, le chargement des dépendances est rejeté jusqu'à ce que la signature du module local soit mise à jour.
Pour un développement conjoint sous l’aile de la Bytecode Alliance plusieurs liés à WebAssembly , auparavant développé séparément par les sociétés fondatrices de l’alliance :
- - runtime pour exécuter des applications WebAssembly avec des extensions WASI en tant qu'applications autonomes classiques. Il prend en charge à la fois le lancement du bytecode WebAssembly à l'aide d'un utilitaire de ligne de commande spécial et la liaison de fichiers exécutables prêts à l'emploi (wasmtime est intégré à l'application en tant que bibliothèque). Wasmtime a une structure modulaire flexible qui vous permet d'adapter le temps d'exécution pour diverses applications, par exemple, vous pouvez créer une version allégée pour les appareils aux ressources limitées ;
- — compilateur et runtime pour exécuter des programmes au format WebAssembly. Distinctif Lucet consiste à utiliser une compilation anticipée à part entière (AOT, advance-of-time) au lieu du JIT dans un code machine adapté à une exécution directe. Le projet a été développé par Fastly et est optimisé pour consommer un minimum de ressources et lancer de nouvelles instances très rapidement (Fastly utilise Lucet dans un moteur de cloud computing qui utilise WebAssembly pour les gestionnaires lancés à chaque requête). Dans le cadre du projet commun, il est prévu de convertir le compilateur Lucet pour utiliser Wasmtime comme base ;
- (WebAssembly Micro Runtime) est un autre moteur d'exécution pour l'exécution de WebAssembly, initialement développé par Intel pour être utilisé dans les appareils Internet des objets. WAMR est optimisé pour une consommation minimale de ressources et peut être utilisé sur des appareils dotés d'une petite quantité de RAM. Le projet comprend un interpréteur et une machine virtuelle pour exécuter le bytecode WebAssembly, une API (un sous-ensemble de Libc) et des outils pour la gestion dynamique des applications ;
- — un générateur de code qui traduit une représentation intermédiaire indépendante des architectures matérielles en code machine exécutable optimisé pour des plates-formes matérielles spécifiques. Cranelift prend en charge la parallélisation de la compilation de fonctions pour une génération de résultats très rapide, ce qui lui permet d'être utilisé pour créer des compilateurs JIT (le JIT basé sur Cranelift est utilisé dans la machine virtuelle Wasmtime) ;
- — une implémentation distincte de l'API WASI (WebAssembly System Interface) pour organiser l'interaction avec le système d'exploitation ;
- — un module pour le gestionnaire de packages Cargo qui implémente une commande pour compiler le code Rust en bytecode WebAssembly à l'aide de l'interface WASI pour utiliser WebAssembly en dehors du navigateur ;
- и — des analyseurs pour analyser le texte (WAT, WAST) et les représentations binaires du bytecode WebAssembly.
Pour récapituler, WebAssembly ressemble beaucoup à Asm.js, mais en ce sens qu'il s'agit d'un format binaire qui n'est pas lié à JavaScript et qui permet d'exécuter dans le navigateur du code intermédiaire de bas niveau compilé à partir de divers langages de programmation. WebAssembly ne nécessite pas de garbage collector car il utilise une gestion explicite de la mémoire. En utilisant JIT pour WebAssembly, vous pouvez atteindre des niveaux de performances proches du code natif. L'un des principaux objectifs de WebAssembly est d'assurer la portabilité, un comportement prévisible et une exécution de code identique sur différentes plates-formes.
Source: opennet.ru