Webassembly on exotic architectures (a 2025 roundup) / Apr 2025

It's about the time of the academic year to come up with project ideas! KC Sivaramakrishnan, Andy Ray and I have been looking into FPGA/OCaml matters recently so I thought I'd review the latest in the land of Webassembly for non-traditional hardware targets. It turns out that there are very fun systems projects going on to turn wasm into a "real" target architecture on several fronts: a native port of Linux to run in wasm, a port of wasm to run in kernel space, a POSIX mapping of wasm, and fledgling wasm-CPUs-on-FPGAs.

Native port of Linux to wasm

The first one is a native port of the Linux kernel to run in webassembly (try it in your browser). This isn't an emulation; instead, the various kernel subsystems have been ported to have wasm interfaces, so the C kernel code runs directly as webassembly, with virtual device layers.

The inspiration for this seems to have come from a famous comment eight years ago on the LKML:

One more general comment: I think this may well be the last new CPU architecture we ever add to the kernel. Both nds32 and c-sky are made by companies that also work on risc-v, and generally speaking risc-v seems to be killing off any of the minor licensable instruction set projects, just like ARM has mostly killed off the custom vendor-specific instruction sets already. If we add another architecture in the future, it may instead be something like the LLVM bitcode or WebAssembly, who knows? -- Arnd Bergmann, LKML, 2018

And this port brings us much closer to that! I need to spelunk more into the diffs to the mainline kernel to see how it all works, but some quick notes:

• the tools/wasm directory shows how some of the glue code works, such as the worker.ts which uses WebWorkers to implement multicore, and the venerable virtio to implement virtual block devices.
• the arch/wasm contains the glue code, and mm.c shows how atomic builtins in wasm are sufficient to implement low-level memory management. The clone implementation leads us to wasm_imports.h which shows all the FFI stubs needed from the runtime in worker.ts. Notably, it looks like the process switcher doesn't use the wasm stack switching extension (possibly for compatibility?).
• the arch/wasm/kernel/syscall.c (and that whole directory) could form the basis for a nice OS teaching course. Implementing the core of an OS on a virtual hypervisor is always an educational experience, and this port is based on "real" Linux!

Running wasm in Linux kernel mode

On the opposite end of the architecture spectrum, we have a Linux in-kernel WASM runtime. This one allows running userspace code within the kernel space, as motivated by:

Since WASM is a virtual ISA protected by a virtual machine, we don't need to rely on external hardware and software checks to ensure safety. Running WASM in the kernel avoids most of the overhead introduced by those checks, e.g. system call (context switching) and copy_{from,to}_user, therefore improving performance. Also, having low-level control means that we can implement a lot of features that were heavy or impossible in userspace, like virtual memory tricks and handling of intensive kernel events (like network packet filtering). -- Why run Wasm in the kernel

There are some interesting example applications available that they accelerate. They report on the speedup for an echo and http server that can run in kernel space:

When compiled with the singlepass backend (unoptimized direct x86-64 code generation) and benchmarked using tcpkali/wrk, echo-server is ~10% faster (25210 Mbps / 22820 Mbps) than its native equivalent, and http-server is ~6% faster (53293 Rps / 50083 Rps). Even higher performance is expected when the other two Wasmer backends with optimizations (Cranelift/LLVM) are updated to support generating code for the kernel. -- kernel wasm benchmarks

Running POSIX applications in the browser

The kernel-wasm port lead me to look more closely at the wasmer runtime, which in turn also extends the wasi server-side interface of WASM to support full POSIX compatibility. You can also view this in the browser as a shell, where a variety of applications can be compiled to wasm and run as if you had a shell in the browser!

There is impressive support for POSIX here, as well as an wasmer/wasix SDK to port existing applications like ffmpeg to run in the browser or on in a server JS runtime.

So what's stopping OCaml --via the new wasm-of-ocaml compiler -- from running in the browser? Just the fact that our target runtime depends on the wasm stack switching extension, and wasmer doesnt yet support that extension. Since there, wasmer 2.3 has improved stack switching performance but the extension isn't quite there yet. So if anyone's looking for some experience with language runtime hacking, this might be a good project. I couldn't find any information on whether wasmer is planning on adding support for this extension yet though.

Running wasm on an FPGA

And last but not least, given all of the above, what would it take to run wasm on an FPGA directly? The existence of the Linux native wasm port is encouraging, since it implies that if you were to get wasm instructions to run directly on an FPGA (just like you might wiht a MIPS FPGA CPU or a RISC-V one), then you could hook up the rest of the OS ecosystem to this as custom drivers.

I found a few projects around this space that I need to look into more:

• wasmachine is an implementation of the WebAssembly specification in a FPGA. It follows a sequential 6-steps design. https://github.com/piranna/wasmachine (see wasm design discussion)
• a wasm-fpga-engine that executes a subset of instructions
• an FPGA accelerator for WASM instructions. This one came before the stack switching extension though, which might make the implementation in hardware significantly easier.

And more...

After first posting this, here are incoming updates. Jonas Kruckenberg tells me that he's got an experimental OS called k23. This is a microkernel that is built around the idea of using Wasm as the primary execution environment:

This allows for a number of benefits:

• Security: WebAssembly is designed to run in a sandboxed environment, making it much harder to exploit.
• Modularity: WebAssembly modules can depend on each other, importing and exporting functionality and data, forming a modular system where dependency management is a first class citizen.
• Portability: WebAssembly is designed to be very portable. Forget questions like "is this binary compiled for amd64 or arm?". k23 programs just run wherever.
• Static Analysis: WebAssembly is famous for being very easy to analyze. This means we can check for bad programs without even running them. -- The k23 manual