EROS: A Fast Capability System

Reference

Shapiro, Jonathan S.; Smith, Jonathan M.; Farber, David J. “EROS: A Fast Capability System.” In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP ’99), Kiawah Island, SC, December 1999. Published as ACM SIGOPS Operating Systems Review 34(5):170-185. URL

Summary

EROS (Extremely Reliable Operating System) is the third-generation reimplementation of the GNOSIS/KeyKOS capability architecture - the lineage created by Norm Hardy et al. at Tymshare in 1982 - clean-roomed in C++ for x86 by Jonathan Shapiro, Jonathan Smith, and David Farber at Penn. The paper’s central claim, surprising to many at the time, is that a pure capability microkernel with transparent single-level store persistence can match or beat conventional Unix-kernel operation costs on commodity hardware. The authors show this through detailed microbenchmarks and careful architectural choices.

Architecturally, EROS is a microkernel. All resources - processes, address spaces, nodes (32-capability arrays), pages, entry capabilities, resume capabilities - are named and manipulated by unforgeable capabilities enforced by a tagged in-kernel data structure. A protection domain is defined by the set of capabilities held. The performance story rests on three pillars: (1) aggressive caching of abstract objects (processes, nodes, pages) in representations chosen for the underlying hardware; (2) unified design of IPC and capability invocation so that cross-domain calls are cheap; and (3) orthogonal persistence via periodic consistent snapshots with copy-on-write - meaning EROS has no file system in the traditional sense: the single-level store is the persistence mechanism, transparent to applications. A machine crash resumes where it left off, modulo the checkpoint interval.

The paper also addresses mandatory access control, the KeySAFE design (user-level reference monitors inserted between compartments for DAC/MAC composition), and the architectural features (nodes, entry capabilities, resume capabilities for one-shot continuations) that together let EROS support confinement and fine-grained POLA. EROS directly inspires seL4, CapROS, Coyotos, and is the principal existence proof cited whenever someone claims capability systems must be slow. It is a central reference in Miller’s Robust Composition thesis and in the Capability Myths Demolished paper’s defeat of the Confinement Myth.

Key Ideas

Single-level store: no file system; persistence is transparent, implemented by periodic consistent copy-on-write snapshots.
Capability is an unforgeable (object-id, rights) pair, kernel-enforced via tagged storage.
Nodes: 32-slot capability arrays, the building block for address spaces (tree of nodes) and process state.
Entry / resume capabilities: first-class continuation-like capabilities for efficient IPC and one-shot reply.
Fast IPC: EROS capability invocation matches L4-class IPC, demonstrated by microbenchmarks.
KeySAFE compartments: user-level reference monitors mediate flow between compartments for policy insertion.
Confinement via factories / constructors: inherited from KeyKOS, demonstrably solves the confinement problem.
Performance is not a capability-system inherent cost: with the right abstractions and caching, ocap kernels match conventional kernels.

Connections

The Heart of Spritely - Distributed Objects and Capability Security - EROS is in the direct intellectual lineage Spritely draws on.
Capability Security, Object Capability Security - EROS is the flagship existence proof for practical capability OSs.
E Language - Miller’s thesis advisor is Shapiro; EROS and E are sister projects in Johns Hopkins’ SRL.
CapTP
Ambient Authority - EROS has essentially none; every action requires an explicit capability invocation.
Confused Deputy - EROS’s design makes confused-deputy scenarios expressible-as-bugs only by explicit negligence.
Principle of Least Authority - fine-grained node capabilities enable POLA at page level.
Distributed Security
Security Kernel Lambda Calculus
Capability Bounding
Capability Revocation

Conceptual Contribution

A pure capability microkernel with transparent orthogonal persistence (single-level store, periodic consistent snapshots) is not inherently slow; with carefully chosen abstract-object caches and a unified IPC/capability-invocation path, EROS matches conventional Unix microbenchmarks on commodity hardware. This refutes decades of folk wisdom that capability systems trade performance for security, and demonstrates that the KeyKOS design - factories, confined subsystems, checkpointed persistence - is viable on modern machines.

Tags

#capability-security #operating-systems #eros #keykos #microkernel #sosp-1999 #single-level-store #orthogonal-persistence #jonathan-shapiro #performance #foundational #confinement

Summary

Rees describes Scheme 48, a programming environment whose design is guided by operating-system security principles. The security kernel is W7, a call-by-value lambda-calculus with extensions for abstract data types, object mutation, and hardware access. Each user or subsystem runs in a separate evaluation environment holding the objects representing that user’s privileges; because environments determine availability of object references, protection and sharing are controlled by construction.

The paper describes experience with Scheme 48 as the programming environment for Cornell’s mobile robots (no underlying OS) and as a secure multi-user workstation environment, arguing that lexical scope + first-class environments are a natural substrate for capability-style security among cooperating agents.

Key Ideas

Lambda-calculus as minimal security kernel via capability-style environments.

Scheme 48 (W7): modules, macros, dynamic isolation, portable across platforms.

Trust mediated by controlling which names bind to which objects.

Authentication via capsules (tamper-proof labelled objects).

Applied to robots and multi-user Scheme environments.

Conceptual Contribution

Claim: Lexical scope and first-class environments in a lambda-calculus variant (W7) are a sufficient security kernel: protection reduces to controlling which names bind to which object references.

Mechanism: Implements Scheme 48 as a capability-style environment where each user/subsystem runs in its own environment; authentication via capsules (tamper-proof labelled objects); deployed on Cornell mobile robots (no OS) and as multi-user workstation environment.

Concepts introduced/used: Capability Security, Lambda Calculus, Lexical Scope, Scheme 48, Capsules, Distributed Security, Multi-Agent Systems

Stance: foundational / engineering

Relates to: Provides a principled, capability-based alternative to the input-validation discipline of Seven Turrets Of Babel and the static DDoS analysis of A Language-Based Approach To Prevent DDoS; relevant to sandboxing malicious tools described in MalTool Malicious Tool Attacks.

Summary

The second paper in Spritely’s three-part design series, this whitepaper lays out the technical core of Goblins — a distributed, transactional, object-programming environment built around object capability security (OCap). The thesis: secure peer-to-peer applications should feel like ordinary programming, not like a separate security discipline, and capability security makes that achievable. The operative slogan is “If you don’t have it, you can’t use it” — authority is conveyed only by holding a reference, never ambient.

The paper works through (1) capability security as ordinary reference-passing, motivated against Access Control Lists and the confused-deputy problem; (2) Goblins itself — a distributed object programming model with promise pipelining, vats as containers of synchronous turns, turns as cheap local transactions, and time-travel debugging; (3) OCapN — a new cross-implementation protocol for secure distributed object communication; (4) portable encrypted storage for capabilities; (5) library/application safety implications. Implementations exist for Guile and Racket Schemes, with a roadmap toward language-heterogeneous object invocation.

Goblins is the modern distillation of a three-decade lineage running through Mark Miller’s E language, the CapTP protocol, Jonathan Rees’s capability-kernel argument, and Carl Hewitt’s actor formalism. It reframes agent communication as object-reference passing over the network, offering an alternative substrate to the ACL/RPC-stack approach that dominates modern LLM-agent protocols.

Key Ideas

Principle of Least Authority (POLA): grant each piece of code only the authority it needs, no more

Object capability security: authority = unforgeable object reference. Lexical scoping + no ambient authority + no global mutable state

Confused-deputy problem: why ACLs fail when a privileged program is tricked into acting for an attacker

Vat: an isolated synchronous execution context; objects live inside vats; vats communicate asynchronously

Turn: an atomic event loop iteration inside a vat; turns are transactional — errors roll back the turn’s local state

Promise pipelining (from CapTP): chain calls on a reference before the prior call resolves, reducing round trips

Time-travel distributed debugging: replay turns deterministically across the network

OCapN (Object Capability Network): protocol for secure, cross-language distributed object invocation

Revocation and accountability as programmable patterns over references

“If you don’t have it, you can’t use it” — the design-level simplification capability security provides

Conceptual Contribution

Claim: Secure peer-to-peer applications become routine when authority is conveyed only by holding an unforgeable object reference — no ambient authority, no global mutable state, lexical scope as the capability kernel — and when the network distribution of such references is itself designed as an ordinary message-passing object system.

Mechanism: Goblins realises the E-language tradition in Scheme (Guile, Racket): objects live in vats; each vat runs atomic turns that serve as cheap local transactions; asynchronous inter-vat invocation uses promise pipelining to collapse round-trips; persistence, upgrade, and cross-language interop are handled by OCapN — a capability-preserving transport protocol. Time-travel debugging exploits the turn-level determinism.

Concepts introduced/used: Object Capability Security, Principle of Least Authority, Ambient Authority, Confused Deputy, Vat Model, Turn (Goblins), Promise Pipelining, OCapN, CapTP, E Language, Time-Travel Debugging, Capability Revocation

Stance: engineering / foundational design doc

Relates to: A modern engineering culmination of the capability-security thread rooted in Security Kernel Lambda Calculus (Rees 1995, explicitly cited) — lexical scope as a capability kernel, extended into a full distributed system. The vat model is a direct descendant of A Universal Modular Actor Formalism for Artificial Intelligence (Hewitt 1973) and sibling to Programming Erlang Second Edition but with security-by-reference as a first-class concern. Frames a structural alternative to the modern LLM-agent protocol stack: where Agent-to-Agent Protocol / Model Context Protocol / Agent Network Protocol layer trust on top of ACL/RPC primitives, OCapN encodes trust in the reference graph itself. The flat context trust model that ClawWorm Self-Propagating Attacks Across LLM Agent Ecosystems exploits and that MalTool Malicious Tool Attacks, AI Agents Under Threat catalogue is precisely the ambient-authority failure capability security is designed to prevent — making Goblins / OCapN a serious candidate substrate for Inter-Agent Trust Models - A Comparative Study’s Constraint trust dimension.

EROS: A Fast Capability System

Reference

Summary

Key Ideas

Connections

Conceptual Contribution

Tags

Backlinks