Root-cause the std79 lockdown gap: likely never engages for any locked identity (FABRIC-3.md §XXV follow-up)
Following up on the messaging-words-not-denied finding: 'MSG-STATUS ACL-STD79-ALLOWED? .' sent into rajames came back UNKNOWN WORD, not "denied" -- acl-std79.4th's own supporting words were never compiled into the VM's dictionary at all. Root cause, confirmed via the raw boot log: "WARN: block 4998 exceeds 1KB, truncating" fires during every std79-locked identity's own birth. capsule_exec_payload() parses "Block N" content as everything from that header to the next "Block N" header or end-of-payload, truncating at 1024 bytes for both storage and execution. MINT_RESTRICTED_PERSONALITY is a short (~200 byte) string written into a zero-padded 4096-byte devblock at mint time; capsule_runcap_ birth() reads back the entire reserved multi-devblock region with no second "Block N" header anywhere in it to terminate "block 4998" early, so the parser treats the whole mostly-padding region as one oversized block. Confirmed universal, not one identity's quirk: the warning fires exactly 8 times in a full 9-identity boot -- once per std79-locked identity (rajames, 00-06; zuse runs natively on Hera, never through this path) -- and dates back to at least 2026-09-10 in this repo's own logs, well before this session. The std79 lockdown has likely never actually engaged, for any of the 8 locked identities, since it was built. Not fully closed to the byte: the real content sits at the start of the oversized block, inside the surviving truncated slice, so truncating the tail shouldn't by itself stop the head from executing -- the exact remaining mechanical step (stale leftover data, a line-boundary artifact, or something else) isn't nailed down yet. Explicitly not fixed -- documented per Bob's own "stop here, document it, and continue" call. Security-relevant (an intended lockdown restricting nothing) and deserves its own deliberate fix with real test coverage, not a bolt-on to an unrelated change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo
This commit is contained in:
co-authored by
Claude Sonnet 5
parent
3c2daf50d1
commit
cb32e6632b
+46
@@ -3279,3 +3279,49 @@ workload-identity × placement-mode as two real factors, ephemeral-birth now the
|
|||||||
placement-mode candidate) once BIRTH's own verification (done here) and the ACL gap (flagged,
|
placement-mode candidate) once BIRTH's own verification (done here) and the ACL gap (flagged,
|
||||||
not yet fixed) are both accounted for.
|
not yet fixed) are both accounted for.
|
||||||
|
|
||||||
|
**Root-cause follow-up, same day, Bob's own call ("stop here, document it, and continue" moved
|
||||||
|
straight to "root-cause the lockdown/messaging gap" as the next thread):** this went further and
|
||||||
|
found a real, concrete, universal mechanism, not just a correlation.
|
||||||
|
|
||||||
|
`' MSG-STATUS ACL-STD79-ALLOWED? .` sent into `rajames` came back `UNKNOWN WORD:
|
||||||
|
'ACL-STD79-ALLOWED?'` -- not merely "MSG-STATUS wasn't denied," but `acl-std79.4th`'s *own*
|
||||||
|
supporting words were never defined in this VM's dictionary at all. `UNKNOWN WORD` and "ACL
|
||||||
|
denied" are genuinely different failure classes (the former means `FIND` never located an entry
|
||||||
|
with that name; the latter means an existing entry's `acl_allow` flag blocked it) -- this rules
|
||||||
|
out "the walk ran but missed some words" and points at "the restricted-personality bootstrap
|
||||||
|
script itself never successfully defined anything from `acl-std79.4th`."
|
||||||
|
|
||||||
|
The raw boot log pinned it precisely: `WARN: block 4998 exceeds 1KB, truncating` fires during
|
||||||
|
every std79-locked identity's own birth. `capsule_exec_payload()` (`capsule_loader.c`) parses
|
||||||
|
"Block N" content as everything from that header to the *next* "Block N" header or end-of-
|
||||||
|
payload, then truncates to 1024 bytes (`LOADER_BLOCK_SIZE`) if it's larger -- both for storage
|
||||||
|
*and* for what actually gets executed. `capsule_mint.c`'s `MINT_RESTRICTED_PERSONALITY` is a
|
||||||
|
short (~200 byte) string written into a zero-padded 4096-byte devblock at mint time; read back
|
||||||
|
by `capsule_runcap_birth()`, which pulls `source_devblocks` worth of raw content (potentially
|
||||||
|
several 4KB devblocks) with no second "Block N" header anywhere in that reserved space to
|
||||||
|
terminate "block 4998" early -- so the parser treats the *entire* reserved region, mostly
|
||||||
|
padding, as one oversized block, exactly matching the observed warning. Confirmed universal, not
|
||||||
|
one identity's one-off mint quirk: the warning fires exactly 8 times in a full 9-identity boot
|
||||||
|
(logs/20260912-170001) -- once per std79-locked identity (`rajames`, `00`-`06`; `zuse` runs
|
||||||
|
natively on Hera and never goes through this path at all) -- and dates back to at least
|
||||||
|
2026-09-10 in this repo's own logs, well before this session. **The std79 lockdown has likely
|
||||||
|
never actually engaged, for any of the 8 locked identities, since it was built.**
|
||||||
|
|
||||||
|
One open question the truncation mechanics alone don't fully explain: the real ~200-byte content
|
||||||
|
sits at the *start* of the oversized block, well inside the surviving first-1024-byte slice, so
|
||||||
|
truncation discarding the *tail* shouldn't by itself prevent the *head* (the actual `S" acl-
|
||||||
|
std79.4th" EXEC` / `ACL-LOCKDOWN-STD79` lines) from executing correctly. Whether stale/non-zero
|
||||||
|
leftover data in that reserved region, a line-boundary artifact where real content meets padding
|
||||||
|
without a clean terminator, or something else entirely is the specific reason the head doesn't
|
||||||
|
execute either is not yet nailed down to the byte -- the warning's universality and exact timing
|
||||||
|
match is strong, corroborating evidence for the diagnosis, not yet a fully closed proof of the
|
||||||
|
last mechanical step.
|
||||||
|
|
||||||
|
**Explicitly not fixed, per Bob's own "document it, and continue" instruction covering this
|
||||||
|
whole thread** -- this is a real, significant, security-relevant finding (an intended lockdown
|
||||||
|
that isn't actually restricting anything) that deserves its own deliberate fix, not a same-
|
||||||
|
session patch bolted onto an unrelated `BIRTH` change. Test coverage worth having once this is
|
||||||
|
fixed: an explicit, automated check that `ACL-STD79-ALLOWED?` (or any allowlist word) actually
|
||||||
|
*exists* and denies a known off-list word for a live std79-locked identity, rather than trusting
|
||||||
|
a clean mint + a clean boot as proof the lockdown engaged.
|
||||||
|
|
||||||
|
|||||||
@@ -1,5 +1,5 @@
|
|||||||
# Capsule Block Manifest — Auto-generated
|
# Capsule Block Manifest — Auto-generated
|
||||||
<!-- Generated by mkcapsule --manifest 2026-09-13T02:28:34Z -->
|
<!-- Generated by mkcapsule --manifest 2026-09-13T02:53:31Z -->
|
||||||
<!-- DO NOT EDIT — re-run mkcapsule --manifest to refresh. -->
|
<!-- DO NOT EDIT — re-run mkcapsule --manifest to refresh. -->
|
||||||
<!-- Hand-written justifications and immutability notes live -->
|
<!-- Hand-written justifications and immutability notes live -->
|
||||||
<!-- in MANIFEST.md alongside this auto-generated index. -->
|
<!-- in MANIFEST.md alongside this auto-generated index. -->
|
||||||
|
|||||||
Binary file not shown.
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user