Skip to content

Latest commit

 

History

History
76 lines (48 loc) · 3.54 KB

File metadata and controls

76 lines (48 loc) · 3.54 KB

Anvil OS

Capability-based microkernel for x86-64

Anvil is a security-focused microkernel written in Rust with a C userspace. It combines the formal rigor of seL4's capability model with the practical API design of Zircon to create a system where every resource access is explicitly authorized, every process is isolated, and every privilege is accounted for.

Why another microkernel?

Most operating systems trust too much code. A single driver bug in a monolithic kernel can take down the entire system. Anvil takes a different approach: the kernel does as little as possible — thread scheduling, memory management, IPC — and everything else runs as isolated userspace services that communicate through message passing.

This isn't a new idea. seL4 proved it can be done with mathematical correctness guarantees. Zircon showed it can be practical enough for consumer devices. Anvil aims for a middle ground: a capability-based system that is both secure by design and approachable for systems programmers.

Architecture

The kernel provides four core subsystems:

Threads — TCB (Thread Control Block) creation, configuration, register setup, and scheduling. SMP-aware with per-CPU run queues and work stealing.

Memory — VMO (Virtual Memory Objects) as the unit of physical memory. VMA mapping into address spaces. Processes cannot touch memory they haven't been explicitly granted access to.

Capabilities — Every kernel object (thread, address space, memory object, endpoint) is accessed through capabilities stored in per-process CNodes. Capabilities carry rights (read, write, manage) that can only be reduced, never escalated. Cross-process capability transfer via cap_copy.

IPC — Synchronous rendezvous-based message passing through Endpoints. Capabilities can be transferred alongside data, enabling secure delegation of authority between services.

Current status

Anvil is in active early-stage development. What works today:

  • Kernel boots on x86-64 (QEMU), multi-core SMP scheduling operational
  • Init process loads services from a CPIO archive, creates their TCB/VSpace/CNode
  • Capability transfer from init to child processes (cap_copy)
  • Child processes interact with their own VSpace (map/unmap memory)
  • Syscall interface: tcb_create, tcb_configure, tcb_set_regs, tcb_resume, vmo_create, vma_map, vma_unmap, vma_alloc, cap_copy

What's next: IPC implementation, name server, bootstrap libc, IO server.

Tech stack

Component Technology
Kernel Rust (nightly, x86_64-unknown-none)
Userspace C (freestanding, -nostdlib)
Build Cargo (kernel) + CMake (userspace)
Target x86-64, QEMU
Boot CPIO-based initramfs

Building

# Build the kernel
cargo build --target x86_64-unknown-none

# Build userspace services
mkdir build && cd build
cmake .. && make -j$(nproc)

# Run in QEMU
./run.sh

See the Developer Guide for detailed setup instructions.

Contributing

Anvil needs systems programmers comfortable with C, virtual memory, and working without a standard library. Current priorities:

  1. Bootstrap libc — minimal C runtime for userspace services (malloc, string functions, printf)
  2. IPC — synchronous message passing through kernel endpoints
  3. Name server — service registry so processes can discover each other
  4. IO server — centralized I/O management replacing debug syscalls

Read the Developer Guide for architecture details and onboarding.

License

[TBD]