Files
LithosAnanake/capsules/contrib
Robert Allan JamesandClaude Sonnet 5 eeceec21a5 FABRIC-3.md §I.5: Milestone 7 trust tiers (QEMU-vs-real-hardware), closing it
Closes the contributor-capsule/trust-tier punch-list item. Decided
direction: QEMU-vs-real-hardware conditional enforcement.

Found before building on that decision: the obvious mechanism (expose
TimerInfo.vm_mode) only works on amd64 -- aarch64 and riscv64 both had
vm_mode hardcoded to 1 unconditionally, meaning they'd always report
"running under QEMU" even on real hardware. Built real detection for
both instead of shipping that: aarch64 checks the ACPI RSDP's OEM ID
for QEMU's "BOCHS " SeaBIOS-heritage signature; riscv64 checks the
devicetree root compatible property for "qemu". Confirmed vm_mode was
otherwise unread anywhere else in either file first -- zero risk to
existing timing behavior.

CAPSULE_FLAG_CONTRIB (mkcapsule.c: FLAG_CONTRIB) path-matches on
capsules/contrib/, mirroring FLAG_MAMA_INIT's exact-match pattern.
contrib_capsule_refused() (capsule_birth.c) enforces: no additional
check under QEMU (same WARN-only as everything else); on real hardware,
a contrib capsule additionally requires CAPSULE_SIG_OK, since it has no
other provenance to fall back on. Wired into capsule_birth_baby() and
capsule_run_experiment().

Also updates §I.7 (Milestone 9): its stated precondition (Milestone 7
closing) is now met, flagged as stale rather than treated as a green
light to design networking from nothing.

Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in the
foreground) -- compile/boot verification only; the real-hardware
enforcement branch is unverifiable from this environment, same as all
of §I.6. logs and DoE CSVs from this session's verification runs
included per this repo's own audit-artifact convention.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
2026-09-04 11:04:25 -04:00
..

capsules/contrib/

Milestone 7 (contributor capsules / trust tiers), FABRIC-3.md §I.5.

Any .4th file placed here gets FLAG_CONTRIB in addition to the usual FLAG_PRODUCTION | FLAG_EXPERIMENT pair — tools/mkcapsule.c's flags_from_name() path-matches on the colon-separated capsule name starting with contrib:, mirroring FLAG_MAMA_INIT's own exact-match pattern one line up in that same function.

Trust-tier direction, decided in conversation 2026-09-04: QEMU-vs-real- hardware conditional enforcement — a contributor capsule is validated more strictly on real hardware than under QEMU, using timer_calibration_record()->vm_mode (include/starkernel/timer.h) as the signal. vm_mode is a real per-architecture hypervisor-vs-hardware detection as of this same pass (amd64: CPUID.1:ECX[31]; aarch64: ACPI RSDP OEM ID; riscv64: devicetree compatible string) — not a build-time flag, so the same binary enforces differently depending on where it actually boots.

Enforcement rule, built 2026-09-04: contrib_capsule_refused() (capsule_birth.c), called from both capsule_birth_baby() and capsule_run_experiment() (never capsule_birth_mama() — Mama's own init can never carry FLAG_CONTRIB, mutually exclusive with FLAG_MAMA_INIT by construction). Under QEMU (vm_mode == 1): no additional check, same WARN-only treatment every other capsule gets. On real hardware (vm_mode == 0): a contrib capsule additionally requires CAPSULE_SIG_OKMISSING/NO_ROOT_KEY, which stay WARN-only for every other capsule (most machines lack the offline signing key), are refused here specifically because a contributor's capsule has no other provenance to fall back on. Additive to, never a replacement for, the existing CAPSULE_SIG_INVALID refusal already enforced on every capsule regardless of FLAG_CONTRIB.