A multi-tenant microVM platform written in Kern, from KVM up

The isolation story went from a proof of concept to a multi-tenant platform in one wave. The decision recorded in docs/design/microvm-kern.md was to write the monitor from scratch in Kern rather than orchestrate Firecracker or Cloud Hypervisor, because a multi-tenant isolation boundary that is someone else's binary is where sovereignty stops.

The guest

Cap<Vm> is a capability kind only the entry module can mint, so an ambient KVM call is E0404. The engine enters 64-bit long mode, implements the Linux boot protocol and boots an unmodified Ubuntu kernel, which logs over a 16550 UART emulated in Kern; emulating the transmit and receive interrupts made that console interactive, so a shell answers uname over a live session. A virtio-blk device mounts real ext4 and the guest boots straight from /dev/vda with no initramfs, running the distribution's own /sbin/init as PID 1. A tap-backed virtio-net NIC gives it a network, and vm_publish_port DNATs a host port to a guest service over nftables, verified end to end.

The platform

Tenants run as one OS process each, the same isolation boundary Firecracker and Fly.io use, so a tenant cannot corrupt a co-tenant through shared in-process state; each gets its own cgroup, Landlock scope and seccomp jailer. Authority is split by capability rather than by convention: spawning and stopping need Cap<Process>, confinement and stats need Cap<Fs>, and only the runner itself mints Cap<Vm>. Every lifecycle transition, created, booted, spawned, stopped, reaped, lands in the same SHA-256-chained event log the compliance trail uses, and microvm_audit_verify checks it independently.

The hardening shipped with it, not after

No guest-supplied value forms a host pointer without first being proven to lie inside the guest's RAM; the bounds check was rearranged so a descriptor address near INT64_MAX cannot overflow-trap and abort the monitor; disk DMA is gated on the backing file's real size so a guest cannot write past it; and kill now rejects a non-positive pid, because a failed spawn's -1 reaching a terminate path would have signalled every process on the host. An adversarial test proves host memory just past the guest region survives a hostile write.