Guest post by Second State and FutureWei
Application containers, such as Docker, are a key driving force behind the growth of Cloud Native applications. However, while the Cloud-Native development paradigm has proven very popular, it is difficult to expand the Cloud-Native infrastructure beyond large data centers since application containers require significant amounts of computing resources. For example, Docker does not support real-time operating systems (RTOS) and only works on POSIX systems. Furthermore, on edge networks and devices, such as smart factories and smart automobiles, the industry ecosystem and suppliers network dictate that applications must be assembled from multiple independent vendors. For example, in a typical electrical vehicle, there are over 100 suppliers writing software components for different parts of the vehicle. It is crucial for the automobile OEM to provide a secure, high-performance, and real-time runtime environment for suppliers and vendors to integrate their software components. There are already several attempts to support application containers on edge RTOSes.
VxWorks is a leading commercial RTOS used in mission critical systems such as airplanes and space ships. VxWorks containers is a recent initiative (in 2021) to support OCI-compliant lightweight containers on the VxWorks RTOS.
However, the Docker approach is not a good fit for RTOS on the edge. Fundamentally, Docker is not real-time and assumes the availability of many underlying OS services. A much better runtime approach for RTOS is high-level bytecode VMs. Such VMs could be much lighter and faster than Docker. They provide capability-based secure sandboxes, make very little assumption about the underlying OS services, and at the same time, support multiple programming languages on the front end. WebAssembly, with its wide industry support and lightweight design, appears to be just the perfect VM runtime for complex edge applications.
Another interesting aspect of WebAssembly is that WebAssembly programs can often be formally verified for correctness just like seL4 itself. That makes them appropriate for mission critical systems like automotive OSes.
WasmEdge and seL4
The seL4 microkernel can function as a hyperviser. It can start a seL4 RTOS and a Linux OS (called guest OS) side by side on the same hardware. The Linux guest OS has a full set of features and tools for file system, networking, user accounts, shell, and CLI, but it is not real-time. The seL4 side is real-time, but headless. Our approach is run the WasmEdge agent in guest Linux. We can upload and store the WasmEdge bytecode file in the guest Linux, and then use the agent to hot deploy and execute the bytecode using a WasmEdge runner installed in seL4. The architecture is as follows.
This agent and runner architecture allows us to combine the guest Linux’s ease-of-use with seL4’s robustness, security, and real-time performance.
This design raises an interesting possibility. Maybe we could run a fully fledged Kubernetes pod in the guest OS to manage and orchestrate WasmEdge applications on seL4. That is an area of active research by the team.
Sample WebAssembly apps
WasmEdge can run any WebAssembly bytecode application on seL4. The sample WebAssembly applications in this demo are compiled from C and Rust source code.
nbody-c.wasmis a program to numerically approximate the N-body problem in C language. It is then compiled into WebAssembly bytecode from C.
hello.wasmis a Rust program to echo a string to the console.
Patching seL4 for WasmEdge runner
The standard libraries in seL4 do not support WasmEdge runner out of the box. We need to patch those libraries to add, turn on, or update some important features. We build a customized version of seL4 with these patches.
A simulator demo
The build script automates the process of building a seL4 distribution with patched libraries, the WasmEdge runner, a guest Linux OS (Ubuntu 20.04), and the WasmEdge agent (called
The build script requires an Ubuntu 20.04 system with developer tools installed. See here for a complete list of apt packages required on the system.
Once the customized seL4 distribution is built, we can run it in a QEMU simulator. We can log into the guest Linux OS’s command shell, upload and save WebAssembly bytecode files, and then run wasmedge_emit to deploy and run those WebAssembly files in seL4. The demo walks you through the entire process. You can watch a video to see it in action! https://youtu.be/2Qu-Trtkspk The GitHub Actions log shows the console output from a successful build task, and the artifact contains the build result. You can simply download the build artifact to your own Ubuntu 20.04 machine and start the simulator to run WebAssembly programs on seL4.
In this article, we demonstrated how to manage and execute WebAssembly applications on seL4 using the simulator. The next step is to run WasmEdge applications on real hardware. One of the key features of WasmEdge is that it is extensible. It is easy to add host function APIs to WasmEdge from shared native libraries so that WasmEdge WebAssembly bytecode programs can access hardware such as GPIO pins, cameras, USB connectors, I/O boards, and GPUs. Stay tuned for more use case demos for WasmEdge on seL4!