{\mu}Fork: Supporting POSIX fork Within a Single-Address-Space OS

Abstract

Single-address-space operating systems have well-known lightweightness benefits that result from their central design idea: the kernel and applications share a unique address space. This model makes these operating systems (OSes) incompatible by design with a large class of software: multiprocess POSIX applications. Indeed, the semantics of the primitive used to create POSIX processes, fork, are inextricably tied to the existence of multiple address spaces. Prior approaches addressing this issue trade off lightweightness, compatibility and/or isolation. We propose {\mu}Fork, a single-address-space operating system design supporting POSIX fork on modern hardware without compromising on any of these key objectives. {\mu}Fork emulates POSIX processes ({\mu}processes) and achieves fork by creating for the child a copy of the parent {\mu}process' memory at a different location within a single address space. This approach presents two challenges: relocating the child's absolute memory references (pointers), as well as providing user/kernel and {\mu}processes isolation without impacting lightweightness. We address them using CHERI. We implement {\mu}Fork and evaluate it upon three real-world use-cases: Redis snapshots, Nginx multi-worker deployments, and Zygote FaaS worker warm-up. {\mu}Fork outperforms previous work and traditional monolithic OSes on key lightweightness metrics by an order of magnitude, e.g. it can offer a fork-bound FaaS function throughput 24% higher than that of a monolithic OS, and can fork a {\mu}process in 54{\mu}s, 3.7x faster than a traditional fork.