Advanced Operating Systems

Transkript

1 Advanced Operating Systems Hans-Albrecht Schindler Wintersemester 2016/17 Teil C: Betriebssystem-Architekturkonzepte Abschnitt 9: Exokernel-Betriebssysteme CSI Technische Universität Ilmenau -

2 9.1 Einleitung Herkömmliche Betriebssysteme Betriebssystem: transformiert die reale Maschine Hardware in virtuelle Maschine mit komfortableren Schnittstellen (vergl. Abschnitt 2.3/Folie 15) Anwendungen API Betriebssystem virtuelle Maschine Hardware Schnittstelle zu Anwendungen (API): bietet dabei exakt die gleichen high-level -Abstraktionen der Hardware für alle Anwendungen an, z.b. Prozesse: gleiches Prozessmodell Dateien: gleiches Dateimodell Adressräume: gleiches Modell Interprozesskommunikation: für alle Anwendungen gleiche Möglichkeiten 9Exokernel-Betriebssysteme / 9.1 Einleitung ws 2016/17 H.-A. Schindler Folie: 9-2

3 Einleitung Problem dabei diese Verfahrensweise: kann Performanz u. Implementierungsspielraum für Applikationen in starkem Maße behindern, insbesondere weil: 1.. sie verhindert, dass Applikationen Vorteile (domänen-)spezifischer Optimierungen nutzen können, 2.. sie Änderungenan der Implementierung existierender Abstraktionen behindert u. 3.. sie Flexibilität des Applikationsentwicklers einschränkt. (Neue Abstraktionen nur durch umständliche Emulation oberhalb der existierenden Abstraktionen realisierbar, falls überhaupt möglich) 9Exokernel-Betriebssysteme / 9.1 Einleitung ws 2016/17 H.-A. Schindler Folie: 9-3

4 Philosophie von Exokernel-Architekturen 9.2 Architekturprinzip Zur Überwindung dieser Einschränkungen: Exokernel-Ansatz spezifiziert alternative Betriebssystemarchitektur: Anwendungen (APIs) Library-Betriebssysteme (kleiner) Exokern Hardware grobkörnige Darstellung einer Exokern-Architektur 9Exokernel-Betriebssysteme / 9.2 Architekturprinzip ws 2016/17 H.-A. Schindler Folie: 9-4

5 Exokernel basierte Betriebssystem-Architektur ( feinkörniger ) gcc API Spezialisierter WWW-Server Anwendungen Virtuelle Speicherverwaltung Dateisystem Netz ein Library- BS Virtuelle Speicherverwaltung Dateisystem Netz Teilmenge des Library-BS (kleiner) Exokern Hardware Speicherseiten Festplatte Netzwerk 9Exokernel-Betriebssysteme / 9.2 Architekturprinzip Darstellung nach[engler98] Bild 1-1 S.12 ws 2016/17 H.-A. Schindler Folie: 9-5

6 Grundgedanken dieser Architektur Trennung von Schutz u. Management der Ressourcen Ressourcen-Schutz: verbleibt bei Rest-Betriebssystem dem Exokernel Ressourcen-Management: wird - soweit wie möglich mittels der Library-Betriebssysteme - den einzelnennicht-vertrauenswürdigen ( non-trusted ) Anwendungen zugeteilt Resultat: 1. traditionelle Verwendung der starren durch jeweiliges Betriebssystem vorgegebenen Abstraktionen der Hardware umgangen 2. somit: zu bestimmter Anwendung passende Abstraktionen sehr einfach realisierbar 3. hierdurch: auch Verwendung eigener u. fremder Innovationen wesentlich erleichtert 9Exokernel-Betriebssysteme / 9.2 Architekturprinzip ws 2016/17 H.-A. Schindler Folie: 9-6

7 Trennung von Schutz u. Management der Ressourcen Exokernel: definiert nur low-level -Schnittstelle Grundgedanken dieser Architektur Low-level = so low (niedrig) wie nur irgend möglich, idealerweise die unmittelbare Hardware-Schnittstelle Exokernel sollte also z.b. Speicher schützen, ohne zu verstehen, wie dieser verwaltet wird Library-Betriebssysteme: implementieren darauf jeweils geeignete high-level -Abstraktionen Applikationsprogrammierer: wählen geeignete Library-Betriebssysteme bzw. schreiben ihre eigenen 9Exokernel-Betriebssysteme / 9.2 Architekturprinzip ws 2016/17 H.-A. Schindler Folie: 9-7

8 Grundgedanken dieser Architektur Exokernel-Techniken Der Exokernel implementiert: Multiplexing der Hardware-Ressourcen exportiert: geschützte Hardware-Ressourcen Hierzu 3 Techniken: 1. securebinding : erlaubt sichere Verwendung von Hardware-Ressourcen durch Applikationen u. Behandlung von Ereignissen. 2. visibleresourcerevocation : beteiligt Applikationen am Entzug von Ressourcen über Ressourcen-Entzugsprotokoll. 3. Abort-Protokoll: erlaubt Exokernel gewaltsame Beendigung von Ressourcenzuordnungen bei unkooperativen Applikationen 9Exokernel-Betriebssysteme / 9.2 Architekturprinzip ws 2016/17 H.-A. Schindler Folie: 9-8

9 Exokernel-Techniken Secure Binding. ist Protection-Mechanismus, der Authorisierung zur Benutzung einer Ressource von tatsächlicher Benutzung trennt. Zur Implementierung 3 Basis-Techniken anwendbar: 1. Hardware-Mechanismen 2. Software-Caching 3. Downloading von Applikationscode Einfach ausgedrückt: Secure Binding erlaubt einem Exokernel Schutz von Ressourcen, ohne diese genau verstehen zu müssen. 9Exokernel-Betriebssysteme / 9.2 Architekturprinzip ws 2016/17 H.-A. Schindler Folie: 9-9

10 Exokernel-Techniken Visible Resource Revocation ( sichtbarer Ressourcen-Entzug) Traditionelle Betriebssysteme: entziehen Ressourcen unsichtbar (invisible), d.h. ohne Mitwirkung der Anwendungen Vorteil:im allgemeinen geringere Latenzzeiten Nachteile: Anwendungen(hier: die Library-Betriebssysteme) erhalten keine Kenntnis über Entzug u. wissen z.b. nichts über Ressourcenknappheit etc. Exokernel-Betriebssysteme: entziehen(meiste) Ressourcen sichtbar sogar Prozessor am Ende einer Zeitscheibe Vorteil: ggf. Erhöhung der Effizienz (bei Prozessor: nur tatsächlich benötigte Zustandskomponenten bei Entzug tatsächlich gespeichert) Nachteil: bei sehr häufigem Entzughat unsichtbarer Entzug höhere Performanz 9Exokernel-Betriebssysteme / 9.2 Architekturprinzip ws 2016/17 H.-A. Schindler Folie: 9-10

11 Exokernel-Techniken Abort-Protokoll ermöglicht Exokernel: Ressourcenentzug bei unkooperativen Library-Betriebssystemen (Verweigerung der Rückgabe, zu späte Rückgabe, >). mildes Abort-Protokoll: ermöglicht sinnvolle Reaktion des Library-Betriebssystems (Library-Betriebssystem erhält Repossession -Ausnahme zugestanden, so dass auf Entzug geeignet reagiert werden kann.) 9Exokernel-Betriebssysteme / 9.2 Architekturprinzip ws 2016/17 H.-A. Schindler Folie: 9-11

12 9.3 Adaptivität als unterstützte nichtfunktionale Eigenschaft Was macht Exokern-Architekturen adaptiv(er)? Abstraktionen u. Mechanismen des Betriebssystems: können den Erfordernissen der Anwendungen angepasst werden Dies bewirkt gleichzeitig: beträchtliche Effizienzsteigerungen! 9Exokernel-Betriebssysteme / 9.3 Adaptivität als unterstützte NFE ws 2016/17 H.-A. Schindler Folie: 9-12

13 9.4 Fallbeispiele 1. Aegis u. das Library-BS ExOS (MIT: Engler) 2. Xok(MIT) 3. Nemesis (Pegasus-Projekt, EU) 4. IntraServices(Frankreich) 5. XOmB (Projekt an der University of Pittsburgh) Exokernel-Betriebssysteme / 9.4 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 9-13

14 An Aegis/ExOS demonstrierte Eigenschaften von Exokernen Aegis/ExOS 1. realisierbar: sehr effiziente Exokerne Grundlage:begrenzte Anzahl einfacher Primitiven, die enthalten sein müssen 2. realisierbar: sicheres Hardware-Multiplexing auf unterer Ebene ( lowlevel ) mit geringem Overhead 3. Traditionelle Abstraktionen: wie virtueller Speicher u. Interprozesskommunikation auf Anwendungsebene effizient implementierbar jeweilige Abstraktion: dann auf einfache Weise erweiterbar, spezialisierbar bzw. ersetzbar 4. für Anwendungen: stark spezialisierte Implementierungen von Abstraktionen generierbar, die genau auf Funktionalität u. Performanz- Anforderungen dieser Anwendung zugeschnitten 9Exokernel-Betriebssysteme / 9.4 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 9-14

15 Aegis/ExOS An Aegis/ExOS demonstrierte Eigenschaften von Exokernen 5. abgesicherte Steuerungsübergabe bei Aegis: 7-mal schnellerals damals beste Implementierung [vergl. Liedtke: Improving IPC by kernel design ] 6. Ausnahmebehandlung bei Aegis: 5-mal schneller als bei damals bester Implementierung 7. durch Aegis: ExOS erhält Flexibilität, die mit Mikrokernel-Systemen nicht erreichbar z.b. virtuelle Speichertechnik: auf Anwendungsebene implementiert, wo diese sehr einfach mit DSM-Systemen u. Garbage-Kollektoren verknüpfbar 8. Aegis erlaubt Anwendungen: Konstruktion effizienter IPC-Primitiven. (Im Gegensatz dazu können nicht vertrauenswürdige Anwendungen oberhalb eines Mikrokernels keinerlei spezialisierte IPC-Primitiven realisieren.) 9Exokernel-Betriebssysteme / 9.4 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 9-15

16 Xok/ExOS 9Exokernel-Betriebssysteme / 9.4 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 9-16

17 Nemesis Hintergrund Nemesis: Betriebssystem aus EU-Verbundprojekt Pegasus zur Realisierung eines verteilten multimediafähigen Systems 1. Version: 1994/95 Entwurfsprinzipien: 1. Anwendungen:sollen Freiheit haben, Betriebsmittel in für sie geeignetster Weise zu nutzen (= Exokernel-Prinzip) 2. Realisierung als sog. vertikal strukturiertes Betriebssystem: weitaus meiste Betriebssystem-Funktionalität: innerhalb der Anwendungen ausgeführt (= Exokernel-Prinzip) 9Exokernel-Betriebssysteme / 9.4 Fallbeispiele wegen Echtzeitanforderungen durch Multimedia: Vermeidung von Client-Server-Prinzip wegen so schlecht beherrschbarer zeitlicher Verzögerungen (neu) ws 2016/17 H.-A. Schindler Folie: 9-17

18 Struktur des Betriebssystems Nemesis Darstellung nach[reed+97] Bild 1.1 S.2 9Exokernel-Betriebssysteme / 9.4 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 9-18

19 Unterstützte nichtfunktionale Eigenschaften A. Laufzeiteigenschaften 9.5 Exokernel: Zusammenfassung 1. Adaptivität Betriebssystem-Abstraktionen u. Mechanismen für jede Anwendung optimal anpassbar 2. Effizienz beachtliche Effizienzsteigerungen bei Anwendungen durch angepasste Betriebssystem-Abstraktionen (vergl. oben) 3. Echtzeitfähigkeit Vermeidungdes Mikrokern-Architekturen inhärent innewohnenden Client-Server-Prinzips mit potentiell möglichen nichtdeterministischen Verzögerungen durch Wartesituationen 9Exokernel-Betriebssysteme / 9.5 Exokernel: Zusammenfassung ws 2016/17 H.-A. Schindler Folie: 9-19

20 Zusammenfassung Unterstützte nichtfunktionale Eigenschaften B. Evolutionseigenschaften 1. Wartbarkeit Veränderungen (Beheben von Fehlern, Anpassungen) leicht möglich, ähnlich wie bei Mikrokernen 2. Portierbarkeit in ähnlicher Weise wie bei Mikrokern-Architekturen (aber keine Untersuchungen bezüglich der Portierung bzw. Neuimplemtierung des Exokerns selbst bekannt) 3. Offenheit und Erweiterbarkeit vollständig oder teilweise neue Library-Betriebssysteme einfach integrierbar Bezüglich aller 3 Eigenschaften: Änderungen betreffen wie beim Mikrokernel oft nur einzelne Komponenten 9Exokernel-Betriebssysteme / 9.5 Exokernel: Zusammenfassung ws 2016/17 H.-A. Schindler Folie: 9-20

21 Zusammenfassung Weitere Vorteile von Exokernen höhere Modularität natürliche Unterstützung für Baukastensysteme 9Exokernel-Betriebssysteme / 9.5 Exokernel: Zusammenfassung ws 2016/17 H.-A. Schindler Folie: 9-21

22 Zusammenfassung Nachteile von Exokernen Gegenüber Betriebssystemen mit einheitlichen Abstraktionen u. Mechanismen für alle Anwendungen: wesentlich erhöhter Entwurfsund Entwicklungsaufwand für jede Anwendung: müssen günstigste Abstraktionen u. Mechanismen gefunden und implementiert werden Letzteres: dürfte Hauptgrund für die bisher geringe Akzeptanz von Exokernen sein 9Exokernel-Betriebssysteme / 9.5 Exokernel: Zusammenfassung ws 2016/17 H.-A. Schindler Folie: 9-22

23 1. [Engler+95] Engler, Dawsen R. u.a.: Exokernel: An Operating System Architecture for Application-Level Resource Management 15th ACM Symposium on Operating System Principles, 1995, S Literatur 2. [Engler98] Engler, Dawsen R.: The Exokernel Operating System Architecture Ph.D. Thes. Massachusetts Institute of Technology, 1998 (im Internet) 3. [Engler+97] Kaashock, M. Frans / Engler, Dawsen R. u.a.: ApplicationPerformance andflexibilityofexokernelsystems, 1997 (im Internet) 4. [Reed+97] Reed, Dickon u.a.: Nemesis the Kernel. Overview, 1997 (in: Pegasus-Veröffentlichungen: im Internet) 9Exokernel-Betriebssysteme / Literatur ENDE Abschnitt 9 ws 2016/17 H.-A. Schindler Folie: 9-23