EriX Program Loader (loaderd)

loaderd is the Phase 4.7 native program-loader service for EriX. It is a no-std service binary that receives only an explicit service endpoint and a send-only vfsd startup peer plus a send-only procd handoff peer.

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 program-loader daemon. Its purpose in EriX is to validate executable sources, build static ELF load plans for the temporary bootstrap bridge, transfer validated filesystem bytes to procd, and hand materialized launch results back to callers.

Functionally, it accepts loader IPC requests, resolves executable paths through the public VFS namespace, reads file contents through vfsd, validates source metadata, validates static ELF segment layout through lib-elf, and returns deterministic success or failure responses after calling procd for accepted static bridge launches. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.

The maintained responsibilities are:

• validate its startup envelope and explicit vfsd/procd peers
• resolve canonical absolute UTF-8 VFS paths through public vfsd calls
• reject malformed, missing, directory, empty, oversized, read-denied, and changed-while-loading executable sources
• build deterministic static ELF load-plan summaries without allocator authority
• transfer validated file-backed executable bytes and segment metadata to procd through the ordered materialization ABI
• expose malformed ELF, invalid load-plan, unsupported dynamic-policy, and process-handoff failures through typed loader responses
• request process creation only through the typed procd begin/chunk/commit materialization handoff
• preserve the non-delegating Phase 4.7 loader authority policy

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.

Status

Implemented baseline:

• no-std loaderd service entry and startup handshake
• SERVICE_ROLE_LOADERD startup validation with no primary control endpoint
• explicit send-only vfsd startup peer at SLOT_LOADERD_LOCAL_VFSD_ENDPOINT_V1
• explicit send-only procd startup peer at SLOT_LOADERD_LOCAL_PROCD_ENDPOINT_V1
• DISCOVER_PATH IPC handling through lib-vfs client helpers
• canonical path, file-type, empty-file, size-limit, execute-bit, and stable metadata checks before reporting a discovered executable
• LAUNCH_PATH static-bootstrap-bridge validation through lib-elf
• deterministic empty argv/env startup state for the static bridge; non-empty argument or environment blocks fail closed until a startup-envelope delivery ABI exists
• malformed ELF and invalid segment-layout rejection before process mutation
• deterministic REQUIRE_DYNAMIC rejection until Phase 5.4 dynamic linking is available
• deterministic procd materialized process handoff after a valid static plan, returning process id, entry point, and launch id on success
• Phase 4.7.6 materialization model: loaderd retains executable bytes only in bounded local scratch until an ordered inline transfer completes; procd owns frame allocation, segment copy, zero-fill, permission sealing, address-space mapping, and cleanup
• Phase 4.7.7 transfer ABI: lib-ipc now defines begin/chunk/commit loaderd -> procd materialization bodies with bounded source identity, source/plan hashes, segment metadata, ordered chunk ranges, and executable or dynamic-object image kind
• Phase 4.7.8 materialized launch: LAUNCH_PATH now sends source bytes and segment metadata through the transfer ABI, receives a procd launch id, and proves the old summary-only handoff is not the filesystem execution path
• Phase 4.7.10 cleanup hardening clears executable scratch after source read, close, final-stat, ELF-plan, and process-handoff failures, and also drops the scratch buffer after successful handoff so executable bytes do not remain in loaderd state
• Phase 4.7 closure is validated by the focused phase4-loader-closure scenario group, which proves VFS policy rejection, malformed ELF rejection, true filesystem-byte execution, stale-source rejection, cleanup, and authority denial without granting extra loader authority
• unit tests for startup, discovery, dispatch, and load-plan contracts

Governance Principles

loaderd governance is scoped to executable source validation and future load plan construction.

The scoped governance rules are:

• It must use explicit startup authority; no ambient VFS, provider, block, key, journal, or peer-service authority is allowed.
• It must read executable bytes only through vfsd, so mounted-provider policy remains authoritative.
• It must fail closed before process mutation unless procd accepts the typed handoff.
• Filesystem-backed execution must transfer validated bytes and segment metadata explicitly to procd; the legacy summary-only handoff is denied and cannot satisfy disk-execution proof.
• Dependencies in Cargo.toml track the main branch; integration tooling supplies local branch overrides for multi-repo validation.

Policy Boundaries

• loaderd does not own process lifecycle; procd remains responsible for process objects, address-space creation, startup, event tracking, and cleanup.
• loaderd does not own address-space or paging policy; vspaced and pagerd retain those responsibilities.
• loaderd does not bypass vfsd or private filesystem providers.
• loaderd does not receive memory, VSPACE, install-grant, or process-control authority for materialization; it can only send bounded launch data through the explicit procd peer.

Contact

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

Discussions should occur via issues or design documents.

No decisions are considered valid without documented rationale.

You can also reach out to maintainers via email: admin@erikinkinen.fi.