Mikrokern Architektur gekürzt
This commit is contained in:
parent
8dc0364822
commit
2cac1c45f8
BIN
Advanced Operating Systems - Cheatsheet.pdf
(Stored with Git LFS)
BIN
Advanced Operating Systems - Cheatsheet.pdf
(Stored with Git LFS)
Binary file not shown.
@ -652,15 +652,15 @@
|
|||||||
\item Programmiermodell:
|
\item Programmiermodell:
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item BS+Anwendung als Ganzes übersetzt: statische Optimierungen durch Compiler (Laufzeit, Speicherbedarf)
|
\item BS+Anwendung als Ganzes übersetzt: statische Optimierungen durch Compiler (Laufzeit, Speicherbedarf)
|
||||||
\item Nebenläufigkeit durch ereignisbasierte Kommunikation zw. Anwendung und Kernel
|
\item Nebenläufigkeit durch ereignisbasierte Kommunikation zw. Anwendung und Kernel
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item command: API-Aufruf, z.B. EA-Operation
|
\item command: API-Aufruf, z.B. EA-Operation
|
||||||
\item event: Reaktion auf diesen durch Anwendung
|
\item event: Reaktion auf diesen durch Anwendung
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item sowohl commands als auch events : asynchron
|
\item sowohl commands als auch events : asynchron
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
\subsubsection{BS: RIOT}
|
\subsubsection{BS: RIOT}
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item sparsames BS,optimiert für anspruchsvollere Anwendungen
|
\item sparsames BS,optimiert für anspruchsvollere Anwendungen
|
||||||
@ -691,48 +691,20 @@
|
|||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
\section{Robustheit und Verfügbarkeit}
|
\section{Robustheit und Verfügbarkeit}
|
||||||
|
Motivation
|
||||||
|
|
||||||
\subsection{Motivation}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item allgemein: verlässlichkeitskritische Anwendungsszenarien
|
||||||
allgemein: verlässlichkeitskritischeAnwendungsszenarien
|
\item Forschung in garstiger Umwelt (Weltraum)
|
||||||
\item
|
\item hochsicherheitskritische Systeme (Finanz, Cloud Dienste)
|
||||||
Forschung in garstiger Umwelt
|
\item hochverfügbare System (öffentliche Infrastruktur, Strom)
|
||||||
\item
|
\item HPC (high performance computing)
|
||||||
Weltraumerkundung
|
|
||||||
\item
|
|
||||||
hochsicherheitskritische Systeme:
|
|
||||||
\begin{itemize*}
|
|
||||||
\item Rechenzentren von Finanzdienstleistern
|
|
||||||
\item Rechenzentren von Cloud-Dienstleistern
|
|
||||||
\end{itemize*}
|
|
||||||
\item
|
|
||||||
hochverfügbare System:
|
|
||||||
\begin{itemize*}
|
|
||||||
\item all das bereits genannte
|
|
||||||
\item öffentliche Infrastruktur(Strom, Fernwärme, ...)
|
|
||||||
\end{itemize*}
|
|
||||||
\item
|
|
||||||
HPC (high performancecomputing)
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
Allgemeine Begriffe
|
||||||
\subsection{Allgemeine Begriffe}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Verlässlichkeit: Fähigkeit, eine Leistung zu erbringen, der man berechtigterweise vertrauen kann
|
||||||
Verlässlichkeit, Zuverlässigkeit (dependability)
|
\item Untereigenschaften
|
||||||
\item
|
|
||||||
übergeordnete Eigenschaft eines Systems [ALRL04]
|
|
||||||
\item
|
|
||||||
Fähigkeit, eine Leistungzu erbringen, der man berechtigterweise
|
|
||||||
vertrauen kann
|
|
||||||
\item
|
|
||||||
Taxonomie: umfasst entsprechend Definition die Untereigenschaften
|
|
||||||
\begin{enumerate*}
|
\begin{enumerate*}
|
||||||
|
|
||||||
\item Verfügbarkeit (availability)
|
\item Verfügbarkeit (availability)
|
||||||
\item Robustheit (robustness, reliability
|
\item Robustheit (robustness, reliability
|
||||||
\item (Funktions-) Sicherheit (safety)
|
\item (Funktions-) Sicherheit (safety)
|
||||||
@ -740,480 +712,227 @@
|
|||||||
\item Integrität (integrity)
|
\item Integrität (integrity)
|
||||||
\item Wartbarkeit (maintainability) (vgl.: evolutionäre Eigenschaften)
|
\item Wartbarkeit (maintainability) (vgl.: evolutionäre Eigenschaften)
|
||||||
\end{enumerate*}
|
\end{enumerate*}
|
||||||
\item
|
\item[$\rightarrow$] nicht für alle Anwendungen sind alle Untereigenschaften erforderlich
|
||||||
1., 4. \& 5. auch Untereigenschaften von IT-Sicherheit (security)
|
|
||||||
\item
|
|
||||||
$\rightarrow$ nicht für alle Anwendungen sind alle
|
|
||||||
Untereigenschaften erforderlich
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
|
||||||
\subsubsection{Robustheitsbegriff}
|
\subsubsection{Robustheitsbegriff}
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Untereigenschaften von Verlässlichkeit: Robustheit (reliability)
|
||||||
Teil der primären Untereigenschaften von Verlässlichkeit: Robustheit
|
\item Ausfall: beobachtbare Verminderung der Leistung eines Systems, gegenüber seiner als korrekt spezifizierten Leistung
|
||||||
(robustness, reliability)
|
\item Robustheit: Verlässlichkeit unter Anwesenheit externer Ausfälle (= Ursache außerhalb des betrachteten Systems)
|
||||||
\item
|
|
||||||
Ausfall: beobachtbare Verminderung der Leistung, die ein System
|
|
||||||
tatsächlich erbringt, gegenüber seiner als korrekt spezifizierten
|
|
||||||
Leistung
|
|
||||||
\item
|
|
||||||
Robustheit: Verlässlichkeit unter Anwesenheit externer Ausfälle (=
|
|
||||||
Ausfälle, deren Ursache außerhalb des betrachteten Systems liegt)
|
|
||||||
\item
|
|
||||||
im Folgenden: kurze Systematik der Ausfälle ...
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
\subsubsection{Fehler, Ausfälle und ihre Vermeidung}
|
||||||
\subsubsection{Fehler und Ausfälle ...}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Fehler $\rightarrow$ fehlerhafter Zustand $\rightarrow$ Ausfall
|
||||||
Fehler $\rightarrow$ fehlerhafter Zustand
|
|
||||||
$\rightarrow$ Ausfall
|
|
||||||
\item
|
|
||||||
grundlegende Definitionen dieser Begriffe (ausführlich: [ALRL04,
|
|
||||||
AvLR04] ):
|
|
||||||
\begin{itemize*}
|
|
||||||
\item Ausfall (failure): liegt vor, wenn tatsächliche Leistung(en), die ein System erbringt, von als korrekt spezifizierter Leistung abweichen
|
|
||||||
\item fehlerhafter Zustand ( error ): notwendige Ursacheeines Ausfalls (nicht jeder error muss zu failure führen)
|
|
||||||
\item Fehler ( fault ): Ursache für fehlerhaften Systemzustand ( error ), z.B. Programmierfehler
|
|
||||||
\end{itemize*}
|
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-fehler.png}
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-fehler.png}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
\begin{description*}
|
||||||
|
\item[Ausfall] (failure) liegt vor, wenn tatsächliche Leistung(en), die ein System erbringt, von als korrekt spezifizierter Leistung abweichen
|
||||||
\subsubsection{... und ihre Vermeidung}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
Umgang mit ...
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item faults: \begin{itemize*} \item Korrektheit testen \item Korrektheit beweisen( $\rightarrow$ formale Verifikation) \end{itemize*}
|
\item Korrektheit testen/beweisen( $\rightarrow$ formale Verifikation)
|
||||||
\item errors: \begin{itemize*} \item Maskierung, Redundanz \item Isolationvon Subsystemen \item $\rightarrow$ Isolationsmechanismen \end{itemize*}
|
|
||||||
\item failures: \begin{itemize*} \item Ausfallverhalten (neben korrektem Verhalten) spezifizieren \item Ausfälle zur Laufzeit erkennen und Folgen beheben, abschwächen... \item $\rightarrow$ Micro-Reboots \end{itemize*}
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\end{itemize*}
|
\item[fehlerhafter Zustand] (error) notwendige Ursache eines Ausfalls (nicht jeder error muss zu failure führen)
|
||||||
|
\begin{itemize*}
|
||||||
|
\item Maskierung, Redundanz
|
||||||
|
\item Isolation von Subsystemen
|
||||||
|
\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
|
||||||
|
\end{itemize*}
|
||||||
|
\end{description*}
|
||||||
|
|
||||||
\subsection{Fehlerhafter Zustand}
|
\subsection{Fehlerhafter Zustand}
|
||||||
|
interner und externer Zustand (internal \& external state)
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item externer Zustand: der Teil des Gesamtzustands, der an externer Schnittstelle sichtbar wird
|
||||||
interner und externer Zustand (internal \& external state)
|
\item interner Zustand: restlicher Teilzustand
|
||||||
\begin{itemize*}
|
\item erbrachte Leistung: zeitliche Folge externer Zustände
|
||||||
\item externer Zustand (einer Systems oder Subsystems): der Teil des Gesamtzustands, der an externer Schnittstelle (also für das umgebende (Sub-) System) sichtbar wird
|
|
||||||
\item interner Zustand: restlicher Teilzustand
|
|
||||||
\item (tatsächlich) erbrachte Leistung: zeitliche Folge externer Zustände
|
|
||||||
\end{itemize*}
|
|
||||||
\item
|
|
||||||
Beispiele für das System ( Betriebssystem-) Kernel :
|
|
||||||
\begin{itemize*}
|
|
||||||
\item Subsysteme: Dateisystem, Scheduler, E/A, IPC, ..., Gerätetreiber
|
|
||||||
\item fault : Programmierfehler im Gerätetreiber
|
|
||||||
\item externer Zustand des Treibers (oder des Dateisystems, Schedulers, E/A, IPC, ...) $\subseteq$ interner Zustand des Kernels
|
|
||||||
%\item
|
|
||||||
% %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-treiber-kernel.png}
|
|
||||||
\end{itemize*}
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
Fehlerausbreitung und (externer) Ausfall
|
||||||
|
|
||||||
\subsubsection{Fehlerausbreitung und (externer)
|
|
||||||
Ausfall}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Wirkungskette: Treiber-Programmierfehler (fault) $\rightarrow$ fehlerhafter interner Zustand des Treibers (error)
|
||||||
Wirkungskette: -[X] Treiber-Programmierfehler (fault) -[X]
|
|
||||||
fehlerhafter interner Zustand des Treibers (error)
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Ausbreitung dieses Fehlers ( failure des Treibers)
|
\item Ausbreitung dieses Fehlers (failure des Treibers)
|
||||||
\item = fehlerhafter externer Zustand des Treibers
|
\item[$\Rightarrow$] fehlerhafter externer Zustand des Treibers
|
||||||
\item = fehlerhafter interner Zustand des Kernels( error )
|
\item[$\Rightarrow$] fehlerhafter interner Zustand des Kernels (error)
|
||||||
\item = Kernelausfall!( failure )
|
\item[$\Rightarrow$] Kernelausfall (failure)
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item[$\boxtimes$]
|
\item Auswirkung: fehlerhafter Zustand weiterer Kernel-Subsysteme
|
||||||
Auswirkung: fehlerhafter interner Zustand eines weiteren
|
\item $\rightarrow$ Robustheit: Isolationsmechanismen
|
||||||
Kernel-Subsystems (z.B. error des Dateisystems)
|
|
||||||
\item
|
|
||||||
$\rightarrow$ Robustheit: Isolationsmechanismen
|
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-treiber-kernel-fehler.png}
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-treiber-kernel-fehler.png}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
|
||||||
\subsection{Isolationsmechanismen}
|
\subsection{Isolationsmechanismen}
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Isolationsmechanismen für robuste Betriebssysteme
|
||||||
im Folgenden: Isolationsmechanismen für robuste Betriebssysteme
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item durch strukturierte Programmierung
|
\item durch strukturierte Programmierung
|
||||||
\item durch Adressraumisolation
|
\item durch Adressraumisolation
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item noch mehr für sichere Betriebssysteme
|
||||||
es gibt noch mehr: Isolationsmechanismen für sichere Betriebssysteme
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item all die obigen...
|
|
||||||
\item durch kryptografische Hardwareunterstützung: Enclaves
|
\item durch kryptografische Hardwareunterstützung: Enclaves
|
||||||
\item durch streng typisierte Sprachen und managed code
|
\item durch streng typisierte Sprachen und managed code
|
||||||
\item durch isolierte Laufzeitumgebungen: Virtualisierung
|
\item durch isolierte Laufzeitumgebungen: Virtualisierung
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
\subsubsection{Strukturierte Programmierung}
|
||||||
\subsubsection{Strukturierte
|
|
||||||
Programmierung}
|
|
||||||
|
|
||||||
Monolithisches BS... in historischer Reinform:
|
Monolithisches BS... in historischer Reinform:
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Anwendungen, Kernel, gesamte BS-Funktionalität
|
||||||
Anwendungen
|
\item programmiert als Sammlung von Prozeduren
|
||||||
\item
|
\item jede darf jede davon aufrufen, keine Modularisierung
|
||||||
Kernel
|
\item keine definierten internen Schnittstellen
|
||||||
\item
|
|
||||||
gesamte BS-Funktionalität
|
|
||||||
\item
|
|
||||||
programmiert als Sammlung von Prozeduren
|
|
||||||
\item
|
|
||||||
jede darf jede davon aufrufen
|
|
||||||
\item
|
|
||||||
keine Modularisierung
|
|
||||||
\item
|
|
||||||
keine definierten internen Schnittstellen
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
Monolithisches Prinzip
|
||||||
\paragraph{Monolithisches Prinzip}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Ziel: Isolation zwischen Anwendungen und Betriebssystem
|
||||||
Ziel: Isolation zwischen Anwendungen und Betriebssystem
|
\item Mechanismus: Prozessor-Privilegierungsebenen (user/kernelspace)
|
||||||
\item
|
\item Konsequenz: fast keine Strukturierung des Kernels
|
||||||
Mechanismus: Prozessor-Privilegierungsebenen ( user space und kernel
|
|
||||||
space )
|
|
||||||
\item
|
|
||||||
Konsequenz für Strukturierung des Kernels: Es gibt keine
|
|
||||||
Strukturierung des Kernels ...
|
|
||||||
\item
|
|
||||||
... jedenfalls fast: Ablauf eines Systemaufrufs (Erinnerung)
|
|
||||||
%\begin{itemize*}
|
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-systemaufruf.png}
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-systemaufruf.png}
|
||||||
%\end{itemize*}
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
Strukturierte Makrokernarchitektur
|
||||||
\paragraph{Strukturierte
|
|
||||||
Makrokernarchitektur}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item schwach strukturierter (monolithischer) Makrokernel
|
||||||
Resultat: schwach strukturierter (monolithischer) Makrokernel
|
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-makrokernelarchitektur.png}
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-makrokernelarchitektur.png}
|
||||||
\begin{itemize*}
|
\item[$\Rightarrow$] Schichtendifferenzierung ( layered operating system )
|
||||||
\item nach [TaWo05], S. 45
|
\item Modularisierung
|
||||||
\end{itemize*}
|
|
||||||
\item
|
|
||||||
Weiterentwicklung:
|
|
||||||
\item
|
|
||||||
Schichtendifferenzierung ( layered operating system )
|
|
||||||
\item
|
|
||||||
Modularisierung (Bsp.: Linux-Kernel) | Kernelcode |
|
|
||||||
|
|
|
||||||
-------------------------
|
|
||||||
| | VFS | | IPC, Dateisystem
|
|
||||||
| | Scheduler, VMM | | Dispatcher,
|
|
||||||
Gerätetreiber |
|
|
||||||
\item
|
|
||||||
Modularer Makrokernel:
|
|
||||||
\item
|
|
||||||
alle Kernelfunktionen in Moduleunterteilt (z.B. verschiedene
|
|
||||||
Dateisystemtypen) $\rightarrow$ Erweiterbarkeit,
|
|
||||||
Wartbarkeit, Portierbarkeit
|
|
||||||
\item
|
|
||||||
klar definierte Modulschnittstellen(z.B. virtualfilesystem, VFS )
|
|
||||||
\item
|
|
||||||
Module zur Kernellaufzeit dynamisch einbindbar
|
|
||||||
( $\rightarrow$ Adaptivität)
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
Modularer Makrokernel
|
||||||
|
|
||||||
\paragraph{Fehlerausbreitung beim
|
|
||||||
Makrokernel}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Kernelfunktionen in Module unterteilt $\rightarrow$ Erweiter-/Portierbarkeit
|
||||||
strukturierte Programmierung:
|
\item klar definierte Modulschnittstellen
|
||||||
\item
|
\item Module zur Kernellaufzeit dynamisch einbindbar (Adaptivität)
|
||||||
\cmark Wartbarkeit
|
|
||||||
\item
|
|
||||||
\cmark Portierbarkeit
|
|
||||||
\item
|
|
||||||
\cmark Erweiterbarkeit
|
|
||||||
\item
|
|
||||||
O (begrenzt) Adaptivität
|
|
||||||
\item
|
|
||||||
O (begrenzt) Schutz gegen statische Programmierfehler: nur durch
|
|
||||||
Compiler (z.B. C private, public)
|
|
||||||
\item
|
|
||||||
\xmark kein Schutz gegen dynamische Fehler
|
|
||||||
\item
|
|
||||||
$\rightarrow$ Robustheit...?
|
|
||||||
\item
|
|
||||||
nächstes Ziel: Schutz gegen Laufzeitfehler...
|
|
||||||
$\rightarrow$ Laufzeitmechanismen
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
\paragraph{Fehlerausbreitung beim Makrokernel}
|
||||||
|
\begin{itemize*}
|
||||||
|
\item[\cmark] Wartbarkeit
|
||||||
|
\item[\cmark] Portierbarkeit
|
||||||
|
\item[\cmark] Erweiterbarkeit
|
||||||
|
\item (begrenzt) Adaptivität
|
||||||
|
\item Schutz gegen statische Programmierfehler nur durch Compiler
|
||||||
|
\item[\xmark] kein Schutz gegen dynamische Fehler
|
||||||
|
\end{itemize*}
|
||||||
|
|
||||||
\subsubsection{Adressraumisolation}
|
\subsubsection{Adressraumisolation}
|
||||||
|
Private virtuelle Adressräume und Fehlerausbreitung
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item private virtuelle Adressräume zweier Tasks ($i\not= j$)
|
||||||
zur Erinnerung: private virtuelle Adressräume zweier Tasks
|
%\item private virtuelle vs. physischer Adresse
|
||||||
($i\not= j$)
|
|
||||||
%\begin{itemize*}
|
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-private-virtuelle-adressräume.png}
|
|
||||||
%\end{itemize*}
|
|
||||||
\item
|
|
||||||
private virtuelle vs. physischer Adresse
|
|
||||||
%\begin{itemize*}
|
%\begin{itemize*}
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-virtuelle-vs-physische-adresse.png}
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-virtuelle-vs-physische-adresse.png}
|
||||||
%\end{itemize*}
|
%\end{itemize*}
|
||||||
|
\item korrekte private vAR: kollisionsfreie Seitenabbildung
|
||||||
|
\item Magie in Hardware: MMU (BS steuert und verwaltet...)
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
Robustheit: Vorteil von privaten vAR?
|
||||||
|
|
||||||
\paragraph{Private virtuelle Adressräume und
|
|
||||||
Fehlerausbreitung}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item[\cmark] nichtvertrauenswürdiger Code kann keine beliebigen physischen Adressen schreiben
|
||||||
korrekte private vAR \textasciitilde{} kollisionsfreie
|
\item[\cmark] Kommunikation zwischen nvw. Code muss durch IPC-Mechanismen explizit hergestellt werden $\rightarrow$ Überwachung und Validierung zur Laufzeit möglich
|
||||||
Seitenabbildung!
|
\item[\cmark] Kontrollfluss begrenzen: Funktionsaufrufe können i.A. keine AR-Grenzen überschreiten
|
||||||
\item
|
|
||||||
Magie in Hardware: MMU (BS steuert und verwaltet...)
|
|
||||||
\item
|
|
||||||
Robustheit: Was haben wir von privaten vAR?
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item \cmark nichtvertrauenswürdiger (i.S.v. potenziell nicht korrekter) Code kann keine beliebigen physischen Adressen schreiben (er erreicht sie ja nicht mal...)
|
\item $\rightarrow$ BS-Zugriffssteuerung kann nicht durch Taskfehler ausgehebelt werden
|
||||||
\item \cmark Kommunikation zwischen nvw. Code (z.B. Anwendungstasks) muss durch IPC-Mechanismen explizit hergestellt werden (u.U. auch shared memory) \begin{itemize*} \item $\rightarrow$ Überwachung und Validierung zur Laufzeit möglich \end{itemize*}
|
\item $\rightarrow$ unabsichtliche Terminierungsfehler(unendliche Rekursion) erschwert ...
|
||||||
\item \cmark Kontrollfluss begrenzen: Funktionsaufrufe können i.A. (Ausnahme: RPC) keine AR-Grenzen überschreiten \begin{itemize*} \item $\rightarrow$ BS-Zugriffssteuerungkann nicht durch Taskfehler ausgehebelt werden \item $\rightarrow$ unabsichtliche Terminierungsfehler(unendliche Rekursion) erschwert ... \end{itemize*}
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
\item keine Isolation zwischen Fehlern innerhalb des Kernels
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
|
||||||
\paragraph{Was das für den Kernel
|
|
||||||
bedeutet}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
private virtuelle Adressräume
|
|
||||||
\begin{itemize*}
|
|
||||||
\item gibt es schon so lange wie VMM
|
|
||||||
\item gab es lange nur auf Anwendungsebene
|
|
||||||
\item $\rightarrow$ keine Isolation zwischen Fehlern innerhalb des Kernels!
|
|
||||||
%\item
|
|
||||||
% %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-virtuelle-kernel-adressräume.png}
|
|
||||||
\end{itemize*}
|
|
||||||
\item
|
|
||||||
nächstes Ziel: Schutz gegen Kernelfehler (Gerätetreiber)...
|
|
||||||
$\rightarrow$ BS-Architektur
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
|
|
||||||
\subsection{Mikrokernelarchitektur}
|
\subsection{Mikrokernelarchitektur}
|
||||||
|
Fortschritt ggü. Makrokernel
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Fortschritt ggü. Makrokernel:
|
\item Strukturierungskonzept
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Strukturierungskonzept:
|
\item strenger durchgesetzt durch konsequente Isolation voneinander unabhängiger Kernel-Subsysteme
|
||||||
\begin{itemize*}
|
\item zur Laufzeit durchgesetzt $\rightarrow$ Reaktion auf fehlerhafte Zustände möglich!
|
||||||
\item strenger durchgesetzt durch konsequente Isolation voneinander unabhängiger Kernel-Subsysteme
|
|
||||||
\item zur Laufzeit durchgesetzt $\rightarrow$ Reaktion auf fehlerhafte Zustände möglich!
|
|
||||||
\end{itemize*}
|
|
||||||
\item zusätzlich zu vertikaler Strukturierung des Kernels: horizontale Strukturierungeingeführt
|
|
||||||
\begin{itemize*}
|
|
||||||
\item $\rightarrow$ funktionale Einheiten: vertikal (Schichten)
|
|
||||||
\item $\rightarrow$ isolierteEinheiten: horizontal (private vAR)
|
|
||||||
\end{itemize*}
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item zusätzlich zu vertikaler Strukturierung des Kernels: horizontale Strukturierung eingeführt
|
||||||
Idee:
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Kernel (alle BS-Funktionalität) $\rightarrow$ $\mu$Kernel (minimale BS-Funktionalität)
|
\item[$\rightarrow$] funktionale Einheiten: vertikal (Schichten)
|
||||||
\item Rest (insbes. Treiber): ,,gewöhnliche'' Anwendungsprozesse mit Adressraumisolation
|
\item[$\rightarrow$] isolierte Einheiten: horizontal (private vAR)
|
||||||
\item Kommunikation: botschaftenbasierteIPC (auch client-server operating system )
|
|
||||||
\item Nomenklatur: Mikrokernelund Serverprozesse
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
\item[$\Rightarrow$] Kernel (alle BS-Funktionalität) $\rightarrow$ $\mu$Kernel (minimale BS-Funk.)
|
||||||
|
\item Rest: ,,gewöhnliche'' Anwendungsprozesse mit AR-isolation
|
||||||
|
\item Kommunikation: botschaftenbasierte IPC (client-server OS)
|
||||||
|
\item Nomenklatur: Mikrokernel und Serverprozesse
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
\subsubsection{Modularer Makrokernel vs. Mikrokernel}
|
||||||
\subsubsection{Modularer Makrokernel vs.
|
|
||||||
Mikrokernel}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-modularer-makrokernel.png}
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-modularer-makrokernel.png}
|
||||||
\item
|
\item minimale Kernelfunktionalität:
|
||||||
minimale Kernelfunktionalität:
|
\item keine Dienste, nur allgemeine Schnittstellenfür diese
|
||||||
\item
|
\item keine Strategien, nur grundlegende Mechanismen zur Ressourcenverwaltung
|
||||||
keine Dienste, nur allgemeine Schnittstellenfür diese
|
\item neues Problem: minimales Mikrokerneldesign
|
||||||
\item
|
|
||||||
keine Strategien, nur grundlegende Mechanismenzur Ressourcenverwaltung
|
|
||||||
\item
|
|
||||||
neues Problem: minimales Mikrokerneldesign
|
|
||||||
\item
|
|
||||||
,,Wir haben 100 Leute gefragt...'': Wie entscheide ich das?
|
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-modularer-makrokernel-2.png}
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-modularer-makrokernel-2.png}
|
||||||
\begin{itemize*}
|
|
||||||
\item Ablauf eines Systemaufrufs
|
|
||||||
\item schwarz: unprivilegierteInstruktionen
|
|
||||||
\item blau:privilegierte Instruktionen
|
|
||||||
\item rot:Übergang zwischen beidem ($\mu$Kern $\rightarrow$ Kontextwechsel!)
|
|
||||||
\end{itemize*}
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
\paragraph{Robustheit von Mikrokernen}
|
||||||
\paragraph{Robustheit von
|
|
||||||
Mikrokernen}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item = Gewinn durch Adressraumisolation innerhalb des Kernels
|
||||||
= Gewinn durch Adressraumisolation innerhalb des Kernels
|
\item[\cmark] kein nichtvertrauenswürdiger Code im Kernelspace, der dort beliebige physische Adressen manipulieren kann
|
||||||
\begin{itemize*}
|
\item[\cmark] Kommunikation zwischen nvw. Code (nicht zur zwischen Anwendungstasks)muss durch IPC explizit hergestellt werden $\rightarrow$ Überwachung und Validierung zur Laufzeit
|
||||||
\item \cmark kein nichtvertrauenswürdiger Code im kernelspace , der dort beliebige physische Adressen manipulieren kann
|
\item[\cmark] Kontrollfluss begrenzen: Zugriffssteuerung auch zwischen Serverprozessen, zur Laufzeit unabhängiges Teilmanagement von Code (Kernelcode) möglich (z.B.: Nichtterminierung erkennen)
|
||||||
\item \cmark Kommunikation zwischen nvw. Code (nicht zur zwischen Anwendungstasks)muss durch IPC explizit hergestellt werden $\rightarrow$ Überwachung und Validierung zur Laufzeit
|
\item Neu:
|
||||||
\item \cmark Kontrollfluss begrenzen: Zugriffssteuerung auch zwischen Serverprozessen, zur Laufzeit unabhängiges Teilmanagement von Code (Kernelcode) möglich (z.B.: Nichtterminierung erkennen)
|
\item[\cmark] nvw. BS-Code muss nicht mehr im Kernelspace laufen
|
||||||
\end{itemize*}
|
\item[\cmark] verbleibender Kernel: klein, funktional weniger komplex, leichter zu entwickeln, zu testen, evtl. formal zu verifizieren
|
||||||
\item
|
\item[\cmark] daneben: Adaptivität durch konsequentere Modularisierung des Kernels gesteigert
|
||||||
Neu:
|
|
||||||
\begin{itemize*}
|
|
||||||
\item \cmark nvw. BS-Code muss nicht mehr im kernelspace (höchste Prozessorprivilegierung) laufen
|
|
||||||
\item \cmark verbleibender Kernel (dessen Korrektheit wir annehmen): klein, funktional weniger komplex, leichter zu entwickeln, zu testen, evtl. formal zu verifizieren
|
|
||||||
\item \cmark daneben: Adaptivitätdurch konsequentere Modularisierung des Kernels gesteigert
|
|
||||||
\end{itemize*}
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
\subsubsection{Mikrokernel: Mach}
|
||||||
\subsubsection{Mach}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item 1975: Aleph (BS des ,,Rochester Intelligent Gateway'')
|
||||||
Mikrokernel-Design: Erster Versuch
|
\item 1979/81: Accent (verteiltes BS), CMU
|
||||||
\begin{itemize*}
|
\item Mach 3.0 (1989): einer der ersten praktisch nutzbaren $\mu$Kerne
|
||||||
\item Carnegie Mellon University (CMU), School of Computer Science 1985 - 1994
|
\item Ziel: API-Emulation ($\not=$ Virtualisierung) von UNIX und -Derivaten auf unterschiedlichen Prozessorarchitekturen
|
||||||
\end{itemize*}
|
\item mehrere unterschiedliche Emulatoren gleichzeitig lauffähig
|
||||||
\item
|
|
||||||
ein wenig Historie
|
|
||||||
\begin{itemize*}
|
|
||||||
\item UNIX (Bell Labs) - K. Thompson, D. Ritchie
|
|
||||||
\item BSD (U Berkeley) - W. Joy
|
|
||||||
\item System V - W. Joy
|
|
||||||
\item Mach (CMU) - R. Rashid
|
|
||||||
\item MINIX - A. Tanenbaum
|
|
||||||
\item NeXTSTEP (NeXT) - S. Jobs
|
|
||||||
\item Linux - L. Torvalds
|
|
||||||
\item GNU Hurd (FSF) - R. Stallman
|
|
||||||
\item Mac OS X (Apple) - S. Jobs
|
|
||||||
\end{itemize*}
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
|
|
||||||
\paragraph{Mach: Ziele}
|
|
||||||
|
|
||||||
Entstehung
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
Grundlage:
|
|
||||||
\begin{itemize*}
|
|
||||||
\item 1975: Aleph(BS des ,,Rochester Intelligent Gateway''), U Rochester
|
|
||||||
\item 1979/81: Accent (verteiltes BS), CMU
|
|
||||||
\end{itemize*}
|
|
||||||
\item
|
|
||||||
gefördert durch militärische Geldgeber:
|
|
||||||
\begin{itemize*}
|
|
||||||
\item DARPA: Defense AdvancedResearch Projects Agency
|
|
||||||
\item SCI: Strategic Computing Initiative
|
|
||||||
\end{itemize*}
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
Ziele
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
Mach 3.0 (Richard Rashid, 1989): einer der ersten praktisch nutzbaren
|
|
||||||
$\mu$Kerne
|
|
||||||
\item
|
|
||||||
Ziel: API-Emulation($\not =$ Virtualisierung!)von UNIX und -Derivaten auf
|
|
||||||
unterschiedlichen Prozessorarchitekturen
|
|
||||||
\item
|
|
||||||
mehrere unterschiedliche Emulatoren gleichzeitig lauffähig
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Emulation außerhalb des Kernels
|
\item Emulation außerhalb des Kernels
|
||||||
\item jeder Emulator: \begin{itemize*} \item Komponente im Adressraum des Applikationsprogramms \item 1...n Server, die unabhängig von Applikationsprogramm laufen \end{itemize*}
|
\item Komponente im Adressraum des Applikationsprogramms
|
||||||
|
\item $1...n$ Server, unabhängig von Applikationsprogramm
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
Mach-Server zur Emulation
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-mach-server.png}
|
|
||||||
\item
|
|
||||||
Emulation von UNIX-Systemen mittels Mach-Serverprozessen
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
$\mu$Kernel-Funktionen
|
$\mu$Kernel-Funktionen
|
||||||
|
|
||||||
\begin{enumerate*}
|
\begin{enumerate*}
|
||||||
\item
|
\item Prozessverwaltung
|
||||||
Prozessverwaltung
|
\item Speicherverwaltung
|
||||||
\item
|
\item IPC-und E/A-Dienste, einschließlich Gerätetreiber
|
||||||
Speicherverwaltung
|
|
||||||
\item
|
|
||||||
IPC-und E/A-Dienste, einschließlich Gerätetreiber
|
|
||||||
\end{enumerate*}
|
\end{enumerate*}
|
||||||
|
|
||||||
unterstützte Abstraktionen ( $\rightarrow$ API,
|
unterstützte Abstraktionen ( $\rightarrow$ API, Systemaufrufe):
|
||||||
Systemaufrufe):
|
|
||||||
|
|
||||||
\begin{enumerate*}
|
\begin{enumerate*}
|
||||||
\item
|
\item Prozesse, Threads, Speicherobjekte
|
||||||
Prozesse
|
\item Ports (generisches, ortstransparentes Adressierungskonzept)
|
||||||
\item
|
\item Botschaften, ... (sekundäre, von den obigen genutzte Abstraktionen)
|
||||||
Threads
|
|
||||||
\item
|
|
||||||
Speicherobjekte
|
|
||||||
\item
|
|
||||||
Ports (generisches, ortstransparentes Adressierungskonzept; vgl. UNIX
|
|
||||||
,,everything is a file'')
|
|
||||||
\item
|
|
||||||
Botschaften
|
|
||||||
\item
|
|
||||||
... (sekundäre, von den obigen genutzte Abstraktionen)
|
|
||||||
\end{enumerate*}
|
\end{enumerate*}
|
||||||
|
|
||||||
Architektur
|
Architektur
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-mach-architektur.png}
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-mach-architektur.png}
|
||||||
\item
|
\item Systemaufrufkosten:
|
||||||
Systemaufrufkosten:
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item IPC-Benchmark (1995): i486 Prozessor, 50 MHz
|
\item IPC-Benchmark (1995): i486 Prozessor, 50 MHz
|
||||||
\item Messung mit verschiedenen Botschaftenlängen( x - Werte)
|
\item Messung mit verschiedenen Botschaftenlängen( x - Werte)
|
||||||
\item ohne Nutzdaten (0 Byte Botschaftenlänge): 115 $\mu$s (Tendenz unfreundlich ...)
|
\item ohne Nutzdaten (0 Byte Botschaftenlänge): 115 $\mu$s (Tendenz unfreundlich ...)
|
||||||
%\item
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-mach-systemaufruf.png}
|
||||||
% %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-mach-systemaufruf.png}
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item Bewertung aus heutiger Sicht:
|
||||||
Bewertung aus heutiger Sicht:
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item funktional komplex
|
\item funktional komplex
|
||||||
\item 153 Systemaufrufe
|
\item 153 Systemaufrufe
|
||||||
\item mehrere Schnittstellen, parallele Implementierungen für eine Funktion
|
\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*}
|
\end{itemize*}
|
||||||
\item
|
\item Fazit:
|
||||||
Fazit:
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item zukunftsweisender Ansatz
|
\item zukunftsweisender Ansatz
|
||||||
\item langsame und ineffiziente Implementierung
|
\item langsame und ineffiziente Implementierung
|
||||||
@ -1221,89 +940,39 @@
|
|||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
Lessons Learned
|
Lessons Learned
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Umsetzung: Designkriterien weitgehend unbekannt
|
||||||
erster Versuch:
|
\item Folgen für Performanz und Programmierkomfort: [Heis19]
|
||||||
\item
|
\item[\xmark] ,,complex'', ,,inflexible'', ,,slow''
|
||||||
Idee des Mikrokernelsbekannt
|
\item wissen etwas über Kosten: IPC-Performanz, Kernelabstraktionen
|
||||||
\item
|
\item wissen nichts über guten $\mu$Kern-Funktionsumfang und gute Schnittstellen
|
||||||
Umsetzung: Designkriterienweitgehend unbekannt
|
|
||||||
\item
|
|
||||||
Folgen für Performanz und Programmierkomfort: [Heis19]
|
|
||||||
\item
|
|
||||||
\xmark ,,complex''
|
|
||||||
\item
|
|
||||||
\xmark ,,inflexible''
|
|
||||||
\item
|
|
||||||
\xmark ,,slow''
|
|
||||||
\item
|
|
||||||
wir wissen etwas über Kosten: IPC-Performanz, Kernelabstraktionen
|
|
||||||
\item
|
|
||||||
wir wissen noch nichts über guten $\mu$Kern-Funktionsumfangund gute
|
|
||||||
Schnittstellen...
|
|
||||||
\item
|
|
||||||
$\rightarrow$ nächstes Ziel!
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
|
||||||
\subsubsection{L4}
|
\subsubsection{L4}
|
||||||
|
Analyse des Mach-Kernels:
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
Made in Germany:
|
|
||||||
\begin{itemize*}
|
|
||||||
\item Jochen Liedtke (GMD, ,,Gesellschaft für Mathematik und Datenverarbeitung''), Betriebssystemgruppe (u.a.): J. Liedtke, H. Härtig, W. E. Kühnhauser
|
|
||||||
\item Symposium on Operating Systems Principles 1995 (SOSP '95): ,,On $\mu$-Kernel Construction'' [Lied95]
|
|
||||||
\end{itemize*}
|
|
||||||
\item
|
|
||||||
Analyse des Mach-Kernels:
|
|
||||||
\begin{enumerate*}
|
\begin{enumerate*}
|
||||||
|
|
||||||
\item falsche Abstraktionen
|
\item falsche Abstraktionen
|
||||||
\item unperformanteKernelimplementierung
|
\item unperformanteKernelimplementierung
|
||||||
\item prozessorunabhängige Implementierung \begin{itemize*} \item Letzteres: effizienzschädliche Eigenschaft eines Mikrokernels \item Neuimplementierung eines (konzeptionell sauberen!) $\mu$-Kerns kaum teurer als Portierung auf andere Prozessorarchitektur \end{itemize*}
|
\item prozessorunabhängige Implementierung
|
||||||
\end{enumerate*}
|
\end{enumerate*}
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
L3 und L4
|
L3 und L4
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Mikrokerne der 2. Generation
|
||||||
Mikrokerne der 2. Generation
|
\item vollständige Überarbeitung des Mikrokernkonzepts
|
||||||
\item
|
|
||||||
zunächst L3, insbesondere Nachfolger L4: erste Mikrokerne der 2.
|
|
||||||
Generation
|
|
||||||
\item
|
|
||||||
vollständige Überarbeitung des Mikrokernkonzepts: wesentliche Probleme
|
|
||||||
der 1. Generation (z.B. Mach) vermieden
|
|
||||||
\item
|
|
||||||
Bsp.: durchschnittliche Performanz von User-Mode IPC in L3 ggü. Mach:
|
|
||||||
Faktor 22 zugunsten L3
|
|
||||||
\begin{itemize*}
|
|
||||||
\item heute: verschiedene Weiterentwicklungen von L4 (bezeichnet heute Familie ähnlicher Mikrokerne)
|
|
||||||
\end{itemize*}
|
|
||||||
%\begin{longtable}[]{@{}lll@{}}
|
|
||||||
%\toprule
|
|
||||||
%First generation & Second Generation & Third generation\tabularnewline
|
|
||||||
%\midrule
|
|
||||||
%\endhead
|
|
||||||
%Eg Mach [87] & Eg L4 [95] & seL4 [09]\tabularnewline
|
|
||||||
%\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-l4-first-g.png} &
|
|
||||||
%\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-L4-second-g.png} &
|
|
||||||
%\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-l4-third-g.png}\tabularnewline
|
|
||||||
%180 syscalls & \textasciitilde7 syscalls & \textasciitilde3
|
|
||||||
%syscalls\tabularnewline
|
|
||||||
%100 kLOC & \textasciitilde10 kLOC & 9 kLOC\tabularnewline
|
|
||||||
%100 $\mu s$ IPC & \textasciitilde1 $\mu
|
|
||||||
%s$ IPC & $0,2-1 \mu s$ IPC\tabularnewline
|
|
||||||
%\bottomrule
|
|
||||||
%\end{longtable}
|
|
||||||
\end{itemize*}
|
\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}
|
||||||
|
|
||||||
|
\subsubsection{Mikrokernel - Designprinzipien}
|
||||||
\paragraph{Mikrokernel-Designprinzipien}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item
|
||||||
Was gehört in einen Mikrokern?
|
Was gehört in einen Mikrokern?
|
||||||
@ -2262,13 +1931,13 @@
|
|||||||
|
|
||||||
%\begin{longtable}[]{@{}lll@{}}
|
%\begin{longtable}[]{@{}lll@{}}
|
||||||
%\toprule
|
%\toprule
|
||||||
%& DAC & MAC\tabularnewline
|
%& DAC & MAC\\
|
||||||
%\midrule
|
%\midrule
|
||||||
%\endhead
|
%\endhead
|
||||||
%IBAC & Unixoide,Linux, Windows & Linux AppArmor, Mac OS
|
%IBAC & Unixoide,Linux, Windows & Linux AppArmor, Mac OS
|
||||||
%Seatbelt\tabularnewline
|
%Seatbelt\\
|
||||||
%TE & - & SELinuxEnterprise Linux (RHEL), RedHat\tabularnewline
|
%TE & - & SELinuxEnterprise Linux (RHEL), RedHat\\
|
||||||
%MLS & Windows UAC & SELinux, TrustedBSD\tabularnewline
|
%MLS & Windows UAC & SELinux, TrustedBSD\\
|
||||||
%\bottomrule
|
%\bottomrule
|
||||||
%\end{longtable}
|
%\end{longtable}
|
||||||
|
|
||||||
@ -2328,13 +1997,13 @@
|
|||||||
%\begin{longtable}[]{@{}lllll@{}}
|
%\begin{longtable}[]{@{}lllll@{}}
|
||||||
%\toprule
|
%\toprule
|
||||||
%acm & paper.pdf & aos-05.pptx & gutachten.tex &
|
%acm & paper.pdf & aos-05.pptx & gutachten.tex &
|
||||||
%worse-engine\tabularnewline
|
%worse-engine\\
|
||||||
%\midrule
|
%\midrule
|
||||||
%\endhead
|
%\endhead
|
||||||
%kühnhauser & rw & - & rw & rx\tabularnewline
|
%kühnhauser & rw & - & rw & rx\\
|
||||||
%schlegel & rw & - & - & rx\tabularnewline
|
%schlegel & rw & - & - & rx\\
|
||||||
%amthor & rw & rw & - & rx\tabularnewline
|
%amthor & rw & rw & - & rx\\
|
||||||
%krause & r & - & - & -\tabularnewline
|
%krause & r & - & - & -\\
|
||||||
%\bottomrule
|
%\bottomrule
|
||||||
%\end{longtable}
|
%\end{longtable}
|
||||||
|
|
||||||
@ -3342,7 +3011,7 @@
|
|||||||
t_i$
|
t_i$
|
||||||
\item
|
\item
|
||||||
Frist für Rendering in Multimedia-Tasks: festgelegt durch periodische
|
Frist für Rendering in Multimedia-Tasks: festgelegt durch periodische
|
||||||
Bildrate (24\textasciitilde48 fps $\rightarrow$ 1/24
|
Bildrate (24~48 fps $\rightarrow$ 1/24
|
||||||
... 1/48 s)
|
... 1/48 s)
|
||||||
\item
|
\item
|
||||||
$\rightarrow$ Berücksichtigung bei Scheduling,
|
$\rightarrow$ Berücksichtigung bei Scheduling,
|
||||||
@ -4949,7 +4618,7 @@
|
|||||||
\item
|
\item
|
||||||
machbar: sehr effiziente Exokerne
|
machbar: sehr effiziente Exokerne
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Grundlage: begrenzte Anzahl einfacher Systemaufrufe (Größenordnung \textasciitilde10) und Kernel-interne Primitiven (,,Pseudo-Maschinenanweisungen''), die enthalten sein müssen
|
\item Grundlage: begrenzte Anzahl einfacher Systemaufrufe (Größenordnung ~10) und Kernel-interne Primitiven (,,Pseudo-Maschinenanweisungen''), die enthalten sein müssen
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item
|
||||||
machbar: sicheres Hardware-Multiplexing auf niedriger
|
machbar: sicheres Hardware-Multiplexing auf niedriger
|
||||||
@ -6635,19 +6304,19 @@
|
|||||||
%\begin{longtable}[]{@{}llllll@{}}
|
%\begin{longtable}[]{@{}llllll@{}}
|
||||||
%\toprule
|
%\toprule
|
||||||
%& Makrokernel & Mikrokernel & Exokernel & Virtualisierung &
|
%& Makrokernel & Mikrokernel & Exokernel & Virtualisierung &
|
||||||
%Multikernel\tabularnewline
|
%Multikernel\\
|
||||||
%\midrule
|
%\midrule
|
||||||
%\endhead
|
%\endhead
|
||||||
%Energieeffizienz & & & (\cmark ) & \xmark & \xmark \tabularnewline
|
%Energieeffizienz & & & (\cmark ) & \xmark & \xmark \\
|
||||||
%Speichereffizienz & \xmark & (\cmark ) & (\cmark ) & & \xmark \tabularnewline
|
%Speichereffizienz & \xmark & (\cmark ) & (\cmark ) & & \xmark \\
|
||||||
%Robustheit & \xmark & \cmark & \xmark & \cmark &\tabularnewline
|
%Robustheit & \xmark & \cmark & \xmark & \cmark &\\
|
||||||
%Verfügbarkeit & \xmark & (\cmark ) & & (\cmark ) & (\cmark )\tabularnewline
|
%Verfügbarkeit & \xmark & (\cmark ) & & (\cmark ) & (\cmark )\\
|
||||||
%Korrektheit & \xmark & \cmark & \xmark & \xmark & (\cmark )\tabularnewline
|
%Korrektheit & \xmark & \cmark & \xmark & \xmark & (\cmark )\\
|
||||||
%Sicherheit & \xmark & \cmark & \xmark & \cmark &\tabularnewline
|
%Sicherheit & \xmark & \cmark & \xmark & \cmark &\\
|
||||||
%Echtzeitfähigkeit & (\cmark ) & (\cmark ) & \cmark & \xmark & \xmark \tabularnewline
|
%Echtzeitfähigkeit & (\cmark ) & (\cmark ) & \cmark & \xmark & \xmark \\
|
||||||
%Adaptivität & \xmark & (\cmark ) & \cmark & \cmark & (\cmark )\tabularnewline
|
%Adaptivität & \xmark & (\cmark ) & \cmark & \cmark & (\cmark )\\
|
||||||
%Wartbarkeit & \cmark & & \cmark & \cmark &\tabularnewline
|
%Wartbarkeit & \cmark & & \cmark & \cmark &\\
|
||||||
%Performanz & (\cmark ) & \xmark & \cmark & \xmark & \cmark \tabularnewline
|
%Performanz & (\cmark ) & \xmark & \cmark & \xmark & \cmark \\
|
||||||
%\bottomrule
|
%\bottomrule
|
||||||
%\end{longtable}
|
%\end{longtable}
|
||||||
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user