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.

What Does “Clean-Room” Mean?⌗

In the context of EriX, clean-room development means:

  • No external source code is copied or reused
  • No third-party libraries or crates are included
  • All components are implemented within the project
  • Only public specifications and documentation may be referenced

The result is a system where every line of code is:

  • understood
  • auditable
  • intentionally designed

This is not just a legal or licensing decision—it is an architectural one.

Why Avoid External Code?⌗

Avoiding external dependencies may seem restrictive. Modern software development typically encourages reuse, and large ecosystems exist precisely to avoid reinventing the wheel.

However, operating systems are not typical applications.

1. Hidden Complexity⌗

External code often brings implicit assumptions:

  • about memory layout
  • about concurrency models
  • about error handling
  • about platform behavior

These assumptions may not align with the architecture of a new operating system, especially one built around capabilities and strict isolation.

2. Enlarged Trusted Computing Base (TCB)⌗

Every dependency increases the size of the trusted computing base.

If a third-party library is used in the kernel or critical system components, its correctness becomes part of the system’s security guarantees.

Clean-room development keeps the TCB:

  • small
  • controlled
  • explicitly defined

3. Auditability and Verification⌗

A system built entirely in-house can be audited systematically.

  • All unsafe code can be reviewed
  • All invariants can be documented
  • All interfaces can be reasoned about

This is especially important for a system like EriX, which emphasizes:

  • explicit authority
  • capability-based security
  • minimal kernel design

4. Architectural Freedom⌗

Reusing existing code often constrains design decisions.

For example:

  • adopting a library may force a particular API shape
  • integrating existing code may require compatibility layers
  • legacy abstractions may leak into new components

Clean-room development allows the system to be shaped entirely by its own principles, rather than by inherited constraints.

Clean-Room vs. Reimplementation⌗

It is important to distinguish clean-room development from simple reimplementation.

Clean-room development does not mean blindly rewriting existing systems.

Instead, it involves:

  • studying public specifications
  • understanding underlying principles
  • designing new implementations from first principles

For example:

  • A filesystem may follow POSIX semantics, but be implemented independently
  • A bootloader may follow UEFI specifications, but use a custom structure
  • A C standard library may expose the same API, but be written entirely in Rust

The goal is compatibility where necessary, without code reuse.

Clean-Room in Practice⌗

In EriX, clean-room constraints are applied across the entire system.

No External Crates⌗

Even in Rust, where dependency reuse is common, EriX avoids external crates.

Instead, it defines internal reusable components such as:

  • memory utilities
  • synchronization primitives
  • capability abstractions

Internal Libraries⌗

Reusable functionality is organized into internal crates, for example:

  • lib-bootimg
  • lib-capabi
  • lib-ipc

These libraries are:

  • versioned
  • controlled within the project
  • designed specifically for the system’s needs

Strict Repository Structure⌗

Each subsystem is isolated:

  • bootloader
  • kernel
  • IPC
  • memory management
  • user-space services

This enforces modularity and prevents hidden coupling.

Reproducible Builds⌗

Clean-room design extends to the build process.

The system aims for:

  • deterministic builds
  • minimal toolchain assumptions
  • explicit build steps

This ensures that artifacts can be reproduced and verified.

Benefits of a Clean-Room OS⌗

1. Full System Understanding⌗

Every component is known and understood.

There are no opaque dependencies or hidden behaviors.

2. Stronger Security Model⌗

With a smaller and controlled TCB:

  • fewer attack surfaces exist
  • invariants are easier to enforce
  • capability-based security can be implemented cleanly

3. Better Research Platform⌗

EriX is not only an operating system—it is also a research platform.

Clean-room development enables:

  • experimentation with new abstractions
  • precise measurement of design trade-offs
  • clear reasoning about authority and isolation

4. Long-Term Maintainability⌗

While initially more work, clean-room systems can be easier to maintain:

  • no dependency breakage
  • no upstream changes to track
  • no version conflicts

The system evolves on its own terms.

Trade-Offs and Challenges⌗

Clean-room development is not without cost.

1. Slower Development⌗

Everything must be built from scratch:

  • basic libraries
  • runtime support
  • system services

This significantly increases initial effort.

2. Reinventing the Wheel⌗

Many problems have already been solved elsewhere.

Reimplementing them requires time and careful design.

3. Fewer Shortcuts⌗

There is no ability to:

  • quickly import a library
  • rely on existing ecosystems
  • delegate complexity to external code

All complexity must be handled directly.

4. Higher Design Responsibility⌗

Every abstraction must be designed deliberately.

Mistakes cannot be easily patched over by swapping dependencies.

Why This Approach Fits EriX⌗

EriX is built around a few core principles:

  • minimal trusted computing base
  • explicit authority through capabilities
  • strict separation between kernel and user space
  • reproducibility and determinism

Clean-room development supports all of these goals.

It ensures that:

  • authority is never hidden inside external code
  • system invariants are fully controlled
  • the architecture remains consistent across all components

A Foundation for Self-Hosting⌗

Clean-room design also supports the long-term goal of self-hosting.

To build EriX within EriX, the system must include:

  • its own toolchain
  • its own runtime libraries
  • its own system interfaces

A system that depends heavily on external components would struggle to achieve this level of independence.

Looking Ahead⌗

Designing a clean-room operating system is a long-term effort. It requires careful planning, disciplined implementation, and a willingness to build fundamental components from scratch.

But it also creates a system that is:

  • transparent
  • controlled
  • deeply understood

In future posts, we will move from principles to implementation, starting with the early boot process and the design of the system’s boot image format.