Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Mozilla, Fastly, Intel et Red Hat lancent l'Alliance Bytecode, une initiative construite autour de WebAssembly
Qui propose d'apporter plus de sécurité, d'ubiquité et d'interopérabilité sur le Web

Le , par Christian Olivier

16PARTAGES

10  0 
Dans un effort commun visant à faire de WebAssembly un runtime informatique multiplateforme, les entreprises Mozilla, Fastly, Intel et Red Hat ont annoncé le lancement de l’Alliance Bytecode. Cette initiative architecturée autour de WebAssembly est axée sur la fourniture d’un bytecode sécurisé par défaut qui peut être exécuté depuis un navigateur Web, un ordinateur de bureau ou une plateforme IoT/embarquée.


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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de youtpout978
Membre expert https://www.developpez.com
Le 13/11/2019 à 17:28
Citation Envoyé par Bardotj Voir le message
Avons nous rééllement besoin de web assembly ?

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
Le WebAssembly est plus performant que le javascript qui est utilisé avec Electron pour faire des applis bureau.
Des virus sont fait en C ou C++, doit-on bannir ces langages pour autant.

Pour les perfs on utilise un paquet de langage moins performant que le natif pour faire des applis de bureau, à part si le but est d'avoir l'appli la plus performante (style jeux AAA, montage photo/video ...).
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 14/11/2019 à 10:14
Citation Envoyé par Bardotj Voir le message
Avons nous rééllement besoin de web assembly ?
Avons nous besoin d'un ordinateur ? Pour survivre, non. Pour programmer, oui.
Avons nous besoin de WebAssembly ? Pour programmer, non. Pour avoir un bytecode efficace, securisé et adapté a de multiple langages, oui.

Citation Envoyé par Bardotj Voir le message
Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude
Pas besoin de faire une étude pour savoir ça. WebAssembly est un bytecode adapté pour avoir de bonnes performances, particulièrement avec les langages stricts, mais il a des contraintes de sécurité qui font qu'il ne pourra pas à 100% au niveau du natif non sécurisé. Mais par rapport au JS les gains sont indéniables.
Il faut aussi voir que les VM des navigateurs privilégient actuelement la vitesse de compilation aux performances. C'est logique pour le web où on ne veut pas attendre au chargement de la page. Mais pour une utilisation en tant qu'application lourde comme le prévoit la Bytecode Alliance, les performances seront certainement privilégiées.

Citation Envoyé par Bardotj Voir le message
50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig
Pour des choses qui seraient de toute façon faites en JavaScript si le WebAssembly n'existait.
1  0 
Avatar de Bardotj
Membre régulier https://www.developpez.com
Le 13/11/2019 à 17:12
Avons nous rééllement besoin de web assembly ?

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
0  3