How KyberOS is designed
Take the Mach microkernel and keep it pure: microkernel, IPC, user-space servers. Put a UNIX personality on top, and plan a Linux personality so that unmodified Linux software can run.
The idea
Linux grew monolithic. Drivers, filesystems and system-call policy share one address space and one bug surface, tens of millions of lines deep. Mach took the opposite shape. Tasks, threads, ports, messages and virtual memory are the only kernel primitives, and drivers, filesystems and POSIX itself live in user-space servers connected by IPC.
Mach plus POSIX is not new. GNU/Hurd has pursued it since 1990, and XNU shipped it by giving up purity and putting BSD inside the kernel. The combination nobody has shipped is a pure Mach kernel built with clang and LLVM on x86_64, with a Linux system-call personality planned to run unmodified Linux software while the native format stays Mach-O.
Pure Mach, no hybrid
There is no BSD layer in the kernel. Speed is meant to come from fast IPC, helpers mapped into each program and a page cache, not from moving policy into the kernel.
Multiple personalities
Mach was designed to host several operating system environments at once. KyberOS plans UNIX as the primary one and Linux for compatibility, as thin shims over a shared POSIX core.
Capability-first
Ports are capabilities, with no ambient authority and no global names. The boundary between personalities is also an isolation boundary.
Mach-O native
clang and ld64.lld produce the native Mach-O format today. ELF is meant to exist only inside the Linux personality.
IPC built for speed
A message round trip costs every program on the system, so we measure it on every build. The home page shows the current figure and what changed.
Versioned from day one
A semantic version and a build number go into every boot banner, so any run can be traced to a build.
How it compares
The table includes the rows KyberOS loses. It is young, and the point is the shape of the design.
| Feature | KyberOS | Linux | XNU | GNU/Hurd | seL4 |
|---|---|---|---|---|---|
| Kernel model | pure Mach microkernel | monolithic | hybrid: Mach plus in-kernel BSD | Mach microkernel plus servers | verified microkernel |
| Native binaries | Mach-O | ELF | Mach-O | ELF | none, it is a component |
| Linux binaries | unmodified, via a Linux personality (planned) | native | no | POSIX sources, not the ELF ABI | no |
| OS personalities | several at once | one | one (BSD) | one (the Hurd) | whatever you build |
| Drivers and filesystems | user-space servers | in the kernel | in the kernel (IOKit) | user-space translators | user-space components |
| Security model | port-right capabilities; the personality boundary isolates | ambient authority plus LSM | BSD plus Mach ports plus MACF | ports and translators | formal capabilities, with proofs |
| Where policy lives | user-space servers | the kernel | the kernel | servers | you decide |
| Maturity | in development; runs a shell in QEMU | runs the world | every Apple device | research, plus a Debian port | defense, aerospace, embedded |
KyberOS loses to seL4 on verification and field record, and Linux compatibility is a milestone, not a shipping feature. No other row combines a pure Mach kernel, a Mach-O native format and Linux binaries as a guest personality.
Personalities on top, pure Mach underneath
The kernel's system-call entry is a thin router. It reads the task's personality field and passes the call to that personality's emulation entry point. The kernel never interprets a system-call number.
Thin shims, shared core
The POSIX core is a library linked into each personality server, not a shared process, so the personality boundary stays a real isolation boundary. Shims handle only what differs: kqueue against epoll, clone against rfork, sysctl against procfs, ptrace dialects.
One fat server, measured splits
Mach's multi-server idea hardly ever happened, because IPC cost punished decomposition. KyberOS starts with one server per personality and splits it only where a measurement justifies it.
Toolchain
clang and LLVM are the native toolchain: ld64.lld for Mach-O and ld.lld or GNU ld for the kernel. LTO, PGO and CFI are planned. The build uses CMake and Ninja, with no autotools in our tree.
Several processors
Mach was drawn for multiprocessors before Linux existed, and KyberOS follows that design. The boot processor is only the first one awake. The others come up through the same entry path, join processor sets and take work from per-processor run queues under one scheduler policy.
Today kernel threads run on every CPU. User programs on a second CPU are not yet reliable, and the fault is being traced.
Processors are objects
In Mach a processor is a kernel object with a port, not a special case in the code. Nothing about CPU 0 is meant to be privileged.
Processor sets
Threads are scheduled onto processor sets, and sets map onto processors. Grouping work is policy, and policy lives outside the kernel, where Mach put it in 1986.
Handoff when it wins
When a thread blocks, the processor can go straight to the thread that holds the work instead of detouring through a queue. It is an idea from the original design.
Milestones
The kernel boots in QEMU and runs a user-space shell on Mach IPC. The milestones are directional, not promises.
| Milestone | State | What it covers |
|---|---|---|
| M0 to M2g | done | Foundations: multiboot2 and PVH boot, physical memory, higher-half virtual memory, kernel heap, Mach vm_fault with copy-on-write, ring 3, syscall/sysret. |
| M3 | done | Mach-native IPC: spaces, ports, typed messages, blocking delivery, notifications, kernel-object RPCs and a direct-handoff fast path. |
| M4 and shell | done | User-space base: a Mach-O bootstrap loader, ring-3 tasks, a console server, spawn composition and a shell over serial. |
| SMP | partly | Application-processor boot, per-CPU run queues, processor sets and targeted IPIs. User programs on a second CPU are still being fixed. |
| M5 | current | Shell and personality growth: a growing system-call surface and the first files served from user space, including programs the shell loads from them. The personality router is proven. |
| M6 | next | POSIX core and VFS: real files under the personalities, then a real /bin/sh. |
| M7 to M8 | planned | The Linux personality running unmodified binaries as guests, then a C library. |
| M9 and later | planned | Capability sandboxing and MAC, secure boot, hardware drivers run in user space, namespaces and containers. |
The kernel charter
Every kernel feature must pass all five rules, or earn a numbered, dated exception in the decision log with a measurement that justifies it.
Same vocabulary
Built from tasks, threads, ports, messages, vm_map, vm_object, memory objects and the scheduler. No new kind of kernel object.
Mechanism in the kernel, policy in servers
The kernel offers the capability, and a user-space server decides how to use it.
Reached through ports
User-visible features are MIG-style interfaces on kernel-served ports. The trap set stays small and stable.
Capability-first
Access goes through port rights. Nothing depends on ambient authority, user IDs or global names.
Internals are free, within limits
Epochs, per-CPU zones, lock-free lookups and turnstile-style priority donation are all allowed behind an unchanged interface with unchanged observable behavior.
Why resume Mach
Mach did not lose on merit. It was early, ambitious and unfinished, in an industry that needed software shipped. The industry took its ideas anyway, inside kernels that traded purity for speed. Apple's systems run on XNU, which kept Mach and put BSD inside it. KyberOS keeps Mach pure.
None of this would be possible if its authors had not written it down. Papers, manuals and interface definitions documented the design well enough to outlive its lab. Rochester planted it, Pittsburgh built it, Utah carried it, GNU kept it going and Apple showed its ideas could run a billion devices.
KyberOS is not a clone and it is not nostalgia. It is the same project resumed: the microkernel they sketched, finished with four decades of hindsight.
Thanks
To the people of Rochester, Pittsburgh, Utah, Grenoble and Cupertino, and to everyone who compiled Mach, wrote for it, or believed the kernel could be small: thank you. We will take it from here.