Mikrokernelarchitektur
This commit is contained in:
parent
bd5724594c
commit
86f907f98b
BIN
Advanced Operating Systems - Cheatsheet.pdf
(Stored with Git LFS)
BIN
Advanced Operating Systems - Cheatsheet.pdf
(Stored with Git LFS)
Binary file not shown.
@ -136,7 +136,7 @@
|
||||
\item Einst: Einprozessor-Systeme
|
||||
\item Heute: Mehrprozessor-/hochparallele Systeme
|
||||
\item neue Synchronisationsmechanismen erforderlich
|
||||
\item $\rightarrow$ unterschiedliche Hardware und deren Multiplexing
|
||||
\item[$\rightarrow$] unterschiedliche Hardware und deren Multiplexing
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Betriebssystemarchitektur}
|
||||
@ -146,7 +146,7 @@
|
||||
\item Exokernelbasierte Architekturen (Library-Betriebssysteme)
|
||||
\item Virtualisierungsarchitekturen
|
||||
\item Multikernel-Architekturen
|
||||
\item $\rightarrow$ unterschiedliche Architekturen
|
||||
\item[$\rightarrow$] unterschiedliche Architekturen
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Ressourcenverwaltung}
|
||||
@ -154,7 +154,7 @@
|
||||
\item Einst: Batch-Betriebssysteme, Stapelverarbeitung (FIFO)
|
||||
\item Heute: Echtzeitgarantien für Multimedia und Sicherheit
|
||||
\item echtzeitfähige Scheduler, Hauptspeicherverwaltung, Ereignismanagement, Umgang mit Überlast/Prioritätsumkehr ...
|
||||
\item $\rightarrow$ unterschiedliche Ressourcenverwaltung
|
||||
\item[$\rightarrow$] unterschiedliche Ressourcenverwaltung
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Betriebssystemabstraktionen}
|
||||
@ -164,7 +164,7 @@
|
||||
\item Erhöhung der Ausfallsicherheit ( $\rightarrow$ verfügbarkeitskritisch)
|
||||
\item Schutz vor Angriffen und Missbrauch ( $\rightarrow$ sicherheitskritisch)
|
||||
\item flexiblen und modularen Anpassen des BS ( $\rightarrow$ hochadaptiv)
|
||||
\item $\rightarrow$ höchst diverse Abstraktionen von Hardware
|
||||
\item[$\rightarrow$] höchst diverse Abstraktionen von Hardware
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Betriebssysteme als Softwareprodukte}
|
||||
@ -173,7 +173,7 @@
|
||||
\item besitzen differenzierte Aufgaben $\rightarrow$ funktionale Eigenschaften
|
||||
\item Anforderungen an Nutzung und Pflege $\rightarrow$ Evolutionseigenschaften
|
||||
\item können für Betriebssysteme höchst speziell sein
|
||||
\item $\rightarrow$ spezielle Anforderungen an das Softwareprodukt BS
|
||||
\item[$\rightarrow$] spezielle Anforderungen an das Softwareprodukt BS
|
||||
\end{itemize*}
|
||||
|
||||
Grundlegende funktionale Eigenschaften von BS: Hardware-
|
||||
@ -472,7 +472,7 @@
|
||||
\item kann notwendigen Performanzbereich bestimmen
|
||||
\end{itemize*}
|
||||
\item \textbf{Anwendungen} können Informationen über jeweils für sie notwendige Performanz liefern
|
||||
\item $\rightarrow$ Kombination mit energieefizientem Scheduling
|
||||
\item[$\rightarrow$] Kombination mit energieefizientem Scheduling
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Speichereffizienz}
|
||||
@ -523,7 +523,7 @@
|
||||
\end{itemize*}
|
||||
\item direkter Einfluss des Betriebssystems auf Hauptspeicherbelegung
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ Speicherbedarf des Kernels
|
||||
\item[$\rightarrow$] Speicherbedarf des Kernels
|
||||
\item statische (min) Größe des Kernels (Anweisungen+Daten)
|
||||
\item dynamische Speicherreservierung durch Kernel
|
||||
\item bei Makrokernel: Speicherbedarf von Gerätecontrollern
|
||||
@ -736,13 +736,13 @@
|
||||
\begin{itemize*}
|
||||
\item Maskierung, Redundanz
|
||||
\item Isolation von Subsystemen
|
||||
\item $\rightarrow$ Isolationsmechanismen
|
||||
\item[$\rightarrow$] Isolationsmechanismen
|
||||
\end{itemize*}
|
||||
\item[Fehler] (fault) Ursache für fehlerhaften Systemzustand ( error ), z.B. Programmierfehler
|
||||
\begin{itemize*}
|
||||
\item Ausfallverhalten spezifizieren
|
||||
\item Ausfälle zur Laufzeit erkennen und Folgen beheben, abschwächen...
|
||||
\item $\rightarrow$ Micro-Reboots
|
||||
\item[$\rightarrow$] Micro-Reboots
|
||||
\end{itemize*}
|
||||
\end{description*}
|
||||
|
||||
@ -763,7 +763,7 @@
|
||||
\item[$\Rightarrow$] Kernelausfall (failure)
|
||||
\end{itemize*}
|
||||
\item Auswirkung: fehlerhafter Zustand weiterer Kernel-Subsysteme
|
||||
\item $\rightarrow$ Robustheit: Isolationsmechanismen
|
||||
\item[$\rightarrow$] Robustheit: Isolationsmechanismen
|
||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-treiber-kernel-fehler.png}
|
||||
\end{itemize*}
|
||||
|
||||
@ -840,8 +840,8 @@
|
||||
\item[\cmark] Kommunikation zwischen nvw. Code muss durch IPC-Mechanismen explizit hergestellt werden $\rightarrow$ Überwachung und Validierung zur Laufzeit möglich
|
||||
\item[\cmark] Kontrollfluss begrenzen: Funktionsaufrufe können i.A. keine AR-Grenzen überschreiten
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ BS-Zugriffssteuerung kann nicht durch Taskfehler ausgehebelt werden
|
||||
\item $\rightarrow$ unabsichtliche Terminierungsfehler(unendliche Rekursion) erschwert ...
|
||||
\item[$\rightarrow$] BS-Zugriffssteuerung kann nicht durch Taskfehler ausgehebelt werden
|
||||
\item[$\rightarrow$] unabsichtliche Terminierungsfehler(unendliche Rekursion) erschwert ...
|
||||
\end{itemize*}
|
||||
\item keine Isolation zwischen Fehlern innerhalb des Kernels
|
||||
\end{itemize*}
|
||||
@ -930,7 +930,7 @@
|
||||
\item funktional komplex
|
||||
\item 153 Systemaufrufe
|
||||
\item mehrere Schnittstellen, parallele Implementierungen für eine Funktion
|
||||
\item $\rightarrow$ Adaptivität (Auswahl durch Programmierer)
|
||||
\item[$\rightarrow$] Adaptivität (Auswahl durch Programmierer)
|
||||
\end{itemize*}
|
||||
\item Fazit:
|
||||
\begin{itemize*}
|
||||
@ -949,321 +949,198 @@
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{L4}
|
||||
Analyse des Mach-Kernels:
|
||||
\begin{enumerate*}
|
||||
\item falsche Abstraktionen
|
||||
\item unperformanteKernelimplementierung
|
||||
\item prozessorunabhängige Implementierung
|
||||
\end{enumerate*}
|
||||
Analyse des Mach-Kernels:
|
||||
\begin{enumerate*}
|
||||
\item falsche Abstraktionen
|
||||
\item unperformante Kernelimplementierung
|
||||
\item prozessorunabhängige Implementierung
|
||||
\end{enumerate*}
|
||||
|
||||
L3 und L4
|
||||
\begin{itemize*}
|
||||
\item Mikrokerne der 2. Generation
|
||||
\item vollständige Überarbeitung des Mikrokernkonzepts
|
||||
\end{itemize*}
|
||||
\begin{tabular}{c|c|c}
|
||||
First generation & Second Generation & Third generation \\\hline
|
||||
Eg Mach & Eg L4 & seL4 \\
|
||||
\includegraphics[width=.3\linewidth]{Assets/AdvancedOperatingSystems-l4-first-g.png} &
|
||||
\includegraphics[width=.3\linewidth]{Assets/AdvancedOperatingSystems-L4-second-g.png} &
|
||||
\includegraphics[width=.3\linewidth]{Assets/AdvancedOperatingSystems-l4-third-g.png} \\
|
||||
180 syscalls & $\sim$ 7 syscalls & $\sim$ 3 syscalls \\
|
||||
100 kLOC & $\sim$ 10 kLOC & 9 kLOC \\
|
||||
100 $\mu s$ IPC & $\sim$ 1 $\mu s$ IPC & $0,2-1 \mu s$ IPC
|
||||
\end{tabular}
|
||||
\begin{tabular}{c|c|c}
|
||||
First generation & Second Generation & Third generation \\\hline
|
||||
Eg Mach & Eg L4 & seL4 \\
|
||||
\includegraphics[width=.2\linewidth]{Assets/AdvancedOperatingSystems-l4-first-g.png} &
|
||||
\includegraphics[width=.2\linewidth]{Assets/AdvancedOperatingSystems-L4-second-g.png} &
|
||||
\includegraphics[width=.2\linewidth]{Assets/AdvancedOperatingSystems-l4-third-g.png} \\
|
||||
180 syscalls & $\sim$ 7 syscalls & $\sim$ 3 syscalls \\
|
||||
100 kLOC & $\sim$ 10 kLOC & 9 kLOC \\
|
||||
100 $\mu s$ IPC & $\sim$ 1 $\mu s$ IPC & $0,2-1 \mu s$ IPC
|
||||
\end{tabular}
|
||||
|
||||
\subsubsection{Mikrokernel - Designprinzipien}
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Was gehört in einen Mikrokern?
|
||||
\begin{itemize*}
|
||||
\item Liedtke: Unterscheidung zwischen Konzepten und deren Implementierung
|
||||
\item bestimmende Anforderungen an beide: \begin{itemize*} \item Konzeptsicht $\rightarrow$ Funktionalität, \item Implementierungssicht $\rightarrow$ Performanz \end{itemize*}
|
||||
\item $\rightarrow$ 1. $\mu$Kernel-Generation: Konzept durch Performanzentscheidungen aufgeweicht
|
||||
\item $\rightarrow$ Effekt in der Praxis genau gegenteilig: schlechte (IPC-) Performanz!
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
\begin{quote}
|
||||
,,The determining criterion used is functionality, not performance. More
|
||||
precisely, a concept is tolerated inside the $\mu$-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]
|
||||
\end{quote}
|
||||
|
||||
Designprinzipien für Mikrokernel-Konzept:
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
$\rightarrow$ Annahmen hinsichtlich der funktionalen
|
||||
Anforderungen:
|
||||
\item Was gehört in einen Mikrokern?
|
||||
\item Konzeptsicht $\rightarrow$ Funktionalität
|
||||
\item Implementierungssicht $\rightarrow$ Performanz
|
||||
\item[$\rightarrow$] 1. Generation: durch Performanzentscheidungen aufgeweicht
|
||||
\item[$\rightarrow$] Effekt in Praxis gegenteilig: schlechte (IPC-) Performanz
|
||||
\end{itemize*}
|
||||
|
||||
Designprinzipien für Mikrokernel-Konzept
|
||||
\begin{enumerate*}
|
||||
\item
|
||||
System interaktive und nicht vollständig vertrauenswürdige
|
||||
Applikationen unterstützen ( $\rightarrow$ HW-Schutz,
|
||||
-Multiplexing),
|
||||
\item
|
||||
Hardware mit virtueller Speicherverwaltung und Paging
|
||||
\item System interaktive und nicht vollständig vertrauenswürdige Applikationen unterstützen ( $\rightarrow$ HW-Schutz,-Multiplexing),
|
||||
\item Hardware mit virtueller Speicherverwaltung und Paging
|
||||
\end{enumerate*}
|
||||
|
||||
Designprinzipien:
|
||||
|
||||
\begin{enumerate*}
|
||||
\item
|
||||
Autonomie: ,,Ein Subsystem (Server)muss so implementiert werden
|
||||
können, dass es von keinem anderen Subsystem gestört oder korrumpiert
|
||||
werden kann.''
|
||||
\item
|
||||
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.''
|
||||
\end{enumerate*}
|
||||
Designprinzipien
|
||||
\begin{description*}
|
||||
\item[Autonomie] Subsystem muss so implementiert werden, dass es von keinem anderen Subsystem gestört oder korrumpiert werden kann
|
||||
\item[Integrität] Subsystem $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.
|
||||
\end{description*}
|
||||
|
||||
L4: Speicherabstraktion
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Adressraum: Abbildung, die jede virtuelle Seite auf einen physischen
|
||||
Seitenrahmen abbildet oder als ,,nicht zugreifbar'' markiert
|
||||
\item
|
||||
Implementierung über Seitentabellen, unterstützt durch MMU-Hardware
|
||||
\item
|
||||
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)
|
||||
\item
|
||||
Mikrokernel-Konzept des Adressraums:
|
||||
\item Adressraum: Abbildung, die jede virtuelle Seite auf einen physischen Seitenrahmen abbildet oder als ,,nicht zugreifbar'' markiert
|
||||
\item Implementierung über Seitentabellen, unterstützt durch MMU-Hardware
|
||||
\item Aufgabe des Mikrokernels (Schicht aller Subsysteme): muss Hardware-Konzept des Adressraums verbergen und durch eigenes Adressraum-Konzept überlagern
|
||||
\item Mikrokernel-Konzept des Adressraums:
|
||||
\begin{itemize*}
|
||||
\item muss Implementierung von beliebigen virtuellen Speicherverwaltungs-und -schutzkonzepten oberhalb des Mikrokernels (d.h. in den Subsystemen) erlauben
|
||||
\item sollte einfach und dem Hardware-Konzept ähnlich sein
|
||||
\end{itemize*}
|
||||
\item
|
||||
Idee: abstrakte Speicherverwaltung
|
||||
\item Idee: abstrakte Speicherverwaltung
|
||||
\begin{itemize*}
|
||||
\item rekursive Konstruktion und Verwaltung der Adressräume auf Benutzer-(Server-)Ebene
|
||||
\item Mikrokernel stellt dafür genau drei Operationen bereit: \begin{enumerate*} \item grant(x) - Server $S$ überträgt Seite $x$ seines AR in AR von Empfänger $S`$ \item map(x) - Server $S$ bildet Seite $x$ seines AR in AR von Empfänger $S`$ ab \item flush(x) - Server $S$ entfernt (flusht) Seite x seines AR aus allen fremden AR \end{enumerate*}
|
||||
\item Mikrokernel stellt dafür genau drei Operationen bereit:
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\begin{description*}
|
||||
\item[grant(x)] Server überträgt Seite $x$ seines AR in AR von Empfänger
|
||||
\item[map(x)] Server bildet Seite $x$ seines AR in AR von Empfänger ab
|
||||
\item[flush(x)] Server entfernt Seite x seines AR aus allen fremden AR
|
||||
\end{description*}
|
||||
|
||||
Hierarchische Adressräume
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Rekursive Konstruktion der Adressraumhierarchie
|
||||
\begin{itemize*}
|
||||
\item Server und Anwendungenkönnen damit ihren Klienten Seiten des eigenen Adressraumes zur Verfügung stellen
|
||||
\item Realspeicher: Ur-Adressraum, vom $\mu$Kernel verwaltet
|
||||
\item Speicherverwaltung(en), Paging usw.: vollständig außerhalb des $\mu$-Kernels realisiert
|
||||
%\item
|
||||
% %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-adressraumhierarchie.png}
|
||||
\end{itemize*}
|
||||
\item Rekursive Konstruktion der Adressraumhierarchie
|
||||
\item Server und Anwendungenkönnen damit ihren Klienten Seiten des eigenen Adressraumes zur Verfügung stellen
|
||||
\item Realspeicher: Ur-Adressraum vom $\mu$Kernel verwaltet
|
||||
\item Speicherverwaltung, Paging... außerhalb des $\mu$-Kernels realisiert
|
||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-adressraumhierarchie.png}
|
||||
\end{itemize*}
|
||||
|
||||
L4: Threadabstraktion
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Thread
|
||||
\item Thread
|
||||
\begin{itemize*}
|
||||
\item innerhalb eines Adressraumesablaufende Aktivität
|
||||
\item $\rightarrow$ Adressraumzuordnung ist essenziell für Threadkonzept (Code + Daten) \begin{itemize*} \item Bindung an Adressraum: dynamisch oder fest \item Änderung einer dynamischen Zuordnung: darf nur unter vertrauenswürdiger Kontrolle erfolgen (sonst: fremde Adressräume les- und korrumpierbar) \end{itemize*}
|
||||
\item innerhalb eines Adressraumes ablaufende Aktivität
|
||||
\item[$\rightarrow$] Adressraumzuordnung essenziell für Threadkonzept
|
||||
\item Bindung an Adressraum: dynamisch oder fest
|
||||
\item Änderung einer dynamischen Zuordnung: darf nur unter vertrauenswürdiger Kontrolle erfolgen
|
||||
\end{itemize*}
|
||||
\item
|
||||
Designentscheidung
|
||||
\item Designentscheidung
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ Autonomieprinzip
|
||||
\item $\rightarrow$ Konsequenz: Adressraumisolation
|
||||
\item $\rightarrow$ entscheidender Grund zur Realisierung des Thread-Konzepts innerhalb des Mikrokernels
|
||||
\item[$\rightarrow$] Autonomieprinzip
|
||||
\item[$\rightarrow$] Konsequenz: Adressraumisolation
|
||||
\item[$\rightarrow$] entscheidender Grund zur Realisierung des Thread-Konzepts innerhalb des Mikrokernels
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
IPC
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Interprozess-Kommunikation
|
||||
\item Interprozess-Kommunikation
|
||||
\begin{itemize*}
|
||||
\item Kommunikation über Adressraumgrenzen: vertrauenswürdig kontrollierte Aufhebung der Isolation
|
||||
\item $\rightarrow$ essenziell für (sinnvolles) Multitasking und -threading
|
||||
\item Kommunikation über Adressraumgrenzen
|
||||
\item vertrauenswürdig kontrollierte Aufhebung der Isolation
|
||||
\item[$\rightarrow$] essenziell für (sinnvolles) Multitasking und -threading
|
||||
\end{itemize*}
|
||||
\item
|
||||
Designentscheidung
|
||||
\item Designentscheidung
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ Integritätsprinzip
|
||||
\item $\rightarrow$ wir haben schon: vertrauenswürdige Adressraumisolation im $\mu$Kernel
|
||||
\item $\rightarrow$ grundlegendes IPC-Konzepts innerhalb des Mikrokernels (flexibel und dynamisch durch Server erweiterbar, analog Adressraumhierarchie)
|
||||
\item[$\rightarrow$] Integritätsprinzip
|
||||
\item[$\rightarrow$] vertrauenswürdige Adressraumisolation im $\mu$Kernel
|
||||
\item[$\rightarrow$] grundlegendes IPC-Konzepts innerhalb des Mikrokernels
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Identifikatoren
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Thread-und Ressourcenbezeichner
|
||||
\item Thread-und Ressourcenbezeichner
|
||||
\begin{itemize*}
|
||||
\item müssen vertrauenswürdig vergeben (authentisch und i.A. persistent) und verwaltet(eindeutig und korrekt referenzierbar)werden
|
||||
\item $\rightarrow$ essenziell für (sinnvolles) Multitasking und -threading
|
||||
\item $\rightarrow$ essenziell für vertrauenswürdige Kernel-und Server-Schnittstellen
|
||||
\item müssen vertrauenswürdig vergeben und verwaltet werden
|
||||
\item[$\rightarrow$] essenziell für (sinnvolles) Multitasking und -threading
|
||||
\item[$\rightarrow$] essenziell für vertrauenswürdige Kernel-/Server-Schnittstellen
|
||||
\end{itemize*}
|
||||
\item
|
||||
Designentscheidung
|
||||
\item Designentscheidung
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ Integritätsprinzip
|
||||
\item $\rightarrow$ ID-Konzept innerhalb des Mikrokernels (wiederum: durch Server erweiterbar)
|
||||
\item[$\rightarrow$] Integritätsprinzip
|
||||
\item[$\rightarrow$] ID-Konzept innerhalb des Mikrokernels
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Lessons Learned
|
||||
|
||||
\begin{enumerate*}
|
||||
\item
|
||||
Ein minimaler Mikrokernel
|
||||
\item Ein minimaler Mikrokernel
|
||||
\begin{itemize*}
|
||||
\item soll Minimalmenge an geeigneten Abstraktionenzur Verfügung stellen:
|
||||
\item flexibel genug, um Implementierung beliebiger Betriebssysteme zu ermöglichen
|
||||
\item Nutzung umfangreicher Mengeverschiedener Hardware-Plattformen
|
||||
\item stellt Minimalmenge geeigneter Abstraktionen verfügbar
|
||||
\item flexibel, um Implementierung beliebiger BS zu ermöglichen
|
||||
\item Nutzung verschiedener Hardware-Plattformen
|
||||
\end{itemize*}
|
||||
\item
|
||||
Geeignete, funktional minimale Mechanismen im $\mu$Kern:
|
||||
\item Geeignete, funktional minimale Mechanismen im $\mu$Kern:
|
||||
\begin{itemize*}
|
||||
\item Adressraum mit map-, flush-, grant-Operation
|
||||
\item Threadsinklusive IPC
|
||||
\item eindeutige Identifikatoren
|
||||
\end{itemize*}
|
||||
\item
|
||||
Wahl der geeigneten Abstraktionen:
|
||||
\begin{itemize*}
|
||||
\item kritischfür Verifizierbarkeit ( $\rightarrow$ Robustheit), Adaptivität und optimierte Performanz des Mikrokerns
|
||||
\end{itemize*}
|
||||
\item
|
||||
Bisherigen $\mu$-Kernel-Abstraktionskonzepte:
|
||||
\begin{enumerate*}
|
||||
\def\labelenumii{\arabic{enumii}.}
|
||||
\item ungeeignete
|
||||
\item zu viele
|
||||
\item zu spezialisierte u. inflexible Abstraktionen
|
||||
\end{enumerate*}
|
||||
\item
|
||||
Konsequenzen für Mikrokernel-Implementierung
|
||||
\item Wahl der geeigneten Abstraktionen: kritisch für Verifizierbarkeit, Adaptivität und optimierte Performanz des Mikrokerns
|
||||
\item Bisherigen $\mu$-Kernel-Abstraktionskonzepte: ungeeignete, zu viele, zu spezialisierte u. inflexible Abstraktionen
|
||||
\item Konsequenzen für Mikrokernel-Implementierung
|
||||
\begin{itemize*}
|
||||
\item müssen für jeden Prozessortyp neu implementiert werden
|
||||
\item sind deshalb prinzipiell nicht portierbar $\rightarrow$ L3-und L4-Prototypen by J. Liedtke: 99\% Assemblercode
|
||||
\item deshalb prinzipiell nicht portierbar $\rightarrow$ L3-/L4-Prototypen: 99\% Assemblercode
|
||||
\end{itemize*}
|
||||
\item
|
||||
innerhalb eines Mikrokernels sind
|
||||
\item innerhalb eines Mikrokernels sind von Prozessorhardware abhängig
|
||||
\begin{enumerate*}
|
||||
\def\labelenumii{\arabic{enumii}.}
|
||||
\item grundlegende Implementierungsentscheidungen
|
||||
\item meiste Algorithmen u. Datenstrukturen
|
||||
\end{enumerate*}
|
||||
\begin{itemize*}
|
||||
\item von Prozessorhardware abhängig
|
||||
\end{itemize*}
|
||||
\item Fazit: Mikrokernel mit akzeptabler Performanz hardwarespezifische Implementierung minimal erforderlicher vom Prozessortyp unabhängiger Abstraktionen
|
||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-l4-ipc-performance.png}
|
||||
\item L4 heute: Spezifikation Mikrokernels (nicht Implementierung)
|
||||
\end{enumerate*}
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Fazit:
|
||||
\begin{itemize*}
|
||||
\item Mikrokernelmit akzeptabler Performanz: hardwarespezifische Implementierung minimalerforderlicher, vom Prozessortyp unabhängiger Abstraktionen
|
||||
%\item
|
||||
% %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-l4-ipc-performance.png}
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Heutige Bedeutung
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
nach Tod von J. Liedtke (2001) auf Basis von L4 zahlreiche moderne BS
|
||||
\item
|
||||
L4 heute: Spezifikation eines Mikrokernels (nicht Implementierung)
|
||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-l4-family.png}
|
||||
\item
|
||||
Einige Weiterentwicklungen:
|
||||
\item
|
||||
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
|
||||
\item
|
||||
University ofNew South Wales (UNSW), Australien (Gernot Heiser):
|
||||
\begin{itemize*}
|
||||
\item Implementierung von L4 auf verschiedenen 64 - Bit-Plattformen, bekannt als L4/MIPS, L4/Alpha
|
||||
\item Implementierung in C (Wartbarkeit, Performanz)
|
||||
\item Mit L4Ka::Pistachio bisher schnellste Implementierung von botschaftenbasierterIPC (2005: 36 Zyklen auf Itanium-Architektur)
|
||||
\item seit 2009: seL4, erster formal verifizierter BS-Kernel (d.h. mathematisch bewiesen, dass Implementierung funktional korrekt ist und nachweislich keinen Entwurfsfehler enthält)
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
%Einige Weiterentwicklungen:
|
||||
%\begin{itemize*}
|
||||
% \item TU Dresden (Hermann Härtig): Neuimplementierung in C++ (L4/Fiasco), Basis des Echtzeit-Betriebssystems DROPS, der Virtualisierungsplattform NOVA und des adaptiven BS-Kernels Fiasco.OC
|
||||
% \item University of New South Wales, Australien
|
||||
% \begin{itemize*}
|
||||
% \item Implementierung von L4 auf verschiedenen 64 - Bit-Plattformen, bekannt als L4/MIPS, L4/Alpha
|
||||
% \item Implementierung in C (Wartbarkeit, Performanz)
|
||||
% \item Mit L4Ka::Pistachio bisher schnellste Implementierung von botschaftenbasierterIPC
|
||||
% \item 2009: seL4, erster formal verifizierter BS-Kernel
|
||||
% \end{itemize*}
|
||||
%\end{itemize*}
|
||||
|
||||
Zwischenfazit
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Begrenzung von Fehlerausbreitung ( $\rightarrow$
|
||||
Folgen von errors ):
|
||||
\item
|
||||
konsequent modularisierte Architektur aus Subsystemen
|
||||
\item
|
||||
Isolationsmechanismen zwischen Subsystemen
|
||||
\item
|
||||
Konsequenzen für BS-Kernel:
|
||||
\item
|
||||
statische Isolation auf Quellcodeebene $\rightarrow$
|
||||
strukturierte Programmierung
|
||||
\item
|
||||
dynamische Isolation zur Laufzeit $\rightarrow$
|
||||
private virtuelle Adressräume
|
||||
\item
|
||||
Architektur, welche diese Mechanismen komponiert: Mikrokernel
|
||||
\item
|
||||
Was haben wir gewonnen?
|
||||
\item
|
||||
\cmark Adressraumisolation für sämtlichen nichtvertrauenswürdigen Code
|
||||
\item
|
||||
\cmark keine privilegierten Instruktionen in nvw. Code (Serverprozesse)
|
||||
\item
|
||||
\cmark geringe Größe (potenziell: Verifizierbarkeit) des Kernels
|
||||
\item
|
||||
\cmark neben Robustheit: Modularitätund Adaptivitätdes Kernels
|
||||
\item
|
||||
Und was noch nicht?
|
||||
\begin{itemize*}
|
||||
\item \xmark Behandlung von Ausfällen ( $\rightarrow$ abstürzende Gerätetreiber ...)
|
||||
\end{itemize*}
|
||||
\item Begrenzung von Fehlerausbreitung ($\rightarrow$ Folgen von errors)
|
||||
\item konsequent modularisierte Architektur aus Subsystemen
|
||||
\item Isolationsmechanismen zwischen Subsystemen
|
||||
\item statische Isolation auf Quellcodeebene $\rightarrow$ strukturierte Programmierung
|
||||
\item dynamische Isolation zur Laufzeit $\rightarrow$ private virtuelle Adressräume
|
||||
\item Architektur, welche diese Mechanismen komponiert: Mikrokernel
|
||||
\item[\cmark] Adressraumisolation für sämtlichen nichtvertrauenswürdigen Code
|
||||
\item[\cmark] keine privilegierten Instruktionen in nvw. Code (Serverprozesse)
|
||||
\item[\cmark] geringe Größe (potenziell: Verifizierbarkeit) des Kernels
|
||||
\item[\cmark] neben Robustheit: Modularitätund Adaptivitätdes Kernels
|
||||
\item[\xmark] Behandlung von Ausfällen ( $\rightarrow$ abstürzende Gerätetreiber ...)
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{3.5 Micro-Reboots}
|
||||
|
||||
\subsection{Micro-Reboots}
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Beobachtungen am Ausfallverhalten von BS:
|
||||
\item
|
||||
Kernelfehler sind (potenziell) fatal für gesamtes System
|
||||
\item
|
||||
Anwendungsfehler sind es nicht
|
||||
\item
|
||||
$\rightarrow$ kleiner Kernel = geringeres Risiko von
|
||||
Systemausfällen
|
||||
\item
|
||||
$\rightarrow$ durch BS-Code in Serverprozessen:
|
||||
verbleibendes Risiko unabhängiger Teilausfälle von BS-Funktionalität
|
||||
(z.B. FS, Treiberprozesse, GUI, ...)
|
||||
\item
|
||||
Ergänzung zu Isolationsmechanismen:
|
||||
\item
|
||||
Mechanismen zur Behandlung von Subsystem-Ausfällen
|
||||
\item
|
||||
= Mechanismen zur Behandlung Anwendungs-, Server- und
|
||||
Gerätetreiberfehlen
|
||||
\item
|
||||
$\rightarrow$ Micro-Reboots
|
||||
\item Beobachtungen am Ausfallverhalten von BS:
|
||||
\item Kernelfehler sind (potenziell) fatal für gesamtes System
|
||||
\item Anwendungsfehler sind es nicht
|
||||
\item[$\rightarrow$] kleiner Kernel = geringeres Risiko von Systemausfällen
|
||||
\item[$\rightarrow$] durch BS-Code in Serverprozessen: verbleibendes Risiko unabhängiger Teilausfälle von BS-Funktionalität (z.B. FS, Treiberprozesse, GUI, ...)
|
||||
\item Ergänzung zu Isolationsmechanismen:
|
||||
\item Mechanismen zur Behandlung von Subsystem-Ausfällen
|
||||
\item = Mechanismen zur Behandlung Anwendungs-, Server- und Gerätetreiberfehlen
|
||||
\item[$\rightarrow$] Micro-Reboots
|
||||
\end{itemize*}
|
||||
|
||||
Ansatz
|
||||
@ -2120,7 +1997,7 @@
|
||||
Sicherheitsmechanismen: Datenstrukturen und Algorithmen, welche die
|
||||
Sicherheitseigenschaften eines Betriebssystems implementieren.
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ Sicherheitsmechanismen benötigt man zur Herstellung jeglicher Sicherheitseigenschaften (auch jener, die in unseren Modellen implizit angenommen werden!)
|
||||
\item[$\rightarrow$] Sicherheitsmechanismen benötigt man zur Herstellung jeglicher Sicherheitseigenschaften (auch jener, die in unseren Modellen implizit angenommen werden!)
|
||||
\item Nutzerauthentisierung ( login - Dientsprogramm, Passwort-Hashing, ...)
|
||||
\item Autorisierungsinformationen (Metainformationen über Rechte, MLS-Klassen, TE-Typen, ...)
|
||||
\item Autorisierungsmechanismen (Rechteprüfung, Politikadministration, ...)
|
||||
@ -2144,7 +2021,7 @@
|
||||
\item groß ( $\rightarrow$ Dateianzahl auf Fileserver)
|
||||
\item dünn besetzt
|
||||
\item in Größe und Inhalt dynamisch veränderlich
|
||||
\item $\rightarrow$ effiziente Datenstruktur?
|
||||
\item[$\rightarrow$] effiziente Datenstruktur?
|
||||
\end{itemize*}
|
||||
\item
|
||||
Lösung: verteilte Implementierung der acm als Spaltenvektoren, deren
|
||||
@ -2564,7 +2441,7 @@
|
||||
\begin{itemize*}
|
||||
\item Einschränkung von erlaubten Typtransitionen (Welches Programm darf mit welchem Typ ausgeführt werden?)
|
||||
\item weitere Abstraktionsschicht: rollenbasierte Regeln (RBAC)
|
||||
\item $\rightarrow$ Schutz gegen nicht vertrauenswürdige Nutzer (vs. nvw. Software)
|
||||
\item[$\rightarrow$] Schutz gegen nicht vertrauenswürdige Nutzer (vs. nvw. Software)
|
||||
\end{itemize*}
|
||||
\item
|
||||
Ergebnis:
|
||||
@ -2686,7 +2563,7 @@
|
||||
\item O setzt Vertrauen in korrekte (und nicht böswillige) Hardwarevoraus
|
||||
\item O Dokumentation und Entwicklerunterstützung (im Ausbau ...)
|
||||
\item \xmark schützt mittels Enclaves einzelne Anwendungen, aber nicht das System
|
||||
\item \xmark steckt hinsichtlich praktischer Eigenschaften noch in den Anfängen (vgl. $\mu$Kernel...): \begin{itemize*} \item Performanz [WeAK18] \item Speicherkapazität(max. Größe EPC: 128 MiB, davon nur 93 MiBnutzbar) \item $\rightarrow$ komplementäre NFE: Speichereffizienz! \end{itemize*}
|
||||
\item \xmark steckt hinsichtlich praktischer Eigenschaften noch in den Anfängen (vgl. $\mu$Kernel...): \begin{itemize*} \item Performanz [WeAK18] \item Speicherkapazität(max. Größe EPC: 128 MiB, davon nur 93 MiBnutzbar) \item[$\rightarrow$] komplementäre NFE: Speichereffizienz! \end{itemize*}
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
@ -2703,7 +2580,7 @@
|
||||
\item Verstehen des Referenzmonitorprinzips
|
||||
\item frühe Forschungen zu Betriebssystemsicherheit in 1970er-1980er Jahren durch US-Verteidigungsministerium
|
||||
\item Schlüsselveröffentlichung: Anderson-Report(1972)[Ande72]
|
||||
\item $\rightarrow$ fundamentalen Eigenschaften zur Charakterisierung von Sicherheitsarchitekturen
|
||||
\item[$\rightarrow$] fundamentalen Eigenschaften zur Charakterisierung von Sicherheitsarchitekturen
|
||||
\end{itemize*}
|
||||
\item
|
||||
Begriffe des Referenzmonitorprinzips kennen wir schon:
|
||||
@ -2720,8 +2597,8 @@
|
||||
\item
|
||||
Idee:
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ sämtliche Autorisierungsentscheidungen durch einen zentralen (abstrakten) Mechanismus = Referenzmonitor
|
||||
\item Bewertet jeden Zugriffsversuch eines Subjekts auf Objekt durch Anwendung einer Sicherheitspolitik (security policy) \begin{itemize*} \item $\rightarrow$ vgl. SELinux \end{itemize*}
|
||||
\item[$\rightarrow$] sämtliche Autorisierungsentscheidungen durch einen zentralen (abstrakten) Mechanismus = Referenzmonitor
|
||||
\item Bewertet jeden Zugriffsversuch eines Subjekts auf Objekt durch Anwendung einer Sicherheitspolitik (security policy) \begin{itemize*} \item[$\rightarrow$] vgl. SELinux \end{itemize*}
|
||||
\item somit: Architekturbeschreibung, wie Zugriffe auf Ressourcen (z.B. Dateien) auf solche Zugriffe, die Sicherheitspolitik erlaubt, eingeschränkt werden
|
||||
\end{itemize*}
|
||||
\item
|
||||
@ -2744,18 +2621,18 @@
|
||||
\item
|
||||
(RM 1) bei sämtlichen Subjekt/Objekt-Interaktionen involviert sind
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ Unumgehbarkeit ( total mediation )
|
||||
\item[$\rightarrow$] Unumgehbarkeit ( total mediation )
|
||||
\end{itemize*}
|
||||
\item
|
||||
(RM 2) geschützt sind vor unautorisierter Manipulation
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ Manipulationssicherheit ( tamperproofness )
|
||||
\item[$\rightarrow$] Manipulationssicherheit ( tamperproofness )
|
||||
\end{itemize*}
|
||||
\item
|
||||
(RM 3) hinreichend klein und wohlstrukturiert sind, um formalen
|
||||
Analysemethoden zugänglich zu sein
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ Verifizierbarkeit ( verifyability )
|
||||
\item[$\rightarrow$] Verifizierbarkeit ( verifyability )
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
@ -4479,7 +4356,7 @@
|
||||
\begin{itemize*}
|
||||
\item Trennung von Schutz und Abstraktion der Ressourcen
|
||||
\item Ressourcen-Schutz und -Multiplexing: verbleibt beim Betriebssystemkernel(dem Exokernel)
|
||||
\item Ressourcen-Abstraktion (und deren Management): zentrale Aufgabe der Library-Betriebssysteme \begin{itemize*} \item $\rightarrow$ autonome Management-Strategien durch in Anwendungen importierte Funktionalität \end{itemize*}
|
||||
\item Ressourcen-Abstraktion (und deren Management): zentrale Aufgabe der Library-Betriebssysteme \begin{itemize*} \item[$\rightarrow$] autonome Management-Strategien durch in Anwendungen importierte Funktionalität \end{itemize*}
|
||||
\item Resultat: \begin{enumerate*} \item systemweit(durch jeweiliges BS vorgegebene) starre Hardware-Abstraktionen vermieden \item anwendungsdomänenspezifische Abstraktionen sehr einfach realisierbar \item (Wieder-) Verwendung eigener und fremder Managementfunktionalität wesentlich erleichtert $\rightarrow$ komplementäre NFEn! (Performanz, EZ-Fähigkeit, Sparsamkeit, ...) \end{enumerate*}
|
||||
\end{itemize*}
|
||||
\item
|
||||
@ -4543,7 +4420,7 @@
|
||||
\begin{itemize*}
|
||||
\item Vorteil: im allgemeinen geringere Latenzzeiten, einfacheres und komfortableres Programmiermodell
|
||||
\item Nachteil: Anwendungen(hier: die eingebetteten Library-BS) erhalten keine Kenntnis über Entzug,bspw. aufgrund von Ressourcenknappheit etc.
|
||||
\item $\rightarrow$ erforderliches Wissen für Management-Strategien!
|
||||
\item[$\rightarrow$] erforderliches Wissen für Management-Strategien!
|
||||
\end{itemize*}
|
||||
\item
|
||||
Exokernel-Betriebssysteme: entziehen(überwiegend) Ressourcen
|
||||
@ -4552,7 +4429,7 @@
|
||||
\begin{itemize*}
|
||||
\item Vorteil: effizientes Management durch Library-BS möglich (z.B. Prozessor: nur tatsächlich benötigte Register werden bei Entzug gespeichert)
|
||||
\item Nachteil : Performanz bei sehr häufigem Entzug, Verwaltungs-und Fehlerbehandlungsstrategien zwischen verschiedenen Library-BS müssen korrekt und untereinander kompatibelsein...
|
||||
\item $\rightarrow$ Abort - Protokoll notwendig, falls dies nicht gegeben ist
|
||||
\item[$\rightarrow$] Abort - Protokoll notwendig, falls dies nicht gegeben ist
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
@ -4579,7 +4456,7 @@
|
||||
\item
|
||||
In der Praxis:
|
||||
\begin{itemize*}
|
||||
\item harte Echtzeit-Fristen (,, innerhalb von 50 $\mu$s'' ) in den wenigsten Anwendungen berücksichtigt \begin{itemize*} \item $\rightarrow$ Abort = lediglich Widerruf aller Secure Bindings der jeweiligen Ressource für die unkooperativeAnwendung, nicht deren Terminierung (= unsichtbarerRessourcenentzug) \item $\rightarrow$ anschließend: Informieren des entsprechenden Library-BS \end{itemize*}
|
||||
\item harte Echtzeit-Fristen (,, innerhalb von 50 $\mu$s'' ) in den wenigsten Anwendungen berücksichtigt \begin{itemize*} \item[$\rightarrow$] Abort = lediglich Widerruf aller Secure Bindings der jeweiligen Ressource für die unkooperativeAnwendung, nicht deren Terminierung (= unsichtbarerRessourcenentzug) \item[$\rightarrow$] anschließend: Informieren des entsprechenden Library-BS \end{itemize*}
|
||||
\item ermöglicht sinnvolle Reaktion des Library-BS (in Library-BS wird ,,Repossession''-Exceptionausgelöst, so dass auf Entzug geeignet reagiert werden kann)
|
||||
\item bei zustandsbehafteten Ressourcen ( $\rightarrow$ CPU): Exokernelkann diesen Zustand auf Hintergrundspeicher sichern $\rightarrow$ Management-Informationen zum Aufräumen durch Library-BS
|
||||
\end{itemize*}
|
||||
@ -4717,7 +4594,7 @@
|
||||
\begin{itemize*}
|
||||
\item Adaptivität
|
||||
\item Wartbarkeit, Sicherheit, Robustheit
|
||||
\item $\rightarrow$ auf gleicher Hardware mehrere unterschiedliche Betriebssysteme ausführbar machen
|
||||
\item[$\rightarrow$] auf gleicher Hardware mehrere unterschiedliche Betriebssysteme ausführbar machen
|
||||
\end{itemize*}
|
||||
\item
|
||||
Idee:
|
||||
@ -4885,14 +4762,14 @@
|
||||
Kernel Mode ausgeführt werden dürfen (Befehle zur Realisierung von
|
||||
E/A, Manipulation der MMU, ...)
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ sensible Instruktionen
|
||||
\item[$\rightarrow$] sensible Instruktionen
|
||||
\end{itemize*}
|
||||
\item
|
||||
$\exists$ Menge an Maschinenbefehlen, die Wechsel des
|
||||
Privilegierungsmodus auslösen (x86: Trap ), wenn sie im User Mode
|
||||
ausgeführt werden
|
||||
\begin{itemize*}
|
||||
\item $\rightarrow$ privilegierte Instruktionen
|
||||
\item[$\rightarrow$] privilegierte Instruktionen
|
||||
\end{itemize*}
|
||||
\item
|
||||
Prozessor ist virtualisierbarfalls (notw. Bed.): sensible
|
||||
@ -5158,7 +5035,7 @@
|
||||
dazu:
|
||||
\begin{itemize*}
|
||||
\item Hypervisor: muss geeignetes Interface definieren (HV-Calls)
|
||||
\item $\rightarrow$ Menge von Prozedur-Aufrufen zur Benutzung durch Gast-Betriebssystem
|
||||
\item[$\rightarrow$] Menge von Prozedur-Aufrufen zur Benutzung durch Gast-Betriebssystem
|
||||
\item bilden eine HV-API als Schnittstelle für Gast-Betriebssysteme (nicht für Nutzerprogramme!)
|
||||
\end{itemize*}
|
||||
\item
|
||||
@ -5680,7 +5557,6 @@
|
||||
\item
|
||||
zum optimalen Einsatz zwingend erforderlich:
|
||||
\begin{enumerate*}
|
||||
\def\labelenumii{\arabic{enumii}.}
|
||||
\item Entwicklung Hardwarearchitektur
|
||||
\item zusätzlich: Entwicklung geeigneter Systemsoftware
|
||||
\item zusätzlich: Entwicklung geeigneter Anwendungssoftware
|
||||
@ -5806,7 +5682,7 @@
|
||||
\item parallelisierungsfähige Hardware
|
||||
\item kausal unabhängige Threads
|
||||
\item passendes (und korrekt eingesetztes!) Programmiermodell, insbesondere Synchronisation!
|
||||
\item $\rightarrow$ Programmierer + Compiler
|
||||
\item[$\rightarrow$] Programmierer + Compiler
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user