WebAssembly as target for linux kernel : a dream that may soon come true

The Web world is converging to have full high performance computing runtime available right in the browser. WebAssembly development will soon bring to JavaScript world the necessary primitives we need to make a proper Linux in browser port.
  • Last Update:2017-09-05
  • Version:001
  • Language:en

VFSync was just released: it demonstrates how a web based Linux virtual machine can be extremely useful to provide ubiquitous access to POSIX based applications. But for now, it is based on the emulation of RISC-V or x86 processors which is still slow. If linux kernel could be actually compiled to target the native assembly of the Web - called WebAssembly - performance could be enhanced greatly. Until now, this was very difficult goal to reach with asm.js because of its underlying memory and execution model. WebAssembly model seems however much more suitable.

I recently I had a quick look at current WebAssembly & Chromium developments. It is great to see that the minimum WebAssembly version starts becoming available in major browsers, but what is even more great, it seems, is that WebAssembly development will (hopefully soon) push and bring to JavaScript world the necessary primitives we need to make a proper Linux in browser port:

SharedArrayBuffer. This lets js/wasm workers work on shared memory and this way essentially organize execution of threads. From https://v8project.blogspot.ru/2017/06/v8-release-60.html:

V8 6.0 introduces support for SharedArrayBuffer, a low-level mechanism to share memory between JavaScript workers and synchronize control flow across workers. SharedArrayBuffers give JavaScript access to shared memory, atomics, and futexes. SharedArrayBuffers also unlock the ability to port threaded applications to the web via asm.js or WebAssembly.

For a brief, low-level tutorial, see the spec tutorial page or consult the Emscripten documentation for porting pthreads.

Threads. Related what is planned on WebAssembly side almost right after first "Minimum Viable Product" is support for threads:

this will allow programs parts implemented in wasm to have the same memory sharing model JS part has with SharedArrayBuffer and to share the memory in between the two.

(P)NaCL -> WASM, Chromium is dropping support for running native code via (P)NaCL and will focus from now on only on supporting WebAssembly:

this is good news because even though (P)NaCL were great technologies to run native code fast in the browser, they were a) Chrome-only, and b) not supported on Mobile. With all-WebAssembly switch we'll hopefully have a way to run code fast on browsers everywhere. Let us hope that WebAssembly will also preserve the nice security model that was introduced with NaCl and proven with Frama-C (see also the slides here).

Future directions

The roadmap of Chromium support for WebAssembly is published at the page: WebAssembly and Friends Roadmap. It is worth a look to get some hints of what will happen next:

  • August 2017: SharedArrayBuffer
  • September 2017: asm.js -> WebAssembly, Wasm - postMessage
  • October 2017: Wasm - Threads

We can also find some hints about the future of WebAssembly in its future roadap: "Proposals we might consider in the future". One of these proposals includes "Finer-grained control over memory" as a possible future extension. With mmap/mprotect/shm/... working it would be possible to emulate an MMU.


The Web world is, it seems, step-by-step converging to have full high performance computing runtime available right in the browser. The Browsix project already implements a prof-of-concept UNIX-like kernel based on the idea to put every process to dedicated service worker with kernel residing in the main JavaScript area, and processes communicating with the kernel via shared memory.

As necessary efficient communication primitives are becoming ready and available in all major browsers such systems should be possible to run without large overhead. With MMU functionality available it will be possible to provide efficient memory mappings and cross-process protection. With filesystems mounted from network via e.g. 9P protocol it should be possible to turn any consumer device with only a browser into capable Linux workstation working on your data locally and in the cloud.

Nexedi is looking for a trainee or volunteer to come work with us on such Linux/WEB port and this way bring whole GNU world to everyone who has only a browser, as it is currently the case for most students in the USA.


  • Logo Nexedi
  • Kirill Smelkov
  • kirr (at) nexedi (dot) com
  • Photo Sven Franck
  • Logo Nexedi
  • Sven Franck
  • sven (dot) franck (at) nexedi (dot) com
  • Photo Xiaowu Zhang
  • Logo Nexedi
  • Xiaowu Zhang
  • xiaowu (dot) zhang (at) nexedi (dot) com