diff --git a/Advanced Operating Systems.md b/Advanced Operating Systems.md index a7964a9..14c1bb7 100644 --- a/Advanced Operating Systems.md +++ b/Advanced Operating Systems.md @@ -185,7 +185,7 @@ Mobile und eingebettete Systeme (eine kleine Auswahl) - Automobile - Steuerung von Motor-und Bremssystemen - Fahrsicherheit - - Insasseninformation (und –unterhaltung) + - Insasseninformation (und -unterhaltung) - (teil-) autonomes Fahren - verteilte Sensornetze (WSN) - Chipkarten @@ -195,15 +195,15 @@ Mobile und eingebettete Systeme (eine kleine Auswahl) - Digitalkameras Beispiel: Weltraumerkundung -- Cassini-Huygens (1997–2017) +- Cassini-Huygens (1997-2017) - Radionuklidbatterien statt Solarzellen - Massenspeicher: SSDs statt Magnetbänder -- Rosetta (2004–2016) +- Rosetta (2004-2016) - 31 Monate im Energiesparmodus -- Opportunity (2003–2019) +- Opportunity (2003-2019) - geplante Missionsdauer: 90 d - Missionsdauer insgesamt: >> 5000 d -- Hayabusa (2003–2010) +- Hayabusa (2003-2010) - Beschädigung der Energieversorgung - Energiesparmodus: um 3 Jahre verzögerte Rückkehr - Voyager 1 (1977 bis heute) @@ -773,6 +773,549 @@ Implementierung # Robustheit und Verfügbarkeit +## Motivation +- allgemein: verlässlichkeitskritischeAnwendungsszenarien + - Forschung in garstiger Umwelt + - Weltraumerkundung + - hochsicherheitskritische Systeme: + - Rechenzentren von Finanzdienstleistern + - Rechenzentren von Cloud-Dienstleistern + - hochverfügbare System: + - all das bereits genannte + - öffentliche Infrastruktur(Strom, Fernwärme, ...) + - HPC (high performancecomputing) + +## Allgemeine Begriffe +- Verlässlichkeit, Zuverlässigkeit (dependability) + - übergeordnete Eigenschaft eines Systems [ALRL04] + - Fähigkeit, eine Leistungzu erbringen, der man berechtigterweise vertrauen kann +- Taxonomie: umfasst entsprechend Definition die Untereigenschaften + 1. Verfügbarkeit (availability) + 2. Robustheit (robustness, reliability + 3. (Funktions-) Sicherheit (safety) + 4. Vertraulichkeit (confidentiality) + 5. Integrität (integrity) + 6. Wartbarkeit (maintainability) (vgl.: evolutionäre Eigenschaften) +- 1., 4. & 5. auch Untereigenschaften von IT-Sicherheit (security) +- $\rightarrow$ nicht für alle Anwendungen sind alle Untereigenschaften erforderlich + +### Robustheitsbegriff +- Teil der primären Untereigenschaften von Verlässlichkeit: Robustheit (robustness, reliability) +- Ausfall: beobachtbare Verminderung der Leistung, die ein System tatsächlich erbringt, gegenüber seiner als korrekt spezifizierten Leistung +- Robustheit: Verlässlichkeit unter Anwesenheit externer Ausfälle (= Ausfälle, deren Ursache außerhalb des betrachteten Systems liegt) +- im Folgenden: kurze Systematik der Ausfälle ... + +### Fehler und Ausfälle ... +- Fehler $\rightarrow$ fehlerhafter Zustand $\rightarrow$ Ausfall + - grundlegende Definitionen dieser Begriffe (ausführlich: [ALRL04, AvLR04] ): + - Ausfall (failure): liegt vor, wenn tatsächliche Leistung(en), die ein System erbringt, von als korrekt spezifizierter Leistung abweichen + - fehlerhafter Zustand ( error ): notwendige Ursacheeines Ausfalls (nicht jeder error muss zu failure führen) + - Fehler ( fault ): Ursache für fehlerhaften Systemzustand ( error ), z.B. Programmierfehler + - ![](Assets/AdvancedOperatingSystems-fehler.png) + +### ... und ihre Vermeidung +- Umgang mit ... + - faults: + - Korrektheit testen + - Korrektheit beweisen($\rightarrow$ formale Verifikation) + - errors: + - Maskierung, Redundanz + - Isolationvon Subsystemen + - $\rightarrow$ Isolationsmechanismen + - failures: + - Ausfallverhalten (neben korrektem Verhalten) spezifizieren + - Ausfälle zur Laufzeit erkennen und Folgen beheben, abschwächen... + - $\rightarrow$ Micro-Reboots + +## Fehlerhafter Zustand +- interner und externer Zustand (internal & external state) + - externer Zustand (einer Systems oder Subsystems): der Teil des Gesamtzustands, der an externer Schnittstelle (also für das umgebende (Sub-) System) sichtbar wird + - interner Zustand: restlicher Teilzustand + - (tatsächlich) erbrachte Leistung: zeitliche Folge externer Zustände +- Beispiele für das System ( Betriebssystem-) Kernel : + - Subsysteme: Dateisystem, Scheduler, E/A, IPC, ..., Gerätetreiber + - fault : Programmierfehler im Gerätetreiber + - externer Zustand des Treibers (oder des Dateisystems, Schedulers, E/A, IPC, ...) ⊂ interner Zustand des Kernels + - ![](Assets/AdvancedOperatingSystems-treiber-kernel.png) + +### Fehlerausbreitung und (externer) Ausfall +- Wirkungskette: + -[X] Treiber-Programmierfehler (fault) + -[X] fehlerhafter interner Zustand des Treibers (error) + - Ausbreitung dieses Fehlers ( failure des Treibers) + - = fehlerhafter externer Zustand des Treibers + - = fehlerhafter interner Zustand des Kernels( error ) + - = Kernelausfall!( failure ) + - [X] Auswirkung: fehlerhafter interner Zustand eines weiteren Kernel-Subsystems (z.B. error des Dateisystems) +- $\rightarrow$ Robustheit: Isolationsmechanismen +- ![](Assets/AdvancedOperatingSystems-treiber-kernel-fehler.png) + +## Isolationsmechanismen +- im Folgenden: Isolationsmechanismen für robuste Betriebssysteme + - durch strukturierte Programmierung + - durch Adressraumisolation +- es gibt noch mehr: Isolationsmechanismen für sichere Betriebssysteme + - all die obigen... + - durch kryptografische Hardwareunterstützung: Enclaves + - durch streng typisierte Sprachen und managed code + - durch isolierte Laufzeitumgebungen: Virtualisierung + +### Strukturierte Programmierung +Monolithisches BS... in historischer Reinform: +- Anwendungen +- Kernel + - gesamte BS-Funktionalität + - programmiert als Sammlung von Prozeduren + - jede darf jede davon aufrufen + - keine Modularisierung + - keine definierten internen Schnittstellen + +#### Monolithisches Prinzip +- Ziel: Isolation zwischen Anwendungen und Betriebssystem +- Mechanismus: Prozessor-Privilegierungsebenen ( user space und kernel space ) +- Konsequenz für Strukturierung des Kernels: Es gibt keine Strukturierung des Kernels ... +- ... jedenfalls fast: Ablauf eines Systemaufrufs (Erinnerung) + - ![](Assets/AdvancedOperatingSystems-systemaufruf.png) + +#### Strukturierte Makrokernarchitektur +- Resultat: schwach strukturierter (monolithischer) Makrokernel +- ![](Assets/AdvancedOperatingSystems-makrokernelarchitektur.png) + - nach [TaWo05], S. 45 +- Weiterentwicklung: + - Schichtendifferenzierung ( layered operating system ) + - Modularisierung (Bsp.: Linux-Kernel) + | Kernelcode | + | ------------------------- | + | VFS | + | IPC, Dateisystem | + | Scheduler, VMM | + | Dispatcher, Gerätetreiber | +- Modularer Makrokernel: + - alle Kernelfunktionen in Moduleunterteilt (z.B. verschiedene Dateisystemtypen) $\rightarrow$ Erweiterbarkeit, Wartbarkeit, Portierbarkeit + - klar definierte Modulschnittstellen(z.B. virtualfilesystem, VFS ) + - Module zur Kernellaufzeit dynamisch einbindbar ($\rightarrow$ Adaptivität) + +#### Fehlerausbreitung beim Makrokernel +- strukturierte Programmierung: + - ✓ Wartbarkeit + - ✓ Portierbarkeit + - ✓ Erweiterbarkeit + - O (begrenzt) Adaptivität + - O (begrenzt) Schutz gegen statische Programmierfehler: nur durch Compiler (z.B. C private, public) + - ✗ kein Schutz gegen dynamische Fehler + - $\rightarrow$ Robustheit...? +- nächstes Ziel: Schutz gegen Laufzeitfehler... $\rightarrow$ Laufzeitmechanismen + +### Adressraumisolation +- zur Erinnerung: private virtuelle Adressräume zweier Tasks ($i\not= j$) + - ![](Assets/AdvancedOperatingSystems-private-virtuelle-adressräume.png) +- private virtuelle vs. physischer Adresse + - ![](Assets/AdvancedOperatingSystems-virtuelle-vs-physische-adresse.png) + +#### Private virtuelle Adressräume und Fehlerausbreitung +- korrekte private vAR ~ kollisionsfreie Seitenabbildung! +- Magie in Hardware: MMU (BS steuert und verwaltet...) +- Robustheit: Was haben wir von privaten vAR? + - ✓ nichtvertrauenswürdiger (i.S.v. potenziell nicht korrekter) Code kann keine beliebigen physischen Adressen schreiben (er erreicht sie ja nicht mal...) + - ✓ Kommunikation zwischen nvw. Code (z.B. Anwendungstasks) muss durch IPC-Mechanismen explizit hergestellt werden (u.U. auch shared memory) + - $\rightarrow$ Überwachung und Validierung zur Laufzeit möglich + - ✓ Kontrollfluss begrenzen: Funktionsaufrufe können i.A. (Ausnahme: RPC) keine AR-Grenzen überschreiten + - $\rightarrow$ BS-Zugriffssteuerungkann nicht durch Taskfehler ausgehebelt werden + - $\rightarrow$ unabsichtliche Terminierungsfehler(unendliche Rekursion) erschwert ... + +#### Was das für den Kernel bedeutet +- private virtuelle Adressräume + - gibt es schon so lange wie VMM + - gab es lange nur auf Anwendungsebene + - $\rightarrow$ keine Isolation zwischen Fehlern innerhalb des Kernels! + - ![](Assets/AdvancedOperatingSystems-virtuelle-kernel-adressräume.png) +- nächstes Ziel: Schutz gegen Kernelfehler (Gerätetreiber)... $\rightarrow$ BS-Architektur + +## Mikrokernelarchitektur +- Fortschritt ggü. Makrokernel: + - Strukturierungskonzept: + - strenger durchgesetzt durch konsequente Isolation voneinander unabhängiger Kernel-Subsysteme + - zur Laufzeit durchgesetzt $\rightarrow$ Reaktion auf fehlerhafte Zustände möglich! + - zusätzlich zu vertikaler Strukturierung des Kernels: horizontale Strukturierungeingeführt + - $\rightarrow$ funktionale Einheiten: vertikal (Schichten) + - $\rightarrow$ isolierteEinheiten: horizontal (private vAR) +- Idee: + - Kernel (alle BS-Funktionalität) $\rightarrow$ μKernel (minimale BS-Funktionalität) + - Rest (insbes. Treiber): ,,gewöhnliche'' Anwendungsprozesse mit Adressraumisolation + - Kommunikation: botschaftenbasierteIPC (auch client-server operating system ) + - Nomenklatur: Mikrokernelund Serverprozesse + +### Modularer Makrokernel vs. Mikrokernel +- ![Abb. nach [Heis19]](Assets/AdvancedOperatingSystems-modularer-makrokernel.png) +- minimale Kernelfunktionalität: + - keine Dienste, nur allgemeine Schnittstellenfür diese + - keine Strategien, nur grundlegende Mechanismenzur Ressourcenverwaltung +- neues Problem: minimales Mikrokerneldesign + - ,,Wir haben 100 Leute gefragt...'': Wie entscheide ich das? +- ![Abb. nach [Heis19]](Assets/AdvancedOperatingSystems-modularer-makrokernel-2.png) + - Ablauf eines Systemaufrufs + - schwarz: unprivilegierteInstruktionen + - blau:privilegierte Instruktionen + - rot:Übergang zwischen beidem (μKern $\rightarrow$ Kontextwechsel!) + +#### Robustheit von Mikrokernen +- = Gewinn durch Adressraumisolation innerhalb des Kernels + - ✓ kein nichtvertrauenswürdiger Code im kernelspace , der dort beliebige physische Adressen manipulieren kann + - ✓ Kommunikation zwischen nvw. Code (nicht zur zwischen Anwendungstasks)muss durch IPC explizit hergestellt werden $\rightarrow$ Überwachung und Validierung zur Laufzeit + - ✓ Kontrollfluss begrenzen: Zugriffssteuerung auch zwischen Serverprozessen, zur Laufzeit unabhängiges Teilmanagement von Code (Kernelcode) möglich (z.B.: Nichtterminierung erkennen) +- Neu: + - ✓ nvw. BS-Code muss nicht mehr im kernelspace (höchste Prozessorprivilegierung) laufen + - ✓ verbleibender Kernel (dessen Korrektheit wir annehmen): klein, funktional weniger komplex, leichter zu entwickeln, zu testen, evtl. formal zu verifizieren + - ✓ daneben: Adaptivitätdurch konsequentere Modularisierung des Kernels gesteigert + +### Mach +- Mikrokernel-Design: Erster Versuch + - Carnegie Mellon University (CMU), School of Computer Science 1985 - 1994 +- ein wenig Historie + - UNIX (Bell Labs) - K. Thompson, D. Ritchie + - BSD (U Berkeley) - W. Joy + - System V - W. Joy + - Mach (CMU) - R. Rashid + - MINIX - A. Tanenbaum + - NeXTSTEP (NeXT) - S. Jobs + - Linux - L. Torvalds + - GNU Hurd (FSF) - R. Stallman + - Mac OS X (Apple) - S. Jobs + +#### Mach: Ziele +Entstehung +- Grundlage: + - 1975: Aleph(BS des ,,Rochester Intelligent Gateway''), U Rochester + - 1979/81: Accent (verteiltes BS), CMU +- gefördert durch militärische Geldgeber: + - DARPA: Defense AdvancedResearch Projects Agency + - SCI: Strategic Computing Initiative + +Ziele +- Mach 3.0 (Richard Rashid, 1989): einer der ersten praktisch nutzbaren μKerne +- Ziel: API-Emulation(≠ Virtualisierung!)von UNIX und -Derivaten auf unterschiedlichen Prozessorarchitekturen +- mehrere unterschiedliche Emulatoren gleichzeitig lauffähig + - Emulation außerhalb des Kernels + - jeder Emulator: + - Komponente im Adressraum des Applikationsprogramms + - 1...n Server, die unabhängig von Applikationsprogramm laufen + +Mach-Server zur Emulation +- ![Abb.: [TaBo15]](Assets/AdvancedOperatingSystems-mach-server.png) +- Emulation von UNIX-Systemen mittels Mach-Serverprozessen + +μKernel-Funktionen +1. Prozessverwaltung +2. Speicherverwaltung +3. IPC-und E/A-Dienste, einschließlich Gerätetreiber + +unterstützte Abstraktionen ($\rightarrow$ API, Systemaufrufe): +1. Prozesse +2. Threads +3. Speicherobjekte +4. Ports (generisches, ortstransparentes Adressierungskonzept; vgl. UNIX ,,everything is a file'') +6. Botschaften +7. ... (sekundäre, von den obigen genutzte Abstraktionen) + +Architektur +- ![](Assets/AdvancedOperatingSystems-mach-architektur.png) + +- Systemaufrufkosten: + - IPC-Benchmark (1995): i486 Prozessor, 50 MHz + - Messung mit verschiedenen Botschaftenlängen( x - Werte) + - ohne Nutzdaten (0 Byte Botschaftenlänge): 115 μs (Tendenz unfreundlich ...) + - ![Heis19](Assets/AdvancedOperatingSystems-mach-systemaufruf.png) +- Bewertung aus heutiger Sicht: + - funktional komplex + - 153 Systemaufrufe + - mehrere Schnittstellen, parallele Implementierungen für eine Funktion + - $\rightarrow$ Adaptivität (Auswahl durch Programmierer) +- Fazit: + - zukunftsweisender Ansatz + - langsame und ineffiziente Implementierung + +Lessons Learned +- erster Versuch: + - Idee des Mikrokernelsbekannt + - Umsetzung: Designkriterienweitgehend unbekannt +- Folgen für Performanz und Programmierkomfort: [Heis19] + - ✗ ,,complex'' + - ✗ ,,inflexible'' + - ✗ ,,slow'' +- wir wissen etwas über Kosten: IPC-Performanz, Kernelabstraktionen +- wir wissen noch nichts über guten μKern-Funktionsumfangund gute Schnittstellen... +- $\rightarrow$ nächstes Ziel! + +### L4 +- Made in Germany: + - Jochen Liedtke (GMD, ,,Gesellschaft für Mathematik und Datenverarbeitung''), Betriebssystemgruppe (u.a.): J. Liedtke, H. Härtig, W. E. Kühnhauser + - Symposium on Operating Systems Principles 1995 (SOSP '95): ,,On μ-Kernel Construction'' [Lied95] +- Analyse des Mach-Kernels: + 1. falsche Abstraktionen + 2. unperformanteKernelimplementierung + 3. prozessorunabhängige Implementierung + - Letzteres: effizienzschädliche Eigenschaft eines Mikrokernels + - Neuimplementierung eines (konzeptionell sauberen!) μ-Kerns kaum teurer als Portierung auf andere Prozessorarchitektur + +L3 und L4 +- Mikrokerne der 2. Generation + - zunächst L3, insbesondere Nachfolger L4: erste Mikrokerne der 2. Generation +- vollständige Überarbeitung des Mikrokernkonzepts: wesentliche Probleme der 1. Generation (z.B. Mach) vermieden +- Bsp.: durchschnittliche Performanz von User-Mode IPC in L3 ggü. Mach: Faktor 22 zugunsten L3 + - heute: verschiedene Weiterentwicklungen von L4 (bezeichnet heute Familie ähnlicher Mikrokerne) + + | First generation | Second Generation | Third generation | + | --------------------------------------------------- | ---------------------------------------------------- | --------------------------------------------------- | + | Eg Mach [87] | Eg L4 [95] | seL4 [09] | + | ![](Assets/AdvancedOperatingSystems-l4-first-g.png) | ![](Assets/AdvancedOperatingSystems-L4-second-g.png) | ![](Assets/AdvancedOperatingSystems-l4-third-g.png) | + | 180 syscalls | ~7 syscalls | ~3 syscalls | + | 100 kLOC | ~10 kLOC | 9 kLOC | + | 100 $\mu s$ IPC | ~1 $\mu s$ IPC | $0,2-1 \mu s$ IPC | + +#### Mikrokernel-Designprinzipien +- Was gehört in einen Mikrokern? + - Liedtke: Unterscheidung zwischen Konzepten und deren Implementierung + - bestimmende Anforderungen an beide: + - Konzeptsicht $\rightarrow$ Funktionalität, + - Implementierungssicht $\rightarrow$ Performanz + - $\rightarrow$ 1. μKernel-Generation: Konzept durch Performanzentscheidungen aufgeweicht + - $\rightarrow$ Effekt in der Praxis genau gegenteilig: schlechte (IPC-) Performanz! + +> ,,The determining criterion used is functionality, not performance. More precisely, a concept is tolerated inside the μ-kernel only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the systems‘s required functionality .'' [Jochen Liedtke] + +Designprinzipien für Mikrokernel-Konzept: +- $\rightarrow$ Annahmen hinsichtlich der funktionalen Anforderungen: +1. System interaktive und nicht vollständig vertrauenswürdige Applikationen unterstützen ($\rightarrow$ HW-Schutz, -Multiplexing), +2. Hardware mit virtueller Speicherverwaltung und Paging + +Designprinzipien: +1. Autonomie: ,,Ein Subsystem (Server)muss so implementiert werden können, dass es von keinem anderen Subsystem gestört oder korrumpiert werden kann.'' +2. Integrität: ,,Subsystem (Server) $S_1$ muss sich auf Garantien von $S_2$ verlassen können. D.h. beide Subsysteme müssen miteinander kommunizieren können, ohne dass ein drittes Subsystem diese Kommunikation stören, fälschen oder abhören kann.'' + +L4: Speicherabstraktion +- Adressraum: Abbildung, die jede virtuelle Seite auf einen physischen Seitenrahmen abbildet oder als ,,nicht zugreifbar'' markiert +- Implementierung über Seitentabellen, unterstützt durch MMU-Hardware +- Aufgabe des Mikrokernels (als gemeinsame obligatorische Schicht aller Subsysteme): muss Hardware-Konzept des Adressraums verbergen und durch eigenes Adressraum-Konzept überlagern (sonst Implementierung von VMM-Mechanismen durch Server unmöglich) +- Mikrokernel-Konzept des Adressraums: + - muss Implementierung von beliebigen virtuellen Speicherverwaltungs-und -schutzkonzepten oberhalb des Mikrokernels (d.h. in den Subsystemen) erlauben + - sollte einfach und dem Hardware-Konzept ähnlich sein +- Idee: abstrakte Speicherverwaltung + - rekursive Konstruktion und Verwaltung der Adressräume auf Benutzer-(Server-)Ebene + - Mikrokernel stellt dafür genau drei Operationen bereit: + 1. grant(x) - Server $S$ überträgt Seite $x$ seines AR in AR von Empfänger $S‘$ + 2. map(x) - Server $S$ bildet Seite $x$ seines AR in AR von Empfänger $S‘$ ab + 3. flush(x) - Server $S$ entfernt (flusht) Seite x seines AR aus allen fremden AR + +Hierarchische Adressräume +- Rekursive Konstruktion der Adressraumhierarchie + - Server und Anwendungenkönnen damit ihren Klienten Seiten des eigenen Adressraumes zur Verfügung stellen + - Realspeicher: Ur-Adressraum, vom μKernel verwaltet + - Speicherverwaltung(en), Paging usw.: vollständig außerhalb des μ-Kernels realisiert + - ![](Assets/AdvancedOperatingSystems-adressraumhierarchie.png) + +L4: Threadabstraktion +- Thread + - innerhalb eines Adressraumesablaufende Aktivität + - $\rightarrow$ Adressraumzuordnung ist essenziell für Threadkonzept (Code + Daten) + - Bindung an Adressraum: dynamisch oder fest + - Änderung einer dynamischen Zuordnung: darf nur unter vertrauenswürdiger Kontrolle erfolgen (sonst: fremde Adressräume les- und korrumpierbar) +- Designentscheidung + - $\rightarrow$ Autonomieprinzip + - $\rightarrow$ Konsequenz: Adressraumisolation + - $\rightarrow$ entscheidender Grund zur Realisierung des Thread-Konzepts innerhalb des Mikrokernels + +IPC +- Interprozess-Kommunikation + - Kommunikation über Adressraumgrenzen: vertrauenswürdig kontrollierte Aufhebung der Isolation + - $\rightarrow$ essenziell für (sinnvolles) Multitasking und -threading +- Designentscheidung + - $\rightarrow$ Integritätsprinzip + - $\rightarrow$ wir haben schon: vertrauenswürdige Adressraumisolation im μKernel + - $\rightarrow$ grundlegendes IPC-Konzepts innerhalb des Mikrokernels (flexibel und dynamisch durch Server erweiterbar, analog Adressraumhierarchie) + +Identifikatoren +- Thread-und Ressourcenbezeichner + - müssen vertrauenswürdig vergeben (authentisch und i.A. persistent) und verwaltet(eindeutig und korrekt referenzierbar)werden + - $\rightarrow$ essenziell für (sinnvolles) Multitasking und -threading + - $\rightarrow$ essenziell für vertrauenswürdige Kernel-und Server-Schnittstellen +- Designentscheidung + - $\rightarrow$ Integritätsprinzip + - $\rightarrow$ ID-Konzept innerhalb des Mikrokernels (wiederum: durch Server erweiterbar) + +Lessons Learned +1. Ein minimaler Mikrokernel + - soll Minimalmenge an geeigneten Abstraktionenzur Verfügung stellen: + - flexibel genug, um Implementierung beliebiger Betriebssysteme zu ermöglichen + - Nutzung umfangreicher Mengeverschiedener Hardware-Plattformen +2. Geeignete, funktional minimale Mechanismen im μKern: + - Adressraum mit map-, flush-, grant-Operation + - Threadsinklusive IPC + - eindeutige Identifikatoren +3. Wahl der geeigneten Abstraktionen: + - kritischfür Verifizierbarkeit ( $\rightarrow$ Robustheit), Adaptivität und optimierte Performanz des Mikrokerns +4. Bisherigen μ-Kernel-Abstraktionskonzepte: + 1. ungeeignete + 2. zu viele + 3. zu spezialisierte u. inflexible Abstraktionen +5. Konsequenzen für Mikrokernel-Implementierung + - müssen für jeden Prozessortyp neu implementiert werden + - sind deshalb prinzipiell nicht portierbar $\rightarrow$ L3-und L4-Prototypen by J. Liedtke: 99% Assemblercode +6. innerhalb eines Mikrokernels sind + 1. grundlegende Implementierungsentscheidungen + 2. meiste Algorithmen u. Datenstrukturen + - von Prozessorhardware abhängig + +- Fazit: + - Mikrokernelmit akzeptabler Performanz: hardwarespezifische Implementierung minimalerforderlicher, vom Prozessortyp unabhängiger Abstraktionen + - ![Heis19](Assets/AdvancedOperatingSystems-l4-ipc-performance.png) + +Heutige Bedeutung +- nach Tod von J. Liedtke (2001) auf Basis von L4 zahlreiche moderne BS +- L4 heute: Spezifikation eines Mikrokernels (nicht Implementierung) +- ![Heis19](Assets/AdvancedOperatingSystems-l4-family.png) +- Einige Weiterentwicklungen: + - TU Dresden (Hermann Härtig): Neuimplementierung in C++ (L4/Fiasco), Basis des Echtzeit-Betriebssystems DROPS, der VirtualisierungsplattformNOVA (genauer: Hypervisor) und des adaptiven BS-Kernels Fiasco.OC + - University ofNew South Wales (UNSW), Australien (Gernot Heiser): + - Implementierung von L4 auf verschiedenen 64 - Bit-Plattformen, bekannt als L4/MIPS, L4/Alpha + - Implementierung in C (Wartbarkeit, Performanz) + - Mit L4Ka::Pistachio bisher schnellste Implementierung von botschaftenbasierterIPC (2005: 36 Zyklen auf Itanium-Architektur) + - seit 2009: seL4, erster formal verifizierter BS-Kernel (d.h. mathematisch bewiesen, dass Implementierung funktional korrekt ist und nachweislich keinen Entwurfsfehler enthält) + +Zwischenfazit +- Begrenzung von Fehlerausbreitung ( $\rightarrow$ Folgen von errors ): + - konsequent modularisierte Architektur aus Subsystemen + - Isolationsmechanismen zwischen Subsystemen +- Konsequenzen für BS-Kernel: + - statische Isolation auf Quellcodeebene $\rightarrow$ strukturierte Programmierung + - dynamische Isolation zur Laufzeit $\rightarrow$ private virtuelle Adressräume + - Architektur, welche diese Mechanismen komponiert: Mikrokernel +- Was haben wir gewonnen? + - ✓ Adressraumisolation für sämtlichen nichtvertrauenswürdigen Code + - ✓ keine privilegierten Instruktionen in nvw. Code (Serverprozesse) + - ✓ geringe Größe (potenziell: Verifizierbarkeit) des Kernels + - ✓ neben Robustheit: Modularitätund Adaptivitätdes Kernels +- Und was noch nicht? + - ✗ Behandlung von Ausfällen ( $\rightarrow$ abstürzende Gerätetreiber ...) + +## 3.5 Micro-Reboots +- Beobachtungen am Ausfallverhalten von BS: + - Kernelfehler sind (potenziell) fatal für gesamtes System + - Anwendungsfehler sind es nicht + - $\rightarrow$ kleiner Kernel = geringeres Risiko von Systemausfällen + - $\rightarrow$ durch BS-Code in Serverprozessen: verbleibendes Risiko unabhängiger Teilausfälle von BS-Funktionalität (z.B. FS, Treiberprozesse, GUI, ...) +- Ergänzung zu Isolationsmechanismen: + - Mechanismen zur Behandlung von Subsystem-Ausfällen + - = Mechanismen zur Behandlung Anwendungs-, Server- und Gerätetreiberfehlen +- $\rightarrow$ Micro-Reboots + +Ansatz +- wir haben: + - kleinen, ergo vertrauenswürdigen (als fehlerfrei angenommenen)μKernel + - BS-Funktionalität in bedingt vertrauenswürdigen Serverprozessen (kontrollierbare, aber wesentlich größere Codebasis) + - Gerätetreiber und Anwendungen in nicht vertrauenswürdigen Prozessen (nicht kontrollierbare Codebasis) +- wir wollen: + - Systemausfälle verhindern durch Vermeidung von errors im Kernel $\rightarrow$ höchste Priorität + - Treiber-und Serverausfälle minimieren durch Verbergen ihrer Auswirkungen $\rightarrow$ nachgeordnete Priorität (Best-Effort-Prinzip) +- Idee: + - Systemausfälle $\rightarrow$ μKernel + - Treiber-und Serverausfälle $\rightarrow$ Neustart durch spezialisierten Serverprozess + +Beispiel: Ethernet-Treiberausfall +- ![](Assets/AdvancedOperatingSystems-ethernet-treiberausfall.png) +- schwarz: ausfallfreie Kommunikation +- rot: Ausfall und Behandlung +- blau: Wiederherstellung nach Ausfall + +Beispiel: Dateisystem-Serverausfall +- ![](Assets/AdvancedOperatingSystems-dateisystem-serverausfall.png) +- schwarz: ausfallfreie Kommunikation +- rot: Ausfall und Behandlung +- blau: Wiederherstellung nach Ausfall + +## Beispiel-Betriebssystem: MINIX +- Ziele: + - robustes Betriebssystems + - $\rightarrow$ Schutz gegen Sichtbarwerden von Fehlern(= Ausfälle) für Nutzer + - Fokus auf Anwendungsdomänen: Endanwender-Einzelplatzrechner (Desktop, Laptop, Smart*) und eingebettete Systeme + - Anliegen: Robustheit > Verständlichkeit > geringer HW-Bedarf +- aktuelle Version: MINIX 3.3.0 + +Architektur +- Kommunikationsschnittstellen ... + - ![](Assets/AdvancedOperatingSystems-minix-architektur.png) + - ... für Anwendungen (weiß): Systemaufrufe im POSIX-Standard + - ... für Serverprozesse (grau): + - untereinander: IPC (botschaftenbasiert) + - mit Kernel: spezielle MINIX-API (kernel calls), für Anwendungsprozesse gesperrt +- Betriebssystem-Serverprozesse: + - ![](Assets/AdvancedOperatingSystems-minix-architektur-bs.png) + - Dateisystem (FS) + - Prozessmanagement (PM) + - Netzwerkmanagement (Net) + - Reincarnation Server (RS) $\rightarrow$ Micro-Reboots jeglicher Serverprozesse + - (u. a.) ... +- Kernelprozesse: + - systemtask + - clocktask + +Reincarnation Server +- Implementierungstechnik für Micro-Reboots: +- Prozesse zum Systemstart ( $\rightarrow$ Kernel Image): system, clock, init, rs + - system, clock: Kernelprogramm + - init: Bootstrapping (Initialisierung von rs und anderer BS-Serverprozesse), Fork der Login-Shell (und damit sämtlicher Anwendungsprozesse) + - rs: Fork sämtlicher BS-Serverprozesse, einschließlich Gerätetreiber +- ![](Assets/AdvancedOperatingSystems-minix-reincarnation-server.png) + +MINIX: Ausprobieren +- [ausführliche Dokumentation](https://wiki.minix3.org/doku.php?id=www:getting-started:start) +- [vorkompiliertes Kernel-Image zum Installieren (VirtualBox, VMWare, ...)](https://wiki.minix3.org/doku.php?id=www:download:start) + +## Verfügbarkeit +- komplementäre NFE zu Robustheit: Verfügbarkeit ( availability ) + - Zur Erinnerung: Untereigenschaften von Verlässlichkeit + 1. Verfügbarkeit (availability) + 2. Robustheit (robustness, reliability) +- Beziehung: + - Verbesserung von Robustheit $\Rightarrow$ Verbesserung von Verfügbarkeit + - Robustheitsmaßnahmen hinreichend , nicht notwendig (hochverfügbare Systeme können sehr wohl von Ausfällen betroffen sein...) +- eine weitere komplementäre NFE: + - Robustheit $\Rightarrow$ Sicherheit (security) + +Allgemeine Definition: Der Grad, zu welchem ein System oder eine Komponente funktionsfähig und zugänglich (erreichbar) ist,wann immer seine Nutzung erforderlichist. (IEEE) + +genauer quantifiziert: +- Der Anteil an Laufzeit eines Systems, in dem dieses seine spezifizierte Leistung erbringt. +- ![](Assets/AdvancedOperatingSystems-verfügbarkeit-laufzeit.png) +- Availability= Total Uptime/ Total Lifetime= MTTF / (MTTF + MTTR) + - MTTR: Mean Time to Recovery ... Erwartungswert für TTR + - MTTF: Mean Time to Failure ... Erwartungswert für TTF +- einige Verfügbarkeitsklassen: + | Verfügbarkeit | Ausfallzeit pro Jahr | Ausfallzeit pro Woche | + | ------------- | -------------------- | --------------------- | + | 90% | > 1 Monat | ca. 17 Stunden | + | 99% | ca. 4 Tage | ca. 2 Stunden | + | 99,9% | ca. 9 Stunden | ca. 10 Minuten | + | 99,99% | ca. 1 Stunde | ca. 1 Minute | + | 99,999% | ca. 5 Minuten | ca. 6 Sekunden | + | 99,9999% | ca. 2 Sekunden | << 1 Sekunde | +- Hochverfügbarkeitsbereich (gefeierte ,,five nines'' availability) +- Maßnahmen: + - Robustheitsmaßnahmen + - Redundanz + - Ausfallmanagement + +### QNX Neutrino: Hochverfügbares Echtzeit-BS +Überblick QNX: +- Mikrokern-Betriebssystem +- primäres Einsatzfeld: eingebettete Systeme, z.B. Automobilbau +- Mikrokernarchitektur mit Adressraumisolation für Gerätetreiber +- (begrenzt) dynamische Micro-Rebootsmöglich +- $\rightarrow$ Maximierung der Uptime des Gesamtsystems + +Hochverfügbarkeitsmechanismen: +1. ,,High-Avalability-Manager'': Laufzeit-Monitor, der Systemdienste oder Anwendungsprozesse überwacht und neustartet $\rightarrow$ μReboot-Server +2. ,,High-Availability-Client-Libraries'': Funktionen zur transparenten automatischen Reboot für ausgefallene Server-Verbindungen + # Sicherheit # Echtzeitfähigkeit # Adaptivität @@ -807,4 +1350,18 @@ Implementierung - MANLEY, JOHNH.: Embedded Systems, MARCINIAK, J. J.(Hrsg.) - TinyOS - KELLNER, SIMON; BELLOSA, FRANK: Energy Accounting Support in TinyOS - - KELLNER, SIMON: Flexible Online Energy Accounting in TinyOS \ No newline at end of file + - KELLNER, SIMON: Flexible Online Energy Accounting in TinyOS +- Verlässlichkeitsbegriff, Fehlermodell: + - [ALRL04] AVIŽIENIS, ALGIRDAS; LAPRIE, JEAN-CLAUDE; RANDELL, BRIAN; LANDWEHR, CARL: Basic Concepts and Taxonomy of Dependable and Secure Computing. In: IEEE Trans. Dependable Secur. Comput. https://doi.org/10.1109/TDSC.2004.2 + - [AvLR04] AVIŽIENIS, ALGIRDAS; LAPRIE, JEAN-CLAUDE; RANDELL, BRIAN: Dependability and Its Threats: A Taxonomy. In: JACQUART, R.(Hrsg.): Building theInformation Society , IFIP International Federation for Information Processing : Springer US, 2004, https://doi.org/10.1007/978 +- DeepSpace 1 Remote Debugging: + - GARRET, RON: Lispingat JPL. URL http://www.flownet.com/gat/jpl-lisp.html +- Kernelarchitekturdesign und Mikrokernelprinzip: + - [Heis19] HEISER, GERNOT: COMP9242 Advanced Operating Systems. Lecture Slides UNSW Australia, 2019. Courtesy of Gernot Heiser, UNSW. https://www.cse.unsw.edu.au/~cs9242/19/lectures.shtml + - [TaBo15] TANENBAUM, ANDREWS; WOODHULL, ALBERTS: Operating Systems Design and Implementation. 3. Aufl. UpperSaddleRiver, NJ, USA: Prentice-Hall, Inc., 2005 +- Mikrokerneldesign, L4: + - [Lied95] LIEDTKE, JOCHEN: On μ-Kernel Construction. In: Operating Systems Review. Special issue for the Fifteenth ACM Symposium on Operating System Principles Bd. 29 (1995), https://doi.org/10.1145/224056.224075 +- MINIX: + - HERDER, JORRITN.; BOS, HERBERT; GRAS, BEN; HOMBURG, PHILIP; TANENBAUM, ANDREWS.: MINIX 3: A Highly Reliable, Self-repairing Operating System. In: ACM SIGOPS Operating Systems Review https://doi.org/10.1145/1151374.1151391 + - TANENBAUM, ANDREWS. APPUSWAMY, RAJA; BOS, HERBERTJ. ; CAVALLARO, LORENZO; GIUFFRIDA, CRISTIANO; HRUBY, TOMAS; HERDER, JORRIT; VANDERKOUWE, ERIK; U.A.: MINIX 3: Status Report and Current Research. In: login: The USENIX Magazine Bd. 35 (2010) https://www.usenix.org/publications/login/june- 2010 + - [TaWo05] TANENBAUM, ANDREWS; WOODHULL, ALBERTS: Operating Systems Design and Implementation. 3. Aufl. UpperSaddleRiver, NJ, USA: Prentice-Hall, Inc. \ No newline at end of file diff --git a/Assets/Advanced-Operating-Systems-systemaufrufkosten.png b/Assets/Advanced-Operating-Systems-systemaufrufkosten.png new file mode 100644 index 0000000..5f29251 Binary files /dev/null and b/Assets/Advanced-Operating-Systems-systemaufrufkosten.png differ diff --git a/Assets/AdvancedOperatingSystems-L4-second-g.png b/Assets/AdvancedOperatingSystems-L4-second-g.png new file mode 100644 index 0000000..e4c1d2b Binary files /dev/null and b/Assets/AdvancedOperatingSystems-L4-second-g.png differ diff --git a/Assets/AdvancedOperatingSystems-adressraumhierarchie.png b/Assets/AdvancedOperatingSystems-adressraumhierarchie.png new file mode 100644 index 0000000..7052f72 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-adressraumhierarchie.png differ diff --git a/Assets/AdvancedOperatingSystems-dateisystem-serverausfall.png b/Assets/AdvancedOperatingSystems-dateisystem-serverausfall.png new file mode 100644 index 0000000..eb67dd6 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-dateisystem-serverausfall.png differ diff --git a/Assets/AdvancedOperatingSystems-ethernet-treiberausfall.png b/Assets/AdvancedOperatingSystems-ethernet-treiberausfall.png new file mode 100644 index 0000000..a8fbbb9 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-ethernet-treiberausfall.png differ diff --git a/Assets/AdvancedOperatingSystems-fehler.png b/Assets/AdvancedOperatingSystems-fehler.png new file mode 100644 index 0000000..96868fa Binary files /dev/null and b/Assets/AdvancedOperatingSystems-fehler.png differ diff --git a/Assets/AdvancedOperatingSystems-l4-family.png b/Assets/AdvancedOperatingSystems-l4-family.png new file mode 100644 index 0000000..ef3aad0 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-l4-family.png differ diff --git a/Assets/AdvancedOperatingSystems-l4-first-g.png b/Assets/AdvancedOperatingSystems-l4-first-g.png new file mode 100644 index 0000000..4d311aa Binary files /dev/null and b/Assets/AdvancedOperatingSystems-l4-first-g.png differ diff --git a/Assets/AdvancedOperatingSystems-l4-ipc-performance.png b/Assets/AdvancedOperatingSystems-l4-ipc-performance.png new file mode 100644 index 0000000..aba7a30 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-l4-ipc-performance.png differ diff --git a/Assets/AdvancedOperatingSystems-l4-third-g.png b/Assets/AdvancedOperatingSystems-l4-third-g.png new file mode 100644 index 0000000..98deaa9 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-l4-third-g.png differ diff --git a/Assets/AdvancedOperatingSystems-mach-architektur.png b/Assets/AdvancedOperatingSystems-mach-architektur.png new file mode 100644 index 0000000..268c960 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-mach-architektur.png differ diff --git a/Assets/AdvancedOperatingSystems-mach-server.png b/Assets/AdvancedOperatingSystems-mach-server.png new file mode 100644 index 0000000..3b6c31c Binary files /dev/null and b/Assets/AdvancedOperatingSystems-mach-server.png differ diff --git a/Assets/AdvancedOperatingSystems-mach-systemaufruf.png b/Assets/AdvancedOperatingSystems-mach-systemaufruf.png new file mode 100644 index 0000000..90d35a4 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-mach-systemaufruf.png differ diff --git a/Assets/AdvancedOperatingSystems-makrokernelarchitektur.png b/Assets/AdvancedOperatingSystems-makrokernelarchitektur.png new file mode 100644 index 0000000..958cabc Binary files /dev/null and b/Assets/AdvancedOperatingSystems-makrokernelarchitektur.png differ diff --git a/Assets/AdvancedOperatingSystems-minix-architektur-bs.png b/Assets/AdvancedOperatingSystems-minix-architektur-bs.png new file mode 100644 index 0000000..d09af7b Binary files /dev/null and b/Assets/AdvancedOperatingSystems-minix-architektur-bs.png differ diff --git a/Assets/AdvancedOperatingSystems-minix-architektur.png b/Assets/AdvancedOperatingSystems-minix-architektur.png new file mode 100644 index 0000000..95a378b Binary files /dev/null and b/Assets/AdvancedOperatingSystems-minix-architektur.png differ diff --git a/Assets/AdvancedOperatingSystems-minix-reincarnation-server.png b/Assets/AdvancedOperatingSystems-minix-reincarnation-server.png new file mode 100644 index 0000000..213a324 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-minix-reincarnation-server.png differ diff --git a/Assets/AdvancedOperatingSystems-modularer-makrokernel-2.png b/Assets/AdvancedOperatingSystems-modularer-makrokernel-2.png new file mode 100644 index 0000000..0cab0e4 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-modularer-makrokernel-2.png differ diff --git a/Assets/AdvancedOperatingSystems-modularer-makrokernel.png b/Assets/AdvancedOperatingSystems-modularer-makrokernel.png new file mode 100644 index 0000000..324464e Binary files /dev/null and b/Assets/AdvancedOperatingSystems-modularer-makrokernel.png differ diff --git a/Assets/AdvancedOperatingSystems-private-virtuelle-adressräume.png b/Assets/AdvancedOperatingSystems-private-virtuelle-adressräume.png new file mode 100644 index 0000000..f943e09 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-private-virtuelle-adressräume.png differ diff --git a/Assets/AdvancedOperatingSystems-treiber-kernel-fehler.png b/Assets/AdvancedOperatingSystems-treiber-kernel-fehler.png new file mode 100644 index 0000000..15fc526 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-treiber-kernel-fehler.png differ diff --git a/Assets/AdvancedOperatingSystems-treiber-kernel.png b/Assets/AdvancedOperatingSystems-treiber-kernel.png new file mode 100644 index 0000000..decd115 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-treiber-kernel.png differ diff --git a/Assets/AdvancedOperatingSystems-verfügbarkeit-laufzeit.png b/Assets/AdvancedOperatingSystems-verfügbarkeit-laufzeit.png new file mode 100644 index 0000000..63d93db Binary files /dev/null and b/Assets/AdvancedOperatingSystems-verfügbarkeit-laufzeit.png differ diff --git a/Assets/AdvancedOperatingSystems-virtuelle-kernel-adressräume.png b/Assets/AdvancedOperatingSystems-virtuelle-kernel-adressräume.png new file mode 100644 index 0000000..e5e1c8f Binary files /dev/null and b/Assets/AdvancedOperatingSystems-virtuelle-kernel-adressräume.png differ diff --git a/Assets/AdvancedOperatingSystems-virtuelle-vs-physische-adresse.png b/Assets/AdvancedOperatingSystems-virtuelle-vs-physische-adresse.png new file mode 100644 index 0000000..fd21471 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-virtuelle-vs-physische-adresse.png differ