A research operating system, written from scratch in Rust

One address space.
No shell. No network. No legacy.

RiftOS is a single-address-space operating system for x86-64. Every program is safe Rust, isolated by the language and by hardware protection keys, sharing one page table and talking through zero-copy IPC. Applications and libraries live in a content-addressed BLAKE3 image store, and nothing in it speaks UNIX, POSIX or TCP/IP.

12 cores
online in 11 ms
210 cycles
per kernel-thread switch
1 interrupt
in 300 ms on an idle CPU
170 tests
host, model-checked and in-guest

Principles

Each of these was a deliberate choice, researched and recorded before any code was written.

A single address space

One global page table that is never switched. Programs run in ring 3 and are separated by memory protection keys rather than separate page tables, so a call into another program costs a key switch, not a TLB flush.

Safe Rust, enforced

A program's own crates may not contain unsafe; the image builder rejects it, macros included. All unsafe code lives in a small, audited framework layer of the kernel behind sound, safe interfaces.

Zero-copy IPC

Synchronous calls migrate the calling thread through generated proxies. Larger messages move ownership through an exchange heap and per-pair rings, so data is handed over, never copied.

Content-addressed images

Every program is one statically linked image, addressed by its BLAKE3 hash and signed with a hybrid Ed25519 and ML-DSA-65 signature. The bootloader refuses anything it cannot verify.

Persistent data, not processes

Programs commit regions of memory that survive reboots at stable addresses. Threads and channels do not persist: services restart from a signed manifest and re-attach to their data.

Deliberately small surface

There is no shell to break into, no network stack to attack, and no POSIX compatibility layer. The interfaces are designed for this system rather than inherited from the 1970s.

Architecture

Boot

RiftLoader, a UEFI application of its own, checks the kernel image against its BLAKE3 hash, builds the initial page tables, exits boot services and jumps into the kernel. It also reserves the low memory the other cores start from.

Memory

The kernel maps all RAM with 1 GiB pages and keeps read-only aliases of its own code. Frames come from a lock-free allocator in the style of LLFree; small objects from per-CPU slabs with message-passing remote frees.

Processors

Its own ACPI parser finds the cores; x2APIC starts them through a stub that goes from real mode straight to long mode. TLB shootdowns are a protocol the memory layer owns, so a faulty messenger can stall a shootdown but never leave a stale translation behind.

Scheduling and time

An EEVDF scheduler on an augmented red-black tree, following current Linux down to delayed dequeue. Timers are a Linux-style wheel plus a heap of precise deadlines on the one-shot local APIC timer, with no periodic tick at all.

Progress

  1. M0

    Workspace and tooling

    Reproducible disk images, a QEMU runner, binary logs over the serial port, guest tests.

  2. M1

    Booting a real kernel

    RiftLoader verifies and loads the kernel, which takes over its own descriptor tables and traps.

  3. M2

    Memory management

    Direct map, lock-free frame allocator, per-CPU slab heap, guard pages and write-protected code.

  4. M3

    Platform and SMP

    ACPI, x2APIC, calibrated clocks, all twelve cores online, IPIs and TLB shootdowns.

  5. M4

    Threads and scheduling

    Locks, kernel threads, the EEVDF run queue and tickless timers are in; blocking, load balancing, SIMD state and RCU are under way.

  6. M5

    Domains

    Ring 3, protection keys, the safe-Rust program target, thread migration and restart on failure.

  7. M6–M7

    IPC and drivers

    Rings, the exchange heap, and the first device drivers as isolated programs.

  8. M8

    Image store

    The BLAKE3 pack store, signed manifests and services started from them.

  9. M9

    Persistence

    A copy-on-write page store with crash injection, commits and migrations.

  10. M10

    Real hardware

    NVMe, booting from USB and measured boot on a Ryzen desktop.

How it is built

Research first

Every milestone starts with a study of the current state of the art. Each design choice goes to the owner as an explicit decision with alternatives, and is recorded before code is written.

Checked, not hoped

Lock-free code is model-checked with loom and shuttle, unsafe code runs under Miri, and the kernel boots in QEMU for every guest test, under both hardware virtualisation and emulation.

Tests that can fail

Critical tests are mutation-checked: the code is broken on purpose to prove the test notices. A TLB test that misses disabled shootdowns, or a lock test that accepts a weakened unlock, is fixed before it counts.