Skip to content

docs(rfc): state the boot grant's rules in RFC-0007 - #33

Merged
MatejGomboc merged 6 commits into
mainfrom
claude/bootstrap-rules
Nov 6, 2026
Merged

MatejGomboc merged 6 commits into
mainfrom
claude/bootstrap-rules

Conversation

@MatejGomboc

Copy link
Copy Markdown
Member

Summary

Moves into RFC-0007 §9 what an unmerged bootstrap draft held and no RFC did, and fixes what writing it down exposed. Proposed RFCs and the document changelog only; no code.

Explanation for the maintainer

The draft of 2026-08-05 sat uncommitted after its number was reused. Most of it had already gone into RFC-0007. Three rules had not:

  1. Every capability has a finite chain back to the boot grant. This is provenance, and a precondition of O-22, not a bound on what anyone can reach.
  2. The root starts the broker. The kernel supplies one edge that depends on nothing running. The services' start-up dependencies are the broker RFC's to prove acyclic.
  3. The boot grant must be complete. A root of authority absent at boot can never exist.

Writing rule 3 down showed that the boot list was not complete, so it gains Device Regions, module 0's Region, the kernel-filled Regions and the root's SchedContext.

Please check these design decisions:

  • The root's SchedContext is now a listed capability. It had no capability, leaving live authority nothing could name.
  • Boot capabilities carry DUPLICATE, TRANSFER and every right their methods check, so the root narrows by deriving. A right missing at boot could never be added.
  • The DTB gains DUPLICATE | TRANSFER, which RFC-0003a §9's rule on handing it on needs.
  • Device Regions are READ | WRITE | DUPLICATE | TRANSFER.
  • IrqControl mints through WRITE.
  • BootInfo runs to as many pages as it needs, because a one-page limit would overflow at about 125 entries.
  • BootCap's flags becomes rights. The field had no other stated use.
  • The root has no grant window.

Which pillar does this serve?

Pillar 2, at the one point the capability system cannot authorise itself. Discharges nothing new; enables O-22.

If this changes a document or the constitution

The constitution is untouched.

  • Cross-references still resolve; no clause is left contradicting another (/check-coherence)
  • If this is a constitution amendment, it is the maintainer's, and docs/CHANGELOG.md records it: not an amendment
  • No section other documents cite has been renumbered

Borrow Ledger

  • I checked the Borrow Ledger (CONSTITUTION.md §4) for this subsystem
  • The verdict for this subsystem is: write ourselves
  • Vendored code retains its original licence notices; new files carry an SPDX header: no new files

unsafe register

  • New unsafe blocks: None
  • Every new unsafe block carries a // SAFETY: comment
  • Every unsafe block is inside a module CLAUDE.md designates for it
  • I have listed them in the session summary / PR description above

Checklist

  • The pre-push checks pass: not run in the devcontainer, because Docker is not running here. Spelling and code spans passed on the host; markdownlint was not re-run for this branch, so CI is its first run
  • Boots in QEMU where applicable: n/a, no code changed
  • CHANGELOG.md updated under [Unreleased]: docs/CHANGELOG.md, which takes document changes
  • Commit messages follow Conventional Commits (see CONTRIBUTING.md)

Reviews

Critical tier: an RFC on the security spine.

Round Reviewers High findings Outcome
1 Soundness, coherence 3 distinct All fixed. Device memory was unreachable as written; three boot-made capabilities were unlisted; "acyclic by construction" was vacuous, because time order makes any history acyclic
2 One fresh reviewer, narrow 0 2 medium, 5 low and 3 nit findings, all applied in b45b714 without a further round, as highs had reached zero

Round 2's fixes have not themselves been reviewed.

Related

RFC-0003 §14.4. RFC-0003a P6 already schedules the wording "not revocable until RFC-0003a" for change.

🤖 Generated with Claude Code

MatejGomboc and others added 6 commits November 6, 2026 16:22
Every capability traces to the boot grant, so the grant graph is acyclic
by construction, and that grant must therefore be complete. Both rules
come from an unmerged bootstrap draft and appeared in no RFC, though
research/0002 asks for the first and O-22's containment argument rests
on it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Acyclicity by time order proved nothing, so RFC-0007 now claims only
that every capability has a finite chain to boot, and leaves the
services' start-up dependencies to the broker RFC. BootInfo's list gains
what it omitted, and boot capabilities carry every right, because a
right absent at boot can never exist.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
State each boot capability's rights rather than "every right", and give
Device Regions theirs. BootInfo runs to as many pages as it needs, so a
large machine cannot lose a root to a one-page limit. The self-test's
second grant is named wherever the absolutes reach it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@MatejGomboc
MatejGomboc merged commit e77433c into main Nov 6, 2026
6 checks passed
@MatejGomboc
MatejGomboc deleted the claude/bootstrap-rules branch November 6, 2026 15:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant