Mozilla recently announced a new standardization effort aiming at running the same WebAssembly code across all devices, machines and operating systems. The new standard, WebAssembly System Interface (WASI), defines one single conceptual operating system interface, which can be implemented by multiple, actual operating systems. At the difference of previous "Run Anywhere" efforts like Java, WASI builds on WebAssembly, a rare collaboration between browser vendors and manufacturers of chips, devices, computers and operating systems to produce a patent-free, open standard. The WASI standard will strive to provide WebAssembly's portability and security through a modular set of standard interfaces, and to provide a solid foundation for an ecosystem. Mozilla and Fastly are already shipping prototypal WASI implementations.
WASI aims to be a system interface for the WebAssembly platform (currently implemented by the four major browser engines). WebAssembly (Wasm) describes itself as a "binary instruction format for a stack-based virtual machine", with the design goal to "execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms". Wasm is used as a target for compilation of high-level languages like C/C++/Rust. While WebAssembly was primarily designed to run on the open web, Mozilla seeks now to extend WebAssembly's reach to non-web embeddings, "including everything from minimal shells for testing to full-blown application environments e.g. on servers in datacenters, on IoT devices, or mobile/desktop apps". As Lin Clark observes:
Code outside of a browser needs a way to talk to the system — a system interface. And the WebAssembly platform doesn’t have that yet.
WASI's stated goal echoes the original Java promise to "Write Once, Run Anywhere". The Java Virtual Machine (JVM) indeed serves a similar purpose, and language flexibility similar to that offered by the WebAssembly platform may be realized in Java via the GraalVM. Java, however, remains a de facto standard, and its owner Oracle has a lawsuit pending against Google for allegedly using unlawfully Java's APIs. By contrast, WebAssembly is the result of a rare collaboration between browser vendors and major companies such as Microsoft, Google, Apple, Mozilla, Intel, Samsung and more. Jay Phelps emphasized at QCon San Francisco 2018:
(...) these companies, they've come together and they've all created the first standardized byte code by all of these major companies. And it's free. It's not a proprietary program. There's no question that this is completely open. And it's not encumbered by patent laws and all that sorts of things.
Furthermore, Wasm, being memory safe and tuned for validation, may have security advantages over Java. Till Schneidereit provides extra arguments to the comparison in favor of Wasm:
(...) WebAssembly has been designed to scale from tiny devices to large server farms or CDNs; is much more language-agnostic than Java; and has a much smaller implementation footprint.
WASI seeks to achieve portable binaries by specifying a common interface to multiple systems, based on abstractions of system functionalities. Such abstractions are clustered into modules, with wasi-core occupying a central role. Lin Clark details:
wasi-core will contain the basics that all programs need. It will cover much of the same ground as POSIX, including things such as files, network connections, clocks, and random numbers.
Other functionalities, like multimedia, 3D graphics, or smart contracts, may be addressed by specific modules. The standardization effort in place aims at specifying carefully the system functionality abstractions to address a large set of operating systems and architectures, while maintaining the performance objective of WebAssembly.
WASI builds on the security aspect of Wasm by adopting a capability-based security model. WASI applications are provided with capabilities, instead of forgeable references (such as a file path) which identify a resource, but do not specify which access rights are appropriate for that resource. Forgeable references force validation by the operating system based on the ambient authority of the requesting program. Lin Clark explains how a WASI app can only open a file if it previously has been given the capability to open that file:
(...) you can’t have code that randomly asks to open
/etc/passwd
. Instead, the code can only operate on the directories that are passed in to it. (...) So the runtime passes in the file descriptors that an app can use to the top level code, and then file descriptors get propagated through the rest of the system on an as-needed basis.
WASI-enabled apps can currently be run in the browser with a polyfill, or outside the browser with Mozilla's Wasmtime, or Fastly's Lucet.
WASI is a work in progress. Lin Clark reflects:
But there are still questions we’ll need to address after wasi-core is fully standardized. Those questions include:
- asynchronous I/O
- file watching
- file locking
The stakes are high. Solomon Hikes, co-founder of Docker, says:
If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task!