Experimental · source not yet public
ABSD
A small x86-64 operating system for stateful, recoverable workloads.
ABSD is being built partly to test Constellation’s semantics below the application layer: what a process, a crash, a write and a recovery have to mean for evidence to survive them. It is operating-system research, not part of any Constellation release, and it currently runs only under QEMU.
What it runs
- Kernel. A small
no_stdRust kernel for x86-64, booted by GRUB through Multiboot2. - Rust userspace with process isolation. Statically linked Rust programs run in ring 3, each in its own address space. Kernel objects (the console, child processes, versioned values called cells, and pipes) are reached only through per-process handles with narrowable rights; stale, guessed or wrong-kind handles fail. A process that faults is reported as faulted without stopping the kernel, and every page, handle and process slot it held is reclaimed.
- A standard-library target. An experimental Rust
stdtarget lets ordinary Rust programs and their dependencies build for ABSD. - Storage. The kernel exports one block device (ATA, or an NVMe namespace) with read, write and flush. Everything above that is userspace: a region layout, an append-only journal, a two-slot generation protocol, and a small filesystem library.
- SQLite in WAL mode. The filesystem exists because Constellation AG’s real SQLite authority store needs one. That store runs on ABSD in WAL mode, with full sync, through a native SQLite VFS; the carried patch only swaps its Unix imports for a platform layer and changes no store logic, schema or SQL.
- Real Constellation components. Besides the AG store, ABSD runs Pulse’s replay evaluator, whose report matches the hosted build byte for byte and whose output agrees with it on all 18 retained traces, and Pulse’s historical journal. Nightshift’s resolver, holding a read-only handle to the disk, answers five requests byte-identically to the Linux build; the kernel refuses its write attempt.
How it is tested
- Deterministic boots. The test suite boots QEMU and requires exact serial milestones and exit status. One boot sends thousands of random system calls from ring 3 and requires the kernel to survive and reclaim everything.
- Crashes. Machine stops at named write points, and worker processes killed mid-operation, across journal appends, generation activation and every sampled filesystem write of an AG admission and of the SQLite checkpoint on close. After each boot, independent host-side readers parse the disk image and check the guest’s recovery; for the AG store the host’s own SQLite recovers the database and recomputes the authority digest.
- Power loss. Under a stated device law — writes not covered by a completed flush may be lost or reordered, and each aligned 512-byte or 4 KiB unit is written atomically — about 1.6 million enumerated or sampled outcomes on the host and 66 cuts inside the guest. In every one, the filesystem mounted exactly one committed state and the AG store recovered either its prior or its new authority. Removing a required flush makes the test fail.
- Refusal over repair. A torn journal is not appendable until an operator truncates it. A damaged filesystem superblock is refused, not rolled back: that costs availability, never correctness.
Limits
- QEMU only. A bootable image for a physical laptop has been prepared and tested under QEMU’s BIOS and UEFI firmware, but ABSD has not booted on physical hardware.
- One CPU. Networking is one kernel-driven network card with the TCP stack inside the process that holds it, static addresses only, enabled only by an explicit boot option; an SSH server runs on it. Programs come from an embedded catalog or are started as images from the filesystem through a broker; there is no dynamic linking.
- One writer process holds the filesystem at a time; there is no filesystem server. The on-disk format is experimental, with no compatibility promise.
- The power-loss result does not cover media that tear a sector unit, media corruption, or whether a particular drive honours its flush command.
- The source is private. The facts on this page come from the project’s own documentation and test records as of 2026-10-01 and cannot be checked from here yet.