EriX Dynamic Link Library (lib-dynlink)

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

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 supported ELF64 x86_64 ET_DYN dynamic-link metadata subset
• define Rust/no-std dynamic artifact ABI constants and the 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 dynamic-linking baseline:

• #![no_std], no-alloc dynamic-link planning API
• crate-wide rustdoc coverage enforced with deny(missing_docs)
• 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
  • erix-dynlink-runtime-graph-v1
  • dependency object paths bound to named lookup roots
  • exact package-version and full feature/manifest/object digest checks
  • an empty manifest as an explicit deny-all runtime-loader authority set
  • object ABI and load-order checks
  • direct object-offset/index traversal without duplicated edge names or ambient path construction
  • 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 and DT_SONAME object identity
  • checked DT_RELACOUNT leading-relative-relocation hints
  • .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
• supported eager dynamic flags: DF_SYMBOLIC and DF_BIND_NOW, including the equivalent DT_FLAGS_1 NOW declaration; unsupported or lazy-binding flags remain rejected
• manifest dependency verification by dynamic object name and object identity
• rejection of duplicate singleton dynamic tags, noncanonical data after DT_NULL, invalid SONAME references, and inaccurate relative-relocation prefixes
• stable DynamicLoadErrorClass mapping shared by loaderd and dynlinkd
• early_link_plan for bootstrap callers before dynlinkd is available
• caller-sized graph-wide symbol resolution over executable, direct dependencies, and transitive dependencies
• requirements queries and caller-provided plan/traversal storage, so the library imposes no object-count, symbol-count, relocation-count, or graph depth policy
• 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
• loaderd and dynlinkd use the caller-sized requirements, object plans, graph plans, and stable error mapping in the runtime materialization transaction
• technical 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.

Governance Principles

lib-dynlink owns validation and deterministic link planning, not executable discovery, storage, mapping, or process authority.

• Interface changes must update direct consumers, architecture documentation, and focused validation together.
• Resource capacity remains caller-owned and derived from validated input structure rather than library-wide policy limits.
• Pre-alpha interfaces may change when doing so removes obsolete, misleading, or authority-bearing compatibility state.
• Non-obvious security or authority choices require documented rationale and review.

Contact

Development occurs in the EriX organization. Maintainers can be reached at admin@erikinkinen.fi.