Three tightly-coupled changes, verified together per Captain Bob's own
"getting rid of the emergency cli" direction:
1. Zuse's identity is thumbdrive-resident, never system-resident. New
zuse_genesis_marker_t (magic/version/zuse_pubkey[32]/crc) replaces
zuse_cert_devblock_t's slot in the top-of-device fence -- the system
now remembers only that a root identity exists and its pubkey, never
a seed. zuse_cert_devblock_t is kept in the repo, marked superseded,
no longer written by any code path.
capsule_mint_identity() grows a genesis mode (issuer_vm=NULL): no
cert is built or written (Zuse isn't verified against a separate
signer -- she's recognized by pubkey match against the marker) and
two new optional out-params (out_pubkey/out_seed) let the caller
install the cert immediately after a genesis mint.
New capsule_zuse_boot_try_attach() (capsule_zuse_boot.c), called
from sk_repl_idle() on every fresh USB attach (the only point in the
boot lifecycle a thumbdrive can actually be detected -- attach
polling doesn't exist yet at kernel_main.c's old one-shot mint point,
which is why that whole block is gone): no marker + blank drive ->
genesis-mint; marker present + matching drive -> read its own
user_identity_seed_t, install the cert. Either way, re-runs
ACL-ZUSE-BOOT (zuse.4th) so zuse_session activates exactly like it
always has for a same-boot cert install -- ACL-PIN only blocks
redefinition, not re-execution, so no new C-side auth logic needed.
2. ACL.4th activated (capsules/init.4th) -- inactive all session until
now. Found and fixed a real bug this immediately surfaced: zuse.4th's
ACL-ZUSE-BOOT tried `['] ACL-ZUSE-BOOT ACL-PIN` from inside its own
still-compiling definition -- the word isn't findable yet at that
point, so the whole definition silently failed to compile every
previous boot this session (dormant, since ACL.4th never loaded).
Fixed: pin after the definition closes, not from within it -- it
only needs to happen once anyway, and pinning doesn't block the
re-invocation genesis/attach needs.
3. The unauthenticated emergency-CLI ACL bypass is retired
(repl.c): `emergency_console = is_hera ? (zuse_session ? 0 : 1) : 0`
deleted from both sk_repl_step and sk_repl_run. Every word run from
Hera's own bare prompt now goes through ordinary ACL enforcement;
emergency_console is driven only by the genuine C-level fault
handler again.
Added ZUSE-SESSION? (starforth_words.c), a read-only diagnostic
matching ZUSE-PUBKEY@'s own precedent, to verify the whole chain
directly rather than by inference.
Verified end-to-end live in QEMU: fresh boot, no thumbdrive ->
ZUSE-SESSION? reads 0. Attach a genuinely blank drive via QMP -> genesis
mint fires automatically (no typing) -> ZUSE-SESSION? reads -1 (true).
Hermes/Artemis both birth clean on all three architectures with ACL
now actually enforced for the first time all session -- no denials, no
UNKNOWN WORD beyond the deliberate POST self-test cases.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ZGkimpfyh63EZyRkNbkPD
Cert storage expanded from the old 16-byte placeholder to a real
32-byte seed + 32-byte pubkey. vm_zuse_cert_install() now has a
kernel-side duplicate in src/starkernel/vm/vm_core.c -- the kernel
build's VM_EXCLUDE list drops src/vm.c entirely (same reason
vm_set_base() already has two independent copies), so the hosted-only
version added earlier this session was never actually linked into the
kernel. FORTH-side ZUSE-CERT-LO@/HI@ replaced with ZUSE-PUBKEY@ (i -- u)
over the public half only; ACL-ZUSE-BOOT now checks
ZUSE-CERT-INSTALLED? before authenticating instead of unconditionally.
Attempted NVRAM-based persistence (GetVariable/SetVariable) for the
first-boot mint flow: page-faulted inside OVMF's variable service
(CR2 in the flash MMIO window). Moving the call site to match the one
proven-safe existing SetVariable call site in this codebase produced
the identical crash -- not a timing issue. Localized with debug
markers (one boot): GetVariable works; SetVariable with real data
never returns. The existing "working" precedent call is actually a
delete-of-nonexistent-variable (size=0, data=NULL), a cheaper path
that never touches flash, so it proved nothing about real writes.
Root cause: this kernel's VMM never maps the region OVMF's variable
service needs for real flash writes -- a genuine gap in UEFI runtime-
services support, not Zuse-specific, and not obviously fixable in a
3-arch-uniform way (flash window location is firmware/arch-specific).
Independently, storing the raw seed in RUNTIME_ACCESS NVRAM would have
been a real security defect regardless of the crash -- readable by any
later-loaded UEFI app or the booted OS.
Reverted to a known-safe state: all NVRAM/mint code removed from
kernel_main.c, init.4th's ACL.4th line back to its documented
commented-out default. Verified clean compile and clean boot on all
three architectures. Cert storage expansion (the part that works)
stays. A dedicated system-identity disk (virtio-blk, already proven
for writes via Artemis) is the recommended next substrate -- not yet
decided or built. Full investigation documented in FABRIC-3.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U14ET9CWAtbQMbYqomKgXd
Found that a pinned CONSTANT is not actually tamper-proof: ACL-PIN only
blocks redefinition, not a >BODY-then-store on the word's existing data
field. Moves the Zuse cert value into C-only VM struct fields
(zuse_cert_lo/hi + zuse_cert_installed fuse bit) with a one-time
vm_zuse_cert_install() and read-only ZUSE-CERT-LO@/HI@/INSTALLED? FORTH
accessors, closing the tamper path structurally instead of by convention.
Deletes the now-insecure ZUSE-CERT-LO/HI CONSTANT words from zuse.4th.
vm_zuse_cert_install() has no caller yet -- the real mint flow (Milestone
6 CA, the MINT word) is still open; this is storage + accessors only, not
a stand-in mint. Documented in FABRIC-3.md. Verified: hosted build clean,
mkcapsule --lint clean (31/31), clean boot to ok> on amd64/aarch64/riscv64
with Stadium conservation intact and no panics.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U14ET9CWAtbQMbYqomKgXd
find and fix the real ACL-TTL measurement bug (zuse session never
authenticated, ACL enforcement never active)
Two mistakes corrected in sequence, both documented in full in
FABRIC-2.md Section R:
1. HEARTBEAT-TICKS@ was swapped to read heartbeat_ticks() -- a newer,
kernel-only ISR hardware-timer counter (src/starkernel/heartbeat.c,
the M5 TIME-TRUST engine) -- based on a misreading of which counter
"the one clock" law refers to. Reverted to vm->heartbeat.tick_count,
Loop #7 "Adaptive Heartrate", the actual year-plus-old counter the
whole physics runtime is built on. Removed the now-irrelevant
HEARTBEAT-PERIOD-NS@ accessor added to diagnose the wrong counter's
adaptive re-arm period. Three-arch QEMU re-acceptance: POST 1012/0/0
on amd64/aarch64/riscv64, HEARTBEAT-TICKS@ confirmed returning 77
(matching the original pre-heartbeat_ticks() acceptance) on all three.
2. The real bug, found after the revert: every "ACL enabled" measurement
in this investigation (Section P's 18-cell campaign, Section Q's
pilot) loaded ACL.4th and ran EXEC-DOE from the bare `ok>` prompt
without ever authenticating a zuse session. repl.c:303 keeps
emergency_console=1 until zuse_session=1; vm_core.c:755 skips the
entire ACL check block (TTL decrement and acl_recheck()) whenever
emergency_console is set. ACL was configured but never armed.
capsules/zuse.4th's pre-existing self-pin bug means the documented
automatic zuse activation doesn't work either (still flagged, not
fixed) -- worked around by invoking the directly-registered
ZUSE-AUTHENTICATE word explicitly.
Validated pilot (amd64, seed 12345, 30 reps, same build, disabled vs.
genuinely zuse-authenticated-enabled): +117 ticks, +0.0448% overhead.
Disabled-arm determinism double-confirmed (261064 ticks, exact repeat
on a fresh boot) -- the 117-tick difference is real signal, not noise.
Reconciles with the original ACL-RWT campaign's own heartbeat-tick
result (+0.0054%-0.0088%, same order of magnitude). Section P's
wall-clock numbers and Section Q's "instrument blind" conclusion are
both marked invalidated/corrected in place, not deleted.
n=1 per arm, one architecture -- not yet a full campaign. Scoped as
next step, not undertaken in this pass.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vm->heartbeat.tick_count (FORTH-dispatch counter)
Captain Bob's law is unambiguous: the adaptive heartbeat is the one and
only clock, full stop. The first cut of this word read the wrong
counter under that name -- vm->heartbeat.tick_count is a colon-word-
dispatch counter gated at a fixed cadence (frozen during idle, blind to
per-dispatch CPU cost, see FABRIC-2.md Section Q). The real adaptive
heartbeat is heartbeat_ticks() in src/starkernel/heartbeat.c, driven
directly by the ISR-latched 100Hz hardware timer -- genuinely
time-based, confirmed advancing during idle wall-clock time on all
three architectures (amd64 4039->5510, aarch64 6126->7607, riscv64
2965->4466, each over ~15s idle). Kernel build only (__STARKERNEL__);
hosted build has no ISR timer and keeps the old fallback.
Three-arch QEMU acceptance: POST 1012/0/0 on each, word live-tested.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The adaptive heartbeat tick counter (vm->heartbeat.tick_count) is the
project's sole canonical clock for timing measurements -- host wall-clock
is not a valid substitute. Exposes it read-only so DoE/overhead campaigns
can measure elapsed ticks instead of wall-clock deltas.
Verified: three-arch QEMU acceptance (amd64/aarch64/riscv64), POST
1012/0/0 on each, HEARTBEAT-TICKS@ live-tested returning a real non-zero
count on all three.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
