Red Hat and WebAssembly

What is WebAssembly?

Historically, WebAssembly (WASM) is a technology widely used in browsers, video gaming and content streaming. Today, it’s also being adapted for use with containers, and as a back-end technology for enabling Function-as-a-Service (FaaS) and Platform-as-a-Service (PaaS). WASM was designed as a portable compilation target, so that languages like C, C++ and Rust could be used in a browser. WASM is developed as an open web standard within the W3C, and provides a binary instruction format for a stack-based virtual machine. This was originally designed to run in a browser, but much like JavaScript, it’s moving to the server side. WASM can be thought of as a new Instruction Set Architecture (ISA) like x86, ARM, or RISC-V.

WASM offers several advantages over compiling to a native ISA. With it, developers can use multiple languages like C, C++ or Rust. At compile-time, the developer chooses WASM as a target instead of x86. This compiled and standardized WASM binary format (also known as bytecode) can be executed on a variety of hardware architectures and operating systems, with a very low disk footprint, and fast cold boot times which promise immediate availability across geographically distributed sites. WASM also includes a capability-based security model to provide sandbox isolation and module signing.

Alone, WASM is an interesting technology, but it lacks some of the most important APIs that common programming languages and applications have come to rely on. Since WASM was originally designed as a browser technology, it was purposefully limited in scope for security reasons. As the use cases expand to the server side, there is greater demand for an extension called Web Assembly System Interface (WASI).

WASI seeks to extend WASM with a set of common POSIX-style APIs that provide typical operating-system-like features, such as filesystems, Berkeley sockets, clocks, networking and cryptography. It also has a number of software security features and capabilities baked into the core design (module isolation and capability based controls inspired by CloudABI) along with faster execution and greater portability. 

Together, WASM and WASI have the potential to solve the compile-once, run-anywhere problem that the technology industry has sought to address for so many years. To run a WASM/WASI binary, you need a WASM Runtime, essentially a virtual machine which can execute it. Today, there are many different implementations of WASM runtimes including Wasmtime, Wasmer, WasmEdge, WAMR, and others. Most of these projects support the base WASM standard, and many are driving the WASI standard forward. Each of these runtime projects is maturing rapidly, but WASI in particular still lacks the maturity needed to compile and run many server-side workloads, such as relational database servers, full blown web servers, etc. Certain WASM runtimes are running ahead of the standards to demonstrate what’s possible with the technology (sockets, for example), while others adhere more strictly to them. Right now, end users need to be very educated when selecting a runtime. What works on one WASM runtime is not necessarily portable today, at least until the WASI standards solidify more, and things are still likely to evolve rapidly.

Red Hat’s involvement in WebAssembly

Red Hat’s involvement in WASM is long standing. We were one of the founding members of the bytecode alliance and have implemented the technology in several upstream and Red Hat-specific projects. Our engineers are working in open source communities to integrate WASM in some very exciting cloud native stacks. We are also working on the formulation and development of the WASI APIs in areas such as cryptography.

We believe that WASM is a highly promising technology, much like containers. It has the potential to provide a lightweight format across multiple architectures. Since WASM/WASI is supporting more and more languages everyday (polyglot), it has the potential to enable developers in their native, preferred language (whether that be Rust, Python, Ruby or Go).

We expect WASM (and WASI) to gain adoption over time, notably in the cloud-native, edge and serverless spaces. In addition, we think that WASM/WASI is a great binary format to be deployed within container images, with the potential to provide portability between hardware architectures. This could simplify the interactions between developers on one architecture (ARM, or x86), and cloud instances deployed on a different architecture.

WASM Integration with OCI

While not the only use case for WASM/WASI, one of the more immediately interesting use cases is deploying WASM binaries within container images. This allows users to create one container image which can be deployed across multiple architectures, saving disk space, compile time and reducing the testing matrix. At runtime, there’s the potential to provide defense in depth with both the WASM security controls, as well as the traditional kernel controls.

Red Hat implemented WASM support into the crun Open Container Initiative (OCI) runtime last year. Code was added to crun to allow the building and running of wasm workloads in a native manner.

Notice that in the above demo, the WASM runtime is being executed by crun within an OCI container. This means the host and other processes on the host are protected not only by namespacing and cgroup resource constraints, but also the security protections of SECCOMP and SELinux. This provides defense in depth alongside WASM’s capabilities based security controls. Since Podman and CRI-O share code, this same work can be used to deploy and run a WASM module within a Kubernetes Pod. This isn’t supported in OpenShift yet, but this demonstrates the potential benefit.

For more information on this crun deployments, check out the article on opensource.com by Red Hat engineers Aditya Rajan & Giuseppe Scrivano, or the step by step tutorial from Red Hat’s Ivan Font, of the CTO office.

Serverless Technologies in Openshift Service Mesh

You can use WebAssembly extensions to add new features directly into the Red Hat OpenShift Service Mesh proxies. This lets you move even more common functionality out of your applications, and implement them in a single language that compiles to WASM bytecode. Developers can then write in their language of choice and compile to a common target of WASM and deploy directly as Envoy HTTP Filters, giving them a wide range of capabilities:

• Manipulating the body and headers of requests and responses
• Out-of-band HTTP requests to services not in the request path, such as authentication or policy checking
• Side-channel data storage and queues for filters to communicate with each other

Looking into the future

At Red Hat, we think WASM/WASI is an exciting technology. On the server side, we see the potential for WASM/WASI to become an industry standard for portable binaries, solving the compile-once, run-anywhere problem. We also see it as an extra layer of security for containers, and a technology which has the potential to solve the fast-startup sandboxing necessary for efficient PaaS and FaaS that also add enhanced security footprints. Finally, we’re excited by the future of the Component Model, and how this facilitates a way to compose applications by combining code from many different programming languages. This is enabled through the use of modular language-agnostic interfaces using an interface definition language (IDL) that allows components and their instantiations to reuse code similar to shared libraries, executables, and processes in Linux.

To enterprise customers, we want to express our cautious excitement about the potential of this technology as well as our perspective that it’s still evolving and maturing. On the browser side, WASM is an established technology, but on the server side, it’s still in a nascent state. There’s a lot of engineering investment in the WASM community, financial investment from venture capital, and startups building on the technology, so we expect things to evolve rapidly.

Today, users can experiment with WASM in Fedora 37 and RHEL 9 using EPEL 9. While there’s only a single WASM runtime package available today, we expect to see more become available over time. Red Hat’s focus today is on upstream community work, and enabling as many people as possible to help shape this technology. We’re contributing upstream, learning, and analyzing where we think WASM and WASI will fit in the enterprise software stack, and we want to encourage you to get involved.