bootloader

The EriX bootloader is a minimal, security-focused bootloader that currently targets UEFI on x86_64 and loads/verifies boot.img artifacts.

EriX is a clean-room, capability-based microkernel operating system written entirely in Rust.

Technical requirements are tracked in the EriX requirements, conventions, and project documentation.

See:

• docs for design documents, specifications, and development plans.
• Related architecture repositories for kernel, services, libraries, drivers, and integration tooling.

Purpose of This Repository

This repository implements the EriX bootloader component. Its purpose in EriX is to verify boot-critical payloads and prepare the initial kernel handoff.

Functionally, it loads the signed boot image, validates payload metadata, prepares memory state, and transfers control to the kernel. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.

The maintained responsibilities are:

• load and validate the signed boot image before transferring control to the kernel
• preserve the boot-time handoff contract expected by the kernel and early services
• keep platform setup deterministic and limited to boot ownership

Clean-Room Policy

EriX follows a strict clean-room philosophy:

• No external source code may be copied.
• No external Rust crates are allowed.
• No code generation tools that embed third-party code.
• All code must be authored within the project.

Violations will result in rejection of the contribution.

License

All EriX repositories are licensed under the ISC License.

Development Model

EriX development is modular, deterministic, reproducible, authority-explicit, security-first, and self-hosting oriented.

This repository follows the project roadmap and the validation rules documented in its own roadmap.

Dependencies

• lib-bootimg for boot.img parsing/verification
• lib-elf for ELF64 parsing
• lib-handoff for handoff schema types

No external Rust crates are used.

Build and Test

make build-uefi
make package-esp

make package-esp expects a signed boot.img fixture at out/fixtures/minimal-boot.img. If it is missing, scripts/package-esp.sh invokes scripts/build-bootimg-fixture.sh, which expects a kernel ELF fixture at out/fixtures/kernel.elf or the KERNEL_ELF path supplied by the caller. The cross-repository integration repository owns boot execution scenarios and virtual-machine topology.

Status

Implemented baseline:

• boot.img load/parse/verify path
• ELF extraction and load-plan path
• handoff build and kernel-transfer path in current UEFI profile
• non-executable blob module loading (including console-font)
• boot-config module loading (SectionType::BootConfig) and handoff inclusion
• GOP framebuffer mode capture + continuity metadata in handoff
• dev-profile early console rendering via lib-console with cursor/generation continuity export
• release-profile quiet early boot (no bootloader serial/framebuffer trace emission)
• integration-owned system boot and malformed-image scenario coverage

Remaining work is focused on contract freeze (kernel/rootd alignment), portability hardening, and expanded adversarial coverage.

Governance Principles

bootloader governance is scoped to early machine setup and verified transfer into the kernel.

The scoped governance rules are:

• It keeps boot policy narrow: validate the image, prepare the handoff, and enter the kernel.
• It must not embed service policy that belongs to rootd or later user-space services.
• It treats malformed or unverifiable boot images as fatal startup errors.
• It keeps platform assumptions documented because later components depend on the handoff contract.

Authority Boundaries

• Boot-time authority ends at the kernel handoff; runtime authority is represented by explicit capabilities after startup.
• Changes to handoff data require matching updates in kernel and boot-image validation tests.

Contact

Development occurs in EriX organization and discussions happen in issues and design documents.

No decisions are considered valid without documented rationale.

Maintainers can be reached via email: admin@erikinkinen.fi.