Roadmap

Development roadmap for Aegis OS — near-term milestones, medium-term goals, and long-term vision

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.

Released Versions

Version Date Highlights
v1.0.0 Apr 12 Initial public release on x86_64
v1.0.1 Apr 16 IPC/AF_UNIX/memfd hardening; Lumen freeze fixes; GUI installer wiring
v1.0.2 Apr 17 PS/2 Esc keypress fix; gui-installer arrow nav; Ctrl+Alt+I; chronos NET_SOCKET cap; deflaked installer test 0/15 → 15/15
v1.0.3 Apr 18 20 new coreutils; kernel envp propagation in execve; sys_sethostname (170); installer warns about overwriting existing Aegis; stsh strerror diagnostic
v1.0.4 Apr 13 security audit findings fixed (SCM_RIGHTS underflow, W^X enforcement, ELF loader validation, ext2 bounds, memfd UAF, TCP ISN, …); interrupt-driven COM1 RX
v1.0.5 Apr Networking on i440fx (legacy PCI fallback + ARP request replies + virtio RX storm fix); ramfs redirect/unlink/rename; ls flag-skip
v1.0.6 Apr ext2 fd-pool leak root-caused (the “ENOENT after ~11 execs” bug); SIGSEGV delivery on ring-3 CPU faults
v1.1.0 Apr GRUB → Limine (fixes AMD bare-metal UEFI boot); WIFSIGNALED; fork-slot reclaim; uaccess EFAULT on unmapped ptrs; signal-EINTR fix; receive-time ^C; stsh bg-reap
v1.1.1 May Desktop apps (calculator/editor/filemanager); font auto-bake at any TTF size; installer creds/verify; xHCI PP; NVMe poll/quarantine/FLUSH; full i8042 rewrite; /proc/kbdstat greeter diagnostics; git-derived version string
v1.2.0 Jun /apps bundle tree; Applications launcher; image viewer + system monitor; unlimited-RAM PMM; Lumen/Bastion memory fixes; +13 coreutils
v1.2.1 Jun 14 DNS fixes (4 musl-ABI gaps); network hangs fixed (blocking syscalls now signal-interruptible); TCP window-update ACK + dup-ACK for large HTTPS downloads
v1.2.2 Jun Security: /bin + /sbin install-protected; setuid binds to authenticated identity; lost-wakeup race in block/wake protocol closed
v1.2.3 Jun 14 wait_event unification — one blocking primitive (kernel/sched/wait_event.h) replaces ~25 hand-rolled sleep/wake loops across pipe/sockets/pty/kbd/mouse
v1.2.4 Jun Tier-1 cleanup: ringbuf_t, va_freelist, fd_resolve, dev_table, aegis_errno.h + SYS_ERR, uaccess_user.h COPY_FROM/TO_USER; refcount_t for fd-backed objects
v1.2.5 Jun BSS ceiling lifted 6 MB → 8 MB; Tier-2 capacity limits raised; errno sweep (magic numbers → named constants throughout)
v1.2.6 Jun TCP per-connection rings moved to KVA (alloc-all-at-init); TCP_MAX_CONNS 64 → 128
v1.2.7 Jun musl res_msend DNS timer patched to CLOCK_MONOTONIC (resolver no longer stalls on a backward wall-clock step)
v1.3.0 Jun 20 Broad virtualized-hardware support + SSH. Shared virtio-pci transport core (virtio.h/virtio_pci.c/virtqueue.c) with ten virtio devices on it (net, blk, rng, scsi, balloon, input, pmem, console, 9p, vsock); more NICs (e1000, e1000e, rtl8139, vmxnet3); AHCI/SATA; VMware PVSCSI; USB mass storage; Intel HDA audio (first sound output); virtio-gpu 2D scanout; pvpanic; fw_cfg host→guest config channel; SSH server (TinySSH port) with ip/ifconfig. Every device gated to silent-skip when absent.

Stability & Security Hardening Pass — June 27, 2026

A focused multi-subsystem stability and correctness pass landed on master (x86-64) — roughly 50 verified fixes across SMP/concurrency, memory management, the syscall/uaccess boundary, networking/signals, and the filesystem. Every fix was clean-built (-Werror), passed both gates (boot oracle + coreutils), and the whole set was co-verified on one integration branch: the SMP amplifier (concurrent fork+exec and multithreaded page-fault stress on -smp 4) ran 30/30 boots clean (zero crashes, double-maps, or double-frees), and the full test suite came back 11 pass / 0 real failures. New in-tree stress reproducers (smpstress, mmfaultstress, futexstress, sysfuzz, elffuzz, fduaf, extabtest) are committed as permanent regression assets, gated behind cmdline tokens so they stay oracle-safe.

SMP / concurrency

  • The long-standing smp_sched corruption bug — root-caused and fixed. Under multi-core scheduling, concurrent process startup could corrupt kernel memory (panics with RIPs jumping into garbage). Root cause: the same task could be scheduled onto two CPUs at once — three scheduler pick-sites selected a runnable task without checking it wasn’t already running elsewhere, so one task’s single kernel stack executed on two cores and sprayed itself with saved register context (which looked like wrong-physical-frame writes). Fixed with an on_cpu guard at every pick-site + correct cross-CPU stack reclaim ordering in ctx_switch. Validated: 0 crashes over ~200 boots versus a ~25% baseline crash rate.
  • Cross-CPU lost-signal race — pending_signals used non-atomic read-modify-write; a concurrently-sent signal could be dropped (lost SIGCHLD/SIGTERM → hung waiter). Made all 12 set/clear sites atomic.
  • waitpid lost-wakeup hang — a parent scanning for a zombie could miss a concurrent child exit and block forever; closed with a new sched_block_locked (scan + block as one critical section).
  • FUTEX_REQUEUE / FUTEX_CMP_REQUEUE implemented + futex slot-recycle fix — contended musl pthread condvars (pthread_cond_broadcast/signal) requeue waiters via this op, which Aegis returned ENOSYS for, so every contended condvar hung under SMP. Latent until now (no userland used pthreads); a direct unblocker for the Ladybird browser port.

Memory management

  • Lock-free concurrent lazy-fault mapping — two threads of one process faulting the same lazy-anonymous page on different CPUs could both install it → double-map panic. Fixed by serializing on the existing window lock (the loser observes the page present and frees its own frame) — no new lock, deadlock-free by construction.
  • Two shipping double-frees: brk-grow that ignored existing VMAs (overlapping-VMA + frame double-free), and munmap of a PROT_NONE page (the unmap no-op’d, then process exit freed the frame a second time → heap corruption).
  • Two exec/fork leaks: the fork OOM-rollback paths leaked the child’s 32 KB VMA table, and elf_load leaked the kernel-virtual mapping (+ its page-table pages) on every execve.
  • pmm_debug double-free sentinel — a flag-gated WARN with a symbolized backtrace at any double-free site, oracle-safe (off by default), making the whole double-free class self-diagnosing under the amplifier.

Syscall / uaccess / capabilities (~20 fixes)

  • Exception-table fault-tolerant copy_*_user (root fix). A Linux-style __ex_table makes every user-memory copy panic-safe: a sibling thread unmapping a buffer mid-syscall now yields a graceful EFAULT instead of a ring-0 kernel panic. This kills the entire validate-then-block-then-copy TOCTOU panic class at the primitive (the four individual panic sites in epoll/poll/read/pread64 were also patched as defense-in-depth).
  • Three kernel-heap use-after-frees — waitpid leader-reap (freeing a process’s page tables while sibling threads still ran), procfs fork/dup (shared per-open state freed under the surviving fd), and pty slave double-open (refcount reset on second open).
  • Unprivileged-execve DoS — a crafted ELF with two PT_LOAD segments in one page caused a double-map kernel panic; now rejected as a clean exec failure (with a reproducer).
  • Plus: accept4 SOCK_CLOEXEC fd-leak, a capability-kind delegation off-by-one, Rust/C ENOCAP value desync, sys_spawn argv/envp E2BIG guards, pipe O_NONBLOCK hang, a corrected clone-flag rejection (the naïve version would have broken every pthread_create), and a USB-HID hot-path serial flood that bogged real hardware on every keystroke/mouse-move.
  • Audited and found sound: the Rust capability core + trusted-path anchor, ELF loader bounds, tty/pty, the USB descriptor parsers, the Lumen client-IPC protocol, and the herald package manager’s .hpkg/ustar parser + ECDSA-P256 signature chain.

Networking / signals / scheduler

  • kill(pid, SIGCONT) / SIGKILL now act on a stopped process — both were no-ops before, so a SIGSTOP‘d process could neither be resumed nor killed (stuck forever).
  • Two cross-socket data leaks — recvfrom/sendto used shared file-static scratch buffers across a preemptible window; concurrent callers could read/transmit each other’s payloads. Moved to per-call stack buffers.
  • IP/ICMP reflection hardening — drop IP fragments (no reassembler → reflection vector), reverse-path-filter wire packets, and guard ICMP echo replies against spoofed sources.
  • Plus sigsuspend/pause lost-wakeup closure, SO_RCVTIMEO/SNDTIMEO overflow clamping, and a full audit of the driver network path (virtio-net, e1000/e1000e, rtl8139, vmxnet3 verified end-to-end).

Filesystem

  • Two ext2 block leaks — unlink/rmdir freed only direct blocks (leaking all indirect / doubly-indirect blocks of files larger than ~48 KiB), and O_TRUNC (> file) zeroed the size without freeing any blocks (leaked on every shell-redirect overwrite).
  • Two directory-corruption bugs — rename onto an existing target created a duplicate directory entry (+ orphaned inode), and symlink onto an existing name did the same; both rooted in a missing same-name check in the directory-entry writer.
  • Malicious-image hardening — ext2_mount divided by superblock geometry fields without a zero-check (#DE kernel fault on a crafted image); now validated before mount.
  • The historical “ENOENT after ~11 sequential ext2 execves” bug (Task 29) was confirmed already fixed (in v1.0.6) — 36+ sequential ext2 execs now pass.

Notes & follow-ups

  • smp_sched (multi-core scheduling) remains default-off pending a bare-metal #GP investigation that needs physical hardware, but the QEMU-reproducible corruption, hang, and condvar classes are now closed — a major step toward the SMP milestone below.
  • Known follow-ups (tracked on branches): a shared lock on the address-space VMA table to fully serialize concurrent mmap syscalls between sibling threads (the current per-thread lock is ineffective for that case; SMP-only, so latent while smp_sched is off).
  • The ARM64 kernel build break (printk.c’s unguarded x86 cli; hlt) predates this pass and is tracked under the ARM64 port.

Open Issues

  • Limine ext2 driver can’t read 1 KiB-block rootfs — the installed kernel boots from the FAT ESP rather than reading from the ext2 root partition directly; Limine’s built-in ext2 driver chokes on the 1 KiB block / dir_index combination. Low priority: the current layout (FAT ESP for the kernel, ext2 NVMe root mounted by the kernel itself) works correctly.

Near-Term: ARM64 Port

The ARM64 port builds (build/aegis-arm64.elf) and boots under qemu-system-aarch64 -machine virt through to the scheduler, where it idles. Development is on the arm64-port branch. There is no aarch64 userland yet — the pre-rebase user blobs were purged, and proc_spawn_init() is a no-op on aarch64 until a real aarch64-musl toolchain is wired up (the main remaining blocker). Raspberry Pi 5 hardware support is deferred. See ARM64.md in the repository for the full port plan.

What works today on QEMU virt

A single aegis-arm64.elf boots on qemu-system-aarch64 -machine virt with either -cpu cortex-a72 (GICv2) or -cpu cortex-a76 -machine virt,gic-version=3 (GICv3) through to [SCHED] OK: scheduler started and then idles (no userland to run yet). The kernel-side subsystems in place:

  • Boot path: boot.S produces a valid Linux arm64 Image with a 64-byte header, detects EL2 entry, drops to EL1 with full register sanitization (SCTLR_EL2, HCR_EL2, CNTHCTL_EL2, CNTVOFF_EL2, CPTR_EL2, HSTR_EL2, VTTBR_EL2, VPIDR_EL2, VMPIDR_EL2, ICC_SRE_EL2), invalidates I-cache and TLB before MMU enable, and builds inline TTBR0/TTBR1 page tables covering up to 8 GB of physical memory.
  • MMU: 4KB granule, 4-level paging, 48-bit virtual addresses, 40-bit physical addresses (required for Pi 5’s peripheral region above 4 GB). Kernel higher-half at 0xFFFF000000000000. Block mappings at L1 for the first eight 1 GB windows with DEVICE attributes on the peripheral blocks and NORMAL cacheable on RAM blocks.
  • Exception vectors: full 16-entry vector table in vectors.S with EL0/EL1 sync/IRQ paths, SPSR sanitization against privilege-escalation via crafted signal frames, and per-EL handlers that save/restore ELR_EL1/SPSR_EL1 correctly across nested preemption (fixing a subtle hazard where kernel-mode IRQs during long syscalls would clobber return state).
  • Context switch: ctx_switch.S saves/restores callee-saved x19-x30 + fp/lr + SIMD via shared scheduler code; proc_enter.S handles the EL1→EL0 trampoline for both initial spawn and fork-return paths.
  • Syscall entry: SVC #0 dispatches through _exc_sync_el0, pulls the syscall number from x8, and reuses the shared syscall_dispatch table from x86. A small ARM64→x86 translation table in kernel/syscall/syscall.c maps Linux-aarch64 syscall numbers to Aegis’s x86 numbering, so musl aarch64 binaries Just Work.
  • Interrupt controller: runtime-dispatched GICv2 (gic.c) and GICv3 (gic_v3.c) drivers. Version selection happens at boot based on the DTB compatible string (arm,gic-400/arm,cortex-a15-gic → v2; arm,gic-v3/arm,gic-600 → v3), or a CPU-feature-register fallback (ID_AA64PFR0_EL1.GIC) when no DTB is available. The v3 driver configures the distributor with ARE_NS|Group1NS, wakes the per-CPU redistributor, and uses ICC_*_EL1 system registers for ack/EOI. Every spinloop has a bounded iteration count and emits a [GICv3] TIMEOUT diagnostic on failure, so real-silicon hangs produce actionable error messages instead of silence.
  • Timer: ARM generic timer at 100 Hz via CNTP_TVAL_EL0 + CNTP_CTL_EL0, routed through the GIC as PPI 30.
  • DTB walker: arch_mm.c includes a recursive cell-tracking device-tree parser with per-node #address-cells/#size-cells + ranges propagation. Correctly handles both QEMU virt’s flat layout and Pi 5’s nested /soc@107c000000/ hierarchy where child nodes use SoC-local addresses that must be translated through the parent’s ranges window. Parses /memory, /intc (wherever it lives in the tree), and /reserved-memory — the last captures TF-A’s 0x0-0x80000 reservation on Pi 5 so the PMM doesn’t hand those pages out.
  • PL011 UART: runtime-probed across both QEMU virt (0x09000000) and Pi 5 BCM2712 (0x107D001000) physical bases by reading UARTPeriphID0 at offset 0xFE0. Firmware-initialized on both platforms; the kernel just latches onto the live base. Plus a pre-MMU “I’m alive” diagnostic directly from boot.S that writes to both candidate addresses before any C code runs, using a temporary exception vector table so faulting probes don’t hang the CPU.
  • Rust capability core: kernel/cap/ cross-compiles cleanly to aarch64-unknown-none without a single line of source changes. The existing no_std crate just needs the target added to rust-toolchain.toml and the Makefile wired up.
  • Userspace: NONE yet. The pre-rebase aarch64 user blobs were purged (a stale blob had masked real regressions), so proc_spawn_init() is a deliberate no-op on aarch64 until an aarch64-musl toolchain is wired up to build real init/shell/coreutils. This is the port’s main remaining blocker.
  • Testing: tests/tests/boot_oracle_arm64.rs runs the arm64 kernel under QEMU via Vortex’s QemuBackend (VORTEX_QEMU_BINARY=qemu-system-aarch64), asserts the 13-line boot subsequence, and has been wired into the GitHub Actions CI matrix alongside the x86 job.

What’s next for ARM64

  • Real-silicon verification on Raspberry Pi 5 — the build/pi5-image/ directory produces a ready-to-flash FAT32 layout (DTB + config.txt + kernel_2712.img, ~1 MB total), and tools/build-pi5-image.sh fetches the Pi firmware blobs from the upstream raspberrypi/firmware repo. Pi 5 hardware bring-up is deferred indefinitely: it would need a USB-TTL serial cable on the Pi 5’s JST-SH debug header (GPIO 14/15 sits behind the RP1 south bridge and would require an RP1 driver that doesn’t exist yet) and — more fundamentally — there is no aarch64 userland to run yet (the A4 blocker). The image tooling exists; the hardware milestone does not.
  • RP1 south bridge driver — Pi 5 houses its USB, Ethernet, GPIO, and additional UARTs behind a custom PCIe-attached chip. Bring-up requires a PCIe host controller driver for the BCM2712 internal root complex plus RP1 register-level knowledge. Until this lands, networking and USB on Pi 5 are unavailable; everything flows through the JST-SH debug console. Circle’s lib/southbridge.cpp is the reference implementation.
  • SMP via PSCI — Pi 5 and QEMU virt both expose PSCI at EL3 (CPU_ON function ID 0xC4000003 via smc #0). Bringing up the remaining three cores is straightforward in principle; the catch on Pi 5 is that TF-A already holds the secondaries in a mailbox spin loop, so CPU_ON returns PSCI_E_ALREADY_ON and the kernel must use TF-A’s mailbox entry-point mechanism instead. Deferred until single-core is verified on silicon.
  • IOMMU / SMMU — Aegis’s x86 roadmap item for DMA isolation applies equally on ARM. SMMUv3 on Pi 5 is exposed to non-secure software in the DTB; programming it is a prerequisite for safely running RP1 drivers with DMA.
  • Full bcm2712d0.dtbo support — newer Pi 5 2 GB / 16 GB boards with BCM2712 D0 stepping need a DT overlay for correct peripheral initialization. The packager ships the overlay conditionally; the kernel has to parse applied-overlay nodes from the DTB rather than the base DTS.

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, and curl -sk https://example.com works from the shell. Per-connection TX rings were moved to KVA in v1.2.6. The remaining work is around send segmentation, proper flow-control window accounting, and sys_setitimer for interval timeouts (Phase 49). These are required for a robust SSH server (Phase 50) under load.

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. POSIX timers (setitimer / alarm / timerfd_*) are Phase 51.

Virtualized Hardware — landed in v1.3.0

Broad hypervisor device support shipped in v1.3.0: a shared virtio-pci transport core with ten virtio devices on it (net, blk, rng, scsi, balloon, input, pmem, console, 9p, vsock), additional NICs (e1000/e1000e, rtl8139, vmxnet3), AHCI/SATA, VMware PVSCSI, USB mass storage, Intel HDA audio, virtio-gpu 2D scanout, pvpanic, and the fw_cfg host→guest config channel. See Device Drivers. The remaining hardware frontier is real bare-metal devices (USB Ethernet, more real NICs) and the OpenCL/3D-acceleration research track.

TinySSH — landed in v1.3.0

A minimal SSH server for remote access shipped in v1.3.0 (a port of TinySSH, NaCl crypto, key-only auth), running as a Vigil service and capability-gated for the listener. This is the first real test of the capability model under adversarial conditions — an internet-facing service that must be confined. See Userspace Services → sshd.

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:

  1. Capability system — done. cap_init, cap_grant, cap_check are Rust.
  2. 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.
  3. 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.
  4. 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. With the ARM64 port now booting on QEMU virt (see above), the remaining work is virtio-mmio transport support (Virtualization.framework exposes virtio devices over MMIO, not PCI) and adapting the boot entry contract to Virtualization.framework’s DTB handoff. The Vortex VM management tool already plans for this integration path, and qemu-system-aarch64 -accel hvf on Apple Silicon already provides a native-speed development loop for the ARM64 kernel in the interim.

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

Herald (/bin/herald) shipped in v1.2.0 as the native package manager. Packages are signed .hpkg (ustar) archives with ECDSA-P256 trust chains, installed via CAP_KIND_INSTALL-gated operations. Chancery is the companion host-side repository manager (Rust). Apps already available on the public feed include Snake, Minesweeper, an image viewer, and an RSS/Atom reader. The long-term goal is a rich third-party app ecosystem where every package ships its own /etc/aegis/caps.d/ policy file and capability grants are audited at install time.

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 — landed in v1.3.0
  • More NIC families as needed (e1000/e1000e, rtl8139, vmxnet3 landed in v1.3.0)
  • Real GPU drivers beyond the scoped AMD iGPU target (virtio-gpu 2D landed in v1.3.0)
  • Audio — Intel HDA output landed in v1.3.0; capture and virtio-sound still open

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 June 2026 (v1.3.0). Priorities may shift as work progresses. The best way to influence direction is to contribute — exec/aegis.