EriX Dynamic Link Library (lib-dynlink)

lib-dynlink provides validation-first native dynamic-link planning helpers for EriX Phase 5.

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 dynamic-link helper library. Its purpose in EriX is to parse and validate supported native dynamic object metadata, then produce deterministic dependency, symbol, and relocation plans without mutating process memory.

Functionally, it validates caller-supplied ELF dynamic tables, SysV hash tables, dynamic string tables, dynamic symbol tables, RELA relocation tables, and DT_NEEDED dependency tags. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.

The maintained responsibilities are:

• parse the Phase 5.4 ELF64 x86_64 ET_DYN dynamic-link metadata subset
• define the Phase 5.4 Rust/no-std dynamic artifact ABI constants and metadata validation surface
• build no-alloc dynamic dependency, symbol, and relocation plans
• provide deterministic load-error classes for loaderd and dynlinkd
• provide a no-service early-link entry point for bootstrap components

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.

Current Support

Implemented Phase 5.4.11 baseline:

• #![no_std], no-alloc dynamic-link planning API
• dynamic artifact ABI constants for ELF64 little-endian x86_64 ET_DYN, .erix_dynlink, erix_dynlink_entry, panic-abort/no-unwind, and unsupported TLS, init/fini, lazy binding, IFUNC, text relocation, and unwind features
• no-alloc validation helpers for supported PIE executable and shared-object metadata
• no-alloc validation helpers for explicit lookup manifests:
  • erix-dynlink-lookup-manifest-v1
  • dependency object paths bound to named lookup roots
  • object ABI, version, identity, and load-order checks
  • rejection of current-directory lookup, global search paths, service-discovery bypass, and direct block-device authority
• parsers for:
  • ELF64 dynamic table entries
  • DT_NEEDED dependency tags
  • .dynstr string references
  • .dynsym symbol entries
  • SysV .hash
  • .rela.dyn and .rela.plt Elf64_Rela tables
• supported relocations:
  • R_X86_64_RELATIVE
  • R_X86_64_GLOB_DAT
  • eager R_X86_64_JUMP_SLOT
  • R_X86_64_64
• manifest dependency verification by dynamic object name and object identity
• stable DynamicLoadErrorClass mapping shared by loaderd and dynlinkd
• early_link_plan for bootstrap callers before dynlinkd is available
• bounded graph-wide symbol resolution over executable, direct dependencies, and transitive dependencies
• relocation write planning with caller-supplied writable range validation and deterministic rejection of text, read-only, out-of-range, and overflow cases
• early kernel-link consumers use the same symbol and relocation policy for boot-store shared objects before the dynlinkd service exists
• Phase 5.4.37 documentation records bootloader and kernel early-link consumers as no-service callers: lib-dynlink supplies metadata constants, relocation policy, plan/error classes, and manifest validation data without receiving filesystem, object-store, process, or service-discovery authority
• CI coverage for Rust formatting, strict clippy, unit tests, docs build, and Markdown linting

The library does not own executable source discovery, filesystem lookup, mapping, relocation execution, process materialization, or service publication. Its lookup-manifest API validates caller-supplied paths and roots as data only; it never opens files or discovers objects.