Red Echo

September 22, 2015

Perhaps the reason I can’t sell myself on a specific minimal microkernel interface is that the system I want to build is not a microkernel at all. What I really want is no interface, no API, but an exokernel system where every program is written as though it were the only occupant of a single machine.

The interior space of a POSIX machine is so complex I’ve given up on the prospect of securing it, but hypervisors seem to have accomplished the job of secure isolation well enough to make the whole “cloud computing” business work. What if processes in this hypothetical environment were merely paravirtualized machines? Each executable would be a single-purpose “operating system” for a virtual machine.

A hypervisor takes the place of the traditional kernel, VirtIO devices stand in for the usual device-manipulation syscalls, and the shell becomes a HID multiplexer. Since each process sees itself as a separate machine, there is no longer any requirement for a shared mutable filesystem; instead of communicating by manipulating shared resources, processes must share resources by communicating.

From this perspective it is no longer important to know whether the system is running on bare metal or within some other host OS. Each process merely interacts with some array of devices to accomplish some defined task. An instance of this system built for a bare-metal environment would have to include drivers for actual devices so that they can be represented as virtio elements, but from the perspective of a program, inside its paravirtual machine, it simply doesn’t matter how many layers of emulation are stacked up above.

This offers a lovely progressive path toward implementation of the various components necessary for a useful operating system, since they can be implemented one by one as QEMU guests. In effect, it’s a redefinition of the API: instead of looking at the traditional POSIX style syscall interfaces as the OS API, we simply define the notional standard PC implied by virtio as the system interface, and anything capable of running on such machine becomes a valid element of the overall system.

In effect, this means that KVM becomes the kernel, and my project would be a shell program which can multiplex a set of interface devices among an array of VMs containing the actual programs I want to use.