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

include/starkernel/artemis_sig.h

@@ -36,14 +36,49 @@
  * thumbdrive and Artemis's own disk could both be attached as USB-MSC
  * devices simultaneously) would have no way to tell them apart.
  *
- * Mirrors homeblocks_sig_t's own structural convention exactly (magic +
- * version + CRC, one 4KiB devblock, same devblock-1 fixed location) --
- * a sibling format, not a field bolted onto homeblocks_sig_t itself:
- * homeblocks_sig_t's own header comment already states it's "deliberately
- * narrow in scope" (identity-drive fields only, no spare room -- its
- * padding is computed to fill exactly 4096 bytes), and Artemis's disk is
- * conceptually a different kind of thing (one dedicated fleet-owned device,
- * not one of many candidate identity drives), not a variant of the same one.
+ * Mirrors homeblocks_sig_t's own structural convention (magic + version +
+ * CRC, one 4KiB header) -- a sibling format, not a field bolted onto
+ * homeblocks_sig_t itself: homeblocks_sig_t's own header comment already
+ * states it's "deliberately narrow in scope" (identity-drive fields only,
+ * no spare room), and Artemis's disk is conceptually a different kind of
+ * thing (one dedicated fleet-owned device, not one of many candidate
+ * identity drives), not a variant of the same one.
+ *
+ * CORRECTION, same day: the first version of this format placed the header
+ * at a fixed bottom-of-device forth-block (4, i.e. devblock 1), copying
+ * homeblocks_sig_t's own devblock-1 convention. That convention is safe for
+ * an identity thumbdrive (raw, dedicated storage -- capsule_mint.c writes
+ * directly, no block-subsystem format involved), but Artemis's disk is
+ * block_subsystem.c's own STFR/v2-formatted volume: devblock 0 holds that
+ * format's header (read_header_4k()/write_header_4k(), block_subsystem.c)
+ * and devblock 1 is the FIRST DEVBLOCK OF THE LIVE BAM
+ * (blk_compute_fresh_geometry(): bam_start = 1). Writing artemis_sig_t
+ * there would have overwritten Artemis's own live allocation map on the
+ * very first real boot this ran against -- caught (via `git status`/`grep`
+ * cross-reference against block_subsystem.c, not against a live disk)
+ * before the genesis-stamp call site ever executed against the real image.
+ *
+ * The header now lives at a fixed offset from the END of the device
+ * instead (ARTEMIS_SIG_DEVBLOCK_FROM_TOP, see below) -- the same
+ * "top-of-device, outside the user-addressable LBN pool" region
+ * block_subsystem.c's own meta_fence_blocks reservation (128 devblocks by
+ * default, BLK_META_FENCE_INIT) already carves out for exactly this kind
+ * of system metadata, and where Zuse's own genesis marker/eligibility list
+ * already live (blk_meta_zone_read()/write(), devblock_from_top 0 and 1+
+ * respectively). This format deliberately does NOT go through
+ * blk_meta_zone_*, though: that accessor requires the device to already be
+ * blk_subsys_attach_device()'d and format-detected (first_disk_slot()) --
+ * exactly the state generic pre-attach discovery (repl.c's idle-loop
+ * USB-MSC scan) doesn't have yet, which is the entire reason this format
+ * exists. artemis_sig_check()/artemis_sig_genesis_stamp() instead compute
+ * the same top-of-device arithmetic independently via blkio_info(), so
+ * they work on a raw, not-yet-attached device exactly like
+ * homeblocks_sig_check() already does. ARTEMIS_SIG_DEVBLOCK_FROM_TOP is
+ * fixed well clear of Zuse's two tenants (0 and 1+, open-ended but
+ * realistically small -- 127 pubkeys per chained devblock) so the two
+ * subsystems' independent top-of-device math can never collide, without
+ * this format needing to know how far the eligibility chain has actually
+ * grown on any given boot.
  *
  * Reserves offset/size pointers to the growable per-VM log-persistence
  * region (FABRIC-3.md §XXVI follow-on's own log-record work), the same way
@@ -81,13 +116,20 @@ extern "C" {
 #define ARTEMIS_SIG_GET_MAGIC(m)   ((uint32_t)((m) & 0xFFFFFFFFULL))
 #define ARTEMIS_SIG_GET_VERSION(m) ((uint8_t)(((m) >> 32) & 0xFF))
 
-/* Same devblock-1 (forth-block 4) convention as HOMEBLOCKS_SIG_START_FBLOCK
- * -- devblock 0 stays reserved for the block-subsystem's own generic
- * 'STFR'/v2 volume header (block_subsystem.h), same reasoning as
- * homeblocks_sig.h's own comment on this. No collision risk with an
- * identity thumbdrive's own homeblocks_sig_t at the same devblock offset --
- * they are different physical/virtual devices entirely. */
-#define ARTEMIS_SIG_START_FBLOCK 4u
+/* Fence-relative top-of-device index -- see this header's own CORRECTION
+ * comment above for why this replaced a fixed bottom-of-device forth-block.
+ * Same "distance from the very last physical devblock" convention
+ * block_subsystem.c's blk_meta_zone_read()/write() use internally (0 =
+ * last devblock, 1 = second-to-last, ...), computed independently here via
+ * blkio_info() rather than through that accessor (which needs an already-
+ * attached, format-detected slot this code runs before). Fixed well past
+ * Zuse's genesis marker (devblock_from_top 0) and eligibility list
+ * (devblock_from_top 1, chained upward as needed) -- see
+ * zuse_eligibility_list.h -- so the two subsystems' independent top-of-
+ * device math can never collide regardless of how large the eligibility
+ * chain grows in practice. Well inside BLK_META_FENCE_INIT (128 devblocks,
+ * block_subsystem.h) on any real Artemis disk. */
+#define ARTEMIS_SIG_DEVBLOCK_FROM_TOP 64u
 
 /*===========================================================================
  * artemis_sig_t - Artemis disk signature header (exactly one 4KiB devblock)
@@ -157,21 +199,18 @@ typedef enum {
 struct blkio_dev;
 
 /*
- * artemis_sig_check - Read and verify the Artemis disk signature header.
- * Mirrors homeblocks_sig_check()'s own contract exactly (same forth-block
- * read pattern, same "starting block is a caller-supplied parameter"
- * separation of concerns).
+ * artemis_sig_check - Read and verify the Artemis disk signature header, at
+ * the fixed ARTEMIS_SIG_DEVBLOCK_FROM_TOP offset from whatever `dev`
+ * reports as its own total size (blkio_info()) -- no attach or format
+ * detection required, same "works on a raw, not-yet-attached device"
+ * contract homeblocks_sig_check() already has.
  *
  * @param dev              Open block device to read from.
- * @param sig_start_fblock First of 4 consecutive forth-blocks holding the
- *                         4KB header -- ARTEMIS_SIG_START_FBLOCK for every
- *                         real caller today.
  * @param out_sig          On ARTEMIS_SIG_OK, populated with the verified
  *                         header. Left unspecified on any other result.
  * @return ARTEMIS_SIG_OK, or the specific reason for refusal.
  */
 artemis_sig_result_t artemis_sig_check(struct blkio_dev *dev,
-                                        uint32_t sig_start_fblock,
                                         artemis_sig_t *out_sig);
 
 /*
@@ -185,6 +224,37 @@ artemis_sig_result_t artemis_sig_check(struct blkio_dev *dev,
  */
 uint64_t artemis_sig_compute_crc(const artemis_sig_t *sig);
 
+/*
+ * artemis_sig_genesis_stamp - One-time write of a fresh artemis_sig_t onto
+ * a disk already confirmed to be Artemis's own (never called speculatively
+ * on an unidentified/blank device -- see the call site in kernel_main.c for
+ * why that's always safe there: virtio_blk_find_artemis() only ever
+ * succeeds against the one dedicated PCI device, so a BLANK read at this
+ * fblock unambiguously means "this disk has never been stamped," not
+ * "this might be some other blank drive"). log_region_offset/devblocks are
+ * written as 0 (not yet allocated) -- step 4's own log-persistence design
+ * allocates them later via a normal artemis_sig_t rewrite, same one-header
+ * location.
+ *
+ * disk_uuid is drawn from rng_get_bytes(), same entropy source
+ * capsule_mint.c already uses for an identity thumbdrive's drive_uuid.
+ * genesis_time_ns is written as 0 -- no monotonic-ns source exists
+ * anywhere in this codebase yet, same open item homeblocks_sig_t's own
+ * minted_time_ns field already carries.
+ *
+ * Idempotent by construction: a caller must check artemis_sig_check()
+ * returns ARTEMIS_SIG_BLANK first (this function does not re-check, to
+ * avoid a second redundant read the caller already just performed).
+ *
+ * @param dev  Open block device to write to. Must already be confirmed as
+ *              Artemis's own disk.
+ * @return 0 on success (including read-back verification), -1 on any
+ *         entropy, write, or verify failure -- the disk is left however
+ *         the failed write left it, same as capsule_mint.c's own
+ *         write-then-verify discipline.
+ */
+int artemis_sig_genesis_stamp(struct blkio_dev *dev);
+
 #ifdef __cplusplus
 }
 #endif