Eros (Mikrokernel)

EROS
Entwickler Universität von Pennsylvania
Johns Hopkins Universität
Die Eros Group, LLC
Geschrieben in C
OS -Familie Fähigkeit basiert
Arbeitszustand Abgesetzt
Erstveröffentlichung 1991; Vor 31 Jahren
Neueste Erscheinung Final / 2005; Vor 17 Jahren
Marketingziel Forschung
Verfügbar in Englisch
Aktualisieren Sie die Methode Kompilieren von Quellcode
Plattformen IA-32
Kernel Typ Echtzeit Mikrokernel
Standard
Benutzeroberfläche		 Befehlszeilenschnittstelle
Vorausgegangen von Kekos
gefolgt von Capros

Äußerst zuverlässiges Betriebssystem (EROS) ist ein Betriebssystem entwickelt ab 1991 bei der Universität von Pennsylvania, und dann Johns Hopkins Universitätund die Eros Group, LLC. Zu den Funktionen gehören automatische Daten und Prozess Beharrlichkeit, einige vorläufig Echtzeit Unterstützung und Fähigkeitsbasierte Sicherheit. Eros ist ein reines Forschungsbetriebssystem und wurde nie in der realen Welt eingesetzt. Ab 2005, Entwicklung hörte zugunsten eines Nachfolgesystems auf, Capros.

Schlüssel Konzepte

Das übergeordnete Ziel des EROS -Systems (und seiner Verwandten) besteht darin, auf der Ebene des Betriebssystems eine starke Unterstützung für die effiziente Umstrukturierung kritischer Anwendungen in kleine Kommunikationskomponenten zu leisten. Jede Komponente kann mit den anderen nur durch geschützte Schnittstellen kommunizieren und vom Rest des Systems isoliert. EIN geschützte SchnittstelleIn diesem Zusammenhang wird das durch den niedrigsten Teil des Betriebssystems durchgesetzt, die Kernel. Dies ist der einzige Teil des Systems, der Informationen von einem verschieben kann Prozess zum anderen. Es hat auch die vollständige Kontrolle über die Maschine und kann (falls ordnungsgemäß konstruiert) nicht umgangen werden. In Eros ist der Kernel-bereitgestellte Mechanismus, mit dem ein Bestandteil die Dienste eines anderen nennt und aufgreift, a Fähigkeit, verwenden Interprozesskommunikation (IPC). Durch die Durchsetzung von mit Fähigkeiten geschützten Schnittstellen stellt der Kernel sicher, dass alle Kommunikationen zu einem Prozess über eine absichtlich exportierte Schnittstelle eintreffen. Es stellt auch sicher, dass das nein Der Aufruf ist möglich, es sei denn, die aufgerufene Komponente verfügt über eine gültige Fähigkeit zur aufgerufenen Komponente. Der Schutz der Fähigkeitssysteme wird erreicht, indem die Ausbreitung von Fähigkeiten von einer Komponente auf eine andere eingeschränkt wird, häufig durch eine Sicherheitsrichtlinie, die bezeichnet wird Einschränkung.

Fähigkeitssysteme fördern natürlich die Komponentenbasis-Softwarestruktur. Dieser organisatorische Ansatz ähnelt dem Programmiersprache Konzept von Objekt orientierte Programmierungtritt aber bei größerer Granularität auf und beinhaltet das Konzept von nicht Nachlass. Wenn die Software auf diese Weise umstrukturiert wird, ergeben sich mehrere Vorteile:

  • Die einzelnen Komponenten sind am natürlichsten strukturiert als Ereignisschleifen. Beispiele für Systeme, die auf diese Weise üblicherweise strukturiert sind Flugzeugflugsteuerungssysteme (siehe auch DO-178B-Software-Überlegungen in der Zertifizierung von Airborne Systems und Geräte) und Telefonschaltsysteme (siehe 5ES -Schalter). Für diese Systeme wird eine ereignisorientierte Programmierung hauptsächlich aufgrund der Einfachheit und Robustheit ausgewählt, die wesentliche Eigenschaften in lebenskritischen und missionskritischen Systemen sind.
  • Komponenten werden kleiner und individuell testbar, was dazu beiträgt, Mängel und Fehler leichter zu isolieren und zu identifizieren.
  • Die Isolation jeder Komponente aus den anderen schränkt den Umfang eines Schadens ein, der auftreten kann, wenn etwas schief geht oder die Software schlecht benimmt.

Insgesamt führen diese Vorteile zu messbar robusteren und sichereren Systemen. Das Plessey System 250 war ein System, das ursprünglich für die Verwendung in Telefonie-Switches entwickelt wurde, die speziell aus Gründen der Robustheit ausgewählt wurde.

Im Gegensatz zu vielen früheren Systemen sind die Fähigkeiten die nur Mechanismus zur Benennung und Verwendung von Ressourcen in Eros, was es manchmal als als bezeichnet wird rein Fähigkeitssystem. Im Gegensatz, Ibm i ist ein Beispiel für ein kommerziell erfolgreiches Fähigkeitssystem, aber kein reines Fähigkeitssystem.

Architekturen von reinen Fähigkeiten werden durch gut getestete und reife mathematische Sicherheitsmodelle unterstützt. Diese wurden verwendet, um formell zu demonstrieren, dass fähigbasierte Systeme sichergestellt werden können, wenn sie korrekt implementiert werden. Es hat sich gezeigt Lipton). Die Beschränkung, die grundlegende Bausteine ​​der Isolation ist, wurde formell überprüft, um durch reine Fähigkeitssysteme durchsetzbar zu sein.[1] und wird durch die Eros auf die praktische Umsetzung reduziert Konstrukteur und die Kekos Fabrik. Für einen anderen primitiven Schutzmechanismus besteht keine vergleichbare Überprüfung. Es gibt ein grundlegendes Ergebnis in der Literatur, die zeigt Sicherheit ist im allgemeinen Fall mathematisch unentscheidbar (siehe HRU, aber beachten Sie, dass es natürlich für einen unbegrenzten Satz eingeschränkter Fälle nachweisbar ist[2]). Von größerer praktischer Bedeutung, es wurde nachgewiesen, dass die Sicherheit nachgewiesen wurde FALSCH Für alle primitiven Schutzmechanismen, die in aktuellen Rohstoffbetriebssystemen versandt werden. Sicherheit ist eine notwendige Voraussetzung für die erfolgreiche Durchsetzung von irgendein Sicherheitsrichtlinie. In praktischer Hinsicht bedeutet dieses Ergebnis, dass es nicht möglich ist allgemein gesagt Um aktuelle Warensysteme zu sichern, ist jedoch potenziell möglich, Fähigkeiten basierende Systeme zu sichern bereitgestellt Sie werden mit ausreichender Pflege implementiert. Weder Eros noch Keykos wurden jemals erfolgreich durchdrungen, und ihre Isolationsmechanismen wurden nie erfolgreich von einem Insider -Angreifer besiegt, aber es ist nicht bekannt, ob die beiden Implementierungen vorsichtig genug waren. Ein Ziel des Coyotos -Projekts war es, zu demonstrieren, dass die Isolation und Sicherheit von Komponenten durch die Anwendung von Softwareverifizierungstechniken definitiv erreicht wurden.

Das L4.sec -System, das Nachfolger der L4 Microkernel -Familie, ist ein Fähigkeitssystem und wurde erheblich von den Ergebnissen des EROS-Projekts beeinflusst. Der Einfluss ist gegenseitig, da die EROS-Arbeit an der Hochleistungsbevölkerung stark von motiviert wurde Jochen liestkeErfolge mit dem L4 Microkernel -Familie.

Geschichte

Der Hauptentwickler von Eros war Jonathan S. Shapiro. Er war auch die treibende Kraft hinter Coyotos, was ein "evolutionärer Schritt" war[3] Jenseits des EROS -Betriebssystems.[4]

Das EROS-Projekt begann 1991 als Reinigungsrekonstruktion eines früheren Betriebssystems. Kekos. Keykos wurde von Key Logic, Inc. entwickelt und war eine direkte Fortsetzung der Arbeiten am früheren Tolles neues Betriebssystem am Himmel (GNOSIS) System, das von Tymshare, Inc. erstellt wurde. Die Umstände im Zusammenhang mit dem Tod von Key Logic im Jahr 1991 machten die Lizenzierung von Keykos unpraktisch. Da Keykos in keinem Fall auf populären Rohstoffverarbeitern betrieben wurde, wurde die Entscheidung getroffen, sie aus der öffentlich verfügbaren Dokumentation zu rekonstruieren.

Bis Ende 1992 war klar geworden, dass sich die Prozessorarchitektur seit der Einführung der Fähigkeitsidee erheblich verändert hatte, und es war nicht mehr offensichtlich, dass Komponenten-strukturierte Systeme praktisch waren. Mikrokernel-Basierte Systeme, die in ähnlicher Weise eine große Anzahl von Prozessen und IPC bevorzugen, standen mit schwerwiegenden Leistungsherausforderungen konfrontiert, und es war ungewiss, ob diese erfolgreich gelöst werden konnten. Das x86 Die Architektur wurde eindeutig als dominierende Architektur entwickelt, aber die teure Benutzer-/Supervisor -Übergangslatenz auf der 386 und 486 stellte ernsthafte Herausforderungen für prozessbasierte Isolation vor. Das EROS -Projekt verwandelte sich zu Forschungsanstrengungen und wechselte in die Universität von Pennsylvania im Mittelpunkt der Dissertationsforschung von Shapiro werden. Bis 1999 eine Hochleistungs -Implementierung für die Pentium Der Prozessor wurde nachgewiesen, dass dies direkt Leistung mit dem wettbewerbsfähig war L4 Microkernel -Familie, was für seine außergewöhnliche Geschwindigkeit in IPC bekannt ist. Der EROS -Begrenzungsmechanismus wurde offiziell überprüft und dabei ein allgemeines formales Modell für sichere Fähigkeitssysteme erstellt.

Im Jahr 2000 trat Shapiro der Fakultät für Informatik der Johns Hopkins University bei. In Hopkins war es das Ziel, zu zeigen, wie es geht verwenden Die vom Eros -Kernel bereitgestellten Einrichtungen zum Bau sicherer und verteidigungsfähiger Server auf Anwendungsebene. Finanziert von der Verteidigung Advanced Research Projects Agency und die Luftwaffenforschungslabor, Eros wurde als Grundlage für ein vertrauenswürdiges Fenstersystem verwendet,[5] Ein Hochleistungs-Netzwerkstapel, verteidigungsfähiger Netzwerkstapel,[6] und die Anfänge eines sicheren Webbrowsers. Es wurde auch verwendet, um die Wirksamkeit der leichten statischen Überprüfung zu untersuchen.[7] Im Jahr 2003 wurden einige sehr herausfordernde Sicherheitsprobleme entdeckt[8] das sind intrinsisch zu irgendein Systemarchitektur basierend auf synchronen IPC -Primitiven (insbesondere einschließlich Eros und L4). Die Arbeiten an Eros hielten zugunsten von Coyotos ein, was diese Probleme gelöst hat.

Ab 2006Eros und seine Nachfolger sind die einzigen weit verbreiteten Fähigkeitssysteme, die auf Warenhardware ausgeführt werden.

Status

Die Arbeit an Eros und Coyotos durch die ursprüngliche Gruppe hat gestoppt, aber es gibt ein Nachfolgesystem.[4] Das Capros Das System baut direkt aus der Eros -Codebasis auf. Capros wird voraussichtlich in verschiedenen kommerziellen Einsätzen veröffentlicht.

Siehe auch

Verweise

  1. ^ Shapiro, Jonathan S.; Weber, Samuel (29. Oktober 1999). Überprüfung des EROS -Begrenzungsmechanismus (Bericht). Archiviert von das Original am 3. März 2016.
  2. ^ Lee, Peter. "Proof-Carrying-Code". Archiviert von das Original am 22. September 2006.
  3. ^ Shapiro, Jonathan (2. April 2006). "Unterschiede zwischen Coyotos und Eros: Eine schnelle Zusammenfassung". Archiviert von das Original Am 2012-07-31.
  4. ^ a b Shapiro, Jonathan S. (7. April 2009). "Status von Coyotos". Coyotos-dev (Mailingliste). Archiviert von das Original am 24. Juli 2014. Abgerufen 16. März 2022. Aktive Arbeiten an Coyotos haben vor einigen Monaten stehen und es ist unwahrscheinlich, dass sie wieder aufgenommen werden.
  5. ^ Shapiro, Jonathan S.; Vanderburgh, John; Northup, Eric; Chizmadia, David. "Design des Eros -vertrauenswürdigen Fenstersystems". Archiviert von das Original am 3. März 2016.
  6. ^ Sinha, Anshumal; Sarat, Sandeep; Shapiro, Jonathan S. "Network-Subsysteme neu geladen: Ein hoher Leistungssteiger, verteidigbarer Netzwerksubsystem". Archiviert von das Original am 3. März 2016.
  7. ^ Chen, Hao; Shapiro, Jonathan S. "Verwenden von buildintegrierten statischen Überprüfungen zur Erhaltung der Korrektheitsinvarianten" (PDF). Archiviert von das Original (PDF) am 3. März 2016.
  8. ^ Shapiro, Jonathan S. "Schwachstellen in synchronen IPC -Designs". Archiviert von das Original am 3. März 2016.

Zeitschriften

  1. Lipton, R. J.; Snyder, L. (Juli 1977). "Ein linearer Zeitalgorithmus für die Entscheidung der Betreffsicherheit". Journal of the ACM. 24 (3): 455–464.
  2. Harrison, Michael A.; Ruzzo, W. L.; Ullman, Jeffrey D. (August 1976). "Schutz in Betriebssystemen". Kommunikation der ACM. 19 (8): 461–471.

Externe Links