Advanced Operating Systems - tu-ilmenau.de · § externer Zustand (einer Systems oder Subsystems):...

-

Peter Amthor Fak. IA / FG VSBS Technische Universität Ilmenau www.tu-ilmenau.de/vsbs

Advanced Operating Systems

Kapitel 3: Robustheit und Verfügbarkeit

Peter Amthor Wintersemester 2018/19

AOS WS 2018/19 © P. Amthor, H.-A. Schindler 3–2

2nd Winter School on Operating Systems (Firmen vor Ort, Verbindung von Theorie und Praxis!)

24.02.-01.03.2019, Web: WSOS 2019


3.1 Motivation

■  allgemein: verlässlichkeitskritische Anwendungsszenarien ◆  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 performance computing)

Deep Space 1 (NASA, seit 1998): „Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience.“ [Garret02]

3.1 Motivation


Warum Betriebssysteme verlässlich sein sollten ...

... nach Andrew Tanenbaum:

https://www.youtube.com/watch?v=bx3KuE7UjGA&t=4m16s

3.1 Motivation


■  Verlässlichkeit (dependability) ◆  übergeordnete Eigenschaft eines Systems [Laprie+04b] ◆  Fähigkeit, eine Leistung zu erbringen, der man berechtigterweise vertrauen

kann

Taxonomie: umfasst entsprechend Definition die Untereigenschaften

1.  Verfügbarkeit (availability) 2.  Robustheit (robustness, reliability) 3.  Sicherheit im Sinne von safety (safety) 4.  Vertraulichkeit (confidentiality) 5.  Integrität (integrity) 6.  Wartbarkeit (maintainability)

Ø  nicht für alle Anwendungen sind alle Untereigenschaften erforderlich

auch Untereigenschaften

von IT-Sicherheit

(vgl.: evolutionäre Eigenschaften)

3.2 Allgemeine Begriffe



■  Teil der primären Untereigenschaften von Verlässlichkeit:

■  Robustheit: Zuverlässigkeit unter Anwesenheit externer Ausfälle

■  im Folgenden: kurze Systematik der Ausfälle...


Robustheitsbegriff



■  Fehler à fehlerhafter Zustand à Ausfall ◆  grundlegende Definitionen dieser Begriffe (ausführlich: [Laprie+04a], [Laprie+04b]):

§  Ausfall (failure): liegt vor, wenn tatsächliche Leistung(en), die ein System erbringt, von als korrekt spezifizierter Leistung abweichen

§  fehlerhafter Zustand (error): notwendige Ursache eines Ausfalls (nicht jeder error muss zu failure führen)

§  Fehler (fault): Ursache für fehlerhaften Systemzustand (error), z.B. Programmierfehler

Fehler und Ausfälle ...


fault error failure Aktivierung (activation)

Ausbreitung (propagation)

Fehler fehlerhafter Zustand Ausfall

✗ ✗

✗

✗

✗

sekundäre Ausfälle


■  Umgang mit ... ◆  faults:

•  Korrektheit testen •  Korrektheit beweisen (à formale Verifikation)

◆  errors: •  Isolation von Subsystemen

à Abschnitt 3.3: Isolationsmechanismen ◆  failures:

•  Ausfallverhalten (neben korrektem Verhalten) spezifizieren •  Ausfälle zur Laufzeit erkennen und Folgen beheben, abschwächen...

à Abschnitt 3.5: Micro-Reboots

... und ihre Vermeidung


fault error failure

Aktivierung (activation)



✗ ✗

✗

✗

✗

sekundäre Ausfälle


■  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

Fehlerhafter Zustand

Kernel

IPC FS Treiber IPC IPC ...



à Robustheit: Isolationsmechanismen

externer Ausfall (aus Sicht des FS)

Fehlerausbreitung und (externer) Ausfall

■  Wirkungskette: Treiber-Programmierfehler (fault)

Kernel

IPC FS Treiber ✗ ✗ ✗

✗


Ausbreitung dieses Fehlers (failure des Treibers) = fehlerhafter externer Zustand des Treibers = fehlerhafter interner Zustand des Kernels (error) = Kernelausfall! (failure)

✗ fehlerhafter interner Zustand des Treibers (error)

✗ Auswirkung: fehlerhafter interner Zustand eines weiteren Kernel-Subsystems (z.B. error des Dateisystems)

IPC IPC ...


3.3 Isolationsmechanismen (Teil I)

■  im Folgenden: Isolationsmechanismen für robuste Betriebssysteme ◆  durch strukturierte Programmierung (3.3.1) ◆  durch Adressraumisolation (3.3.2)

■  es gibt noch mehr: Isolationsmechanismen für sichere Betriebssysteme ◆  all die obigen... ◆  durch kryptografische Hardwareunterstützung: Enclaves (Kap. 4) ◆  durch streng typisierte Sprachen und managed code (Kap. 4) ◆  durch isolierte Laufzeitumgebungen: Virtualisierung (Kap. 6) (à Teil II)

3.3 Isolationsmechanismen

fault error




✗ ✗

✗

✗

✗

failure


3.3.1 Strukturierte Programmierung


Monolithisches Betriebssystem

■  Anwendungen ■  Kernel

◆  gesamte BS-Funktionalität ◆  programmiert als

Sammlung von Prozeduren ◆  jede darf jede davon

aufrufen ◆  keine Modularisierung ◆  keine definierten internen

Schnittstellen

(Abb.: [Preikschat97], S. 3)


Monolithisches Prinzip

■  Ziel: Isolation zwischen Anwendungen und Betriebssystem ■  Mechanismus: Prozessor-Privilegierungsebenen (user mode und

kernel mode) ■  Konsequenz für Strukturierung des Kernels:

Es gibt keine Strukturierung des Kernels ...

■  ... jedenfalls fast: Ablauf eines Systemaufrufs (Erinnerung)


Kernel-code

App

main

user mode

kernel mode syscall handler utility

trap

dispatching


Strukturierte Makrokernarchitektur

■  Resultat: schwach strukturierter (monolithischer) Makrokernel


main-Prozedur

handler-Prozeduren

utility-Prozeduren

(Abb. nach [Tanenbaum06], S. 45)


Strukturierte Makrokernarchitektur

■  Resultat: schwach strukturierter (monolithischer) Makrokernel


main-Prozedur fixer Einstiegspunkt für sämtliche Anwendungs-Kernel-Kommunikation

handler-Prozeduren Implementierung des jeweiligen BS-Dienstes für jeden Systemaufruf

utility-Prozeduren Implementierung von BS-Hintergrunddiensten, die von Systemaufrufimplementierung genutzt werden (z.B. Speicheradressen lesen/schreiben)

(Abb. nach [Tanenbaum06], S. 45)


Modularer Makrokernarchitektur

■  Weiterentwicklung: ◆  Schichtendifferenzierung (layered operating system) ◆  Modularisierung (Bsp.: Linux-Kernel)


VFS

IPC, Dateisystem

Scheduler, VMM

Dispatcher, Gerätetreiber

Kernelcode

■  Modularer Makrokernel: ◆  alle Kernelfunktionen in Module unterteilt (z.B. verschiedene Dateisysteme)

à Erweiterbarkeit, Wartbarkeit, Portierbarkeit ◆  klar definierte Modulschnittstellen (z.B. virtual file system, VFS) ◆  live updates: Module zur Kernellaufzeit dynamisch einbindbar (à 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 à Robustheit...?

■  nächstes Ziel: Schutz gegen Laufzeitfehler ...

à Laufzeitmechanismen


3.3.2 Adressraumisolation

■  zur Erinnerung: private virtuelle Adressräume zweier Tasks (i ≠ j)


pAR

Kernel

vAR (Taskj ) vAR (Taski )


Adressraumisolation

■  private virtuelle vs. physischer Adresse


pAR

Kernel

vAR (Taskj ) vAR (Taski )

int *x = (int *)0x2800f2;*x = 42;

int *y = (int *)0x2800f2;*y = 9 * 6;

54 42


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-Mech. explizit hergestellt werden (u.U. auch shared memory) à Überwachung und Validierung zur Laufzeit möglich

✓  Kontrollfluss begrenzen: Funktionsaufrufe können i.A. (Ausnahme: RPC) keine AR-Grenzen überschreiten à BS-Zugriffssteuerung kann nicht durch Taskfehler ausgehebelt

werden (vgl. Kap. 4) à unabsichtliche Terminierungsfehler (unendliche Rekursion)

erschwert .... 3.3.2 Adressraumisolation


Was das für den Kernel bedeutet

■  private virtuelle Adressräume ◆  gibt es schon so lange wie VMM ◆  gab es lange nur auf Anwendungsebene ◆  à keine Isolation zwischen Fehlern innerhalb des Kernels!

■  nächstes Ziel: Schutz gegen Kernelfehler (Gerätetreiber!) ... à BS-Architektur

Kernel



3.4 Mikrokernelarchitektur

■  Fortschritt ggü. Makrokernel: ◆  Strukturierungskonzept:

strenger durchgesetzt durch konsequente Zerlegung in voneinander unabhängige Teilsysteme

◆  zusätzlich zu vertikaler Strukturierung des Kernels: senkrechte Strukturierung eingeführt à funktionale Einheiten: senkrecht (Schichten) à isolierte Einheiten: waagerecht (private vAR)

■  Idee: ◆  Kernel (alle BS-Funktionalität) à µKernel (minimale BS-Funktionalität) ◆  Rest (insbes. Treiber): „gewöhnliche“ Anwendungsprozesse mit

Adressraumisolation ◆  Kommunikation: botschaftenbasierte IPC (auch client-server operating

system) ◆  Nomenklatur: Mikrokernel und Serverprozesse



Modularer Makrokernel vs. Mikrokernel


VFS

IPC, Dateisystem

Scheduler, VMM


■  minimale Kernelfunktionalität: ◆  keine Dienste, nur allgemeine Schnittstellen ◆  keine Strategien, nur Mechanismen

■  neues Problem: Mikrokerneldesign ◆  „Wir haben 100 Leute gefragt...“: Wie entscheide ich das??? (3.4.2)

IPC, VMM

App App

Dateisystem-Server

Treiber1

Scheduler-Server

Treiber2 Treiber3

...

user mode

kernel mode

(Abb. nach [Heiser14])


Modularer Makrokernel vs. Mikrokernel


VFS

IPC, Dateisystem

Scheduler, VMM


■  Ablauf eines Systemaufrufs: (vgl. F. 3-13) ◆  schwarz: unprivilegierte Instruktionen ◆  blau: privilegierte Instruktionen ◆  rot: Übergang zwischen beidem (à Kontextwechsel!)

IPC, VMM

App App

Dateisystem-Server

Treiber1

Scheduler-Server

Treiber2 Treiber3

...

user mode

kernel mode



Robustheit von Mikrokernen

■  = Gewinn durch Adressraumisolation innerhalb des Kernels (vgl. F. 3-20): ✓  nichtvertrauenswürdiger Code im kernel mode kann keine beliebigen

physischen Adressen schreiben ✓  Kommunikation zwischen nvw. Code (nicht zur zwischen Anwendungstasks)

muss durch IPC explizit hergestellt werden à Ü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)



Robustheit von Mikrokernen

■  = Gewinn durch Adressraumisolation innerhalb des Kernels (vgl. F. 3-20): ✓  nichtvertrauenswürdiger Code im kernel mode kann keine beliebigen

physischen Adressen schreiben ✓  Kommunikation zwischen nvw. Code (nicht zur zwischen Anwendungstasks)

muss durch IPC explizit hergestellt werden à Ü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. Kernelcode muss nicht mehr im kernel mode (= höchste

Prozessorprivilegierung) laufen ✓  verbleibender Kernel (dessen Korrektheit wir annehmen müssen): klein,

funktional weniger komplex, leichter zu entwickeln, zu testen, evtl. formal zu verifizieren

✓  daneben: Adaptivität durch konsequentere Modularisierung des Kernels gesteigert



3.4.1 Mach

3.4.1 Mach

Mikrokernel-Design: Erster Versuch

Carnegie Mellon University (CMU), School of Computer Science 1985 – 1994


Ein wenig Historie

System V

Mac OS X (Apple)

R. Rashid

S. Jobs

R. Stallman

3.4.1 Mach

1970

1980

GNU Hurd (FSF)

1990

K. Thompson D. Ritchie

W. Joy

NeXTSTEP (NeXT)

UNIX (Bell Labs)

BSD (U Berkeley)

Mach (CMU)


  Entwicklungshistorie ◆  entwickelt auf Grundlage älterer Systeme:

•  1975: Aleph (BS des „Rochester Intelligent Gateway“), U Rochester

•  1979/81: Accent (verteiltes BS), CMU

◆  Entwicklung stark gefördert durch DARPA (SCI) •  DARPA: Defense Advanced Research Projects Agency •  SCI: Strategic Computing Initiative

◆  1986: Mach 1.0 – Multiprozessor-Betriebssystem ◆  1988: Mach 2.5 – noch kein Mikro-Kern; viel BSD-UNIX-Code ◆  1989: Mach 3.0 – Mikrokernversion

•  Grundlage für weitere Entwicklungen, insbesondere verteilte Systeme

Entwickler: Richard Rashid

Mach: Entstehung

3.4.1 Mach


  Mach-Mikrokernel ◆  einer der ersten praktisch nutzbaren µKerne

◆  entwickelt als Basis zur Emulation (∆ zu Virtualisierung!) von UNIX und

Derivaten u  mehrere unterschiedliche Emulatoren gleichzeitig lauffähig (s. F. 3-31)

•  Emulation außerhalb des Kernels •  jeder Emulator:

–  Komponente im Adressraum des Applikationsprogramms –  1 … n Server, die unabhängig von Applikationsprogramm laufen

Mach: Ziele

3.4.1 Mach


([Tanenbaum92], Abb. 15-1, S. 639)

Emulation von UNIX-Systemen mittels Mach-Serverprozessen

Mach-Server zur Emulation

3.4.1 Mach


  Komponenten innerhalb des µKernels:

1.  Prozessverwaltung 2.  Speicherverwaltung 3.  IPC- und E/A-Dienste

einschließlich Gerätetreiber

  unterstützte Abstraktionen (à 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]

Mach

3.4.1 Mach



Mach: Architektur

3.4.1 Mach

µKernel

Basis-FS

App1 App2 App3

Swapping

(UNIX-Emulatoren)

...

User Space

Kernel Space Gerätetreiber

Scheduling IPC VMM


■  Bewertung aus heutiger Sicht: §  funktional komplex §  153 Systemaufrufe §  mehrere Schnittstellen, parallele Implementierungen für eine Funktion

à Adaptivität (Auswahl durch Programmierer)

Mach: Bewertung

3.4.1 Mach

■  Fazit: ◆  zukunftsweisender Ansatz ◆  langsame und ineffiziente Implementierung

■  Systemaufrufkosten: §  Benchmark (1995): i486

Prozessor, 50 MHz §  Messung mit verschiedenen

Botschaftenlängen (x-Werte) §  ohne Nutzdaten (0 Byte

Botschaftenlänge): 115 µs (Tendenz unfreundlich ...)

0

100

200

300

400

500

0 1000 2000 3000 4000

Mach-Systemaufrufperformanz

(nach [Heiser14])

[B]

[µs]


Mach: Lessons Learned

■  erster Versuch: ◆  Idee des Mikrokernels bekannt ◆  Umsetzung: Designkriterien weitgehend unbekannt

■  Folgen für Performanz und Programmierkomfort (s.a. [Heiser14]): ✗  „complex“ ✗  „inflexible“ ✗  „slow“

3.4.1 Mach

µKernel

■  Lessons Learned: ◆  wir wissen etwas über Kosten: IPC-Performanz ◆  wir wissen noch nichts über guten µKern-

Funktionsumfang und gute Schnittstellen...

à nächstes Ziel!


3.4.2 L4

3.4.2 L4

■  Made in Germany: ◆  Jochen Liedtke (GMD, „Gesellschaft für Mathematik

und Datenverarbeitung“), Betriebssystemgruppe (u.a.): J. Liedtke, H. Härtig, W. Kühnhauser

◆  Symposium on Operating Systems Principles 1995 (SOSP’95): „On µ-Kernel Construction“ [Liedtke95]

■  Analyse des Mach-Kernels: 1.  falsche Abstraktionen 2.  unperformante Implementierung 3.  prozessorunabhängige Implementierung

•  Letzteres: effizienzschädliche Eigenschaft eines Mikrokernels •  Neuimplementierung eines (konzeptionell sauberen!) µ-Kerns kaum teurer

als Portierung auf andere Prozessorarchitektur


■  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)

L3 und L4

3.4.2 L4

COMP9242 Advanced Operating Systems

S2/2014 Week 1: Introduction to seL4

COMP9242 S2/2014 W01 ©2011 Gernot Heiser UNSW/NICTA. Distributed under Creative Commons Attribution License 2

Copyright Notice

These slides are distributed under the Creative Commons Attribution 3.0 License

•  You are free: –  to share—to copy, distribute and transmit the work –  to remix—to adapt the work

•  under the following conditions: –  Attribution: You must attribute the work (but not in any way that

suggests that the author endorses you or your use of the work) as follows:

•  “Courtesy of Gernot Heiser, [Institution]”, where [Institution] is one of “UNSW” or “NICTA”

The complete license text can be found at http://creativecommons.org/licenses/by/3.0/legalcode

COMP9242 S2/2014 W01

©2011 Gernot Heiser UNSW/NICTA. Distributed under Creative Commons Attribution License 3

Monolithic Kernels vs Microkernels

•  Idea of microkernel: –  Flexible, minimal platform –  Mechanisms, not policies –  Goes back to Nucleus [Brinch Hansen, CACM’70]

COMP9242 S2/2014 W01

Hardware

VFS

IPC, file system

Scheduler, virtual memory

Device drivers, dispatcher

Hardware

IPC, virtual memory

Application

Application

Unix Server

File Server Device

Driver

Syscall

IPC

Kernel Mode

User Mode

©2011 Gernot Heiser UNSW/NICTA. Distributed under Creative Commons Attribution License 4

Microkernel Evolution

First generation

•  Eg Mach [’87]

•  180 syscalls •  100 kLOC •  100 µs IPC

Third generation

•  seL4 [’09]

•  ~3 syscalls •  9 kLOC •  0.2–1 µs IPC

COMP9242 S2/2014 W01

IPC, MMU abstr. Scheduling

Kernel memory Devices

Low-level FS, Swapping

Memory Objects

Second generation


Memory- mangmt library

•  Eg L4 [’95]

•  ~7 syscalls •  ~10 kLOC •  ~ 1 µs IPC


Kernel memory

(Abb.: [Heiser14])


■  Was gehört in einen Mikrokern? ◆  Liedtke: Unterscheidung zwischen Konzepten und deren Implementierung ◆  bestimmende Anforderungen an beide:

Konzeptsicht à Funktionalität, Implementierungssicht à Performanz

Ø  1. µKernel-Generation: Konzept durch Performanzentscheidungen aufgeweicht

Ø  Effekt in der Praxis genau gegenteilig: schlechte (IPC-) Performanz!

Mikrokernel-Designprinzipien

3.4.2 L4

„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.“


■  Designprinzipien für Mikrokernel-Konzept: Ø  Annahmen hinsichtlich der funktionalen Anforderungen:

1.  System interaktive und nicht vollständig vertrauenswürdige Applikationen unterstützen (à 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₁ muss sich auf Garantien von S₂ 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.“

Mikrokernel-Designprinzipien

3.4.2 L4


■  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

L4: Speicherabstraktion

3.4.2 L4 | Speicherabstraktion


■  Idee: abstrakte Speicherverwaltung ◆  rekursive Konstruktion und Verwaltung der Adressräume auf

Benutzer- (Server-) Ebene ◆  Mikrokernel stellt dafür genau drei Operationen bereit:

1.  map

2.  flush

3.  grant

L4: Speicherabstraktion



■  Rekursive Konstruktion der Adressraumhiearchie ◆  Server und Anwendungen kö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

Realspeicher

Pager 2 Pager 1

Pager 3

Pager 4

Anwendung Anwendung

Anwendung Anwendung


Hierarchische Adressräume


■  grant(x)

§  Eigentümer S eines Adressraumes gibt beliebige Seite x an Adressraum von Empfänger S‘ weiter

§  Voraussetzungen: -  S‘ stimmt zu -  S selbst darf auf x zugreifen (à Grundlage der Isolation)

§  weitergegebene Seite x: -  aus Adressraum von S entfernt -  in Adressraum von S‘ eingefügt


grant-Operation


■  map(x)

§  Eigentümer S eines Adressraumes bildet beliebige Seite x in Adressraum von Empfänger S‘ ab

§  Voraussetzungen: -  S‘ stimmt zu -  S selbst darf auf x zugreifen (à Grundlage der Isolation)

§  abgebildete Seite x: -  in Adressraum von S‘ eingefügt -  in Adressräumen von S und S‘ zugreifbar


map-Operation


■  flush(x)

§  Eigentümer S eines Adressraumes flusht (revoziert) beliebige Seite x §  Voraussetzung: -  S selbst darf auf x zugreifen

§  geflushte Seite x: -  bleibt in Adressraum von S zugreifbar -  wird aus den Adressräumen aller S‘, welche auf x durch ein grant oder

map von S Zugriff erhalten haben, entfernt §  alle S‘ müssen nicht zustimmen

Ø  flush ist nicht autonomieschädlich, obwohl explizite Zustimmung betroffener Adressräume nicht erforderlich ist:

•  flushbar: nur eigene Seiten •  betroffene Adressräume haben potentiellem flush bei Akzeptieren von

map- oder grant-Operation bereits zugestimmt


flush-Operation


■  Thread ◆  innerhalb eines Adressraumes ablaufende Aktivität ◆  à 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 Ø  Autonomieprinzip Ø  Konsequenz: Adressraumisolation Ø  entscheidender Grund zur Realisierung des Thread-Konzepts innerhalb

des Mikrokernels

3.4.2 L4 | Threadabstraktion

L4: Threadabstraktion


■  Interprozess-Kommunikation ◆  Kommunikation über Adressraumgrenzen: vertrauenswürdig kontrollierte

Aufhebung der Isolation ◆  à essenziell für (sinnvolles) Multitasking und –threading

■  Designentscheidung

Ø  Integritätsprinzip Ø  wir haben schon: vertrauenswürdige Adressraumisolation im µKernel Ø  grundlegendes IPC-Konzepts innerhalb des Mikrokernels (flexibel und

dynamisch durch Server erweiterbar, analog Adressraumhierarchie)

IPC



Identifikatoren


■  Thread- und Ressourcenbezeichner ◆  müssen vertrauenswürdig vergeben (authentisch und i.A. persistent) und

verwaltet (eindeutig und korrekt referenzierbar) werden ◆  à essenziell für (sinnvolles) Multitasking und –threading ◆  à essenziell für vertrauenswürdige Kernel- und Server-Schnittstellen

■  Designentscheidung

Ø  Integritätsprinzip Ø  ID-Konzept innerhalb des Mikrokernels (wiederum: durch Server erweiterbar)


1.  Ein minimaler Mikrokernel §  soll in darauf implementierten Subsystemen Minimalmenge an geeigneten

Abstraktionen zur Verfügung stellen, •  die flexibel genug, um Implementierung beliebiger Betriebssysteme zu

ermöglichen •  u. Nutzung umfangreicher Menge verschiedener Hardware-Plattformen

gestattet

2.  Geeignete, funktional minimale Mechanismen: §  Adressraum mit map-, flush- u. grant-Operation §  Threads inklusive IPC §  eindeutige Identifikatoren sind solche Basis

3.  Wahl der geeigneten Abstraktionen: §  kritisch, für Flexibilität, Verifizierbarkeit und Performanz des Mikrokerns

L4: Lessons Learned

3.4.2 L4


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

6.  innerhalb eines Mikrokernels sind 1.  grundlegende Implementierungsentscheidungen 2.  meiste Algorithmen u. Datenstrukturen

von Prozessorhardware abhängig

L4: Lessons Learned

3.4.2 L4


7.  Ihr Entwurf muss durch Performanz-Vorhersagen u. -Analysen diktiert werden.

8.  Neben ungeeigneten Basis-Abstraktionen, häufigste Fehler durch unzureichendes Verständnis des kombinierten Hardware-Software-Systems oder ineffiziente Implementierungen.

à L3- und L4-Prototypen by J. Liedtke: 99% Assemblercode

(Zur weiteren Lektüre: J. Liedtke. 1995. On µ-Kernel Construction. SIGOPS Operating Systems Review 29, 5 (Dec. 1995), S. 237-250.)

L4: Lessons Learned

3.4.2 L4


■  Fazit: ◆  Mikrokernel mit akzeptabler Performanz: hardwarespezifische

Implementierung minimal erforderlicher, vom Prozessortyp unabhängiger Abstraktionen

L4: Lessons Learned

3.4.2 L4

0

100

200

300

400

500

0 1000 2000 3000 4000

Systemaufrufperformanz

Mach L4

(nach [Heiser14])

[B]

[µs]

115 µs

5 µs


■  nach Tod von J. Liedtke (2001) auf Basis von L4 zahlreiche moderne BS ■  L4 heute: Spezifikation eines Mikrokernels (nicht Implementierung)

L4: Heutige Bedeutung

3.4.2 L4

©2012 Gernot Heiser, UNSW/NICTA. Distributed under Creative Commons Attribution License 5

0

100

200

300

400

0 2000 4000 6000 Message Length [B]

Mach [µs]

0

100

200

300

400

0 2000 4000 6000 Message Length [B]

Mach

L4

[µs]

1993 “Microkernel” IPC Performance

COMP9242 S2/2014

115 µs

5 µs

i486 @ 50 MHz

Culprit: Cache footprint [SOSP’95] raw copy


L4 IPC Performance over 20 Years

Name Year Processor MHz Cycles µs Original 1993 i486 50 250 5.00 Original 1997 Pentium 160 121 0.75 L4/MIPS 1997 R4700 100 86 0.86 L4/Alpha 1997 21064 433 45 0.10 Hazelnut 2002 Pentium 4 1,400 2,000 1.38 Pistachio 2005 Itanium 1,500 36 0.02 OKL4 2007 XScale 255 400 151 0.64 NOVA 2010 i7 Bloomfield (32-bit) 2,660 288 0.11 seL4 2013 i7 Haswell (32-bit) 3,400 301 0.09 seL4 2013 ARM11 532 188 0.35 seL4 2013 Cortex A9 1,000 316 0.32

COMP9242 S2/2014


Minimality: Source Code Size

Name Architecture C/C++ asm total kSLOC Original i486 0 6.4 6.4 L4/Alpha Alpha 0 14.2 14.2 L4/MIPS MIPS64 6.0 4.5 10.5 Hazelnut x86 10.0 0.8 10.8 Pistachio x86 22.4 1.4 23.0 L4-embedded ARMv5 7.6 1.4 9.0 OKL4 3.0 ARMv6 15.0 0.0 15.0 Fiasco.OC x86 36.2 1.1 37.6 seL4 ARMv6 9.7 0.5 10.2

COMP9242 S2/2014 ©2012 Gernot Heiser, UNSW/NICTA. Distributed under Creative Commons Attribution License 8

93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13

L3→L4 “X” Hazelnut Pistachio

L4/Alpha

L4/MIPS

seL4

OKL4-µKernel

OKL4-Microvisor

Codezero

P4 → PikeOS

Fiasco Fiasco.OC

L4-embed.

Nova GMD/IBM/Karlsruhe

UNSW/NICTA

Dresden

L4 Family Tree

Assember

C++

C

Asm+C

C++

C C

Portable

Caps

Verified

COMP9242 S2/2014

API Inheritance

Code Inheritance

(Abb.: [Heiser14])


■  Einige Weiterentwicklungen:

§  TU Dresden (Hermann Härtig): Neuimplementierung in C++ (L4/Fiasco), Basis des Echtzeit-Betriebssystems DROPS, der Virtualisierungsplattform NOVA (genauer: Hypervisor, à Kap. 6) und des adaptiven BS-Kernels Fiasco.OC

§  University of New 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

botschaftenbasierter IPC (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)

L4: Heutige Bedeutung

3.4.2 L4


Zwischenfazit

■  Begrenzung von Fehlerausbreitung (à Folgen von errors): ◆  konsequent modularisierte Architektur aus Subsystemen ◆  Isolationsmechanismen zwischen Subsystemen

■  Konsequenzen für BS-Kernel: ◆  statische Isolation auf Quellcodeebene à strukturierte Programmierung ◆  dynamische Isolation zur Laufzeit à 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ät und Adaptivität des Kernels

■  Und was noch nicht? ✗  Behandlung von Ausfällen

(à 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 à kleiner Kernel = geringeres Risiko von Systemausfällen à durch BS-Code in Serverprozessen: verbleibendes Risiko unabhäniger 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

à Micro-Reboots

3.5 Micro-Reboots

fault error




✗ ✗

✗

✗

✗

failure


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

à höchste Priorität ◆  Treiber- und Serverausfälle minimieren durch Verbergen ihrer

Auswirkungen à nachgeordnete Priorität (Best-Effort-Prinzip)

■  Idee: ◆  Systemausfälle à µKernel ◆  Treiber- und Serverausfälle à Neustart durch spezialisierten Serverprozess

3.5 Micro-Reboots


Beispiel: Ethernet-Treiberausfall

3.5 Micro-Reboots

■  schwarz: ausfallfreie Kommunikation ■  rot: Ausfall und Behandlung ■  blau: Wiederherstellung nach Ausfall

µKernel

Browser

Netzwerk-Server

Ethernet-Treiber

µReboot-Server

alive?

µKernel

Browser

Netzwerk-Server

Ethernet-Treiber

µReboot-Server

¬alive; reboot

µKernel

Browser

Netzwerk-Server

Ethernet-Treiber *

µReboot-Server

new eth

resend


Beispiel: Dateisystem-Serverausfall

3.5 Micro-Reboots

■  schwarz: ausfallfreie Kommunikation ■  rot: Ausfall und Behandlung ■  blau: Wiederherstellung nach Ausfall

µKernel

vim

FS- Server

HDD-Treiber

µReboot-Server

alive?

ODD-Treiber

cdr

µKernel

FS- Server

µReboot-Server

¬alive; reboot

vim cdr

HDD-Treiber

ODD-Treiber

µKernel

FS- Server *

µReboot-Server

vim cdr

HDD-Treiber

ODD-Treiber

rewrite


3.6 Beispiel-Betriebssystem: MINIX

■  Ziele: ◆  robustes Betriebssystems ◆  à 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 ■  für alle, die noch nie davon gehört haben:

„What is MINIX? The most popular OS in the world, thanks to Intel“

3.6 MINIX

„An Open Letter to Intel“: https://www.cs.vu.nl/~ast/intel/


µKernel

Architektur

3.6 MINIX

■  Kommunikationsschnittstellen ... ◆  ... 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

Anwendungen

User Space

Kernel Space

Gerätetreiberprozesse

POSIX system calls

MINIX kernel calls

IPC IPC

IPC

IPC

MINIX kernel calls


Architektur

■  Betriebssystem-Serverprozesse: ◆  Dateisystem (FS) ◆  Prozessmanagement (PM) ◆  Netzwerkmanagement (Net) ◆  Reincarnation Server (RS) à Micro-Reboots jeglicher Serverprozesse ◆  (u. a.) ...

µKernel

FS

App1 App2 App3

VMM PM ...

...

User Space

Kernel Space

Net RS


3.6 MINIX


Architektur

■  Kernelprozesse: ◆  system task ◆  clock task

µKernel

FS

App1 App2 App3

VMM PM ...

...

User Space

Kernel Space

Net RS


system clock

echte Prozesse, höchste Scheduling-Prio.

3.6 MINIX


Reincarnation Server

3.6 MINIX

Implementierungstechnik für Micro-Reboots: ■  Prozesse zum Systemstart (à 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

init rs

...

bash

app1 app2 appn

fs pm

... tty treiberm treiber1

... interrupt: terminierter Kindprozess


MINIX: Ausprobieren!

3.6 MINIX

■  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


3.7 Verfügbarkeit

3.7 Verfügbarkeit

■  komplementäre NFE zu Robustheit: Verfügbarkeit (availability)

  Beziehung: ◆  Verbesserung von Robustheit ⇒ 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 ⇒ Sicherheit (security) (à nächstes Kapitel)

Zur Erinnerung: Untereigenschaften von Verlässlichkeit



  Allgemeine Definition: ◆  Der Grad, zu welchem ein System oder eine Komponente funktionsfähig und

zugänglich (erreichbar) ist, wann immer seine Nutzung erforderlich ist. (IEEE)

■  genauer quantifiziert: ◆  Der Anteil an Laufzeit eines Systems, in dem dieses seine spezifizierte

Leistung erbringt.

system up (lt. Spezifikation funktionsfähig)

system down (keine oder nicht

spezifikationsgemäße Funktion)

MTTF

MTTR

Availability = Total Uptime / Total Lifetime = MTTF / (MTTF + MTTR) •  MTTR: Mean Time to Recovery •  MTTF: Mean Time to Failure

Begriff

t

3.7 Verfügbarkeit


■  einige Verfügbarkeitsklassen:

■  Maßnahmen: ◆  Robustheitsmaßnahmen ◆  Redundanz ◆  Ausfallmanagement

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


Überblick:

QNX: Mikrokern-Betriebssystem

§  primäres Einsatzfeld: eingebettete Systeme, z.B. Automobilbau

§  Mikrokernarchitektur mit Adressraumisolation für Gerätetreiber

§  (begrenzt) dynamische Micro-Reboots möglich à Maximierung der uptime des Gesamtsystems

QNX Neutrino: Hochverfügbares Echtzeit-BS

3.7 Verfügbarkeit


Gewährleistung der Hochverfügbarkeit:

1.  High-Avalability-Manager Laufzeit-Monitor, der ein mehrstufiges Recovery durchführen kann, falls Systemdienste oder Anwendungsprozesse ausfallen („abstürzen“) à µReboot-Server

2.  High-Availability-Client-Libraries Funktionen zum transparenten automatischen Recovery für ausgefallene Server-Verbindungen

QNX Neutrino

3.7 Verfügbarkeit


Verlässlichkeitsbegriff, Ausfallmodell: ■  [Laprie+04a]

Algirdas Avizienis, Jean-Claude Laprie, Brian Randell: Dependability and its Threats – A Taxonomy IFIP Congress Topical Sessions 2004, S. 91-120

■  [Laprie+04b] Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, Carl E. Landwehr: Basic Concepts and Taxonomy of Dependable and Secure Computing IEEE Transactions on Dependable and Secure Computing, Vol. 1, No. 1, Jan-Mar 2004, S. 11–33

Deep Space 1 Remote Debugging: ■  [Garret02]

Ron Garret: Lisping at JPL 2002. Online: http://www.flownet.com/gat/jpl-lisp.html

Literatur


Kernelarchitekturdesign und Mikrokernelprinzip: ■  [Preikschat97]

Wolfgang Schröder-Preikschat (wosch): N.N. ■  [Tanenbaum92]

Andrew S. Tanenbaum: Modern Operating Systems Prentice-Hall 1992, ISBN 0-13-588187-0

■  [Heiser14] Gernot Heiser: COMP9242 Advanced Operating Systems Lecture Slides UNSW Australia, 2014. Courtesy of Gernot Heiser, UNSW.

Mikrokerneldesign, L4: ■  [Liedtke95]

Jochen Liedtke: On µ-Kernel Construction ACM SIGOPS Operating Systems Review 29, 5 (Dec 1995), S. 237-250. DOI: https://doi.org/10.1145/224056.224075

Literatur


MINIX: ■  [Tanenbaum06]

Andrew S. Tanenbaum, Albert S. Woodhull: Operating Systems – Design and Implementation (3rd ed.) Pearson Education 2006, ISBN 978-0-13-142938-3

■  [Herder06] Jorrit N. Herder, Herbert Bros, Ben Gras, Philip Homburg, Andrew S. Tanenbaum: MINIX 3: A Highly Reliable, Self-Repairing Operating System ACM SIGOPS Operating Systems Review 40, 3 (Jul 2006), S. 80–89

■  [Tanenbaum10] Andrew S. Tanenbaum, Raya Appuswamy, Herbert Bros, Lorenzo Cavallaro, Cristiano Guiffrida, Tomáš Hrubý, Jorrit N. Herder, Erik van der Kouwe, David van Moolenbroek: MINIX 3: Status Report and Current Research USENIX ;login:, Vol. 35, No. 3 (Jun 2010), S. 7–13

Literatur

ENDE Kap. 3

Advanced Operating Systems - tu-ilmenau.de · § externer Zustand (einer Systems oder Subsystems):...

Documents

Transcript of Advanced Operating Systems - tu-ilmenau.de · § externer Zustand (einer Systems oder Subsystems):...