3 Commits

Include renames

Author	SHA1	Message	Date
Robert Allan JamesandClaude Sonnet 5	2a30212bd3	Real per-VM log persistence: source attribution + ACL pin (FABRIC-3.md §XXVII) ... Wires the previously-unused vm_log_attributed_vm() into LOG-APPEND's kernel primitive so persisted log records carry a trustworthy source (the real attributed VM's registry name, or "HADES" pseudo-source) instead of a caller-supplied, trivially forgeable string. Drops src-addr/src-u from LOG-APPEND's stack signature accordingly. Pins LOG-APPEND via bare ACL-PIN in Artemis's own init.4th, matching BIRTH/CAPSULE-BIRTH's precedent for a privileged word that can't reach the shared, host-portable ACL.4th. Also fixes two console-banner nitpicks: a mis-rendering em dash (U+2014) in the boot banner, and drops "Emergency" from the CLI banner text. Doc corrections to artemis_sig.h/zuse_eligibility_list.h reconciling the three fixed devblock ranges now in play. LOG-FLUSH (the intended normal entry point) and level-aware log eviction remain open, flagged not fixed. Re-verified clean boot to ok> on all 3 architectures after every change. riscv64 showed one new, unrelated virtio_blk write-timeout anomaly during Artemis's early physics self-test (self-recovered, boot unaffected, sector doesn't map to the log region) -- flagged, not investigated. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016UNhH1mhi52i6Qihh7ZV5S	2026-09-13 08:56:33 -04:00
Robert Allan JamesandClaude Sonnet 5	61755fde78	Artemis genesis stamp: fix a BAM-corrupting offset before it ever ran (FABRIC-3.md §XXVI follow-on, Step 3) ... Step 3: one-time artemis_sig_t genesis stamp, written once kernel_main.c's virtio-blk path confirms Artemis's own disk, so the disk image is later recognizable generically (repl.c's idle-loop USB-MSC scan, built in the prior commit) regardless of which bus found it. Correction made before this ever touched the real disk: the signature's first design (committed in 29b6789) placed it at a fixed bottom-of-device forth-block (4, devblock 1) -- copying homeblocks_sig_t's own convention, which is safe for a raw identity thumbdrive but not for Artemis's own disk. Artemis's disk is block_subsystem.c's own STFR/v2-formatted volume: devblock 0 holds that format's header and devblock 1 is the FIRST DEVBLOCK OF THE LIVE BAM (blk_compute_fresh_geometry(): bam_start = 1). The original design would have overwritten Artemis's live allocation map on the very first real boot. Caught via direct cross-reference against block_subsystem.c before the genesis-stamp call site was ever run against the real image -- no corruption occurred. Fixed by moving the header to a fixed offset from the END of the device instead (ARTEMIS_SIG_DEVBLOCK_FROM_TOP=64), the same top-of-device region block_subsystem.c's own meta_fence_blocks reservation (128 devblocks) already carves out for system metadata, and where Zuse's genesis marker/ eligibility list already live -- but computed independently via blkio_info() rather than through blk_meta_zone_*(), since that accessor needs an already-attached, format-detected slot, which is exactly the state pre-attach generic discovery doesn't have yet. Picked well clear of Zuse's two tenants (devblock_from_top 0 and 1+, open-ended) so the two subsystems' independent math can never collide. Also reordered kernel_main.c: rng_init() now runs before the Artemis virtio-blk block (was after) -- the genesis stamp needs rng_get_bytes() for disk_uuid, and the original order would have failed the stamp on every boot. Verified live: booted amd64 against the real disk/artemis.img twice -- first boot logs "Artemis: genesis signature stamped" (confirmed blank at the target offset beforehand via a host-side read), second boot on the now-stamped image logs no re-stamp (idempotent, CRC/read-back verified) -- both boots and aarch64/riscv64 (against the same now-stamped image) all still report "Artemis: 22998 data blocks" / "PASS: persist-read" unchanged, confirming the BAM and data pool were never touched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo	2026-09-13 07:31:21 -04:00
Robert Allan JamesandClaude Sonnet 5	29b6789860	Artemis bus-agnostic discovery: signature format + idle-loop generalization (FABRIC-3.md §XXVI follow-on) ... Step 1: new artemis_sig_t header format (magic 'ARTM', sibling to homeblocks_sig_t, distinct so a generic scan can tell Artemis's own disk apart from an identity thumbdrive by content alone) -- artemis_sig.h/.c, wired into Makefile.starkernel. Step 2: sk_repl_idle()'s existing per-USB-MSC-slot attach handling (the pattern WIREBIND already uses for identity thumbdrives) now also checks for the ARTM signature whenever a device's home-blocks check comes back BLANK. On a match, once Artemis's own storage-attach round-trip (HERA-BLK-ATTACH-REQ/BLK-ATTACH-ACK) confirms success, capsule_zuse_boot_load_root_pubkey() runs -- the same call kernel_main.c's synchronous QEMU-only virtio-blk path already makes, now reachable without a hardcoded PCI vendor/device scan. That function is already idempotent (no-op once zuse_root_pubkey_known is set), so no boot restructuring was needed despite the initial concern that deferring Artemis discovery to the idle loop would require one. Verified: clean build + QEMU boot to [zuse@Hera] ok> on all three architectures, zero regression to the existing virtio-blk/Zuse-thumbdrive attach path. Steps 3 (genesis-stamping onto disk/artemis.img) and 4 (growable production log-persistence region) not yet started. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo	2026-09-13 07:16:48 -04:00