View source for EROS (microkernel)

{{Short description|Capability-based operating system}}
{{Infobox OS
| name = EROS
| screenshot = 
| caption = 
| developer = [[University of Pennsylvania]]<br/>[[Johns Hopkins University]]<br/>The EROS Group, LLC
| family = [[Capability-based security|Capability-based]]
| working state = Discontinued
| released = {{Start date and age|1991}}<!-- If known, add |mm|dd|df=yes -->
| latest release version = Final
| latest release date = {{Start date and age|2005}}<!-- If known, add |mm|dd|df=yes -->
| marketing target = Research
| programmed in = [[C (programming language)|C]]
| language = English
| update model = Compile from [[source code]]
| supported platforms = [[IA-32]]
| kernel type = [[Real-time operating system|Real-time]] [[microkernel]]
| userland = 
| ui = [[Command-line interface]]
| license = 
| preceded by = [[KeyKOS]]
| succeeded by = CapROS
| website = <!-- {{URL|www.example.org}} -->
}}
'''Extremely Reliable Operating System''' ('''EROS''') is an [[operating system]] developed starting in 1991 at the [[University of Pennsylvania]], and then [[Johns Hopkins University]], and The EROS Group, LLC. Features include automatic data and process [[Orthogonal persistence|persistence]], some preliminary [[real-time operating system|real-time]] support, and [[capability-based security]]. EROS is purely a research operating system, and was never deployed in real world use. {{As of|2005}}, development stopped in favor of a successor system, CapROS.

==Key concepts==
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 (operating system)|kernel]]. That is the only part of the system that can move information from one [[Process (computing)|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-based security|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 (object-oriented programming)|inheritance]]. When software is restructured in this way, several benefits emerge:

*The individual components are most naturally structured as [[event-driven programming|event loops]]. Examples of systems that are commonly structured this way include [[aircraft flight control system]]s (see also [[DO-178B|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|Lipton]]). Confinement, which is the fundamental building block of isolation, has been formally verified to be enforceable by pure capability systems,<ref>{{cite conference |last1=Shapiro |first1=Jonathan S. |last2=Weber |first2=Samuel |date=October 29, 1999 |url=https://flint.cs.yale.edu/cs428/doc/eros-verify.pdf |title=Verifying the EROS Confinement Mechanism |conference=2000 IEEE Symposium on Security and Privacy |location=Berkeley, CA, USA |doi=10.1109/SECPRI.2000.848454}}</ref> 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 (security)|HRU]], but note that it is of course provable for an unbounded set of restricted cases<ref>{{cite web |url=https://www.cs.cmu.edu/~petel/papers/pcc/ |last=Lee |first=Peter |title=Proof-Carrying Code |url-status=dead |archive-url=https://web.archive.org/web/20060922165628/https://www.cs.cmu.edu/~petel/papers/pcc/ |archive-date=September 22, 2006}}</ref>). 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==
The primary developer of EROS was Jonathan S. Shapiro. He was also the driving force behind Coyotos, which was an "evolutionary step"<ref>{{cite web |url=http://www.coyotos.org/docs/misc/eros-comparison.html |title=Differences Between Coyotos and EROS: A Quick Summary |last=Shapiro |first=Jonathan |date=April 2, 2006 |archive-url=https://archive.today/20120731181325/http://www.coyotos.org/docs/misc/eros-comparison.html |archive-date=2012-07-31 |url-status=dead}}</ref> beyond the EROS operating system.<ref name="Coyotos">{{cite mailing list |url=http://www.coyotos.org/pipermail/coyotos-dev/2009-April/001867.html |title=Status of Coyotos |date=April 7, 2009 |access-date=16 March 2022 |mailing-list=coyotos-dev |last=Shapiro |first=Jonathan S. |quote=Active work on Coyotos stopped several months ago, and is unlikely to resume. |archive-url=https://web.archive.org/web/20140724050708/http://www.coyotos.org/pipermail/coyotos-dev/2009-April/001867.html |archive-date=July 24, 2014}}</ref>

The EROS project started in 1991 as a clean-room reconstruction of an earlier operating system, [[KeyKOS]]. KeyKOS was developed by Key Logic, Inc., and was a direct continuation of work on the earlier ''Great New Operating System In the Sky'' ([[GNOSIS]]) system created by Tymshare, Inc. The circumstances surrounding Key Logic's demise in 1991 made licensing KeyKOS impractical. Since KeyKOS did not run on popular commodity processors in any case, the decision was made to reconstruct it from the publicly available documentation.

By late 1992, it had become clear that processor architecture had changed significantly since the introduction of the capability idea, and it was no longer obvious that component-structured systems were practical. [[Microkernel]]-based systems, which similarly favor large numbers of processes and IPC, were facing severe performance challenges, and it was uncertain if these could be successfully resolved. The [[x86]] architecture was clearly emerging as the dominant architecture but the expensive user/supervisor transition latency on the [[Intel 80386|386]] and [[Intel 80486|486]] presented serious challenges for process-based isolation. The EROS project was turning into a research effort, and moved to the [[University of Pennsylvania]] to become the focus of Shapiro's dissertation research. By 1999, a high performance implementation for the [[Pentium]] processor had been demonstrated that was directly performance competitive with the [[L4 microkernel family]], which is known for its exceptional speed in IPC. The EROS confinement mechanism had been formally verified, in the process creating a general formal model for secure capability systems.

In 2000, Shapiro joined the faculty of Computer Science at Johns Hopkins University. At Hopkins, the goal was to show how to ''use'' the facilities provided by the EROS kernel to construct secure and defensible servers at application level. Funded by the [[Defense Advanced Research Projects Agency]] and the [[Air Force Research Laboratory]], EROS was used as the basis for a trusted window system,<ref>{{cite conference |url=https://www.usenix.org/legacy/publications/library/proceedings/sec04/tech/full_papers/shapiro/shapiro.pdf |title=Design of the EROS Trusted Window System |last1=Shapiro |first1=Jonathan S. |last2=Vanderburgh |first2=John |last3=Northup |first3=Eric |last4=Chizmadia |first4=David |conference=13th USENIX Security Symposium |date=2004 |location=San Diego, CA, USA}}</ref> a high-performance, defensible network stack,<ref>{{cite conference |url=https://www.usenix.org/legacy/publications/library/proceedings/usenix04/tech/general/full_papers/sinha/sinha.pdf |title=Network Subsystems Reloaded: A High-Performance, Defensible Network Subsystem |last1=Sinha |first1=Anshumal |last2=Sarat |first2=Sandeep |last3=Shapiro |first3=Jonathan S. |conference=2004 USENIX Annual Technical Conference |date=2004 |location=Boston, MA, USA}}</ref> and the beginnings of a secure web browser. It was also used to explore the effectiveness of lightweight static checking.<ref>{{cite web |url=http://www.eros-os.org/papers/ccs04.pdf |title=Using Build-Integrated Static Checking to Preserve Correctness Invariants |last1=Chen |first1=Hao |last2=Shapiro |first2=Jonathan S. |archive-url=https://web.archive.org/web/20160303194224/http://www.eros-os.org/papers/ccs04.pdf |archive-date=March 3, 2016 |url-status=dead}}</ref> In 2003, some very challenging security issues were discovered<ref>{{cite conference |url=https://srl.cs.jhu.edu/courses/600.439/shap03vulnerabilities.pdf |title=Vulnerabilities in Synchronous IPC Designs |last=Shapiro |first=Jonathan S. |conference=2003 Symposium on Security and Privacy |date=2003 |location=Berkeley, CA, USA |doi=10.1109/SECPRI.2003.1199341}}</ref> that are intrinsic to ''any'' system architecture based on synchronous IPC primitives (notably including EROS and L4). Work on EROS halted in favor of Coyotos, which resolved these issues.{{citation needed|date=March 2022}}

{{As of|2006}}, EROS and its successors are the only widely available capability systems that run on commodity hardware.

==Status==
Work on EROS and Coyotos by the original group has halted, but there is a successor system.<ref name="Coyotos" /> CapROS (Capability Based Reliable Operating System), a successor of EROS, is an open-source, commercially oriented operating system.<ref>{{cite journal |last=Chakraborty |first=Pinaki |title=Research purpose operating systems &ndash; a wide survey |journal=GESJ: Computer Science and Telecommunications |volume=3 |number=26 |year=2010 |issn=1512-1232}}</ref>

==See also==
*[[Nanokernel]]

==References==
{{Reflist}}

===Journals===
#<span id="Lipton">{{Cite journal |last1=Lipton |first1=R. J. |last2=Snyder |first2=L. |date=July 1977 |title=A Linear Time Algorithm for Deciding Subject Security |journal=Journal of the ACM |volume=24 |issue=3 |pages=455–464|doi=10.1145/322017.322025 |s2cid=291367 |doi-access=free }}</span>
#<span id="HRU">{{Cite journal |last1=Harrison |first1=Michael A.|author1-link=Michael A. Harrison |last2=Ruzzo |first2=W. L. |last3=Ullman |first3=Jeffrey D. |author3-link=Jeffrey Ullman |date=August 1976 |title=Protection in Operating Systems |journal=Communications of the ACM |volume=19 |issue=8 |pages=461–471|doi=10.1145/360303.360333 |s2cid=5900205 |doi-access=free }}</span>

==External links==
* {{webarchive|url=https://web.archive.org/web/20160304064914/http://www.eros-os.org/eros.html|date=March 4, 2016|title=EROS home page}}

{{Object-capability security}}
{{Real-time operating systems}}
{{Microkernel}}

[[Category:Microkernels]]
[[Category:Real-time operating systems]]
[[Category:Capability systems]]
[[Category:X86 operating systems]]