This was the first outing in 2013 for unikernels as a compelling technique for building specialised infrastructure components such as DNS, HTTP or OpenFlow switches. It explains the single-address space memory layout for x86_64 Xen unikernels, how they work with the MirageOS OCaml code, and very competitive performance despite end-to-end type-safety down to the device drivers.

In this article from 2015, Antti Kantee takes us on a brief tour of how and why the operating systems of today came about, then makes the case that "in the ages past the mountain-machine, there is no one all-encompassing operating system because there are so many styles to computing". He explains the role of rump kernels in providing componentized, reusable, production-quality drivers to support running existing applications in new styles of computing — as demonstrated by the Rumprun unikernel — and concludes with splitting the operating system and drivers into separate paths of systems development.

This 2015 paper introduces the Xen/ARMv7 port of unikernels that run on commodity boards (e.g. the £39 Cubieboard2) and are thus suitable for building IoT clouds. It also shows off the fast boot capability of unikernels via the Jitsu Xen toolstack, which boots a VM in response to DNS lookups in real time. Unikernel VMs can often boot faster than a Linux container, due to their lack of reliance on disk access. It also illustrates the security advantages of unikernels vs a conventional Linux stack.

Existing SSL/TLS stacks remain stubbornly vulnerable to low-level attacks and logical errors in their state machines. This paper describes how we rebuilt the protocol from scratch to be fundamentally more resistant to such attacks, while remaining fully interoperable with external services. To assure ourself of this, the same nqsb-TLS code can be used as an oracle to verify that protocol traces from OpenSSL or other implementations conform to its behaviour. See also nqsb.io.

Since unikernels do not have a conventional filesystem, we had the opportunity to build one custom-made for distributed, delay-tolerant environments such as a cloud or IoT. Irmin is based on the same techniques as the Git version control system, but scaled up to support a full unikernel filesystem.

Since existing applications often require a POSIX filesystem, we also designed a mechanism for mathematically specifying what it means to be POSIX at all (normally difficult to ascertain due to it only being written down as a large, prose specification). We use this model for two purposes: to test existing filesystems for compliance and find several bugs, but also as the reference design for a unikernel POSIX filesystem that guarantees compliance.

Unikernels run a single language runtime per VM address space, and so multiple languages form a distributed system. MirageOS (written in OCaml) supports a sophisticated foreign function interface that lets it interoperate with other language runtimes running inside other virtual machines. This lets us construct unikernel enclaves that run older applications written in C/C++/Node.js/etc, but handling all network traffic such as TCP/IP or TLS via the safe MirageOS unikernel.