Files
LithosAnanake/capsules/zuse.4th
T
Robert Allan JamesandClaude Sonnet 5 e5cbc71f46 Phase 8 C (2/n): expand cert storage; NVRAM persistence crashed, reverted
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
2026-08-26 15:55:27 -04:00

34 lines
1.3 KiB
Forth

Block 4016
( zuse.4th - Bootstrap superuser for StarForth ACL )
( Named for Konrad Zuse, pioneer of programmable computers. )
( Sole superuser; mints credentials; owns emergency REPL. )
( Loaded by ACL.4th; must not load before ACL.4th. )
( FUTURE: Replace with thumbdrive Ed25519 PKI. )
( HUMAN-REVIEW: capsule hash = root of superuser trust. )
( Cert (seed+pubkey) lives in C-only VM fields, installed by )
( kernel_main.c's first-boot mint-or-load (NVRAM ZuseCert). )
( NOT a CONSTANT: ACL-PIN blocks redefinition, not a )
( >BODY-then-store, so a pinned CONSTANT isn't tamper-proof. )
( Read with ZUSE-PUBKEY@ / ZUSE-CERT-INSTALLED? -- both C )
( primitives, read-only; the seed has no FORTH access at all. )
Block 4017
( ACL-ZUSE-BOOT ( -- ) )
( Only authenticates if a real cert was installed this boot -- )
( refuses god-mode to a Zuse with no real identity behind her )
( (no runtime services, no entropy). Pins itself against )
( redefinition either way. ZUSE-AUTHENTICATE is C-only; no )
( FORTH word grants god-mode except through this sequence. )
: ACL-ZUSE-BOOT ( -- )
ZUSE-CERT-INSTALLED? IF
ZUSE-AUTHENTICATE
LOG-INFO" zuse: activated"
ELSE
LOG-INFO" zuse: NOT activated -- no cert installed"
THEN
['] ACL-ZUSE-BOOT ACL-PIN ;
Block 4018
( Self-activation )
ACL-ZUSE-BOOT