Mozilla, Fastly, Intel, and Red Hat recently announced the formation of a joint organization, Bytecode Alliance, which aims to improve WebAssembly’s ecology outside of the browser by collaborating to implement standards and propose new standards.
WebAssembly, also known as Wasm, is a binary instruction format designed for stack-based virtual machines, and Wasm serves as a portable target for compiling advanced languages such as C/C?/Rust, allowing client and server applications to be deployed on the Web.
Version 1.0 is already supporting Chrome, Firefox, Safari, and Edge.
Why did the four companies form Bytecode Alliance this time? Lin Clark is featured on Mozilla’s official blog.
Lin says that network users are now at increasing risk, and that large-scale modular applications are being built, with 80 percent of the code base coming from package registries such as npm, PyPI, and crates.io. Such an approach would certainly make the ecology prosperous, but security concerns are also increasing rapidly.
Those who compromise these securityes exploit the trust of the user, and when the user uses the application, they do not know the software dependencies behind them, whether there are malicious code users do not know, nor can they know whether they can be trusted.
So the alliance wants to advance security in this area through WebAssembly technology. Bytecode Alliance builds a solid and secure foundation to secure untrusted code, whether in the cloud, on-premises desktop, or on a small IoT device. Developers can use open source code in the same way without putting users at risk, and these common reusable base sets can be used alone or embedded in other libraries and applications.
Specifically, all of these dependency-related security issues are due to different software/modules/files having permission to access other content, and WebAssembly can provide some isolation so that untrusted code can be run securely.
You can design a schema for small processes or containers and microservices similar to Unix, but this isolation is lightweight and the communication between them is no slower than regular function calls.
With this pattern, you can encapsulate a single instance of a WebAssembly module, or a small group of module instances that want to share memory between them. It also eliminates the need to discard powerful programming language features, such as function signatures and static type checking.
Lin describes some of the current technical solutions for WebAssembly, including a few key points:
Each WebAssembly module is sandboxed by default, and by default, the module does not have access to the API and system calls.
The memory model, unlike normal binaries that are compiled directly into x86, the WebAssembly module cannot access all memory in its process, but can only access the blocks of memory that have been allocated to it.
Interface types, modules can communicate using more complex values, such as strings, sequences, records, variants, and their nested combinations. This makes it easy for the two modules to exchange data, which is secure and fast.
APIs and system calls with the concept of permissions so that they can give different modules different permissions to different resources, i.e. WASI, WebAssembly system interfaces. It provides a way to isolate different modules from each other and give them fine-grained permissions on specific parts of the file system and other resources, as well as fine-grained permissions for calls to different systems.
These are the technologies that are already present in WebAssembly technology, but there is no way to pass these security controls down to the dependency tree, which requires a way to give the parent module the same security controls that give it the dependency.
This is what Bytecode Alliance is currently working on, planning to take the fine-grained form of individual module virtualization, an idea that researchers have validated in a research environment and is currently working to introduce it to WebAssembly.