EriX Memory Service (memd)

memd is the user-space memory policy service. It owns allocation policy decisions above kernel primitive object semantics.

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 mem service daemon. Its purpose in EriX is to provide the mem service role through explicit IPC and startup authority.

Functionally, it implements the daemon runtime, state model, IPC handling, and validation tests. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.

The maintained responsibilities are:

• implement the mem service runtime and state model
• validate startup authority before accepting IPC requests
• handle exactly framed service operations through the assigned endpoint set
• keep service behavior, tests, and authority invariants documented

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.

Implementation Status

Runtime baseline:

• no_std executable service binary (x86_64-unknown-none) with SysV entry ABI
• startup envelope parsing/validation via lib-bootstrap
• role/intake contract validation via lib-capabi
• startup ready-state validates actual local slot type/rights with caller-local QUERY_LOCAL_CAP on bare metal and QUERY_CAP in host/test scaffolding
• the host/test QUERY_CAP fallback is cfg-scoped so runtime/release builds remain warning-free
• runtime allocation uses the one explicitly startup-transferred, manage-only RAM allocator-domain capability; it never scans the local CSpace
• startup state stores that exact slot directly and rejects a missing or second allocator capability, without a bitmap or service-local capacity ceiling
• allocation policy forwards the caller's page-granular size, alignment, and exact frame rights; the kernel searches the complete authenticated extent domain and atomically reserves the concrete physical subrange
• runtime IPC server loop (RECV + REPLY) for frame allocation and read-only allocator-total requests, using the canonical transport capacity without service-local deadlines
• request dispatch reads only the common request identifier and operation identifier before selecting the operation-specific exact body; no request flags or compatibility padding remain
• ordinary startup, kernel-control, and public-service messages admit no transferred authority; unexpected receipts are retired before rejection, and uncertain cleanup terminates the service
• allocation requests name the caller-local destination slot for the returned frame capability; no service-global destination-slot convention remains
• root's dedicated memory endpoint source SLOT_KERNEL_MEM_ENDPOINT (2224) is copied into memd's role-local primary control slot 174; the runtime never addresses root's source slot
• one explicit transaction-local frame-export source slot; the single-threaded service retires it before receiving the next request
• newly allocated frame caps are placed after the startup-reserved local transfer slots so runtime output does not overwrite the declared startup bundle
• allocation replies retain their bytes and provisional frame source until the kernel either completes the transfer or returns a terminal transfer error; memd then drops the exact source before handling another request
• a terminal frame-transfer error is returned as an authority-free typed reply, so an occupied caller destination slot is not mistaken for retryable delivery backpressure
• allocation size and alignment must both be non-zero page multiples; memd does not silently rewrite caller-supplied alignment policy
• the reply's physical address is kernel-produced DMA metadata, not an input to vspaced and not authority to bind or map arbitrary memory
• memd has no registry or logging dependency: it becomes available for physical-memory requests before named and logd start
• the allocator-total projection uses the existing dedicated kernel memory endpoint, returns only total and live-allocated byte counts, and accepts or transfers no capability authority
• memd does not receive a name-resolution scope, self-register, or hold a broad discovery endpoint

Dynamic Boot Artifact Evidence

The runtime image contract documents memd as a dynamic boot artifact. The image build packages the memory manager service as an ELF64 x86_64 ET_DYN executable with .erix_dynlink metadata in the signed dynlink-store and mirrors it under /lib/erix/dynlink with its required shared objects.

Startup remains rootd/kernel process-control before procd is available; authority remains the explicit memory-control endpoint and startup transfer set. Dynamic packaging and filesystem mirror records are evidence and launch inputs only; they do not grant filesystem, loader, object-store, service- discovery, provider-bypass, block-device, or dynlinkd authority. memd receives only the documented startup endpoints, peers, and capabilities for its role.

Governance Principles

memd governance is scoped to memory service policy above kernel allocation mechanisms.

The scoped governance rules are:

• It mediates only the memory authority assigned at startup.
• It keeps allocation and mapping requests bounded by explicit caller authority.
• It preserves kernel policy separation by implementing user-space memory service behavior.
• It rejects malformed or overbroad memory requests fail-closed.

Authority Boundaries

• memd operates only through startup-assigned service capabilities.
• New authority must be represented in bootstrap/capability validation and integration tests before use.
• The public protocol has no caller-driven frame-free operation. A caller controls only the transferred capability in its named destination slot; memd retains no source alias after a successful handoff.

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.