Zinnia: A Rust-Written Kernel That Bypasses Unsafe Code

The operating system kernel has long been considered one of the most unforgiving domains in software engineering. C and C++ have dominated this space for decades, their direct memory access and minimal runtime overhead making them natural fits for code that must manage hardware directly. But that dominance has come at a cost: memory safety bugs in kernels have been the root cause of countless security vulnerabilities and system crashes. Zinnia, a kernel project that began in 2024, takes a different approach. Written almost entirely in Rust, it attempts to avoid unsafe code wherever possible, offering a glimpse of what systems programming might look like when memory safety is a first-class concern.

The project's ambitions are notable not for their novelty but for their execution. Zinnia implements a broad range of POSIX APIs in its system calls, along with common extensions found in Linux and BSD systems. Support for interfaces like epoll and timerfd means that software written for mainstream Unix-like systems can, in principle, run on Zinnia without significant modification. This compatibility layer is not merely academic. It enables the kernel to run somewhat modern desktop environments using both Wayland and X11 sessions, a practical demonstration that a Rust-based kernel can interface with the complex graphics and input stacks that real desktop use demands.

Driver architecture reveals another layer of thoughtful design. Most drivers in Zinnia are implemented as modules, specifically Rust ELF dynamic libraries that get loaded and linked during the boot process from an initrd. This approach mirrors how Linux handles loadable kernel modules, but with Rust's type system and ownership model providing stronger guarantees about how those modules interact with the kernel core. The implications for reliability are significant. Driver bugs, which historically account for a large proportion of kernel crashes, operate within Rust's safety constraints rather than outside them.

Booting is handled through the Limine bootloader, which supports UEFI-based systems. This is a pragmatic choice. Rather than investing effort in low-level boot firmware, Zinnia leverages existing bootloader infrastructure to reach the point where its Rust code can take over. The result is that the kernel now boots on many real x86_64 machines, moving beyond the emulator environment where many hobby kernels remain trapped.

The trajectory of Zinnia mirrors a pattern seen in other systems programming projects that begin as personal learning exercises and gradually accumulate features as the author's understanding deepens. What started as a way to learn more about systems programming has become a kernel that runs on physical hardware and supports desktop workflows. This organic growth is common in open source, but it carries its own risks. A project built by a single developer or small team must eventually grapple with the enormous surface area of a modern operating system, from power management to file systems to networking stacks.

The broader context matters here. Zinnia is part of a small but growing ecosystem of Rust-based operating system projects. These include larger efforts like Redox OS and academic projects like theseus, as well as the ongoing work to integrate Rust into the Linux kernel itself. Each of these projects tests a different hypothesis about how Rust's guarantees can be applied to systems code. Zinnia's focus on avoiding unsafe code puts it at one end of this spectrum, prioritizing safety over the flexibility that unsafe blocks provide.

The trade-offs are real. Avoiding unsafe code entirely means that certain low-level operations, particularly those involving raw pointer manipulation or direct hardware register access, must be wrapped in safe abstractions or restructured entirely. This can add complexity and sometimes performance overhead. For a kernel that aims to support real hardware and run desktop environments, the question is whether these abstractions can be made efficient enough to matter in practice.

Zinnia's support for aarch64 and riscv64 architectures is planned but not yet prioritized. This is a sensible focus. Getting the x86_64 implementation solid and well-tested before expanding to other architectures reduces the surface area for bugs and allows the developer to build confidence in the core abstractions. The RISC-V community in particular has shown interest in Rust-based systems, so future support there could open interesting possibilities.

For developers interested in systems programming, Zinnia represents something valuable: a working example of a Rust kernel that prioritizes safety without abandoning practical functionality. The project is open to contributions, and its relatively small codebase makes it more approachable than larger kernels. Whether it grows into a production-ready system or remains an educational project, the techniques it demonstrates are worth studying. The question of whether memory-safe languages can meaningfully improve kernel reliability is no longer theoretical. Projects like Zinnia are providing empirical answers, one system call at a time.

The project repository is available for those who want to examine the code directly or contribute to its development.