Merge branch 'master' of github.com:wieerwill/Informatik

Advanced Operating Systems.md

@@ -47,7 +47,7 @@ Gegenstand dieser Vorlesung: Konstruktionsrichtlinien für solche ,,High-End Bet
         - Quality ofservice(QoS) requirements
         - u.a.
 - ,,~ilities''
-    - im Englischen: nichtfunktionale Eigenschaften eines Systems etc. informell auch als seine „ilities“ bezeichnet, hergeleitet von Begriffen wie
+    - im Englischen: nichtfunktionale Eigenschaften eines Systems etc. informell auch als seine ,,ilities'' bezeichnet, hergeleitet von Begriffen wie
         - Stability
         - Portability
         - ...
@@ -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)
@@ -242,7 +242,7 @@ Energiezustände beim Betrieb von Festplatten:
 - Schlussfolgerung: durch geringe Verlängerungen des idle - Intervalls kann signifikant der Energieverbrauch reduziert werden.
 
 #### Prefetching-Mechanismus
-- Prefetching („Speichervorgriff“, vorausschauendes Lesen) & Caching
+- Prefetching (,,Speichervorgriff'', vorausschauendes Lesen) & Caching
   - Standard-Praxis bei moderner Datei-E/A
   - Voraussetzung: Vorwissen über benötigte Folge von zukünftigen Datenblockreferenzen (z.B. Blockadressen für bestimmte Dateien, gewonnen durch Aufzeichnung früherer Zugriffsmuster beim Start von Anwendungen -Linux: readahead syscall)
   - Ziel: Performanzverbesserungdurch Durchsatzerhöhung u. Latenzzeit-Verringerung
@@ -270,7 +270,7 @@ Energiezustände beim Betrieb von Festplatten:
   - Regeln für diese Strategie:
     1. Optimales Prefetching: Jedes _prefetch_ sollte den nächsten Block im Referenzstrom in den Cache bringen, der noch nicht dort ist.
     2. Optimales Ersetzen: Bei jedem ersetzenden _prefetch_ sollte der Block überschrieben werden, der am spätesten in der Zukunft wieder benötigt wird.
-    3. „Richte keinen Schaden an“: Überschreibe niemals Block A um Block B zu holen, wenn A vor B benötigt wird.
+    3. ,,Richte keinen Schaden an'': Überschreibe niemals Block A um Block B zu holen, wenn A vor B benötigt wird.
     4. Erste Möglichkeit: Führe nie ein ersetzendes _prefetch_ aus, wenn dieses schon vorher hätte ausgeführt werden können.
 - Energieeffizientes Prefetching
   - Optimale Ersetzungsstrategie und 3 unterschiedliche Prefetching-Strategien:
@@ -286,7 +286,7 @@ Energiezustände beim Betrieb von Festplatten:
 - Auswertung: Regeln für energieeffiziente Prefetching-Strategie nach Papathanasiou elal.: [PaSc04]
   1. Optimales Prefetching: Jedes _prefetch_ sollte den nächsten Block im Referenzstrom in den Cache bringen, der noch nicht dort ist.
   2. Optimales Ersetzen: Bei jedem ersetzenden _prefetch_ sollte der Block überschrieben werden, der am spätesten in der Zukunft wieder benötigt wird.
-  3. „Richte keinen Schaden an“: Überschreibe niemals Block A um Block B zu holen, wenn A vor B benötigt wird.
+  3. ,,Richte keinen Schaden an'': Überschreibe niemals Block A um Block B zu holen, wenn A vor B benötigt wird.
   4. Maximiere Zugriffsfolgen: Führe immer dann nach einem _fetch_ oder _prefetch_ ein weiteres _prefetch_ aus, wenn Blöcke für eine Ersetzung geeignet sind. (i.S.v. Regel 3)
   5. Beachte Idle-Zeiten: Unterbrich nur dann eine Inaktivitätsperiode durch ein _prefetch_ , falls dieses sofort ausgeführt werden muss, um einen Cache-Miss zu vermeiden.
 
@@ -333,7 +333,7 @@ Verlustleistung: $P_{leakage}$
 - Typ einer Anwendung
   - entscheidet über jeweilige Nutzererwartung
     1. Hintergrundanwendung (z.B. Compiler); von Interesse: Gesamt-Bearbeitungsdauer, Durchsatz
-    2. Echtzeitanwendung(z.B. Video-Player, MP3-Player); von Interesse: „flüssiges“ Abspielen von Video oder Musik
+    2. Echtzeitanwendung(z.B. Video-Player, MP3-Player); von Interesse: ,,flüssiges'' Abspielen von Video oder Musik
     3. Interaktive Anwendung (z.B. Webbrowser); von Interesse: Reaktivität, d.h. keine (wahrnehmbare) Verzögerung zwischen Nutzer-Aktion und Rechner-Reaktion
   - Insbesondere kritisch: Echtzeitanwendungen, interaktive Anwendungen
 
@@ -413,7 +413,7 @@ Energiebewusstes RR: Reaktivität und Fairness
 - Beispiel: Synergie nichtfunktionaler Eigenschaften
   - Performanz nur möglich durch Parallelität $\rightarrow$ Multicore-Hardware
   - Multicore-Hardware nur möglich mit Lastausgleich und Lastverteilungauf mehrere CPUs
-  - dies erfordert ebenfalls Verteilungsstrategien: „Energy-aware Scheduling“ (Linux-Strategie zur Prozessorallokation -nicht zeitlichem Multiplexing!)
+  - dies erfordert ebenfalls Verteilungsstrategien: ,,Energy-aware Scheduling'' (Linux-Strategie zur Prozessorallokation -nicht zeitlichem Multiplexing!)
 
 ### Systemglobale Energieeinsparungsmaßnahmen
 - Traditionelle Betriebssysteme: Entwurf so, dass zu jedem Zeitpunkt Spitzen-Performanzangestrebt
@@ -434,8 +434,8 @@ Energiebewusstes RR: Reaktivität und Fairness
   - Steuerung/Strategien: Softwareunterstützungnotwendig!
 
 Dynamisches Energiemanagement (DPM)- Strategien (Klassen) bestimmt, wann und wie lange eine Hardware-Komponente sich in Energiesparmodusbefinden sollte
-- Greedy: Hardware-Komponente sofort nach Erreichen des Leerlaufs in Energiesparmodus, „Aufwecken“ durch neue Anforderung
+- Greedy: Hardware-Komponente sofort nach Erreichen des Leerlaufs in Energiesparmodus, ,,Aufwecken'' durch neue Anforderung
-- Time-out: Energiesparmodus erst nachdem ein definiertes Intervall im Leerlauf, „Aufwecken“ wie bei Greedy-Strategien
+- Time-out: Energiesparmodus erst nachdem ein definiertes Intervall im Leerlauf, ,,Aufwecken'' wie bei Greedy-Strategien
 - Vorhersage: Energiesparmodus sofort nach Erreichen des Leerlaufs, wenn Heuristik vorhersagt,dass Kosten gerechtfertigt
 - Stochastisch: Energiesparmodus auf Grundlage eines stochastischen Modells
 
@@ -496,7 +496,7 @@ weitere Einflussfaktoren: Speicherverwaltungskosten
 - dynamische Speicherreservierung durch Tasks
 
 ##### Beispiel 1: sparsam
-Prozesskontrollblock (PCB, Metadatenstruktur des Prozessdeskriptors) eines kleinen Echtzeit-Kernels („DICK“):
+Prozesskontrollblock (PCB, Metadatenstruktur des Prozessdeskriptors) eines kleinen Echtzeit-Kernels (,,DICK''):
 ```cpp
 // Process Control Block (PCB)
 struct pcb {
@@ -631,8 +631,691 @@ Einflussfaktoren des Betriebssystems:
 - Modularisierung (zur Kompilierzeit) des Kernels: gezielte Anpassung an Einsatzdomäne möglich
 - Adaptivität (zur Kompilier-und Laufzeit) des Kernels: gezielte Anpassung an sich ändernde Umgebungsbedingungen möglich ($\rightarrow$ Cassini-Huygens-Mission)
 
+## Architekturentscheidungen
+- bisher betrachtete Mechanismen: allgemein für alle BS gültig
+- ... typische Einsatzgebiete sparsamer BS: eingebettete Systeme
+- eingebettetes System: (nach [Manl94] )
+  - Computersystem, das in ein größeres technisches System, welches nicht zur Datenverarbeitung dient,physisch eingebunden ist.
+  - Wesentlicher Bestandteil dieses größeren Systems hinsichtlich seiner Entwicklung, technischer Ausstattung sowie seines Betriebs.
+  - Liefert Ausgaben in Form von (menschenlesbaren)Informationen, (maschinenlesbaren)Daten zur Weiterverarbeitung und Steuersignalen.
+- BS für eingebettete Systeme: spezielle, anwendungsspezifische Ausprägung der Aufgaben eines ,,klassischen'' Universal-BS
+  - reduzierter Umfang von HW-Abstraktion, generell: hardwarenähere Ablaufumgebung
+  - begrenzte (extrem: gar keine) Notwendigkeit von HW-Multiplexing & -Schutz
+- daher eng verwandte NFE: Adaptivitätvon sparsamen BS
+- sparsame Betriebssysteme:
+  - energieeffizient ~ geringe Architekturanforderungen an energieintensive Hardware (besonders CPU, MMU, Netzwerk)
+  - speichereffizient ~ Auskommen mit kleinen Datenstrukturen (memory footprint)
+- Konsequenz: geringe logische Komplexität des Betriebssystemkerns
+- sekundär: Adaptivität des Betriebssystemkerns
+
+### Makrokernel (monolithischer Kernel)
+![](Assets/AdvancedOperatingSystems-makrokernel.png)
+- User Space:
+  - Anwendungstasks
+  - CPU im unprivilegiertenModus (Unix ,,Ringe'' 1...3)
+  - Isolation von Tasks durch Programmiermodell(z.B. Namespaces) oder VMM(private vAR)
+- Kernel Space:
+  - Kernelund Gerätecontroller (Treiber)
+  - CPU im privilegierten Modus (Unix ,,Ring'' 0)
+  - keine Isolation (VMM: Kernel wird in alle vAR eingeblendet)
+
+### Mikrokernel
+![](Assets/AdvancedOperatingSystems-mikrokernel.png)
+- User Space:
+  - Anwendungstasks, Kernel-und Treiber tasks ( Serverprozesse, grau)
+  - CPU im unprivilegiertenModus
+  - Isolation von Tasks durch VMM
+- Kernel Space:
+  - funktional minimaler Kernel(μKernel)
+  - CPU im privilegierten Modus
+  - keine Isolation (Kernel wird in alle vAR eingeblendet)
+
+### Architekturkonzepte im Vergleich
+- Makrokernel:
+  - ✓ vglw. geringe Kosten von Kernelcode (Energie, Speicher)
+  - ✓ VMM nicht zwingend erforderlich
+  - ✓ Multitasking ($\rightarrow$ Prozessmanagement!)nicht zwingend erforderlich
+  - ✗ Kernel (inkl. Treibern) jederzeit im Speicher
+  - ✗ Robustheit, Sicherheit, Adaptivität
+- Mikrokernel:
+  - ✓ Robustheit, Sicherheit, Adaptivität
+  - ✓ Kernelspeicherbedarf gering, Serverprozesse nur wenn benötigt ($\rightarrow$ Adaptivität)
+  - ✗ hohe IPC-Kosten von Serverprozessen
+  - ✗ Kontextwechselkosten von Serverprozessen
+  - ✗ VMM, Multitasking i.d.R. erforderlich 
+
+## Beispiel-Betriebssysteme
+### TinyOS
+- Beispiel für sparsame BS im Bereich eingebetteter Systeme
+- verbreitete Anwendung: verteilte Sensornetze (WSN)
+- ,,TinyOS'' ist ein quelloffenes, BSD-lizenziertes Betriebssystem
+- das für drahtlose Geräte mit geringem Stromverbrauch, wie sie in
+    - Sensornetzwerke, ($\rightarrow$  Smart Dust)
+    - Allgegenwärtiges Computing,
+    - Personal Area Networks,
+    - intelligente Gebäude,
+    - und intelligente Zähler.
+- Architektur:
+  - grundsätzlich: monolithisch (Makrokernel) mit Besonderheiten:
+  - keine klare Trennung zwischen der Implementierung von Anwendungen und BS (wohl aber von deren funktionalen Aufgaben!)
+  - $\rightarrow$ zur Laufzeit: 1 Anwendung + Kernel
+- Mechanismen:
+  - kein Multithreading, keine echte Parallelität
+  - $\rightarrow$ keine Synchronisation zwischen Tasks
+  - $\rightarrow$ keine Kontextwechsel bei Taskwechsel
+  - Multitasking realisiert durch Programmiermodell 
+  - nicht-präemptives FIFO-Scheduling
+  - kein Paging$\rightarrow$ keine Seitentabellen, keine MMU
+- in Zahlen:
+  - Kernelgröße: 400 Byte
+  - Kernelimagegröße: 1 - 4 kByte
+  - Anwendungsgröße: typisch ca. 15 kB, Datenbankanwendung: 64 kB
+- Programmiermodell:
+  - BS und Anwendung werden als Ganzes übersetzt: statische Optimierungen durch Compilermöglich (Laufzeit, Speicherbedarf)
+  - Nebenläufigkeit durch ereignisbasierte Kommunikation zw. Anwendung und Kernel
+    - $\rightarrow$  command: API-Aufruf, z.B. EA-Operation (vglb. Systemaufruf)
+    - $\rightarrow$  event: Reaktion auf diesen durch Anwendung
+  - sowohl commands als auch events : asynchron
+- Beispieldeklaration:
+    ```cpp
+    interface Timer {
+      command result_t start(char type, uint32_t interval);
+      command result_t stop();
+      event result_t fired();
+    }
+    interface SendMsg {
+      command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr msg);
+      event result_t sendDone(TOS_MsgPtr msg, result_t success);
+    }
+    ```
+
+### RIOT
+[RIOT-Homepage: http://www.riot-os.org]
+- ebenfalls sparsames BS,optimiert für anspruchsvollere Anwendungen (breiteres Spektrum)
+- ,,RIOT ist ein Open-Source-Mikrokernel-basiertes Betriebssystem, das speziell für die Anforderungen von Internet-of-Things-Geräten (IoT) und anderen eingebetteten Geräten entwickelt wurde.''
+  - Smartdevices,
+  - intelligentes Zuhause, intelligente Zähler,
+  - eingebettete Unterhaltungssysteme
+  - persönliche Gesundheitsgeräte,
+  - intelligentes Fahren,
+  - Geräte zur Verfolgung und Überwachung der Logistik.
+- Architektur:
+  - halbwegs: Mikrokernel
+  - energiesparendeKernelfunktionalität:
+    - minimale Algorithmenkomplexität
+    - vereinfachtes Threadkonzept $\rightarrow$ keine Kontextsicherung erforderlich
+    - keine dynamische Speicherallokation
+    - energiesparende Hardwarezustände vom Scheduler ausgelöst (inaktive CPU)
+  - Mikrokerneldesign unterstützt komplementäre NFE: Adaptivität, Erweiterbarkeit
+  - Kosten: IPC (hier gering!)
+- Mechanismen:
+  - Multithreading-Programmiermodell
+  - modulare Implementierung von Dateisystemen, Scheduler, Netzwerkstack
+- in Zahlen:
+  - Kernelgröße: 1,5 kByte
+  - Kernelimagegröße: 5 kByte
+
+Implementierung
+- ... kann sich jeder mal ansehen (keine spezielle Hardware, beliebige Linux-Distribution, FreeBSD, macOSX mit git ):
+  ```bash
+  $ git clone git://github.com/RIOT-OS/RIOT.git
+  $ cd RIOT
+  $ cd examples/default/
+  $ make all
+  $ make term
+  ```
+- startet interaktive Instanz von RIOT als ein Prozess des Host-BS
+- Verzeichnis RIOT: Quellenzur Kompilierung des Kernels, mitgelieferte Bibliotheken, Gerätetreiber, Beispielanwendungen; z.B.:
+  - RIOT/core/include/thread.h: Threadmodell, Threaddeskriptor
+  - RIOT/core/include/sched.h,
+  - RIOT/core/sched.c: Implementierung des (einfachen) Schedulers
+- weitere Infos: riot-os.org/api
+
 
 # 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
@@ -668,3 +1351,17 @@ Einflussfaktoren des Betriebssystems:
 - TinyOS
   - KELLNER, SIMON; BELLOSA, FRANK: Energy Accounting Support in TinyOS
   - 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.