Mozilla, Rápidamente, Intel y Red Hat sus esfuerzos en el desarrollo de tecnologías que ayuden a hacer de WebAssembly una plataforma universal para la ejecución segura de código en cualquier infraestructura, sistema operativo o dispositivo. Se ha formado una comunidad para el desarrollo conjunto de runtime y compiladores que permitan el uso de WebAssembly no solo en navegadores web. .
Para crear programas portátiles entregados en formato WebAssembly que puedan ejecutarse fuera del navegador, sugerimos utilizar la API (Interfaz del sistema WebAssembly), que proporciona interfaces de software para la interacción directa con el sistema operativo (API POSIX para trabajar con archivos, sockets, etc.). Una característica distintiva del modelo de ejecución de aplicaciones que utilizan WASI es que se ejecutan en un entorno sandbox para aislarse del sistema principal y utilizan un mecanismo de seguridad basado en la gestión de capacidades para acciones con cada uno de los recursos (archivos, directorios, sockets, llamadas al sistema). , etc.) la aplicación debe recibir los permisos adecuados (solo se proporciona acceso a la funcionalidad declarada).
Uno de La alianza creada es una solución al problema de distribuir aplicaciones modulares modernas con una gran cantidad de dependencias. En este tipo de aplicaciones, cada dependencia puede ser una fuente potencial de vulnerabilidades o ataques. Tomar el control de una dependencia le permite obtener el control de todas las aplicaciones asociadas a ella. La confianza en la aplicación implica automáticamente confianza en todas las dependencias, pero las dependencias a menudo las desarrollan y mantienen equipos de terceros cuyas actividades no se pueden controlar. Los miembros de Bytecode Alliance tienen la intención de proporcionar una solución integral para la ejecución segura de aplicaciones WebAssembly que no son inherentemente confiables.
Para protección, se propone utilizar el concepto de nanoprocesos, en el que cada módulo de dependencia se separa en un módulo WebAssembly aislado por separado, cuyas potencias se establecen solo en relación con este módulo (por ejemplo, una biblioteca para procesar cadenas no poder abrir un socket de red o un archivo). A diferencia de la separación de procesos, los controladores de WebAssembly son livianos y casi no requieren recursos adicionales; la interacción entre controladores no es mucho más lenta que llamar a funciones normales. La separación se puede realizar no solo a nivel de módulos individuales, sino también a nivel de grupos de módulos que, por ejemplo, necesitan trabajar con áreas de memoria comunes.
Los poderes solicitados pueden determinarse tanto en el nivel de las dependencias mismas como delegarse a las dependencias a lo largo de la cadena mediante los módulos principales (los recursos en WASI están asociados con un tipo especial de descriptor de archivo: capacidad). Por ejemplo, a un módulo se le puede delegar la capacidad de acceder a un directorio específico y a llamadas al sistema, y si la infraestructura de desarrollo del módulo se ve comprometida o se identifica una vulnerabilidad, durante un ataque, el acceso se limitará solo a estos recursos. Las declaraciones de recursos por parte de los creadores de módulos pueden ser un indicador de actividad sospechosa, como cuando un módulo de procesamiento de texto solicita permiso para abrir una conexión de red. Se verifican los permisos establecidos inicialmente y, si cambian, se rechaza la carga de dependencia hasta que se actualice la firma del módulo local.
Para el desarrollo conjunto bajo el ala de Bytecode Alliance varios relacionados con WebAssembly , previamente desarrollado por separado por las empresas fundadoras de la alianza:
- — tiempo de ejecución para ejecutar aplicaciones WebAssembly con extensiones WASI como aplicaciones independientes normales. Admite tanto el inicio del código de bytes de WebAssembly mediante una utilidad de línea de comando especial como la vinculación de archivos ejecutables ya preparados (wasmtime está integrado en la aplicación como una biblioteca). Wasmtime tiene una estructura modular flexible que le permite escalar el tiempo de ejecución para varias aplicaciones; por ejemplo, puede crear una versión simplificada para dispositivos con recursos limitados;
- — compilador y tiempo de ejecución para ejecutar programas en formato WebAssembly. Distintivo Lucet consiste en el uso de una compilación anticipada completa (AOT, antes de tiempo) en lugar de JIT en código de máquina adecuado para la ejecución directa. El proyecto fue desarrollado por Fastly y está optimizado para consumir recursos mínimos y lanzar nuevas instancias muy rápidamente (Fastly usa Lucet en un motor de computación de borde en la nube que usa WebAssembly para los controladores lanzados en cada solicitud). Como parte del proyecto conjunto, está previsto convertir el compilador Lucet para utilizar Wasmtime como base;
- (WebAssembly Micro Runtime) es otro tiempo de ejecución para ejecutar WebAssembly, desarrollado originalmente por Intel para su uso en dispositivos de Internet de las cosas. WAMR está optimizado para un consumo mínimo de recursos y se puede utilizar en dispositivos con una pequeña cantidad de RAM. El proyecto incluye un intérprete y una máquina virtual para ejecutar el código de bytes de WebAssembly, una API (un subconjunto de Libc) y herramientas para la gestión dinámica de aplicaciones;
- — un generador de código que traduce una representación intermedia independiente de las arquitecturas de hardware en código de máquina ejecutable optimizado para plataformas de hardware específicas. Cranelift admite la paralelización de la compilación de funciones para una generación de resultados muy rápida, lo que permite su uso para crear compiladores JIT (el JIT basado en Cranelift se usa en la máquina virtual Wasmtime);
- — una implementación separada de la API WASI (WebAssembly System Interface) para organizar la interacción con el sistema operativo;
- — un módulo para el administrador de paquetes Cargo que implementa un comando para compilar código Rust en código de bytes WebAssembly usando la interfaz WASI para usar WebAssembly fuera del navegador;
- и - analizadores para analizar texto (WAT, WAST) y representaciones binarias del código de bytes de WebAssembly.
En resumen, WebAssembly se parece mucho a Asm.js, pero en el sentido de que es un formato binario que no está ligado a JavaScript y permite ejecutar en el navegador código intermedio de bajo nivel compilado a partir de varios lenguajes de programación. WebAssembly no requiere un recolector de basura porque utiliza administración de memoria explícita. Al utilizar JIT para WebAssembly, puede lograr niveles de rendimiento cercanos al código nativo. Entre los principales objetivos de WebAssembly está garantizar la portabilidad, el comportamiento predecible y la ejecución de código idéntico en diferentes plataformas.
Fuente: opennet.ru