Files
LithosAnanake/logs
Robert Allan JamesandClaude Sonnet 5 cb32e6632b
Build / build-amd64-iso (push) Waiting to run
Build / build-aarch64-iso (push) Waiting to run
Build / build-riscv64-img (push) Waiting to run
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
2026-09-12 22:59:54 -04:00
..
2026-08-02 05:11:24 -04:00
2026-08-02 05:11:24 -04:00
2026-08-02 05:11:24 -04:00
2026-09-01 12:09:20 -04:00
2026-09-01 12:09:20 -04:00

logs/

QEMU acceptance-run history and Tripod smoke-test results.

  • <timestamp>/{amd64,aarch64,riscv64}/ — 255 timestamped three-arch QEMU acceptance run directories, one per invocation of the kernel QEMU acceptance workflow.
  • qemu-screenshot-*.png, qemu-screenshot-*.log, qemu-{amd64,aarch64,riscv64}-*.log, fbtest-console-*.png — loose timestamped QEMU serial captures and framebuffer screenshots from individual manual runs (not part of the timestamped-directory convention above).
  • hermes-tripod-smoke-results.md, hermes-channel-smoke-results.md — captured output from tools/hermes_tripod_smoke.sh and tools/hermes_channel_smoke.sh.
  • hermes-tripod-integration-design.md — design notes for the Tripod integration test.

Note: QEMU_BASELINE.log at the repo root (not in this directory) is the primary kernel regression baseline referenced by .claude/CLAUDE.md; the logs here are supplementary historical captures. See also logs2/ (a separate, flatter QEMU log archive) and experiments/bare_metal/runs/ (DoE-specific run output).