The overriding goal of the EROS system (and its relatives) is to provide strong support at the operating system level for the efficient restructuring of critical applications into small communicating components. Each component can communicate with the others only through protected interfaces, and is isolated from the rest of the system. A
protected interface, in this context, is one that is enforced by the lowest level part of the operating system, the
kernel. That is the only part of the system that can move information from one
process to another. It also has complete control of the machine and (if properly constructed) cannot be bypassed. In EROS, the kernel-provided mechanism by which one component names and invokes the services of another is a
capability, using
inter-process communication (IPC). By enforcing capability-protected interfaces, the kernel ensures that all communications to a process arrive via an intentionally exported interface. It also ensures that
no invocation is possible unless the invoking component holds a valid capability to the invoked component. Protection in capability systems is achieved by restricting the propagation of capabilities from one component to another, often through a security policy termed
confinement. Capability systems naturally promote component-based software structure. This organizational approach is similar to the programming language concept of
object-oriented programming, but occurs at larger granularity and does not include the concept of
inheritance. When software is restructured in this way, several benefits emerge: • The individual components are most naturally structured as
event loops. Examples of systems that are commonly structured this way include
aircraft flight control systems (see also
DO-178B Software Considerations in Airborne Systems and Equipment Certification), and telephone switching systems (see
5ESS switch). Event-driven programming is chosen for these systems mainly because of simplicity and robustness, which are essential attributes in life-critical and mission-critical systems. • Components become smaller and individually testable, which helps to more readily isolate and identify flaws and bugs. • The isolation of each component from the others limits the scope of any damage that may occur when something goes wrong or the software misbehaves. Collectively, these benefits lead to measurably more robust and secure systems. The
Plessey System 250 was a system originally designed for use in telephony switches, which capability-based design was chosen specifically for reasons of robustness. In contrast to many earlier systems, capabilities are the
only mechanism for naming and using resources in EROS, making it what is sometimes referred to as a
pure capability system. In contrast,
IBM i is an example of a commercially successful capability system, but it is not a pure capability system. Pure capability architectures are supported by well-tested and mature mathematical security models. These have been used to formally demonstrate that capability-based systems can be made secure if implemented correctly. The so-called "safety property" has been shown to be decidable for pure capability systems (see
Lipton). Confinement, which is the fundamental building block of isolation, has been formally verified to be enforceable by pure capability systems, and is reduced to practical implementation by the EROS
constructor and the KeyKOS
factory. No comparable verification exists for any other primitive protection mechanism. There is a fundamental result in the literature showing that
safety is mathematically undecidable in the general case (see
HRU, but note that it is of course provable for an unbounded set of restricted cases). Of greater practical importance, safety has been shown to be
false for all of the primitive protection mechanisms shipping in current commodity operating systems. Safety is a necessary precondition to successful enforcement of
any security policy. In practical terms, this result means that it is not possible
in principle to secure current commodity systems, but it is potentially possible to secure capability-based systems
provided they are implemented with sufficient care. Neither EROS nor KeyKOS has ever been successfully penetrated, and their isolation mechanisms have never been successfully defeated by any inside attacker, but it is not known whether the two implementations were careful enough. One goal of the Coyotos project was to demonstrate that component isolation and security has been definitively achieved by applying software verification techniques. The L4.sec system, which is a successor to the
L4 microkernel family, is a capability-based system, and has been significantly influenced by the results of the EROS project. The influence is mutual, since the EROS work on high-performance invocation was motivated strongly by
Jochen Liedtke's successes with the
L4 microkernel family. ==History==