Uranium-238-v0.3.1

Ferrum now reads boot files through a userspace filesystem service and launches multiple configured services. An independently versioned immutable archive, session-scoped streaming operations and bounded channel wait sets make executable discovery explicit without putting pathname resolution in the kernel.

Boot delivery and filesystem layout have separate contracts

Boot envelope v2 carries an initial ELF and opaque initramfs bytes. The existing
BootInfo v3 transport, source reservations, permanent supervisor RO/NX aliases
and 4 MiB total payload ceiling remain. UEFI uses BOOT.ELF; RISC-V uses initrd.
The kernel validates the envelope and loads init, without parsing archive paths.

Ferber initramfs format v1 has a little-endian header, sorted fixed-size path
index, dense string table and uncompressed file data. The allocation-free parser
validates the entire archive before lookup. It bounds entry counts, path sizes
and depth and rejects malformed paths, missing parents, duplicate or unsorted
entries, unsupported kinds, overflow, overlaps, nonzero padding and trailing data.
Only files and directories are supported. There is no public archive acronym or
filename extension, compression, ownership database or authentication claim.

Host tooling packs reproducibly, lists and verifies through the production parser,
and extracts into a new destination using no-follow directory operations and
exclusive creation. Failed packing preserves existing output. Extraction does
not overwrite existing files or restore archive-supplied ownership metadata.

Init delegates bytes and sessions to its filesystem process

Bootstrap protocol v3 keeps startup ABI v1 unchanged. Init receives the services
Job and a sealed archive VMO with READ, MAP, INSPECT and TRANSFER rights. It maps
the archive to construct sbin/initfs, then relinquishes its mapping and moves
the archive to the filesystem process. Initfs retains an RO/NX mapping for its
lifetime and receives no process-creation authority.

Session pairs are created and delegated before process start through the existing
task ABI. General queued channel-endpoint transfer remains prohibited. OPEN,
READ, LIST, CLOSE and STAT messages operate through a delegated session channel.
Open IDs increase monotonically and have meaning only within that session;
they are not independently transferable capabilities. Reads are bounded to
4096 bytes, directories are paginated and each session has eight open slots.

Malformed messages, unexpected capabilities and failed replies disconnect the
offending client. They do not terminate the entire filesystem service. The
server rotates client selection and blocks on wait sets rather than polling.

Wait sets extend the existing cancellation and idle rules

Syscall 23, sys_chan_wait_many, accepts 1–16 channel handles and returns the
lowest ready input index without consuming a message. Readability includes
queued data and peer closure. Every handle requires READ and WAIT; all entries
are validated before reporting readiness and endpoint aliases are rejected.

One task token and generation cover every registration. Setup failure rolls
back earlier registrations; return, cancellation and teardown remove the whole
set. Close, slot reuse or revocation of any watched capability cancels the wait.
The scheduler includes all members in producer/source analysis. Filesystem
waiting gains no implicit external wake root. Existing syscall contracts remain.

Configured services are prepared before any of them execute

Init reads etc/services.conf and executable bytes through initfs. The bounded
configuration specifies up to eight required services and explicit filesystem
access (fs or none). The default image contains initfs and two configured
service executables, with filesystem access granted to one. Init prepares all
configured drafts before starting any configured child. Existing ELF validation,
zero-filled BSS, segment permissions and executable sealing remain enforced.

Readiness, challenge fanout and idle evidence are bound to each real child
process and its exact endpoint. Aggregate readiness must match actual Job
membership. Missing or invalid files, failed construction, unexpected exits and
unrooted waits fail startup. The shutdown probe reclaims init and every service
and checks restored allocation, capability and process accounting.

During validation, two defects were fixed: reusing a PONG buffer while forwarding
the next child's PING, and admitting an earlier configured service before a later
executable had been validated. Adversarial checks also exposed filesystem-wide
termination on malformed clients or full reply queues; these failures are now
contained to their sessions.

Verification separates implementation evidence from release metadata

Local host tests passed for archive/tool round trips and malformed data,
filesystem protocol/session isolation and stale IDs, configuration, scheduler
wait sets, channel races and allocation failures, task construction, hierarchical
accounting and ELF parsing/loading. Both kernel targets passed Clippy with
warnings denied. QEMU coverage on both architectures includes init/service
execution, software wake, protection faults, replay rejection, missing or invalid
configured executables, malformed-client containment, reply-queue flooding and
disconnected waits. Release ISO boots passed for init and software wake. The
freestanding ELF, shell syntax, workflow lint and strict log-parser checks passed.
These local observations precede this PR's hosted CI results.

A physical x86-64 boot on the 32 GiB MSI B650M-A PRO WIFI reached:

[FERBER_TEST] memory_verification: PASS
[FERBER_TEST] boot_payload: PASS
[FERBER_TEST] service_launch: PASS
[FERBER_TEST] multiservice_idle: PASS
[FERBER_TEST] init_ready: PASS
[FERBER_TEST] init_waiting: PASS

The run managed 32218 MiB (31.46 GiB), 8247922 frames and 24 extents. It used the
pre-bump 0.3.0 banner and validates the initramfs implementation build. The
newly versioned 0.3.1 ISO is not claimed as physically tested. The policy to
version and identify clean candidates before hardware validation was adopted
after this run; its provenance cannot be reconstructed retroactively from the
photo. The dedicated software-wake build was not flashed, and no physical
RISC-V validation is claimed.

Integrated allocation-failure injection during multi-service preparation/start
and quota exhaustion with several retained drafts remain coverage gaps; lower
level task and allocator failure tests passed. Execution remains cooperative,
single-CPU and integer-only with interrupts masked. Writable or persistent
filesystems, general VFS/mount policy, dynamic filesystem-session connections,
restart/dependency policy, recoverable user faults, preemption and SMP remain
outside this release. AArch64 is the next prioritized port and is not implemented.

Both crates advance to 0.3.1 without dependency changes. See the
archive format, filesystem protocol,
syscall ABI and init contract.

Contributions:

• feat: add initramfs and configured Ferrum services by @notvcto in #6

Full Changelog: Uranium-238-v0.3.0...Uranium-238-v0.3.1

Uranium-238-v0.3.0

Ferrum init now constructs and launches an independently built resident service on RISC-V64 and x86-64. Staged task creation keeps construction authority separate from running-process lifetime, while tracked wake sources distinguish legitimate multi-service waiting from cooperative deadlock.

Userspace constructs a child before publishing it

Task ABI v1 adds syscalls 17–22: process create, map, give, initial-thread create,
start and abort. Creating a process requires explicit MANAGE authority through a
live concrete Job capability. Controllers revalidate the creating authority and
its ancestry before construction operations. Abort remains available after Job
authority revocation when the controller itself is still live.

A draft begins with zero handles and cannot execute before successful start.
Mapping accepts bounded owned-RAM VMOs, retains backing independently of handles,
requires sealed backing for RX and retains writable permits for RW/NX. Guarded
stack ranges remain reserved. Capability delegation moves eligible VMO, leaf
Resource or channel capabilities into actual assigned child slots. It does not
implicitly clone parent authority or enable graph-owning channel payloads.

Initial-thread creation prepares one guarded user stack, a kernel-stack VMO and
startup ABI v1. Scheduler admission reserves fallible storage before publishing
one runnable task. Failed preparation remains retryable; final controller release
aborts an unstarted draft. Started controllers retain weak process references;
closing them cannot kill a started child. Job and scheduler ownership continues
until termination, with final reclamation on the dispatcher stack. Admission is
bounded to 64 live processes/tasks and remains subject to hierarchical budgets.

Init receives executable bytes and explicit launch authority

A bounded boot bundle contains exactly two independently linked static ELF
executables: init and its first service. The allocation-free parser rejects
invalid counts, ordering, flags, padding, overlaps, overflow, truncated ranges
and trailing bytes. The existing 4 MiB firmware payload bound and BootInfo v3
remain unchanged. UEFI retains the transport filename BOOT.ELF; RISC-V uses
initrd delivery. This format is not a general initramfs or authenticated boot.

The kernel loads init and delegates a weak Job authority for a dedicated 16 MiB
services Job plus a sealed read-only source-image VMO through bootstrap protocol
v2. Ferrum uses the shared bounded ELF parser, creates fresh segment VMOs,
populates file bytes and zero-filled BSS, seals executable backing, installs child
mappings, moves a bootstrap endpoint, creates the initial thread and starts it.
Temporary source mappings and construction handles are released after setup.
The kernel does not construct the running child on init's behalf.

Readiness requires execution and a rooted wait graph

The service announces READY and answers a PING forwarded through init. Kernel
evidence observes successful sends from the actual service process, verifies the
paired endpoint and pending challenge, and checks that the same service remains
alive and blocked on that endpoint before reporting success. Unsolicited or
replayed PONGs cannot satisfy a later challenge. Weak observation references do
not keep channels alive. Unexpected child exits receive explicit diagnostics.

The scheduler connects blocked readers to admitted tasks holding live WRITE
capabilities and requires the bounded wait graph to reach a registered source.
Source leases use weak endpoint identity and checked generations. Holding both
ends of a closed cycle does not make it a legitimate wake source. The normal
bootstrap source permits a validated terminal steady state with init and its
service blocked. Interrupts remain masked there.

A separate service-wake-probe queues concrete software work after quiescence,
resumes both processes, checks challenge 75 and releases its source lease.
This demonstrates cooperative software delivery, not hardware interrupt wakeup.

Finite warmup and measured shutdown runs precede the resident run. The service
exits zero, init exits with its expected closure status one, and dispatcher
reclamation restores frame, capability-node and process baselines.

Build names match the program they select

The Cargo feature is now init, replacing minimal-init. Make uses INIT=1.
Cargo cfgs, scripts, CI and active documentation use the new name; historical
release notes retain the terminology used by their releases. service-wake-probe
depends on init. The feature rename does not alter the syscall ABI.

make run INIT=1 builds and boots the bundle on RISC-V.
make x86-iso INIT=1 packages the release init/service ISO. CI publishes that
configuration. The shared ELF parser is used by both kernel loading and Ferrum's
service construction.

Verification includes physical x86 service launch

Local host suites and the complete RISC-V/x86 QEMU smoke matrices passed before
the version bump. Coverage includes production task syscalls and lifetime rules,
allocation failures and admission retry, scheduler wait graphs/source leases,
bundle and protocol validation, malformed/replayed bootstrap messages and native
service execution. Existing capability, channel, VMO, paging, accounting and ELF
regressions also passed. Four independent adversarial reviews completed with no
confirmed issues remaining after fixes.

After the feature rename, both architecture configurations built and passed
Clippy with warnings denied. Fresh RISC-V init/replay boots and x86 release init
and software-wake ISO boots passed. Freestanding ELF and log-parser checks passed.
After the version bump, release init Clippy passed on both kernel targets and
the UEFI loader with warnings denied. The ten task tests, four scheduler tests,
bundle/protocol tests and strict log-parser self-check passed again. These local
observations precede hosted Actions validation for this tag.

A physical x86-64 boot on the 32 GiB MSI B650M-A PRO WIFI reached:

[FERBER_TEST] memory_verification: PASS
[FERBER_TEST] boot_payload: PASS
[FERBER_TEST] service_launch: PASS
[FERBER_TEST] multiservice_idle: PASS
[FERBER_TEST] init_ready: PASS
[FERBER_TEST] init_waiting: PASS

That run managed 31.46 GiB and used the pre-bump 0.2.14 banner. The dedicated
software-wake build was not flashed. No physical RISC-V result is claimed.

The kernel and UEFI loader advance to 0.3.0 without dependency upgrades.
This remains a prerelease. Execution remains cooperative,
single-CPU and integer-only with interrupts masked. Initramfs, named-service
loading, namespace/filesystem services, general service management, independent
user-fault recovery, preemption, IRQ-safe allocation and SMP remain pending.

See the task ABI, init contract and
boot-bundle contract for exact rights, bounds and lifetimes.

Full Changelog: Uranium-238-v0.2.14...Uranium-238-v0.3.0

Uranium-238-v0.2.14

Job memory limits now account for physical storage across the hierarchy on RISC-V64 and x86-64. Allocations retain their original budget through capability transfer, creator exit and foreign destruction. Uranium decays. The outstanding charge waits for the last owner.

Job limits include their descendants

The previous Job limit and usage fields become enforced allocation budgets.
Admission checks the complete retained ancestry before changing counters; an
exhausted or closed ancestor rejects the reservation without a partial charge.
The bootstrap root Job receives half of managed physical RAM as its limit,
with at most 32 child edges below it.

A System budget accounts for bootstrap reservations, permanent kernel tables
and kernel-owned allocations. Its inclusive usage also contains Job charges,
so System and Job totals must not be added together. System has no policy quota
and can still encounter physical exhaustion. Bootstrap reservations are adopted
once after the physical allocator initializes. Native checks reconcile System
usage with bootstrap-reserved and allocated frame totals.

Allocator overhead belongs to an owner

The buddy allocator now uses separate arenas per budget. Charges count complete
physical backing pages, including ownership headers, alignment padding, unused
blocks and fragmentation. Fully coalesced pages return to the bitmap allocator
and release their charge. Large allocations charge the complete rounded span.
The payload ceiling remains 128 MiB and supported alignment remains at most
4 KiB; a page-aligned 4 KiB payload can consume two pages with its header.

Allocation headers retain the original budget. Freeing from another allocation
context refunds that owner. Reallocation preserves ownership, accounts for old
and replacement storage concurrently when replacement is required, and preserves
the old allocation on failure. Budget metadata is allocated under the parent
budget so the budget cannot own its own allocation.

Process construction, thread stacks, ELF population, capability nodes, syscall
buffers and mapping metadata now participate in allocation accounting. Channel
queue and waiter growth uses the channel's original budget; message buffers
retain their own owners. Target task records belong to their Job, while global
scheduler storage and the dispatcher stack are explicitly System-owned. Job,
process and thread ID allocation also rejects exhaustion instead of wrapping.

Closing authority does not refund live backing

Owned VMOs retain frame charges independently of their capabilities. Transfer,
duplication, attenuation, close and revocation do not move those charges.
Mappings and queued capabilities can keep backing alive after its creator exits.
Physical/MMIO VMOs do not charge device addresses as owned RAM; their metadata
still uses accounted heap storage.

Killing a Job closes its budget before cascading termination. Closed ancestry
rejects new allocations, including reuse of cached buddy blocks. Existing memory
remains usable and reclaimable. Retained budget ancestry survives the structural
Job until its final allocation disappears. Owned frames are freed before their
charge is released; private page-table removal flushes local translations before
freeing tables and refunding them on both architectures. Failed preparation
unwinds provisional charges without publishing partial mappings.

Fallible syscall allocation paths distinguish quota or closed-ancestry denial
(-28) from physical or allocator exhaustion (-12). The existing global
user-created VMO backing limit remains an additional policy counter, rather
than a second charge for the same physical pages. Infallible Rust allocation
paths can still panic on exhaustion. No new syscall numbers are introduced.

Allocation context follows execution

The cooperative dispatcher selects the running process's budget and returns to
System ownership before dispatcher work and reclamation. Scoped owner overrides
and allocation-failure capture must finish before a task switch; assertions
enforce that boundary. The ledger is serialized, but the production context
still assumes one active CPU with interrupts masked. Host concurrency tests use
thread-local contexts and do not establish production IRQ or SMP safety.

The probe keeps the charge after killing its creator

The separately compiled accounting fixture runs producer and consumer processes
under sibling Jobs with 4 MiB limits and an 8 MiB parent limit. Each encounters
a Job-denied VMO creation. The producer then creates and writes an 8 KiB VMO,
derives a read/transfer capability and sends it to the consumer. After producer
exit and Job closure, the consumer reads the surviving backing while evidence
checks that the original closed budget retains the charge. Final foreign release
restores backing capacity. Warmup plus three measured batches restore frame,
capability-node, Job/process, scheduler and allocation-budget baselines.

JOB_ACCOUNTING_PROBE=1 builds the dedicated verification ISO. Its required
markers are memory_verification, job_accounting and boot_payload, each
with the [FERBER_TEST] prefix and PASS result. Ordinary boots also run native
checks against the real global allocator, including closed budgets, ancestor
denial, foreign destruction and accounting restoration.

Validation covers both ports and physical x86

Before the version bump, all 93 host tests passed: 17 memory, 13 channel,
15 ELF parser, seven loader/startup, eight UEFI payload, two init protocol,
two VMO core, one VMO syscall, eight Sv39 walker, ten PML4 walker and ten
production ledger/allocator tests. All 44 RISC-V and 37 x86 QEMU smoke cases
passed, together with all seven release ISO scenarios through OVMF's CD-ROM
path. Default and probe-feature Clippy configurations passed on both kernel
targets, as did release UEFI Clippy, with warnings denied. Shell syntax,
strict log-parser self-checks and diff checks passed.

After the version bump, fresh accounting and minimal-init release ISOs passed
OVMF boots and freestanding ELF validation. Accounting and minimal-init Clippy
passed on both kernel targets, together with release UEFI Clippy, all with
warnings denied. The ten accounting host tests, strict log-parser self-check
and manifest/lockfile consistency checks also passed again.

Additional adversarial checks exercised 30,000 mixed allocator operations across
seven bounded owners, 12,000 operations with foreign-context frees, 260 payload
size/alignment combinations, and forced allocation/reallocation failures across
40 combinations. A temporary weakened closed-ancestor check was detected by the
cached-arena regression. No confirmed bugs remained from the independent reviews.
Host metadata allocation and instrumented paging remain distinct from native
execution evidence.

A physical x86-64 boot on the 32 GiB MSI B650M-A PRO WIFI reached all three
accounting markers, with native hierarchical accounting checks reporting OK
and 31.46 GiB managed RAM. That run used the pre-bump 0.2.13 banner. Physical
RISC-V hardware has not been available; RISC-V evidence remains QEMU-only.
Hosted Actions results remain separate from these local results.

The kernel and UEFI loader advance to 0.2.14 without dependency upgrades.
The published ISO continues to boot minimal Ferrum init using startup ABI v1.
This remains a prerelease; 0.3.0 stays reserved. Userspace task creation,
service launch, preemption, IRQ-safe allocation and SMP remain pending. The
accounting contract is documented in Job accounting.

Full Changelog: Uranium-238-v0.2.13...Uranium-238-v0.2.14

Uranium-238-v0.2.13

Userspace can write code into a VMO, seal its backing irreversibly, and execute it through an RX mapping on both architectures. Writable aliases anywhere block publication; old WRITE rights cannot reopen sealed memory. Uranium-238 decays. This state transition does not.

Executable authority is explicit before sealing

Syscall 16, sys_vmo_seal(handle, options=0), requires MANAGE and EXECUTE
through a live owned-RAM VMO capability. It seals the entire object, allocates
nothing and succeeds again when called with valid authority on sealed backing.
There is no unseal, partial seal or implicit mapping conversion.

Creation options 0 and 1 preserve their previous rights exactly. The new
VMO_CREATE_EXECUTABLE bit requires VMO_CREATE_MAPPABLE; options 3 grant
MAP and EXECUTE in addition to the original rights. Option 2 alone and unknown
bits are invalid. Sealing never manufactures capability rights or replaces a
handle. Existing aliases keep their rights bits and share the object's state.

Syscall 14 accepts permission 5 for RX, requiring READ, MAP, EXECUTE and sealed
backing. RO remains available on mutable or sealed objects; RW/NX requires
mutable backing. RWX and execute-only requests remain invalid. Existing size,
logical-page, protected-range, mapping-record and private-table limits remain
unchanged. Physical/MMIO and nonowning VMOs remain excluded.

Writable mappings retain permits through invalidation

The VMO's content lock now protects sealed state and an object-wide count of
writable-mapping permits. A writable mapping in any process blocks seal with
-16, even after its originating capability is closed, transferred or revoked.
RO mappings may remain installed. A writable subrange blocks the whole object;
publication does not silently remove another process's access.

RW admission acquires a nonallocating RAII permit before fallible mapping
preparation. Failed allocation or quota admission releases it. A successful
mapping record retains it until exact unmap or process teardown invalidates
the translations. Invalid or partial unmap cannot release it. Killing a task
only marks it dead; dispatcher reaping and fallback destruction preserve the
address-space-before-owner ordering.

After sealing, writes through surviving WRITE handles, new RW mappings and
ordinary internal VMO write methods return permission failure. Empty writes
are denied too. The syscall checks eligibility before user preflight or staging;
the write method checks again under the shared state lock when committing.
Reads and ordinary capability ownership operations retain their existing rules.
Revocation still does not remove installed mappings.

Kernel output copies continue requiring effective writable user pages. VMO
read destinations, capability inspection and channel byte/handle/count outputs
cannot write through RO or RX aliases. Denied receives preserve the queued
message and handle ownership. The guarantee covers supported user-controlled
mutation paths; trusted supervisor RAM aliases remain RW/NX.

RX installation publishes instructions locally

Both production walkers perform an allocation-free instruction-publication
step after committing executable leaves and flushing local translations.
RISC-V executes fence.i with compiler-visible memory effects; x86-64 executes
CPUID leaf zero between compiler fences. This orders code written through the
supervisor RAM alias before fetching it through the user mapping.

The initial RISC-V user-entry fence alone does not cover executable code
installed during later returning syscalls. Failed maps and non-executable maps
skip the new publication hook. Trusted ELF RX installation uses the same
walker hook without changing loader ownership or adopting user sealing charges.
Local publication is not remote instruction synchronization or an SMP shootdown.

The fixture calls the bytes it publishes

The separately compiled sealing fixture contains relocation-free leaf functions
returning 17 and 42. It copies their bytes through syscall 13, seals the VMOs,
maps RX and calls them in user mode. Its peer holds a writable alias to prove
publication remains blocked after source-handle closure and revocation, then
unmaps explicitly so sealing can proceed.

The producer and consumer execute shared sealed backing, retain executable
mappings after handle closure/revocation and report actual return values through
channels. The producer replaces function A with separately sealed function B
at the same VA in an already-running process and observes 42 instead of 17.
Kernel evidence requires the result messages, successful seal/map operations,
two clean exits and drained records. Warmup plus three measured batches restore
frame, node, process, scheduler and user-backing-budget baselines.

VMO_SEAL_PROBE=1 builds the dedicated verification ISO. Its required markers
are memory_verification, vmo_sealing and boot_payload, each with the
[FERBER_TEST] prefix and PASS result. A separate sealed-RX-write build requires
a matching user-origin protection fault, including the known instruction,
address, hardware cause and retained sealed RX metadata. Its marker is
vmo_sealing_write_rx; that deliberate fault halt does not prove reclamation.
Existing RO-write and NX-execute probes remain separate regressions.

Validation includes adversarial review and physical x86 execution

Post-interruption implementation validation passed all 41 RISC-V and 35 x86
QEMU smoke cases, plus the release sealing ISO boot through OVMF's CD-ROM path.
All 80 host tests passed: 17 memory, 12 channel, 15 ELF parser, seven loader/startup,
eight UEFI payload, two init protocol, two VMO core, one production VMO syscall,
seven production Sv39 walker and nine production PML4 walker tests. Default
and all 11 user-probe/deadlock feature Clippy configurations passed on both
kernel targets with warnings denied, as did release UEFI Clippy. Both fixture
modes built for both architectures in debug and release; shell syntax and the
strict log-parser self-check passed.

Release preflight repeated all 80 host tests and the parser self-check.
After the version bump, fresh 0.2.13 minimal-init and sealing release ISOs passed
OVMF boots and freestanding ELF shape checks. Default, minimal-init, normal
sealing and sealed-write-fault Clippy passed on both kernel targets, together
with release UEFI Clippy, all with warnings denied.

Four independent reviewers examined the patch: red team, blue team, contract
lawyer and failure gremlin. No confirmed runtime bugs were found. One missing
consolidated syscall error-table entry was fixed and rechecked. Additional
adversarial checks covered rights subsets, options, permission encodings,
publication recovery, provisional permit rollback, alias quotas, retained dead
processes and final ownership. A blue-team mutation check verified that the
regressions detect premature writable-permit release. Host harness substitutes
and instrumented walker results remain distinct from actual CPU execution.

A physical x86-64 boot on the 32 GiB MSI workstation reached all three sealing
markers with the pre-bump 0.2.12 banner and 31.46 GiB managed RAM. That run
includes actual RX execution, same-address code replacement, cross-process
writable-alias blocking and repeated reclamation checks. The sealed-RX-write
fault probe remains QEMU-validated. Physical RISC-V hardware has not been
available for validation. Hosted Actions results remain separate from local
evidence.

The QA protocol now includes the independent blue-team defensive-control lens.
A dedicated Easter egg engineer protocol permits fitting comments, interactions
and runtime behavior with ordinary safety and verification requirements. This
patch adds one comment beside the seal transition and registers it in the
encoded contributor guide: WRITE bits on old handles are now collector's items.

The kernel and UEFI loader advance to 0.2.13 without dependency upgrades.
The published ISO continues to boot minimal Ferrum init; startup ABI v1 and its
readiness protocol are unchanged. This remains a prerelease; 0.3.0 stays
reserved. Userspace task creation, service launch, protection changes, partial
unmap and hierarchical Job charging remain pending. Execution is cooperative,
integer-only and single-CPU with interrupts masked. Raw kernel writes, DMA,
concurrent mapped writers, interrupt reentrancy, CPU migration and remote
instruction/TLB synchronization remain outside these guarantees.

Full Changelog: Uranium-238-v0.2.12...Uranium-238-v0.2.13

Uranium-238-v0.2.12

Uranium-238 v0.2.12

Userspace can map owned-RAM VMOs read-only or read/write, share their backing across isolated processes, and unmap exact regions. Both paging implementations prepare new tables before publishing mappings and reclaim empty private tables after invalidation. Uranium-238 still has a longer lifetime than a closed handle.

MAP authority is explicit and mappings remain non-executable

sys_vmo_create(size, 0) preserves the byte API's original rights. The new
VMO_CREATE_MAPPABLE option adds MAP; no option grants EXECUTE. Syscall 14 maps
a page-aligned logical subrange at an explicit address. RO requires MAP and
READ; RW/NX additionally requires WRITE. Syscall 15 removes one exact mapping
record belonging to the caller. It needs no surviving handle or MANAGE right.

Maps exclude physical/MMIO and nonowning VMOs, partial logical pages,
noncanonical or out-of-user-range addresses, registered stacks and their
guards. Existing leaves, huge mappings and reserved nonzero entries cannot be
overwritten. Partial unmaps, combined records and loader/stack unmaps fail.
The existing byte-copy ABI and startup ABI v1 remain unchanged.

Each process is limited to 64 user mapping records, 16,384 mapped pages
(64 MiB, counting aliases) and 256 private table frames, including its root
and loader/stack tables. Each map remains bounded to 16 MiB. The existing
user-created backing budget is separate and follows the VMO's lifetime.

Records own backing independently of capability nodes

A successful mapping retains an Arc<Vmo> together with its virtual range,
VMO offset and permissions. It does not retain the capability node or its
ancestry. Closing, transferring or revoking a handle leaves existing mappings
valid. Revocation still rejects later operations through that node; it does
not withdraw installed memory access. RO describes this mapping's permitted
access, and does not promise an immutable object when other writers exist.

Unmap validates every expected frame and permission before changing tables.
Backing stays owned until translation invalidation completes and is released
outside the process lock. Last-thread reaping drains dynamic mappings from
the permanent-root dispatcher stack, including when another kernel reference
retains the dead Process. Killing a process only marks its tasks dead and
never tears down the active address space in place.

Page-table changes publish only after preparation succeeds

Sv39 and PML4 preflight the complete raw range and count missing table
prefixes. New table frames are allocated and zeroed off-tree, with record
capacity and quotas checked before reachable PTEs change. Returned preparation
errors leave existing mappings and effective permissions unchanged. The final
publication path allocates nothing. x86 ancestor permission changes occur
only during that commit and preserve existing sibling restrictions.

Exact unmap clears validated leaves and prunes empty owned lower-half tables.
Reserved entries and other mappings prevent pruning. Both ports detach links
and flush local translation state before freeing retired table frames. Roots,
shared upper-half tables and VMO data frames are excluded from that pruning.
These operations retain the current single-active-CPU, interrupts-masked
contract; local flushes are not SMP shootdowns.

The external fixture exercises real mapped access

The independently compiled producer and consumer map shared backing, access
it through volatile loads/stores and transfer a READ/MAP capability through a
channel. Mappings survive handle close, updates remain visible across
processes, and unmap/remap at the same address checks replacement backing.
Kernel evidence requires successful mapping and channel operations, two clean
exits, drained records and repeated restoration of frame, node, task and
backing-budget baselines after warmup.

The dedicated VMO_MAP_PROBE=1 ISO requires memory_verification,
vmo_mapping and boot_payload PASS markers. Separate RO-write and NX-execute
builds require diagnosed user faults with the expected origin, instruction,
address and mapping metadata. Their deliberate fault halts do not claim task
reclamation. The published ISO continues to boot minimal Ferrum init.

Validation includes failures and physical x86 execution

Implementation validation passed all 36 RISC-V and 31 x86 QEMU smoke cases,
plus the release mapping ISO through OVMF's CD-ROM path. All 78 host tests
passed: 17 memory, 12 channel, 15 ELF parser, seven loader/startup, eight UEFI
payload, two init protocol, two VMO core, one production VMO syscall, six
production Sv39 walker and eight production PML4 walker tests. Default and
all three mapping-feature kernel Clippy configurations passed on both ports
with warnings denied. External fixture builds, shell syntax and strict log
parser self-checks passed.

Post-bump release preflight passed fresh 0.2.12 minimal-init and mapping
ISO boots through OVMF, release UEFI Clippy with warnings denied, and the
strict log-parser self-check. Both ISO builds passed the freestanding ELF
shape check.

Three independent QA reviewers found no confirmed implementation bugs.
Additional adversarial checks covered intermediate allocation failures,
unchanged PTE snapshots on failure, raw reserved entries, table boundaries,
alias-page quota exhaustion, backing pinning and cleanup. Host walkers use
substituted allocation/translation support; QEMU provides separate evidence
for actual local translation and userspace access.

A physical x86-64 boot on the 32 GiB MSI workstation reached all three mapping
markers with the pre-bump 0.2.11 banner and 31.46 GiB managed RAM. Dedicated
RO-write/NX-execute fault probes remain QEMU-validated. There has been no
physical RISC-V validation. Hosted Actions results remain separate from local
evidence.

The kernel and UEFI loader advance to 0.2.12 without dependency upgrades.
This remains a prerelease; 0.3.0 stays reserved. Executable publication,
protection changes, partial unmap, userspace task creation and hierarchical
Job charging remain pending. Execution remains cooperative, integer-only and
single-CPU with interrupts masked. Content locks do not serialize mapped
writers, and mapped-writer, DMA, interrupt-reentrancy and SMP safety remain
outside this release's guarantees.

Uranium-238-v0.2.11

Userspace can create, read and write owned-RAM VMOs through capability handles. Byte copies validate complete ranges and stage their data; allocation charges survive aliases, transfer and queued ownership. Two isolated processes verify shared backing and read-only enforcement. Uranium-238 still decays; closing a handle is not a half-life.

Three syscalls expose fresh memory without physical authority

Syscall 11 creates a zeroed VMO and returns its handle. Calls 12 and 13 read
and write exact byte ranges, returning zero only after complete success.
Logical size remains distinct from page-rounded backing. Creation accepts
1 byte through 16 MiB; each copy is bounded to 64 KiB. Options must be zero,
and physical/MMIO VMOs are excluded from this byte ABI.

Created capabilities receive READ, WRITE, DUPLICATE, TRANSFER, INSPECT and
MANAGE. They receive no MAP or EXECUTE authority. Existing handle operations,
attenuation, subtree revocation and channel move semantics continue to apply.
The concrete VMO object remains shared by aliases and derived capabilities;
generic inspection retains its existing type/rights format.

Copies stage before committing and charges follow backing

A per-object content lock serializes kernel byte operations while size and
frame ownership remain immutable. Complete logical ranges, frame aliases and
user mappings are validated before a fallible heap staging buffer is used.
Writes snapshot the user source before changing backing; reads snapshot the
VMO before changing user output. Physical overlap is handled without violating
nonoverlapping-copy contracts. Contradictory physical aliases within a read
output are rejected using the shared channel-output validator.

Returned validation and allocation errors leave destinations unchanged.
Unpublished creation failures unwind frames, object/node ownership and budget
charges. Final ownership is destroyed after process, table and content guards
are released. These guarantees depend on stable mappings; they are not atomic
visibility guarantees against future mapped writers or other CPUs.

User-created backing is charged in pages against the smaller of 64 MiB and
one quarter of managed pages. The reservation belongs to the VMO until final
backing destruction. Duplication, derivation, transfer, queued messages and
creator exit neither recharge nor prematurely release it. Kernel-created
VMOs remain uncharged. This is a global bound on the new allocation surface,
not enforced hierarchical Job quotas or reserved kernel headroom. The roadmap
now distinguishes existing Job policy fields from implemented accounting.

The external fixture proves sharing across processes

The separate userspace-vmo-probe configuration loads a producer and consumer
from an independently compiled Rust ELF. The producer checks zeroing, bounds
and errors, duplicates and derives a read-only child, then transfers it through
a channel. The consumer reads the bytes and cannot write through that child.
A producer update remains visible after the producer closes its owner and
exits; the consumer then releases final ownership.

Kernel evidence requires successful VMO, capability and channel operations,
two clean exits and no leaked handles. A warmup and three measured batches
restore frame, node, process, scheduler and user-budget baselines. The required
markers are memory_verification, vmo_syscalls and boot_payload, each with
the [FERBER_TEST] prefix and PASS result. The published release ISO continues
to select minimal init; VMO_PROBE=1 builds the dedicated verification ISO.
Startup ABI v1 and init's START/READY protocol are unchanged.

Validation covers boundaries, failures and physical execution

Local validation passed all 29 RISC-V and 25 x86 UEFI smoke cases, plus the
final release VMO ISO boot through OVMF. All 64 host tests passed: 17 memory,
12 channel, 15 ELF parser, seven loader/startup, eight UEFI payload, two init
protocol, two VMO core and one production VMO syscall allocation test.
Both kernel targets passed default and VMO-feature Clippy with warnings
denied; shell syntax and strict log-parser self-checks passed.

Release preflight repeated all 64 host tests, minimal-init and VMO-feature
Clippy on both kernel targets, release UEFI Clippy, shell/parser checks and a
freshly built 0.2.11 minimal-init release ISO boot through OVMF. The release
ELF shape check passed.

Three independent QA reviewers found no confirmed implementation bugs.
Additional adversarial checks covered byte-copy boundaries, output-alias
validation, every intermediate frame-allocation failure, final-owner release
and queued revoked descendants. One consolidated error-table documentation
finding was fixed and rechecked. Host harnesses substitute allocation or
translation where required; those results do not replace hardware execution.

A physical x86-64 boot on the 32 GiB MSI workstation reached all three VMO
markers with the pre-bump 0.2.10 banner. That demonstrates the two-process
exchange, denied read-only write, shared updates and repeated reclamation and
budget checks. Hosted Actions results remain separate from local evidence.

The kernel and UEFI loader advance to 0.2.11 without dependency upgrades.
This remains a prerelease; 0.3.0 stays reserved. User mapping/unmapping,
executable publication/sealing and hierarchical Job charging remain pending.
Execution remains cooperative, integer-only and single-CPU with interrupts
masked. Content locks do not establish mapped-writer, DMA, interrupt-reentrancy
or SMP safety, and minimal init still has no service-launching event loop.

Uranium-238-v0.2.10

Ferber boots minimal Ferrum init as a separately delivered Rust executable. Init discovers its delegated bootstrap channel, completes startup and remains alive in a validated blocking receive. The scheduler still diagnoses ordinary cooperative deadlock. Uranium-238 now waits deliberately; it has no services to launch yet.

Init owns a defined startup protocol

The release ISO now carries userspace/init/ as BOOT.ELF. RISC-V receives the
same independently built program through its initrd path. Shared userspace
entry, syscall and linker support serves both init and the retained finite ELF
fixture. Kernel compilation still embeds no executable.

Startup ABI v1 and BootInfo v3 remain unchanged. The process is born with an
empty handle table, then receives one explicitly delegated READ | WRITE | WAIT
channel before admission. Its assigned handle comes from the startup record;
no slot number is an ABI. Init receives no job, namespace, device or process
creation authority.

A separate versioned 16-byte bootstrap protocol exchanges START and READY.
Both sides validate exact length, magic, version, opcode, reserved zero fields
and absence of transferred handles. Init then blocks on the same endpoint.
Malformed input, closure and unsupported subsequent messages cause failure.
Named ELF admission returns numeric process/thread identities while preserving
rollback on construction or admission failure. No new syscalls are introduced.

A live init wait is distinct from cooperative deadlock

The kernel accepts terminal waiting only when init is the sole live task and
has sent exactly one valid READY reply. Its pending receive must match the
expected slot, capability node, channel pair, opposite endpoint side and actual
registered wait token. Rights, current generation, notification state and
cancellation errors are checked. Unexpected queued traffic prevents success.
An open peer or a task named init cannot waive these checks.

Validation runs on the permanent-root dispatcher stack outside locks. The
kernel retains its bootstrap peer and init's live resources through terminal
halt. Ordinary scheduler runs retain the exact diagnostic
cooperative deadlock: live tasks with no runnable producer. Unexpected init
exit is diagnosed after safe dispatcher reclamation rather than freeing an
executing stack. Existing cancellation and wait reconciliation remain active.

Every init boot first exercises the same executable through private
close-after-park runs: close the kernel peer, resume the blocked task, observe
its failure exit and reap it. A warmup and measured repetition restore frame,
capability-node and root-job process baselines before admitting the final live
instance. Final init resources intentionally remain owned.

Verification covers successful waiting and rejected startup

Successful boots require [FERBER_TEST] markers for memory_verification,
boot_payload, init_ready and init_waiting. The last marker requires the
actual suspended receive; READY alone cannot satisfy it. Separate adversarial
executables exercise malformed readiness, closure, premature exit and waiting
on an unrelated channel without adding test commands to production init.
Strict log parsers reject contradictory, duplicate and truncated evidence.

Local validation passed 26 RISC-V cases and 23 x86 UEFI cases across main and focused
runs, plus the release init ISO. Final focused validation after
wait-registration strengthening passed RISC-V debug at 256 MiB/four harts and
the x86 release init ISO. All 61 host tests passed: 17 memory, 12 channel,
15 ELF parser, seven loader/startup, eight UEFI payload and two init protocol.
Both minimal-init kernel Clippy checks passed with -D warnings; default
RISC-V and x86 ELF checks, shell syntax and log-parser self-checks passed.
Three independent adversarial QA reviews reported no confirmed bugs.

A physical x86-64 boot on the 32 GiB MSI workstation reached all four required
markers with the pre-bump 0.2.9 banner. The prerequisite close/resume/reclaim
checks therefore also completed. Hosted Actions results remain separate from
local validation.

The kernel and UEFI loader advance to 0.2.10 without dependency upgrades.
This remains a prerelease; 0.3.0 stays reserved. Execution is cooperative,
integer-only and single-CPU with interrupts masked. Terminal waiting has no
interrupt-driven event source or startup deadline. Init does not yet launch
services; userspace task creation, event-driven idle and a shell remain ahead.

Full Changelog: Uranium-238-v0.2.9...Uranium-238-v0.2.10

Uranium-238-v0.2.9

The userspace Rust ELF now arrives separately from the kernel. RISC-V receives it through the device tree; UEFI reads BOOT.ELF beside the kernel. Both execute the existing startup and bootstrap-channel protocol, then verify reclamation. Uranium-238 remains unstable. The executable no longer needs to be embedded to participate.

Boot delivery no longer depends on kernel compilation

The opt-in ELF path accepts one raw static ELF of 1 byte through 4 MiB.
BootInfo v3 appends a shared descriptor containing the exact byte length,
physical source address and permanent virtual alias. RISC-V validates paired
four- or eight-byte /chosen/linux,initrd-start and linux,initrd-end
properties. UEFI optionally reads \BOOT.ELF into dedicated, zero-padded
LoaderData pages before its final memory-map handoff.

Kernel builds no longer embed the fixture or require its build-time path.
The Makefile, ESP and ISO packagers, smoke scripts and release workflow build
and deliver the executable separately. Resident builds permit absence; the
ELF path diagnoses missing or invalid payloads before task admission. Startup
ABI v1 and the bootstrap protocol remain unchanged.

Reserved source pages have a checked supervisor mapping

Discovery reserves the complete page-rounded source before allocator metadata
or bootstrap tables can claim it. The permanent source alias is supervisor
RO/NX, excluded from ordinary writable RAM aliases. Runtime checks validate
each source page before publication. A retained physical VMO describes the
backing without clearing or freeing it. ELF loading copies into fresh owned
segment VMOs; repeated process teardown restores the ordinary accounting
baselines while source pages remain reserved for the boot lifetime.

Bounds, supported address widths, reported RAM coverage and explicit reserved
ranges are checked. Firmware RAM descriptions remain trusted; RISC-V does
not independently audit every device node for overlapping MMIO. This is not
verified boot, an archive format, an initramfs, or service-launching init.

Adversarial review tightened mapping and failure paths

Three independent QA reviews found and drove fixes for high physical UEFI
addresses clobbering unrelated virtual mappings, payload allocation leaks on
later pre-ExitBootServices failures, and negative-test logs accepting unrelated
failure lines. Focused regressions cover those cases. UEFI cleanup does not
call firmware after an ExitBootServices attempt.

Smoke tests replace the external image with missing, malformed and valid
early-exit payloads while checking that the kernel binary remains unchanged.
Successful execution requires [FERBER_TEST] boot_payload: PASS after the
existing ELF protocol and reclamation checks; discovery alone cannot pass.

Validation covers both ports and physical x86 execution

The full local QEMU matrices passed 17 RISC-V and 15 x86 UEFI cases before
the final QA fixes. Focused post-fix validation passed the RISC-V debug
external-ELF boot at 256 MiB/four harts and the x86 release ELF ISO boot.
The normal release ISO also passed during QA. Host suites passed 17 memory,
eight UEFI payload, 15 ELF parser and seven loader/startup tests. ELF kernel
Clippy checks on both targets and release UEFI Clippy passed with
-D warnings; smoke-log self-checks passed.

A physical x86-64 boot on the 32 GiB MSI workstation showed all four markers:
memory_verification, userspace_elf, userspace_bootstrap_channel, and
boot_payload. That run used the pre-bump 0.2.8 banner. It demonstrated
execution of the separately delivered ELF and completion of its protocol.
Hosted GitHub Actions results are separate from this local evidence.

The kernel and UEFI loader advance to 0.2.9 without dependency upgrades.
This remains a prerelease; 0.3.0 is reserved. Execution remains cooperative,
integer-only and single-CPU, with interrupts disabled. Init, service launch
and userspace task creation remain pending.

Uranium-238-v0.2.8

Startup ABI v1 places a 32-byte versioned little-endian record at the ELF fixture's initial stack pointer. Shared no_std Rust code decodes it, discovers the explicitly delegated bootstrap channel in a nonzero handle slot, receives the prequeued challenge, sends the reply, closes the handle, yields, and exits. The existing protocol order remains unchanged on both architectures. Uranium-238's half-life is longer than this protocol's lifetime.

The startup record describes a test process without granting authority

Processes are still created with empty handle tables. The ELF loader can
explicitly install a single READ | WRITE bootstrap channel before scheduler
admission and writes the assigned handle number into a fixed 32-byte record at
initial SP. The shared ABI uses fixed-width little-endian fields, a magic,
version, size, presence flag, and zeroed reserved bytes. It rejects malformed
lengths, versions, flags, reserved values, and inconsistent absent handles.
Handle zero remains representable; the test deliberately uses slot 7 to prove
that startup code discovers the handle from the record.

The process keeps its full stack mapping and guard page. Only initial SP points
at the record near the top of the 16 KiB stack. Explicit stack-pointer bounds
and alignment are validated independently of the stack mapping extent, so
teardown still releases the full stack. Loader setup and scheduler-admission
failures unwind the process, mappings, stack, and delegated capability.

Shared Rust preserves the Checkpoint B contract

The ELF fixture is now a shared integer-only no_std Rust program with small
architecture entry and syscall shims. RISC-V userspace builds for
riscv64imac-unknown-none-elf and LP64 because the scheduler does not preserve
user FP state; the kernel remains riscv64gc-unknown-none-elf. x86-64 retains
its freestanding target. The shared code validates the startup record and
channel handle, then runs the existing sequence: unknown syscall, receive,
send, close, yield, and exit. Kernel-side response verification and cleanup
checks remain in place. Initialized data, BSS, register, and stack preservation
checks remain part of the fixture.

This does not define init's production ABI, launch services, or add argc,
argv, environment, auxiliary-vector, or task-creation support. The ELF image
is still embedded for opt-in test builds. Startup pointer failure paths remain
fatal under the current user-fault policy; host parser tests do not execute the
kernel panic path or emulate a malformed boot record fault.

Local validation covers both architectures and the ELF ISO

Host suites pass 43 tests: 15 ELF parser, seven loader/startup, nine memory,
and 12 channel tests. A separate red-team mutation run checks 65,536 startup
record mutations. QEMU passes all 27 boots: 13 RISC-V cases, 12 x86 UEFI
cases, and normal plus ELF release-ISO boots. Kernel base and ELF-probe Clippy
checks pass with -D warnings on both targets; both separately compiled user
fixtures pass debug and release warning-free builds. Script self-tests and
syntax checks pass. Hosted GitHub Actions is not claimed as locally run.

A physical x86-64 boot on the MSI workstation showed
memory_verification, userspace_elf, and userspace_bootstrap_channel pass
markers on the ELF path. The boot banner reported 0.2.7, before this version
bump. No physical RISC-V run is claimed.

The kernel and UEFI loader advance to 0.2.8 without dependency upgrades.
This remains a prerelease. Version 0.3.0 is reserved for the next milestone.

Full Changelog: Uranium-238-v0.2.7...Uranium-238-v0.2.8

Uranium-238-v0.2.7

Checkpoint B gives the static ELF fixture one explicitly delegated channel endpoint after process creation and before scheduler admission. The handle table is empty at birth; the fixture receives a prequeued challenge through the existing nonblocking syscall, returns a reply, closes its handle, and exits. The kernel verifies the reply and cleanup on RISC-V 64 and x86-64. This is test startup plumbing, not init's production ABI. Uranium's half-life is long. This protocol is deliberately not.

The test fixture proves delegation follows empty-at-birth

The process is constructed with an empty handle table. Checkpoint B then
installs one bootstrap channel endpoint in slot 0 with READ | WRITE rights
before scheduler admission. The kernel prequeues a challenge. Independently
linked RISC-V and x86-64 fixtures receive it through the existing nonblocking
channel receive syscall, send a reply through the existing nonblocking send
syscall, close the delegated handle, and exit. The kernel checks the exact
reply and confirms task, handle, and scheduler cleanup before emitting
[FERBER_TEST] userspace_bootstrap_channel: PASS.

No syscall numbers or production service tasks are added. Slot 0 and this
challenge/reply exchange belong only to the test ABI. Init startup, argument
and environment setup, and a production bootstrap service protocol remain
future work.

Checkpoint A remains the same bounded static loader

ELF64 ET_EXEC validation, VMO-backed load segments, strict page permissions,
zeroed BSS, guarded 16 KiB user stack, scheduler admission, and repeated
reclamation remain in place. Checkpoint A continues to leave the handle table
empty. Checkpoint B uses the same validation and loader, then delegates the
endpoint explicitly before the task can run.

Local validation covers both fixtures and the release image

All 41 host tests pass: 15 ELF parser, five loader, nine memory, and 12
channel tests. All 27 QEMU/ISO boots pass: 13 RISC-V cases, 12 x86 UEFI cases,
and both normal and ELF release-ISO boots. The ELF ISO smoke checks the actual
release packaging path. Kernel and probe Clippy checks pass with -D warnings
for both targets; release UEFI Clippy and x86 ELF checks pass as well. Hosted
GitHub Actions is not claimed as locally run.

The maintainer booted the ELF build on physical x86-64 hardware. The
userspace_elf and userspace_bootstrap_channel markers passed. No physical
RISC-V run is claimed. The boot preceded the version metadata bump.

The kernel and UEFI loader advance to 0.2.7 without dependency upgrades.
The release workflow publishes the opt-in ELF checkpoint ISO as ferber.iso.
It remains a prerelease. Version 0.3.0 is reserved for the next milestone.