Skip to main content
Aurora OS is designed as a dual-target operating system that runs both natively on bare metal hardware and in modern web browsers via WebAssembly. This unique architecture enables development and testing in browsers while maintaining production-ready native kernel code.

​
System architecture

Aurora OS employs a hybrid kernel architecture that balances performance with modularity:

Native kernel

Bare metal x86_64/ARM kernel with hybrid architecture

Browser runtime

BPE/U engine for running Aurora OS in web browsers

WASM bridge

WebAssembly compilation and browser API integration

Hybrid design

How native and browser targets share code

​
Dual-target approach

The native kernel runs directly on x86_64 and ARM hardware:
  • Bootloader: Limine bootloader (UEFI + legacy BIOS)
  • Kernel: C/Assembly hybrid kernel with Rust components
  • Memory: 4-level paging, physical allocator, heap with slab caches
  • Scheduler: CFS-inspired preemptive scheduler
  • VFS: Virtual file system with tmpfs
  • Network: TCP/UDP/IP stack with socket syscalls
  • Security: KASLR, ASLR, stack canaries, capability tokens
See STATUS.md for current implementation status.

​
Core subsystems

​
Process management

Aurora OS implements a UNIX-like process model:
  • Process creation: fork() creates child processes with copy-on-write
  • Program execution: execve() loads ELF binaries
  • Scheduling: Preemptive CFS scheduler with vruntime fairness
  • IPC: Message passing with capability tokens, shared memory
  • Signals: POSIX-style signal delivery with user handlers
Implementation: kernel/src/proc/ (native), wasm-runtime/pwa/bpe/bpe-process.js (browser)

​
Memory management

Multi-tier memory system:
1

Physical memory allocator

Bitmap-based allocator tracking 4 KiB frames, memory-map awareImplementation: kernel/src/mm/pmm.c
2

Virtual memory

4-level paging (PML4 → PDPT → PD → PT) with higher-half kernel mappingImplementation: kernel/src/mm/vmm.c
3

Heap allocator

Free-list allocator with slab caches for common sizes (16, 32, 64, 128, 256 bytes)Implementation: kernel/src/mm/heap.c
4

Browser storage

OPFS-backed virtual memory with IndexedDB fallbackImplementation: wasm-runtime/pwa/bpe/bpe-memory.js

​
File system

VFS layer provides a unified interface for all file systems: 
struct inode {
    uint32_t ino;
    uint32_t mode;
    uint32_t uid, gid;
    uint64_t size;
    struct inode_ops *ops;
};

struct inode_ops {
    ssize_t (*read)(struct inode *, void *buf, size_t count, off_t offset);
    ssize_t (*write)(struct inode *, const void *buf, size_t count, off_t offset);
    int (*create)(struct inode *parent, const char *name, uint32_t mode);
    int (*unlink)(struct inode *parent, const char *name);
};
tmpfs implementation provides in-memory file storage:
  • Mounted at boot on / and /tmp
  • Supports files, directories, symlinks
  • Stores data in kernel heap
Implementation: kernel/src/fs/tmpfs.c (native), wasm-runtime/pwa/bpe/bpe-vfs.js (browser)

​
Networking

Native kernel includes a minimal TCP/UDP/IP stack:
  • Layers: Ethernet → IP → TCP/UDP
  • Socket API: socket(), bind(), connect(), send(), recv()
  • Driver support: E1000 network card driver
  • Browser: WebSocket bridge for network access
Implementation: kernel/src/net/, drivers/net/e1000.c

​
Security architecture

  • KASLR: Kernel Address Space Layout Randomization
  • ASLR: User-space address randomization
  • Implemented via random offset in linker script and loader
Implementation: kernel/src/mm/vmm.c:235
  • Stack canaries: GCC -fstack-protector-strong
  • NX bit: Non-executable stack and heap pages
  • Guard pages: Unmapped pages between stacks
Compiler flags: Makefile:25
  • Capability tokens: 256-bit random tokens for IPC authorization
  • MAC policies: Mandatory Access Control for agent isolation
  • Module signing: RSA-2048 signatures on loadable modules
Implementation: rust/caps/ (Rust no_std crate)
  • PBKDF2: 600,000 iterations for password hashing
  • AES-GCM: Encrypted credential storage
  • OPFS isolation: Origin-scoped file system
  • CSP headers: Content Security Policy enforcement

​
Performance characteristics

​
Native kernel

OperationLatencyNotes
Context switch~2 μsMeasured on Intel i7-9700K
Syscall overhead~100 nsSYSCALL/SYSRET fast path
Page fault (COW)~5 μsCopy-on-write page allocation
Fork (small process)~50 μsIncludes page table copy
Memory allocation (kmalloc)~200 nsSlab cache hit
VFS path resolution~1 μs/componenttmpfs lookup

​
Browser runtime

OperationLatencyNotes
Window animation380 msSmooth open with GPU acceleration
Button interaction120 msMaterial ripple effect
Frame rate60 fpsConsistent across all animations
Boot sequence< 2 sBIOS → Login screen
OPFS read/write~2 msAsync I/O
Performance measurements are from development builds. Production builds with optimizations may differ.

​
Design principles

Performance first

Hot paths (context switch, syscall, allocation) stay in kernel. No IPC overhead for critical operations.

Security by design

KASLR, ASLR, stack canaries, NX, capability tokens, and module signing built in from the start.

Modularity

Loadable signed modules for drivers. Agent runtime in userspace with strong sandboxing.

Developer experience

Develop and test in browsers via BPE/U. Deploy to bare metal when ready.

​
Technology stack

Native kernel:
  • C11 (kernel core)
  • GAS assembly (boot, context switch, syscall entry)
  • Rust (capability system, crypto primitives)
  • Linker script for higher-half kernel mapping
Browser runtime:
  • JavaScript ES2022 (BPE/U engine, desktop UI)
  • WebAssembly (future: compiled kernel modules)
  • Web APIs (OPFS, IndexedDB, WebCrypto, WebSocket)
  • Service Worker (offline PWA support)
Build system:
  • GNU Make (native builds)
  • Cross-compiler toolchain (x86_64-elf-gcc)
  • Emscripten (WASM compilation)
  • QEMU (testing and development)

​
Next steps

Kernel internals

Dive into the native kernel implementation

BPE/U engine

Explore the browser processing engine

WASM runtime

Learn about WebAssembly integration

Development setup

Set up your development environment

Build docs developers (and LLMs) love

Get started for freeTalk to us