Moss: A Rust-Based Linux-Compatible Kernel Exploring Async Design

The landscape of operating system development has long been dominated by C-based kernels, with Linux standing as the most prominent example of this paradigm. However, a new experimental project called Moss is challenging this status quo by building a Linux-compatible kernel entirely in Rust, demonstrating that modern systems programming languages can deliver both safety and performance at the kernel level.

A New Approach to Kernel Design

Moss represents a fundamental rethinking of kernel architecture, combining the safety guarantees of Rust with the proven Linux ABI to create something both innovative and practical. The kernel currently runs a dynamically linked Arch Linux aarch64 userspace, including essential tools like bash, BusyBox, coreutils, ps, top, and strace. This achievement is particularly noteworthy because it demonstrates that a relatively young kernel can achieve meaningful compatibility with existing Linux applications.

The architecture of Moss is built around several key innovations. First, it provides full support for aarch64 while maintaining a well-defined Hardware Abstraction Layer (HAL) that allows for easy porting to other architectures such as x86_64 and RISC-V. This modular approach to architecture abstraction represents a significant departure from traditional monolithic kernel designs.

Memory Management Reimagined

One of Moss's most sophisticated features is its comprehensive memory management system. The kernel implements full Memory Management Unit (MMU) enablement with page table management, supporting advanced features like Copy-on-Write (CoW) pages and safe copy operations to and from userspace. The memory subsystem includes kernel and userspace page fault management, kernel stack-overflow detection, and support for shared library mapping and relocation.

The allocator design is particularly elegant, featuring a buddy allocator for physical addresses, smalloc for boot allocations and memory reservation tracking, and a full slab allocator for kernel object allocations. The slab allocator includes a per-CPU object cache, optimizing performance for multi-core systems.

The Async Revolution in Kernel Space

Perhaps the most revolutionary aspect of Moss is its embrace of Rust's async/await model within the kernel context. This design choice fundamentally changes how kernel operations are structured and executed. All non-trivial system calls are written as async functions, with sleep-able functions explicitly marked with .await suffixes. This approach provides several critical advantages:

• The compiler enforces that spinlocks cannot be held over sleep points, eliminating a common class of kernel deadlocks
• Any future can be wrapped with the .interruptable() combinator, allowing signals to interrupt waiting operations
• The asynchronous model naturally handles I/O-bound operations more efficiently

This design philosophy represents a significant departure from traditional kernel architectures, where blocking operations and complex locking mechanisms often lead to subtle bugs and performance issues.

Process Management and System Call Implementation

Moss implements a comprehensive process management system supporting both uni-processor (UP) and symmetric multi-processing (SMP) scheduling via Earliest Eligible Virtual Deadline First (EEVDF) algorithm. The kernel currently implements 105 Linux syscalls, including fundamental operations like fork(), execve(), clone(), and full process lifecycle management.

The signal handling implementation is particularly robust, supporting delivery, masking, and propagation of signals including SIGTERM, SIGSTOP, SIGCONT, and SIGCHLD. The ptrace support is sufficient to run strace on Arch binaries, enabling powerful debugging capabilities.

Virtual File System and Storage Drivers

Moss features a Virtual File System (VFS) with full async abstractions, supporting multiple filesystem drivers. The current implementation includes a ramdisk block device, FAT32 filesystem driver (read-only), Ext2/3/4 filesystem driver (read support with partial write support), devfs driver for kernel character device access, tmpfs driver for temporary file storage in RAM, and procfs driver for process and kernel information exposure.

Architecture-Agnostic Design Through libkernel

A key architectural decision in Moss is the separation of architecture-specific code from core logic through the libkernel library. This design allows kernel logic to be tested on host machines (such as x86) before running on bare metal, significantly improving the development and testing workflow. The library provides strong typing for Virtual Addresses (VA), Physical Addresses (PA), and User Addresses (UA), along with containers for VMA management, generic page-based ring buffers, and synchronization primitives.

The test suite is comprehensive, with over 230 tests ensuring functionality across architectures. This includes validating Aarch64 page table parsing logic on x86 hosts, demonstrating the effectiveness of the architecture-agnostic design.

Building and Development Experience

Moss provides a relatively straightforward development experience. Prerequisites include QEMU for aarch64 emulation, dosfstools and mtools for virtual filesystem creation, and the aarch64-none-elf toolchain. The build process is streamlined through scripts that handle dependency building and image creation.

The project includes a dedicated userspace test suite (usertest) to validate syscall behavior at runtime, ensuring that the kernel's interface with userspace applications remains stable and correct.

Current Status and Future Directions

Moss is under active development with several key focus areas identified for the roadmap. The networking stack, particularly TCP/IP implementation, is a priority, along with expanding filesystem support to include fully read/write capable drivers. The team is also working on expanding syscall coverage beyond the current 105 implementations and bringing up systemd support.

Non-Goals and Philosophical Approach

Importantly, the Moss project explicitly defines its non-goals, which include binary compatibility beyond aarch64 and production hardening. This clarity of purpose allows the project to focus on its core mission: exploring asynchronous design and Linux ABI compatibility in Rust. Moss is positioned as an experimental kernel rather than a production-ready operating system, which provides the freedom to innovate without the constraints of backward compatibility and stability requirements.

The Broader Implications

The existence and progress of Moss have significant implications for the future of operating system development. By demonstrating that a Linux-compatible kernel can be built in Rust with async/await patterns, Moss challenges the assumption that C is the only viable language for kernel development. The project shows that modern language features can be effectively applied to systems programming, potentially leading to safer and more maintainable kernel code.

The success of Moss could influence future kernel development practices, encouraging more experimentation with alternative architectures and programming paradigms. The project serves as a proof of concept that the Linux ecosystem can accommodate innovation at the kernel level while maintaining compatibility with existing applications and tools.

Conclusion

Moss represents an exciting intersection of systems programming, language design, and operating system architecture. By leveraging Rust's safety features and async/await model, the project demonstrates a viable path toward more robust and maintainable kernel implementations. While still experimental, Moss provides valuable insights into how modern programming languages and design patterns can be applied to kernel development, potentially influencing the next generation of operating systems.

The project's success in running a full Arch Linux userspace on aarch64 hardware demonstrates that the approach is not merely theoretical but practically achievable. As Moss continues to evolve and expand its capabilities, it will be fascinating to see how its innovations influence the broader landscape of operating system development and whether the async/await model becomes more widely adopted in kernel contexts.