26 ;;Quote: EROS uses capabilities to run active systems of user code; allows broken or hostile code

26 ;;Quote: EROS has formal verification of security properties and very little performance loss

27 ;;Quote: all operating system resources must be accounted for

27 ;;Quote: workload must not effect correct operations

27 ;;Quote: the EROS kernel cannot create or destroy resources; uses main memory as a cache

27 ;;Quote: all kernel operations are atomic; either complete within a deadline or no observable effect

27 ;;Quote: the EROS kernel does not maintain state; user-allocated storage stores the security and execution state; may be cached

27 ;;Quote: explicitly designate the source of any authority

27 ;;Quote: a secure system must start in a consistent and secure state; EROS periodically verifies a consistent, global checkpoint of the entire state of the machine; used for bootstrapping

28 ;;Quote: EROS uses kernel-protected capabilities; Amoeba treats capabilities as data and can not distinguish them from data

28 ;;Quote: the EROS kernel caches all state; requires explicit allocation of the memory map and dependency tracking

29 ;;Quote: EROS is a large space of capability-protected objects; memory pages, capability nodes, CPU time, network connections; only way to invoke operations

29 ;;Quote: trace every operation to an authorizing capability; every procedure call identifies capabilities; applications require a schedule capability

29 ;;Quote: EROS allows transmission of capabilities across authorized communication paths; this does not limit security

30 ;;Quote: EROS truncates messages to undefined destinations; otherwise, fault handlers may lead to denial-of-service, buffering creates local state, and timeouts are not repeatable under load

32 ;;Quote: EROS is 3x faster than Linux fork/exec and 1000x faster than Linux page faults and memory management

33 ;;Quote: principle-driven design allows effective checks for errors; in eight years, every EROS kernel bug was caught by an assertion check