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
This commit is contained in:
Robert Allan James
2026-08-26 15:55:27 -04:00
co-authored by Claude Sonnet 5
parent f223a31cec
commit e5cbc71f46
17 changed files with 54299 additions and 46 deletions
+9 -8
View File
@@ -118,7 +118,8 @@ void vm_set_base(VM* vm, unsigned b)
/* vm_tick* and heartbeat functions moved to vm_time.c */
/**
* @brief One-time write of the Zuse cert value (blows the fuse).
* @brief One-time write of the Zuse cert (seed + derived pubkey) -- blows
* the fuse.
*
* Deliberately not backed by a dictionary CONSTANT: ACL-PIN only blocks
* redefinition (vm_create_word shadowing), not a >BODY-then-store on the
@@ -127,17 +128,17 @@ void vm_set_base(VM* vm, unsigned b)
* corresponding FORTH store word closes that path entirely -- see
* FABRIC-3.md's Milestone 4 mint-then-pin writeup for the finding.
*
* @param vm VM instance.
* @param lo Cert value, low half.
* @param hi Cert value, high half.
* @return 0 on success; -1 if already installed (fuse already blown).
* @param vm VM instance.
* @param seed Ed25519 seed, 32 bytes (the private identity).
* @param pubkey Ed25519 public key derived from seed, 32 bytes.
* @return 0 on success; -1 if already installed (fuse already blown).
*/
int vm_zuse_cert_install(VM* vm, uint64_t lo, uint64_t hi)
int vm_zuse_cert_install(VM* vm, const uint8_t seed[32], const uint8_t pubkey[32])
{
if (!vm) return -1;
if (vm->zuse_cert_installed) return -1;
vm->zuse_cert_lo = lo;
vm->zuse_cert_hi = hi;
memcpy(vm->zuse_cert_seed, seed, 32);
memcpy(vm->zuse_cert_pubkey, pubkey, 32);
vm->zuse_cert_installed = 1;
return 0;
}