Implementation Status

CambiOS Implementation Status

Living status doc. This file is the single source of truth for “what is currently built.” It is auto-refreshed when feature work lands (see CLAUDE.md § Post-Change Review Protocol Step 8). Pure intent and plans live in CambiOS.md and the design docs; this file is for current state.

If you’re trying to figure out “is X done yet?” — this is the doc to read. If you’re trying to figure out “should X be done a certain way?” — read the linked design doc instead.

At a glance

• 447 unit tests passing on host (x86_64-apple-darwin)
• x86_64: clean release build, boots in QEMU with 2 CPUs, 6 boot modules running (policy-service, key-store, fs-service, virtio-blk, compositor, shell). arcobj list/put/get works end-to-end; objects persist across reboots on virtio-blk. Compositor is the Phase Scanout-1 scaffold (ADR-014) — registers endpoint 28, enters headless mode, idles; no scanout-driver bound yet.
• AArch64: clean release build, boots in QEMU virt, make img-aarch64 now builds + includes virtio-blk + compositor (same 6-module limine.conf as x86_64). Driver’s port-I/O init path is x86_64-specific — on AArch64 the driver enters no_device_loop() and ObjectStore stays RAM-backed until AArch64 device IRQ routing lands.
• Bare metal: USB boot tooling complete (make img-usb builds GPT image; make usb DEVICE=/dev/diskN writes safely); not yet tested on target hardware (Dell Precision 3630)

Subsystem status

Phase markers

CambiOS uses informal phases to mark identity/storage milestones. These phases are referenced from identity.md and FS-and-ID-design-plan.md.

RISC-V port phases (parallel track — see ADR-013)

v1 Roadmap progress

The v1 milestone is “interactive, network-capable, identity-rooted OS running on real hardware with persistent storage.” Items in dependency order:

Currently blocking the v1 sequence: Phase 3.4 (policy service). Revocation (Phase 3.1), channels (Phase 3.2d), and audit infrastructure (Phase 3.3) are done. Once the policy service exists, items 4-10 sit on top of it and proceed in order.

Test coverage

Run with: RUST_MIN_STACK=8388608 cargo test --lib --target x86_64-apple-darwin

Known issues

• AArch64 SMP timer on AP: PPI 30 (ARM Generic Timer) does not fire on the second CPU in QEMU virt. Single-CPU mode works fully. Investigation pending; may be a QEMU configuration issue or a missing GIC redistributor configuration step on the AP path.
• AArch64 device IRQ routing: GIC enable_spi() / set_spi_trigger() exist as functions but are not called from the boot path or handle_wait_irq(). Device IRQs (virtio, PL011 RX) are not yet functional on AArch64. Affects virtio-blk polling-mode viability too — deferred.
• Legacy-virtio queue-size clamping (virtio-net): user/virtio-net/src/main.rs caps the virtqueue at 32 entries, but the device advertises more (QEMU: 256) and legacy virtio’s Queue Size register is read-only — the driver MUST use the device-reported size. The mismatch puts avail/used rings at different offsets on the two sides, so completions never arrive. Diagnosed during Phase 4a.ii. Fix: bump MAX_QUEUE_SIZE to 256 and drop the clamp (the virtio-blk driver does this). Re-enable the network drivers in limine.conf only after fixing this.
• fb-demo (Phase GUI-1) blocks Phase 4a services when both are enabled: When fb-demo is in limine.conf alongside the Phase 4a modules (fs-service, virtio-blk, shell), fb-demo’s SYS_MAP_FRAMEBUFFER call completes kernel-side (kernel prints [fb-syscall] write_user_buffer rc=Ok(32)) but fb-demo’s userspace never prints [FB-DEMO] after syscall, and the subsequent boot modules (fs-service, virtio-blk, shell) never reach their service loops. Root cause undiagnosed; likely an issue in the framebuffer syscall’s return path or fb-demo’s expectations about the mapping. Temporarily disabling fb-demo.elf in limine.conf lets the Phase 4a chain come up cleanly. Not a Phase 4a bug — it’s a Phase GUI-1 concern — but listed here because it affects the arcobj interactive demo.
• Boot module ordering is non-deterministic Resolved. Sequential boot-time module loading landed: SYS_MODULE_READY = 36 + BlockReason::BootGate + BOOT_MODULE_ORDER static. Each boot module’s _start calls sys::module_ready() after endpoint registration; modules boot in dependency order (policy → ks → fs → virtio-blk → shell → hello.elf). limine.conf reordered accordingly.
• Intermittent kernel page fault in Scheduler::schedule during task-exit cleanup Resolved. Root cause was two interacting bugs: (1) handle_exit did not purge the exiting task from the scheduler’s ready queues, leaving a stale TaskId that later dereferenced a freed slot; (2) ChannelManager::revoke_all_for_process returned a [Option<ChannelRecord>; MAX_CHANNELS] (~36 KiB) on the 8 KiB kernel stack, overflowing into adjacent task stacks and corrupting the BSP scheduler’s data. Fixes: Scheduler::purge_task(tid) helper added (called from handle_exit before yield_save_and_switch), revoke_all_for_process changed to return Vec<ChannelRecord>, and KERNEL_STACK_SIZE bumped from 8 KiB to 32 KiB.
• ELF loader doesn’t merge overlapping segment permissions: If two PT_LOAD segments share a page with different permissions, the first segment’s permissions win. Worked around in user-space linker scripts via ALIGN(4096) before .data. Loader fix is roadmap item 20.
• Kernel stack not freed on process exit: handle_exit now performs full cleanup (capabilities, channels, VMAs, page table frames, heap) as of Phase 3.2d.ii. The 32 KiB kernel stack per task is the remaining leak — freeing it requires a deferred-dealloc mechanism (can’t free the stack you’re running on). The leak is bounded by num_slots × 32 KiB (~6.4 MiB worst case). Scheduled for a dedicated cleanup pass.
• Pre-existing user-space driver warnings: cargo build on the user/virtio-net/ and user/i219-net/ crates emits dead_code / unused_imports warnings for scaffolded driver state (PCI field metadata, unused transport constants, phy_read/phy_write stubs, DmaBuf::zero, etc.). These are excluded from the main kernel workspace (Cargo.toml exclude list) so they do not affect kernel builds, but surface when make run invokes them. Not a correctness issue — the fields/methods are staged for future use. Tracking here so they get cleaned up when the respective drivers get their next real-hardware bring-up pass.
• Virtio-net TX completion may require yield to idle on QEMU TCG: QEMU TCG defers virtio TX processing to its event loop, which runs during guest hlt. The driver yields and the idle task hlts, which works for small bursts but the UDP stack’s ARP retry/timeout logic doesn’t yet exploit this fully.
• Clippy warnings (~125 remaining, down from 164): Auto-fixable suggestions applied; doc formatting and module-level comment style fixed. Remaining breakdown: ~67 multiple_unsafe_ops_per_block (unsafe block splitting in arch code — debatable in hardware-adjacent code), ~25 missing // SAFETY: comments, ~12 static_mut_refs (Rust 2024 edition migration — IDT/GDT/TSS patterns need UnsafeCell or addr_of!), ~20 new_without_default suggestions. Scheduled for a dedicated cleanup pass between Phase 3.2d (channels) and Phase 3.3 (telemetry), before the static mut deprecation becomes a hard error.

Cross-references

• CambiOS.md — source-of-truth architecture document
• identity.md — identity architecture (Phases 0-7 are defined here)
• FS-and-ID-design-plan.md — settled decisions for the identity + storage layer
• SECURITY.md — enforcement status table (security-specific subset of this document)
• GOVERNANCE.md — project governance, deployment tiers, scope boundaries (companion to ADR-009)
• ASSUMPTIONS.md — catalog of every numeric bound in kernel code with SCAFFOLDING / ARCHITECTURAL / HARDWARE / TUNING category
• README.md — public-facing summary
• SCHEDULER.md — scheduler implementation reference
• docs/adr/ — architecture decision records (ADRs 000-013)
• CLAUDE.md — kernel technical reference and required-reading map