Kernel Drivers Compiled to Javascript and Run in Browser

The unique anykernel capability of NetBSD allows the creation of rump kernels, which are partially paravirtualized kernels running on top of a high-level hypervisor. This technology e.g. enables running the same file system driver in the monolithic kernel or as a microkernel style server in userspace. POSIX-compatible systems have been more or less supported as rump kernel hypervisors for the past 5 years. A long-time goal has been to extend hypervisor support further, for example to embedded systems. This would bring the solid driverbase of NetBSD available to such systems with only the cost of implementing the hypervisor.

To see how far things can go, last week I started toying with the idea of using a javascript engine as a rump kernel hypervisor. I was planning to compile the NetBSD kernel sources into javascript and manually implement the hypervisor. After some searching for a C->javascript compiler, I found emscripten, which translates C into javascript via LLVM bitcode. Not only is the compiler itself extremely mature, but there is also extensive support for the POSIX API. This meant that I could not only compile the kernel drivers to javascript with emscripten, I could also compile the existing POSIX hypervisor and have it work.

The approach of compiling kernel drivers into javascript allows them to be directly accessed from existing javascript code. Yes, I did add a sys/arch/javascript into the kernel source tree. This contrasts the approach taken by another similar experiment, where an x86 Linux is run inside a x86 machine emulator running in a javascript engine.

I have thrown together a small proof-of-concept demo of how to build a web service with the capability to access file system images using kernel file system drivers compiled to javascript. I compiled a rump kernel with support for the FFS, tmpfs and kernfs file systems. This rump kernel backend is tied to a lightweight web page which passes requests from forms to the rump kernel and displays results. When the javascript is run, it downloads an FFS image (rump.data), bootstraps a rump kernel, and mounts the FFS image r/o at /ffs. The status can be further manipulated with interactive commands.

The demo is available here. I've tested it to work with Firefox and tested it to not work with Internet Explorer. YMMV with other browsers. Note, the javascript and the FFS image together are close to 5.5MB in size, so the page may load for a few moments over a slow link -- javascript is not exactly compact and whitespace removal was the only size reduction technique I used. If you're interested in comparing the generated javascript with the C sources, you can also look at the unoptimized version (14MB).