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

> On main since rc2: A multi-tenant microVM platform written in Kern, from KVM up.

Source: https://kern-lang.eu/releases/multi-tenant-microvm-platform

On main since rc2

## Release notes

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.