36C3 - Leaving legacy behind

media.ccc.de/v/36c3-11172-lea...
Reducing carbon footprint of network services with MirageOS unikernels
Is the way we run services these days sustainable? The trusted computing base -- the lines of code where, if a flaw is discovered, jeopardizes the security and integrity of the entire service -- is enormous. Using orchestration systems that contain millions of lines of code, and that execute shell code, does not decrease this. This talk will present an alternative, minimalist approach to secure network services - relying on OCaml, a programming language that guarantees memory safety - composing small libraries (open source, permissively licensed) to build so-called MirageOS unikernels -- special purpose services. Besides web services, other digital infrastructure such as VPN gateway, calendar server, DNS server and resolver, and a minimalistic orchestration system, will be presented. Each unikernel can either run as virtual machine (KVM, Xen, BHyve, virtio), as a sandboxed process (seccomp which whitelists only 8 system calls), or in smaller containments (GenodeOS, muen separation kernel) -- even a prototypical ESP32 backend is available.
Starting with an operating system from scratch is tough, lots of engineering hours have been put into the omnipresent ones. Reducing the required effort by declaring certain subsystems being out of scope -- e.g. hardware drivers, preemptive multitasking, multicore -- decreases the required person-power.
The MirageOS project started as research project more than a decade ago at the University of Cambridge, as a minimal guest for Xen written in the functional programming language OCaml. Network protocols (TCP/IP, DHCP, TLS, DNS, ..), a branchable immutable store (similar and interoperable with git) are available. The trusted computing base is roughly two orders of magnitude smaller than contemporary operating systems. The performance is in the same ballpark as conventional systems. The boot time is measured in milliseconds instead of seconds.
Not only the binary size of a unikernel image is much smaller, also the required resources are smaller: memory usage easily drops by a factor of 25, CPU usage drops by a factor of 10.
More recently we focused on deployment: integration of logging, metrics (influx, grafana), an orchestration system (remote deployment via a TLS handshake, offers console access and an event log) for multi-tenant systems (policies are encoded in the certificate chain).
We are developing, mostly thanks to public funding, various useful services: a CalDAV server storing its content in a remote git repository, an OpenVPN client and server, DNS resolver and server (storing zone files in a remote git repository) with let's encrypt integration, a firewall for QubesOS, image viewer mainly for QubesOS, ...
The experience while developing such a huge project is that lots of components can be developed and tested by separate groups - and even used in a variety of different applications. The integration of the components is achieved in a type-safe way with module types in OCaml. This means that lots of errors are caught by the compiler, instead of at runtime.
Hannes Mehnert
fahrplan.events.ccc.de/congre...