Every operating system begins before it is really itself. The CPU starts in a platform-defined environment, firmware initializes enough hardware to load the first executable, and that executable prepares the machine for the kernel. Only after this chain has done its work can the operating system begin enforcing its own rules. That early path is easy to treat as plumbing, but the boot process is part of the security model. For EriX, boot is the first place where untrusted bytes become trusted execution, and it is also the first place where machine authority is translated into explicit structure: verified images, memory maps, module descriptors, entry addresses, framebuffer metadata, ACPI pointers, and eventually kernel objects.

Operating systems are usually associated with C. That association is understandable. C is small, predictable, close to the machine, and historically dominant in kernel work. It gives the programmer direct access to memory, registers, layout, and calling conventions. Those are exactly the things a kernel needs. They are also exactly the things that make kernels hard to secure. EriX is written primarily in Rust because the project is built around one central idea:

Security discussions often focus on individual bugs: a buffer overflow a confused-deputy flaw an unchecked parser a privilege escalation path Those bugs matter, but they are symptoms of a deeper question: How much code must be correct for the system to remain secure? That code is the trusted computing base, usually shortened to TCB. The size and shape of the TCB determine how much code must be trusted, audited, tested, and reasoned about.

Few operating system design debates have lasted as long as the debate between microkernels and monolithic kernels. At a surface level, the distinction seems simple: monolithic kernels keep most operating system services inside the kernel microkernels move most services into user space In practice, the trade-off is more subtle. The real question is not whether one structure is universally faster, cleaner, or more secure. The real question is where authority, complexity, failure, and performance costs should live.

Most modern operating systems are built on decades of accumulated code, libraries, and external dependencies. While this ecosystem enables rapid development, it also introduces complexity, hidden assumptions, and potentially unexamined security risks. EriX takes a different approach. It is developed as a clean-room operating system, meaning that every component—from the bootloader to user-space services—is implemented within the project itself, without incorporating external source code or third-party libraries. This post explores what clean-room development means in practice, why it is useful, and what trade-offs it introduces.

Modern operating systems enforce security boundaries between processes, files, devices, and users. However, the way these boundaries are implemented varies significantly across system designs. Most mainstream operating systems rely on identity-based access control and global namespaces. Capability-based operating systems take a fundamentally different approach: they represent authority explicitly and make it a first-class concept. This post introduces capability-based systems, explains how they differ from traditional designs, and outlines why they are central to the design of EriX.

Operating systems are among the most complex pieces of software ever built. They manage memory, schedule computation, control hardware, and enforce the security boundaries that protect every application running on a machine. Yet many of the operating systems we rely on today are built on architectural ideas that date back several decades. While these systems are extraordinarily powerful and battle-tested, they also carry decades of accumulated complexity. This project explores a different direction: building a modern, capability-based microkernel operating system from scratch, with a strong focus on explicit authority, minimal trusted computing base (TCB), and strict separation between kernel and user space.