Mozilla, Fastly, Intel and Red Hat promote WebAssembly as a platform for universal use

Mozilla, Fastly, Intel and Red Hat companies united its efforts in the development of technologies that contribute to the transformation of WebAssembly into a universal platform for the safe execution of code in any infrastructures, operating systems and devices. A community has been formed to jointly develop runtime and compilers that allow WebAssembly to be used not only in web browsers. Bytecode Alliance.

To create portable programs delivered in WebAssembly format that can be executed outside the browser, it is proposed to use the API WASI (WebAssembly System Interface), which provides programming interfaces for direct interaction with the operating system (POSIX API for working with files, sockets, etc.). A distinctive feature of the execution model of applications using WASI is running in a sandbox environment to isolate from the main system and applying a security mechanism based on capability control - for actions with each of the resources (files, directories, sockets, system calls, etc.) the application must be given appropriate permissions (only access to the declared functionality is granted).

One of objectives The created alliance is a solution to the problem of distribution of modern modular applications that have a large number of dependencies. In such applications, each dependency can be a potential source of vulnerabilities or attacks. Taking control of a dependency allows you to gain control of all related applications as well. Trust in an application automatically implies trust in all dependencies, but dependencies are often developed and maintained by extraneous teams whose activities cannot be controlled. Members of the Bytecode Alliance intend to provide a complete solution for the secure execution of WebAssembly applications that are inherently untrustworthy.

For protection, it is proposed to use the concept of nanoprocesses, in which each dependency module is separated into a separately isolated WebAssembly module, the permissions of which are set in relation to this module only (for example, a library for processing strings will not be able to open a network socket or file). Unlike separation into processes, WebAssembly handlers are lightweight and require almost no additional resources - interaction between handlers is not much slower than calling ordinary functions. Separation can be carried out not only at the level of individual modules, but also at the level of groups of modules, which, for example, need to work with common memory areas

The requested permissions can be defined both at the level of the dependencies themselves, and delegated to dependencies along the chain by parent modules (resources in WASI are associated with a special type of file descriptors - capability). For example, a module can be delegated the ability to access a specific directory and system calls, and if the module development infrastructure is compromised or a vulnerability is identified, access will be limited to these resources during an attack. Declaring resources by module creators can be an indicator of suspicious activity, such as when a word processing module requests permission to open a network connection. The initially set permissions are checked and, if they change, the dependency load is rejected until the module's local signature is updated.

For joint development under the wing of Bytecode Alliance translated several related to WebAssembly Projectspreviously separately developed by the founding companies of the alliance:

  • wasmtime - runtime for executing WebAssembly applications with WASI extensions as ordinary stand-alone applications. It supports both launching WebAssembly bytecode using a special command line utility, and linking ready-made executable files (wasmtime is built into the application as a library). Wasmtime has a flexible modular structure that allows you to scale the runtime for different applications, for example, you can form a stripped down version for devices with limited resources;
  • It shines - compiler and runtime for executing programs in WebAssembly format. Distinctive feature Lucet is an application instead of JIT full-fledged ahead-of-time compilation (AOT, ahead-of-time) into machine code suitable for direct execution. The project was developed by Fastly and is optimized to consume minimal resources and launch new instances very quickly (Fastly uses Lucet in a cloud edge computing engine that uses WebAssembly for handlers that run on each request). As part of a joint project, the Lucet compiler is planned to be converted to use Wasmtime as a basis;
  • WAMR (WebAssembly Micro Runtime) is another runtime for running WebAssembly, originally developed by Intel for use in IoT devices. WAMR is optimized for minimal resource consumption and can be used on devices with a small amount of RAM. The project includes an interpreter and a virtual machine for executing WebAssembly bytecode, an API (a subset of Libc) and a toolkit for dynamic application management;
  • crane lift - a code generator that translates an intermediate representation independent of hardware architectures into executable machine code optimized for specific hardware platforms. Cranelift supports parallelized compilation of functions for very fast result generation, which allows it to be used to create JIT compilers (Cranelift-based JIT is used in the Wasmtime virtual machine);
  • WASI common - a separate implementation of the WASI API (WebAssembly System Interface) for organizing interaction with the operating system;
  • cargo-wasi - a module for the Cargo package manager that implements a command for compiling Rust code into WebAssembly bytecode using the WASI interface to use WebAssembly outside the browser;
  • what ΠΈ wasmparser - parsers for parsing text (WAT, WAST) and binary representations of WebAssembly bytecode.

Recall that WebAssembly is a lot like Asm.js, but is different the fact that it is a binary format that is not tied to JavaScript and allows you to execute low-level intermediate code compiled from various programming languages ​​in the browser. WebAssembly does not require the use of a garbage collector, as it uses explicit memory management. Through the use of JIT for WebAssembly, you can achieve a level of performance close to native code. Among the main tasks of WebAssembly is the provision of portability, predictability of behavior and identity of code execution on different platforms.

Source: opennet.ru

Add a comment