See the Bastion project page for the implementation status sidebar, component breakdown, and project log.
What exists
Bastion currently boots on real x86-64 hardware through UEFI. The kernel covers a hand-written assembly machine core, VGA framebuffer, Ethernet driver, TCP/IPv4/ARP stack, TCP shell, live kernel replacement without a full reboot, DMA allocator, PCI, serial I/O, PS/2 keyboard input, ACPI integration, USB/xHCI, IOMMU/VT-d DMA confinement, 802.11 wireless, and service execution. Above the assembly floor, the kernel is being rewritten out of Rust and into Vulkgryph (.vg), its own controlled language, which has its own compiler and x86-64 code generator.
Bare-metal x86-64 kernel with UEFI boot, interrupt tables, context switching, syscall trampolines, and atomics.
Intel Ethernet path with ARP, IPv4, TCP, a guarded TCP shell, and live kernel replacement over the network. A secured WPA3-SAE wireless association has been qualified on real hardware; the wireless data path has not.
Framebuffer, PCI, DMA allocation, serial, keyboard, ACPI, and USB-controller work are under active development.
Vulkgryph (.vg) compiles process descriptions to native x86-64 ELF — runnable binaries for Linux development, and relocatable objects the kernel links against.
Current direction
The direction is a small, inspectable system with explicit boundaries: boot, interrupts, drivers, network state, service behavior, and remote operation are kept visible rather than hidden behind a general-purpose operating environment.
Concretely, that now means removing Rust from the kernel in favour of .vg, subsystem by subsystem. Scheduling, timer and interrupt sequencing, exception containment, paging, ACPI parsing, and the IOMMU path have moved across, and the superseded Rust is deleted rather than left in place. Each boundary is recorded with the baseline commits it was proven against, the tested kernel hash, and an explicit statement of what it does not claim; most are qualified across five consecutive runs on real hardware rather than in emulation.
Current limits
Bastion is still an active engineering system. It needs production hardening, external documentation, naming cleanup, and validation across more machines before it should be treated as deployable software. There is no release date.
Full self-hosting is not claimed. Kernel builds accept a natively compiled object only when it is byte-identical to the output of the Rust reference compiler, and the reference is still used where that match is unavailable — so Rust continues to participate in producing some kernel objects. Native object staging across the whole kernel, the operator shells, C interoperability needed for ACPI, the wireless data path, and the trust-anchor work all remain open.