Roadmap

Aegis is v1 software. On x86_64 the kernel boots, runs a full userspace, enforces capabilities at every syscall boundary, and serves network traffic. The filesystem is writable on NVMe, signals and pipes work, musl-linked utilities run against a fairly complete syscall surface, and application processors come up cleanly. But significant work remains before Aegis can credibly claim production-grade security or broad hardware support. This page describes what comes next, roughly ordered by priority and dependency.

Contributions are welcome at any stage. File issues or propose changes at exec/aegis.

Near-Term: ARM64 Port

Aegis currently targets x86_64 exclusively. The kernel/arch/arm64/ directory contains early scaffolding — a PL011 UART driver, GICv2 interrupt stubs, a linker script, a boot entry point, and stub files for userspace binaries — but the port is not functional. Completing it is the first major roadmap item.

What needs to be built:

Boot path. The existing boot.S needs a full aarch64 boot sequence: EL2-to-EL1 transition (or EL1 direct entry for QEMU -machine virt), BSS zeroing, initial stack setup, branch to kernel_main. The Multiboot2 protocol does not apply — ARM boots via device tree or UEFI, so the kernel entry contract changes.
MMU setup. AArch64 uses a different page table format (4KB granule, 4-level with TTBR0/TTBR1 split). The existing mmu_early.c and vmm_arm64.c need to implement identity mapping for early boot, then a higher-half kernel mapping equivalent to the x86_64 layout.
Exception vectors. vectors.S must implement the full EL1 exception vector table: synchronous exceptions (syscalls via SVC, page faults, alignment faults), IRQ, FIQ, and SError. The x86_64 IDT/ISR model does not translate directly.
Context switch. ctx_switch.S needs to save/restore callee-saved registers (x19-x30, SP, NZCV, FPCR/FPSR, SIMD state) and switch TTBR0 for process address spaces.
Syscall entry. AArch64 uses SVC #0 (not SYSCALL/SYSRET). The exception handler must extract the syscall number from a register (x8 by convention), dispatch to the existing syscall table, and return via ERET.
Driver abstraction. The x86_64 drivers (NVMe, xHCI, virtio-net, RTL8169) use PCI ECAM for device discovery and x86 I/O ports in some paths. ARM platforms use MMIO exclusively and discover devices via device tree. The driver layer needs a platform-agnostic device discovery interface so that existing drivers work on both architectures with minimal changes. For QEMU -machine virt, virtio-mmio (not virtio-pci) is the standard transport.
Interrupt controller. The existing gic.c stub needs a full GICv2 (or GICv3) distributor and CPU interface implementation to replace the x86 LAPIC/IOAPIC.
Timer. ARM generic timer (CNTPCT_EL0 / CNTP_CTL_EL0) replaces the PIT/LAPIC timer for scheduling ticks.

The target platform is QEMU virt (aarch64). Real hardware support (Raspberry Pi, Apple Silicon under Virtualization.framework) is a later goal.

Near-Term: Kernel Feature Completion

These items are the remaining gaps before the security model is fully demonstrable on x86_64. They are largely independent of each other and can be worked on in parallel.

TCP Polish

The network stack is implemented end-to-end (TCP, UDP, IP, ARP, DHCP client, poll/select/epoll, SO_REUSEADDR, SO_REUSEPORT) and carries real traffic — the in-tree httpd serves requests to the host. The outstanding item is a known race on the outbound TCP path that surfaces under specific retransmit timing. Fixing it requires tightening the send-queue/locking contract in kernel/net/tcp.c and adding a regression test that reproduces the race deterministically.

sys_setitimer for interval connection timeouts is also still missing — most server code today relies on poll timeouts instead.

Milestone: A sustained HTTP load test against Aegis httpd runs for 24 hours with zero hung connections or dropped retransmits.

Timer Infrastructure

Replace PIT-only timing with HPET or TSC-based high-resolution timers. clock_gettime already exists but runs at PIT resolution; a better clock source would enable nanosecond precision, per-process CPU time accounting, and tighter scheduling jitter.

TinySSH

A minimal SSH server for remote access. Statically linked, capability-gated (CAP_NET for the listener, CAP_AUTH for session authentication). This is the first real test of the capability model under adversarial conditions — an internet-facing service that must be confined.

Security Audit

At feature completion, the kernel will be roughly 10-15K lines of C plus the Rust capability core. Small enough for a serious line-by-line audit of every syscall path, every capability check, every pointer validation. This is the gate before anything runs in a non-experimental environment.

Medium-Term Goals

Rust Migration

The capability validation core (kernel/cap/src/lib.rs) is the first kernel subsystem written in Rust, compiled as a #![no_std] staticlib and linked via C FFI. This is the template for a gradual, subsystem-by-subsystem migration.

Planned migration order:

Capability system — done. cap_init, cap_grant, cap_check are Rust.
Syscall dispatch — the syscall table and argument validation layer. This is the primary attack surface for userspace-to-kernel exploitation. Rust’s bounds checking and type safety would eliminate entire classes of bugs here.
Drivers — DMA descriptor processing, MMIO register access, ring buffer management. The security considerations section of the driver documentation lists the specific risks: no IOMMU, unchecked descriptor lengths, trusted MMIO reads. Rust safe abstractions for MMIO and DMA would address these structurally.
Memory management — the VMM and VMA subsystems. These are the most complex and the last to migrate, because they are deeply intertwined with architecture-specific assembly.

Each subsystem follows the same pattern: #![no_std] crate, extern "C" FFI boundary, staticlib linked into the kernel. No Rust types leak into C. The C-to-Rust boundary is explicit and auditable.

virtio-gpu Support

Paravirtualized GPU for QEMU guests. Enables hardware-accelerated 2D rendering for the Lumen compositor without requiring a real GPU driver. The virtio-gpu protocol supports scanout configuration, 2D resource creation, and transfer-to-host operations — enough for a composited desktop without 3D.

AMD iGPU Driver (RDNA2)

Scoped to modesetting and SDMA 2D blits — not a full AMDGPU driver. Enough to set a display mode and accelerate framebuffer operations on AMD APUs (Ryzen 6000+). The full AMDGPU register space is enormous; this targets the minimum viable subset for a server or kiosk display.

Intel igb NIC Driver

The igb family covers most modern Intel server and desktop NICs (I210, I211, I350, I354). Adding igb alongside the existing RTL8169 driver gives Aegis viable network support on the majority of x86 hardware. The driver model is similar to RTL8169: descriptor rings, MMIO registers, polling-mode operation.

Apple Virtualization Framework Support

QEMU is the current development and testing platform, but Apple’s Virtualization.framework provides native hypervisor support on Apple Silicon Macs with significantly better performance. This requires the ARM64 port (above) plus virtio-mmio transport support (Virtualization.framework exposes virtio devices over MMIO, not PCI). The Vortex VM management tool already plans for this integration path.

SMP Scheduling Maturity

Application processors are brought up via INIT-SIPI-SIPI and enter an idle loop with per-CPU GDT/TSS/LAPIC state, so multi-core boot works today. What remains is turning that foothold into a real multi-core scheduler:

Per-CPU run queues with work-stealing for load balancing (the scheduler currently runs workloads primarily on the BSP)
Fine-grained locking on shared kernel state (PMM bitmap, VMM, global task table) — the current spinlocks are coarse and were written for a uniprocessor invariant
IPI-driven TLB shootdown on vmm_unmap and cross-CPU preemption wakeup
Per-CPU LAPIC timer replacing the shared PIT tick
KPTI (kernel page-table isolation) — separate user/kernel PML4 per CPU to mitigate Meltdown-class side-channel attacks. Capabilities do not address microarchitectural information leaks; KPTI does.

A lock audit of all global kernel state is a prerequisite for any of this landing safely.

Milestone: -smp 4 in QEMU boots all cores, the scheduler distributes workers across them, and HTTP load testing shows throughput scaling with core count.

Long-Term Vision

Self-Hosting

Aegis should be able to build itself. This requires a working C compiler (likely a port of a small C compiler like cproc or chibicc), an assembler, a linker, and make. Self-hosting is a strong correctness signal — it exercises the filesystem, process model, memory management, and syscall interface under sustained, complex workloads.

Package Management

A minimal package manager for installing, updating, and removing statically-linked binaries. Packages carry capability policy metadata — installing httpd also installs its /etc/aegis/caps.d/httpd policy file. No dynamic dependency resolution (all binaries are statically linked against musl).

AMD iGPU Acceleration (Full Path)

The medium-term AMD iGPU entry targets modesetting and SDMA 2D blits — enough to drive a display and accelerate memcpy-class framebuffer operations. The long-term goal is the rest of the stack: GFX ring submission, shader compilation, command buffer management, and enough of the Display Core Next (DCN) interface to drive the compositor through the GPU instead of writing pixels from the CPU.

Scoping this honestly: a full AMDGPU-equivalent driver is ~500K lines in Linux and tracks a moving firmware ABI. Aegis will not attempt feature parity. The target is enough acceleration that Lumen’s compositing pipeline — dirty-rect blits, frosted glass, window scaling, cursor overlay — runs on the GPU instead of the CPU, with the CPU-path software rasterizer remaining as a fallback. Vulkan, OpenGL, and compute workloads are out of scope.

The dependency chain: IOMMU support first (DMA attacks are unacceptable for a shared-memory driver), then firmware loading (PSP, SMU, SDMA blobs), then ring submission plumbing, then a narrow command stream for 2D composition. Each layer is independently testable via PCIe passthrough on real hardware.

Broader Hardware Support

IOMMU programming (VT-d / AMD-Vi) for DMA isolation — the single most impactful security improvement for the driver layer, and a prerequisite for the AMD iGPU work above
AHCI/SATA for older storage hardware
More NIC families as needed
Real GPU drivers beyond the scoped AMD iGPU target
Audio (likely virtio-sound first, then Intel HDA)

Real Hardware Coverage

Aegis already boots on real x86_64 hardware — the current reference machine is a ThinkPad X13 Gen 1 (Ryzen 7 4750U), where the kernel comes up cleanly through ACPI, brings up NVMe storage, and runs the full userspace including Lumen and the desktop shell. The remaining gap on that machine is networking: it has no built-in Ethernet, and Aegis does not yet have a USB-C / USB Ethernet driver. USB NIC support (likely starting with the ASIX AX88179 or RTL8153 families that ship in most USB-C dongles) is the next concrete real-hardware milestone.

Beyond that, the long tail is the usual: more NIC families, more storage controllers, ACPI quirks for machines that differ meaningfully from QEMU’s emulated platform, and eventually GPU initialization on hardware where UEFI GOP isn’t enough.

This roadmap reflects the state of development as of April 2026. Priorities may shift as work progresses. The best way to influence direction is to contribute — exec/aegis.