10. JAVM Capability System🔗

The JAVM extends the base PVM with an seL4-style capability system. Code and data are separate (Harvard architecture) — a CODE cap is opaque, you cannot read its instructions as data. CALL is a synchronous function call between VMs, not a process spawn. Any protocol capability (FETCH, STORAGE_R, etc.) can be transparently replaced with a CALLABLE to a wrapper VM for policy enforcement.

Five program capability types govern memory, code, and VM ownership. Protocol capabilities provide kernel services (storage, preimages, transfers) via the same CALL interface. The cap table (256 slots, u8 index) holds all capabilities for a VM. Each cap table is a CNode — operations resolve cap references through HANDLE chains (capability indirection), enabling cross-CNode management without GRANT/REVOKE.

Two PVM instructions handle all capability operations: ecalli (CALL a cap, subject in immediate, compiler can optimize) and ecall (management ops + dynamic CALL, subject/object in registers, always kernel dispatch). Registers phi[7..10] have the same meaning in both instructions.

1. 10.1. Capability Types
2. 10.2. Capability Indirection
3. 10.3. Cap Table
4. 10.4. VM Lifecycle
5. 10.5. ecalli / ecall Dispatch
6. 10.6. Protocol Cap Numbering
7. 10.7. Program Blob Format (JAR v2)
8. 10.8. Limits