System Platform

01 // CAPABILITIES

Thirteen syscalls need no capability, because each acts only on the caller itself: write (fd 1, its console output), exit, yield, getpid, uptime, args (its own arguments), sleep, udp_close (a socket it already owns), and cap_list, cap_check, cap_revoke and cap_restrict (its own handles, which it can inspect, drop or narrow but never widen). The thirteenth, console_read, is limited instead to the one process the kernel has lent the console’s input; anyone else gets ERR_PERM, audited. Every other syscall is default deny: the caller must hold a live capability handle of the right kind, rights and scope, or it gets ERR_PERM and the refusal lands in the audit trail, enforced in the kernel’s syscall layer. Delegation only narrows: spawn inherits the parent's set exactly (in v1.0.0, minus the two console-only capabilities), and spawn_caps grants parent ∩ requested. A child can never hold what its parent lacked.

02 // SYSTEM SERVICES

Services are ordinary Ring 3 processes — no hidden privileged daemons. A static registry declares each service's binary, dependencies, and the exact capabilities it runs with. The supervisor starts them in a deterministic, cycle-checked dependency order, contains crashes, and applies a bounded restart policy (3 restarts, then Failed — no restart storms). The svc command shows the real state table.

Since v0.10.0 the persistent services are started by /sbin/init — pid 1, an ordinary Ring 3 program with fixed authority — from /etc/init.conf, each with exactly the capabilities the file gives it. Init reports every start, restart and failure to the kernel, which checks that the process is init's own child and prints the capabilities from its own record; if init dies, the kernel ends its services and starts a new init.

03 // APPS, PACKAGES, UPDATES

An application ships as one ITPKG file: a strict manifest (name, version, requested capabilities — unknown keys or capabilities are errors, never silently tolerated) plus the ELF payload, integrity-protected by SHA-256 and re-verified at every launch. The persistent store keeps version-numbered packages with commit markers; install, update, rollback, and recovery are each one crash-atomic filesystem transition — an interrupted update can never activate.

Honesty note: SHA-256 is integrity, not authenticity, so since V0.8 a package also carries an Ed25519 signature, checked after the digest. Since v0.9.0 the kernel trusts only an offline root, and signing keys only through root-signed certificates limited by package-name scope and release-epoch validity, subject to a signed revocation list (ADR-0021). v0.8.1 checks against one compiled-in development key whose seed is published: the mechanism is real, that key anchors no trust.

The platform's privileged path — request → identity → capability check → deterministic service → action → audit — is the only privileged path. An AI agent gets no other entry point: it requests actions exactly like any untrusted application, subject to the same default-deny capabilities, the same sandbox, and the same audit trail. The released v0.10.0 image contains no AI component.

In v1.0.0, the first agent works exactly this way. It holds the view and the right to propose, both console-granted only, plus IPC and reads under /etc/ai; its own attempts at svc_report, fs_write and spawn are refused, and no syscall it can call performs either of its two actions — resuming the scheduler, retrying a failed service. Inference runs in Ring 3, in inferd under /sbin/init; the kernel only re-evaluates the pinned model on the view it served, to check the agent’s claim, and never acts on a model’s output. A proposal the kernel accepts waits for approve or deny at the console; an approved action runs in kernel code, is verified, is rolled back if the check fails, and each step is audited with the model and view digests the proposal cited.

Source: docs/SECURITY_MODEL.md · ADR-0012 · evidence in the repository's artifacts/qemu/ JSON + serial logs