docs(rfc): propose RFC-0003 — the capability table - #7
Merged
Conversation
The first Phase 1 design RFC, and the first consumer of the threat model:
it cites the obligations it discharges by number (O-1, O-2, O-4, and the
destruction half of O-3), which is the working style the model exists for.
The load-bearing decision is representation. Three lineages argued:
- seL4's CNode radix: rejected as the primary structure. It is the
"baroque capability hierarchies" grave §3 names, and its complexity
budget assumes formal verification Setonix does not have.
- A flat per-process handle table (Zircon lineage): recommended. O(1)
lookup, no user-visible structure, small enough to hold in one head —
with seL4's invariants applied to it: handles are indices into kernel
memory (unforgeable), derivation is subset-only (rights are monotone
decreasing, no widening operation exists), generations close the ABA
reuse hole the old C++ blueprint already identified.
- L4 thread-local minimalism: rejected; fits the process-holds-resources
split worse.
Transfer is a Rust move. The kernel-side Capability deliberately has no
Clone: duplication is derive, an explicit recorded operation. This is where
§3's "Rust's ownership and move semantics model capability transfer at
compile time" stops being a slogan — the borrow checker enforces that a
capability lives in exactly one table or one in-flight message.
The RFC also constrains the syscall ABI before it exists: every
resource-touching syscall takes a handle; no syscall names a resource by
path, PID or any ambient identifier. O-4 becomes a birth constraint the
syscall RFC inherits, not a retrofit.
Honest gaps, named rather than papered over: selective transitive
revocation is proposed (badges plus shallow derivation records, keeping
revocation policy in the broker where §3 puts policy) but deferred to
RFC-0003a with the broker RFC as input; multi-core table synchronisation
couples to the IPC RFC; the memory-capability/MMU handshake and the no-root
bootstrap of the first capabilities are open questions listed for their own
RFCs.
Verified: spelling and markdown gates clean across 53 files; every O-number
cited resolves against docs/threat-model.md.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The first Phase 1 design RFC, and the first to argue against the threat model by obligation number: discharges O-1 (unforgeability), O-2 (non-widenability), O-4 (no ambient authority), and the destruction half of O-3 (revocability) — with selective revocation honestly deferred to RFC-0003a.
The core proposal: a flat per-process handle table (Zircon lineage) carrying seL4's invariants — handles as kernel-table indices, subset-only derivation, generation counters against reuse — explicitly steering around the baroque capability hierarchies grave. Capability transfer is a Rust move (no
Clone), making §3's compile-time-transfer claim concrete. §9 constrains the future syscall ABI to capability-indexed operations only, so O-4 is inherited by every syscall ever written.Which pillar does this serve?
Pillar 2, directly — and it is the enforcement surface every other pillar rests on.
If this changes a document or the constitution
docs/threat-model.md)docs/CHANGELOG.mdrecords itBorrow Ledger
Microkernel core — write ourselves, design only; lineage table in §10 credits seL4, Zircon, KeyKOS/EROS, and our own BlueOS blueprint (its generation-counter instinct is adopted).
unsaferegisterunsafeblocks: None — paper only.For your review, specifically
🤖 Generated with Claude Code