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.

This operating system is called EriX.

Why Build Another Operating System?⌗

At first glance, building a new operating system seems unnecessary. Mature systems like Linux, Windows, and BSD already exist and power billions of devices.

However, these systems evolved under historical constraints. Over time they accumulated layers of abstractions, compatibility mechanisms, and legacy interfaces. While these features are often necessary for real-world software, they also make it difficult to experiment with fundamentally different architectural ideas.

Research operating systems have long explored alternative approaches to operating system design. Microkernels, capability systems, and formally verified kernels have demonstrated that it is possible to build systems that are smaller, more secure, and easier to reason about.

The goal of EriX is not to replace existing operating systems. Instead, it is an exploration of how a modern operating system might be designed if we start from first principles.

Microkernels and the Trusted Computing Base⌗

One of the central ideas behind EriX is the microkernel architecture.

Traditional monolithic kernels include many services directly inside the kernel itself. These often include:

  • device drivers
  • filesystems
  • networking stacks
  • process management subsystems

While this approach can be efficient, it also increases the size of the trusted computing base (TCB). The TCB includes every piece of code that must behave correctly for the system to remain secure and reliable.

Microkernels take a different approach.

A microkernel keeps only the most fundamental mechanisms inside the kernel, typically including:

  • thread scheduling
  • address space management
  • inter-process communication (IPC)
  • capability management
  • interrupt and exception handling

Everything else runs in user space, including drivers, filesystems, and higher-level services.

This design drastically reduces the amount of code that must be trusted. Failures in user-space components are less likely to compromise the entire system, and individual components can be restarted or replaced without bringing down the kernel.

Capability-Based Security⌗

Another central design principle of EriX is capability-based security.

Most operating systems rely heavily on ambient authority. In these systems, processes often have implicit access to resources based on global namespaces, user identities, or inherited privileges.

For example, a process might open a file simply because it knows the file’s path and the operating system decides the process has permission to access it.

Capability systems take a different approach.

A capability is an unforgeable token that grants access to a specific object with specific rights. A process can only access an object if it possesses a capability that authorizes that access.

Capabilities have several important properties:

  • They explicitly represent authority.
  • They can be transferred between processes.
  • They can restrict operations to a precise set of rights.

In a capability-based system, authority flows through explicit transfers rather than through global namespaces. This makes the system easier to reason about and helps eliminate entire classes of security vulnerabilities.

Why Rust?⌗

Operating systems are traditionally written in C or assembly. These languages provide precise control over hardware and memory but also make it easy to introduce subtle bugs.

Memory safety bugs—such as use-after-free, buffer overflows, and data races— have historically been one of the largest sources of vulnerabilities in systems software.

EriX is written primarily in Rust.

Rust provides strong guarantees about memory safety while still allowing low-level control over hardware. The language’s ownership model helps prevent many classes of bugs at compile time, while its explicit unsafe blocks make potentially dangerous operations visible and auditable.

Using Rust does not eliminate all possible errors, but it significantly raises the baseline for safety in systems programming.

A Clean-Room Operating System⌗

One unusual aspect of the EriX project is its clean-room development approach.

All components of the system are implemented within the project itself. No external source code is copied or incorporated, and no third-party libraries are used.

This constraint serves several purposes:

  • It ensures that the entire system can be understood and audited.
  • It avoids hidden dependencies and unexpected behaviors.
  • It forces architectural decisions to be explicit rather than inherited.

Clean-room development also turns the project into an educational exercise. Every subsystem—from the bootloader to the memory manager—must be designed and implemented deliberately.

A Long-Term Goal: Self-Hosting⌗

One of the long-term goals of EriX is self-hosting.

A system is considered self-hosting when it can build its own source code using tools that run on the system itself.

For EriX, this means that eventually:

  • the Rust compiler runs on EriX
  • the build tools run on EriX
  • the entire operating system can be compiled natively inside EriX

Reaching this milestone requires implementing many layers of infrastructure, including filesystems, process management, and a POSIX-compatible user-space environment.

Why Document the Journey?⌗

Building an operating system is a long and complex process. Many of the most interesting insights appear not in the final system, but in the decisions, trade-offs, and mistakes encountered along the way.

This blog documents the development of EriX as it evolves. Future posts will cover topics such as:

  • designing a boot image format
  • implementing capability spaces
  • building an IPC system
  • managing memory authority
  • constructing user-space servers

The goal is to make the development process transparent and educational.

Looking Ahead⌗

EriX is still in its early stages. Much of the system remains to be built, and many design decisions will undoubtedly evolve over time.

But the guiding principles are already clear:

  • minimal kernel
  • explicit authority
  • capability-based security
  • strict modularity
  • clean-room implementation

In the next post, we will explore one of the core ideas behind the system:

what capability-based operating systems are, and why they matter.