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.

Uranium-238-v0.2.6

Ferber can load a separately compiled static ELF into a fresh zero-handle process on RISC-V 64 and x86-64. The opt-in checkpoint validates the image, builds VMO-backed segments and a guarded stack, then runs it through the existing cooperative scheduler. A physical x86-64 boot reached the userspace ELF verification marker. Init and production image delivery remain ahead.

Static image validation happens before task construction

Checkpoint A accepts ELF64 little-endian ET_EXEC images for the exact target
architecture. It bounds input size, header counts, segment count, and mapped
memory before allocating process resources. Checked ranges reject truncated
tables, overflowing addresses, invalid alignment, page-zero mappings, overlapping
rounded segments, and entries outside file-backed executable bytes.

Load segments permit only R-X, R--, or RW- user mappings. Writable-executable
and execute-only segments are rejected. The parser rejects dynamic linking,
interpreters, PIE images, TLS, relocation sections, executable stacks, and
unsupported program-header requirements. Accepted ABI flags do not validate
the image's instructions; execution remains integer-only.

Limits are 4 MiB of file data, 32 program headers, 16 load segments, 16 MiB of
page-rounded segment memory, and 256 section headers. The stack and its guard
have a reserved range that load segments cannot overlap. The complete contract
is documented in the ELF loading specification.

The process owns every loaded segment

Each segment receives a separate zeroed VMO. The loader copies file bytes at
their in-page offset and leaves BSS and page tails zero. Process ownership
retains those VMOs until teardown; page tables do not own leaf frames.

The kernel creates the process under the root Job and allocates a separate
16 KiB RW/NX user stack with an unmapped guard page below it. Initial SP is
the aligned stack top. No arguments, environment, auxiliary vector, return
address, or bootstrap channel are installed. The handle table starts and
remains empty for this fixture.

Construction completes before scheduler admission. Failed setup kills and
detaches the partial process. Process/thread allocation and ownership-slot
reservation use fallible paths. A thread now retains its own ELF entry PC;
the scheduler no longer assumes every user task enters the resident probe's
fixed code address. Existing yield and exit syscalls handle the loaded task;
no syscall numbers are added.

An independently linked fixture checks execution and reclamation

The fixture is built separately for each architecture with its own linker
script, entry at 0x400000, and separate text, read-only data, and writable
data segments. The kernel embeds the resulting file through FERBER_USER_ELF.
This is a test-delivery mechanism; BootInfo version 2 and firmware handoff
remain unchanged.

The program checks initialized data, multi-page zeroed BSS, writable data,
stack alignment, unknown-syscall return, cooperative yield with preserved
register/stack/data state, and successful exit. One warmup and three measured
executions must restore frame, capability-node, and root-Job process counts
and leave the scheduler empty before the harness prints:

[FERBER_TEST] userspace_elf: PASS

The ELF scenario also requires memory_verification: PASS. It runs instead
of the resident userspace suite and does not establish handle/channel probe
coverage or recoverable user-fault isolation.

The physical marker covers the opted-in fixture path

The maintainer supplied a physical x86-64 boot screenshot showing
[FERBER_TEST] USERSPACE_ELF: PASS. That marker follows successful fixture
loading, execution, syscall checks, and repeated reclamation checks. It does
not establish arbitrary executable compatibility, init startup, dynamic
linking, or physical RISC-V support.

All 40 local host tests passed: 15 parser, four loader, nine memory, and 12
channel tests. All 27 local QEMU/ISO boots passed: 13 RISC-V cases, 12 x86 UEFI
cases, and both normal and ELF release-ISO paths. The kernel targets and probe
configurations, including the independently compiled ELF fixtures, passed Clippy
with -D warnings; release UEFI Clippy and x86 ELF checks also passed. These
are local validation results; no hosted CI run is claimed.

Host regression suites cover malformed images and bounded parser behavior,
plus production loader construction against fallible model resources. Loader
checks include copied bytes, zeroing, permissions, guard collisions, partial
mapping failure, and scheduler-admission rollback. The model does not exercise
physical allocation, hardware page tables, or context switching. The physical
boot preceded the version metadata bump.

The release ISO runs the ELF checkpoint

Enable the fixture with userspace-elf-probe and an absolute FERBER_USER_ELF
path. make x86-iso USERSPACE_ELF_PROBE=1 produces an ELF-test ISO. The release
workflow also builds this feature and publishes it as ferber.iso, with no
emulator debug-port feature enabled. Ordinary builds and make x86-iso without
the option retain the resident probes. Both kernel and loader versions advance
to 0.2.6 without dependency upgrades.

Execution remains cooperative on one active CPU with interrupts disabled.
Init, bootstrap-channel delegation, startup arguments, reserved boot payloads,
userspace task-creation APIs, VMO and FastCall syscalls, preemption, SMP,
FP/vector state, concurrent unmapping, and recoverable user faults remain
future work. An unexpected user fault still follows the fatal kernel path.

Uranium-238-v0.2.5

Resident user tasks now yield to one another, wait for channel messages, and exit without halting surviving tasks on RISC-V 64 and x86-64. A permanent-root dispatcher reclaims exited task resources after leaving their stacks and address spaces. The new scheduling, blocking-receive, and reclamation markers have been confirmed on physical x86-64 hardware. Uranium remains cooperative.

Yield lets another resident task run

Syscall 0 now yields cooperatively and returns zero when the calling task
resumes. With no other runnable task, it resumes itself. Syscall 1 retires
the calling thread without returning; surviving tasks continue running.

The dispatcher uses the existing callee-saved CPU contexts, VMO-backed kernel
stacks, and per-task trap/syscall frames. It selects each task's address space
and trusted kernel-entry stack before returning to userspace. Both architectures
run the same resident scheduling contract. x86-64 also disables user FSGSBASE
instructions and traps FP/SIMD use to prevent unsaved state crossing task
boundaries. Protection keys are disabled because PKRU is not task state yet.
FP/vector execution remains unsupported.

The ready queue remains a VecDeque. Scheduling runs on one active CPU with
interrupts disabled. Tasks must yield, block, or exit before another task runs;
this release adds no timer preemption or SMP execution.

Blocking receive retains the caller's original authority

Syscall 10 receives with the same six arguments and transactional output
rules as nonblocking receive (9). It requires both READ and WAIT, even
when a message is already queued. Newly created channel endpoints include
WAIT; send remains nonblocking.

An empty open queue parks the caller. Message arrival or final peer closure
makes it runnable, and readiness is rechecked before delivery. Another
receiver may consume the message first, causing the caller to wait again.
There is no timeout.

A suspended call retains its original capability identity. Closing its source
slot cancels the call with -9; reusing that numeric slot cannot redirect it.
Revoking its node or an ancestor cancels it with -116. The dispatcher checks
waits at cooperative boundaries and revalidates authority before delivery.
Cancellation leaves output buffers and queued messages unchanged. Revocation
alone does not close an endpoint; closure still follows its final backing owner.

Reclamation happens after leaving the exited task

The dispatcher runs on a retained VMO-backed stack under the permanent kernel
root. It detaches exited threads and last-thread processes, then drops their
resources outside scheduler, process, handle-table, and channel locks. It can
therefore release stacks, address spaces, handles, and endpoint backing without
freeing the stack or page tables currently executing the cleanup.

Repeated resident runs check restored physical-frame and capability-node
baselines and an empty scheduler registry. The harness halts after all tasks
exit and verification completes. If live tasks are all blocked without a
runnable producer, it reports a deadlock instead of success.

Normal boots now require eight verification markers with the [FERBER_TEST]
prefix: memory_verification, privilege_switch_roundtrip, handle_syscalls,
capability_mutation, channel_syscalls, cooperative_scheduling,
blocking_channel_receive, and task_reclamation, each ending in : PASS.

Validation includes a new physical x86-64 boot

I booted the sprint ISO on physical x86-64 hardware with 32 GiB installed. The
screenshot shows all eight verification markers passing, followed by the
intended clean halt. This validates the normal resident path.
That boot preceded the final CR4.PKE hardening and version metadata bump; the
final CPU-state setup was checked in QEMU. No physical RISC-V run or physical
fault/deadlock probe is claimed.

All 11 final-tree RISC-V smoke cases, all 10 x86 UEFI smoke cases, and the
release ISO smoke passed locally: 22 cases total. RISC-V covers debug/release
normal boots at 128 MiB/1 hart and 256 MiB/4 harts, debug/release supervisor
read, RX-write, and NX-execute probes, and debug deadlock. x86 covers debug
normal at 512 MiB, release normal at 1024 MiB, release invalid-opcode at
512 MiB, debug/release supervisor-read, RX-write, and NX-execute at 512 MiB,
and debug deadlock at 512 MiB. The separate ISO case boots the release image
through UEFI.

The separate debug cooperative-deadlock-probe requires the exact diagnostic
cooperative deadlock: live tasks with no runnable producer and rejects the
three cooperative success markers. A timeout or unrelated panic cannot pass
this scenario. The configured smoke suites contain 11 RISC-V cases, 10 x86
UEFI cases, and one release ISO case.

Both kernel targets and their CI probe configurations, including the deadlock
probe, passed Clippy with -D warnings; release UEFI Clippy also passed.
Debug/release x86 ELF checks, 12 channel host tests, and nine memory host tests
passed. These are local results. No hosted CI run is claimed.

Both kernel and loader versions advance to 0.2.5 without dependency upgrades.
The release asset remains ferber.iso.

General userspace and preemption remain future work

The scheduler currently runs kernel-created resident tasks. ELF loading, init,
userspace task creation, VMO and
FastCall syscalls, interrupt-driven wakeup, timer preemption, SMP, FP/vector
state, and concurrent unmapping remain pending. Graph-owning capability
transfer remains rejected until its lifetime policy is defined. Reclamation
guarantees cover the resident task lifecycle exercised here.

Full Changelog: Uranium-238-v0.2.4...Uranium-238-v0.2.5

Uranium-238-v0.2.4

Userspace can create paired channel endpoints, send bounded messages, and receive messages with explicitly transferred capabilities on RISC-V 64 and x86-64. Failed sends preserve sender handles; failed receives preserve the queued message and user outputs. The original v0.2.4 build's channel syscall probe passed on physical x86-64 hardware with 32 GiB installed. One CPU still does all the work. Uranium has time.

Ferber was previously called Wolfram. This re-release rebuilds v0.2.4 with the
Ferber project, kernel, loader, and ISO names. Kernel behavior is unchanged;
physical-hardware evidence below belongs to the original build.

Nonblocking channel syscalls cross the userspace boundary

Syscalls 7, 8, and 9 create endpoint pairs, send messages, and receive messages.
Both architectures use the same ABI, with little-endian handle and count fields.
Messages remain bounded to 64 KiB and 64 transferred handles; each endpoint
queue holds at most 64 messages. Calls return immediately when a queue is empty
or full.

Sending requires WRITE on the endpoint and TRANSFER on every payload
capability. Receiving requires READ. Payloads are accepted only when both
their capability type and concrete object backing identify a VMO or the current
leaf Resource object. Graph-owning objects remain excluded until their transfer
semantics prevent ownership cycles.

Create, send, and receive validate all affected user memory and handle-table
state before committing. A rejected send leaves source slots intact. A rejected
receive leaves the queued message, handle table, and output buffers intact,
including when output ranges alias the same physical memory. Queued messages
drain before peer closure is reported.

Shared channel state removes opposite-send lock inversion

Each endpoint pair now uses one lock for both queues and endpoint liveness.
Sending no longer locks the peer endpoint, so opposite-direction sends do not
acquire endpoint locks in reverse order. Endpoint destruction detaches queued
messages while locked and drops their owned references after unlocking.

Discarding a message releases its capability references without revoking nodes,
aliases, or descendants. Explicit revocation remains controlled by MANAGE.
Channel and task capabilities are rejected as message payloads until the kernel
has a complete policy for graph ownership and cycles.

Memory verification follows the detected map

The fixed 4 GiB threshold, dedicated high-frame capacity feature, and special
8 GiB smoke cases are removed. Verification now follows detected extent
boundaries and exercises ordinary VMO allocation, mapping, copies, unmapping,
and accounting regardless of RAM size. It checks representative boundaries;
it does not write across every physical frame.

The roadmap also places initramfs and bootstrap loading in Phase 3, an initial
userspace on-disk filesystem after block-device support in Phase 4, and native
NVMe plus the capability-native filesystem in Phase 6. The disk format and
write/crash-consistency contract remain future decisions.

Validation includes emulators and physical x86-64

All 20 QEMU boot cases pass: 10 RISC-V, 9 x86 UEFI, and one release ISO boot.
The three channel host tests and nine memory host tests pass. Both kernel
targets, probe configurations, and the UEFI loader pass Clippy with
-D warnings. Smoke-log parser checks, shell syntax checks, and debug/release
x86 ELF validation pass.

The original Wolfram-branded v0.2.4 ISO was booted on physical x86-64 hardware
with 32 GiB installed. Firmware memory discovery reported 31.46 GiB managed
across 23 extents. Memory verification, privilege switching, handle syscalls,
capability mutation, and channel syscalls all passed before the kernel halted as
designed. No physical RISC-V run is claimed. Hosted CI is the remaining
post-push check.

Scheduling and general capability graphs remain unfinished

The kernel still runs one active CPU and one resident task. Blocking receive,
scheduler integration, general transfer of graph-owning objects, IRQ-safe
allocation, and SMP-safe locking remain future work. The memory verification
walks the detected map's boundaries and uses owned backing; it does not perform
an exhaustive destructive test of installed RAM.