wieerwill/Informatik
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Mikrokernelarchitektur

Browse Source
This commit is contained in:
WieErWill 2022-02-25 10:50:21 +01:00
parent bd5724594c
commit 86f907f98b
2 changed files with 148 additions and 272 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
Advanced Operating Systems - Cheatsheet.pdf (Stored with Git LFS)
View File

Binary file not shown.

390
Advanced Operating Systems - Cheatsheet.tex
View File

@ -136,7 +136,7 @@
\item Einst: Einprozessor-Systeme \item Einst: Einprozessor-Systeme
\item Heute: Mehrprozessor-/hochparallele Systeme \item Heute: Mehrprozessor-/hochparallele Systeme
\item neue Synchronisationsmechanismen erforderlich \item neue Synchronisationsmechanismen erforderlich
\item $\rightarrow$ unterschiedliche Hardware und deren Multiplexing \item[$\rightarrow$] unterschiedliche Hardware und deren Multiplexing
\end{itemize*} \end{itemize*}
\subsubsection{Betriebssystemarchitektur} \subsubsection{Betriebssystemarchitektur}
@ -146,7 +146,7 @@
\item Exokernelbasierte Architekturen (Library-Betriebssysteme) \item Exokernelbasierte Architekturen (Library-Betriebssysteme)
\item Virtualisierungsarchitekturen \item Virtualisierungsarchitekturen
\item Multikernel-Architekturen \item Multikernel-Architekturen
\item $\rightarrow$ unterschiedliche Architekturen \item[$\rightarrow$] unterschiedliche Architekturen
\end{itemize*} \end{itemize*}
\subsubsection{Ressourcenverwaltung} \subsubsection{Ressourcenverwaltung}
@ -154,7 +154,7 @@
\item Einst: Batch-Betriebssysteme, Stapelverarbeitung (FIFO) \item Einst: Batch-Betriebssysteme, Stapelverarbeitung (FIFO)
\item Heute: Echtzeitgarantien für Multimedia und Sicherheit \item Heute: Echtzeitgarantien für Multimedia und Sicherheit
\item echtzeitfähige Scheduler, Hauptspeicherverwaltung, Ereignismanagement, Umgang mit Überlast/Prioritätsumkehr ... \item echtzeitfähige Scheduler, Hauptspeicherverwaltung, Ereignismanagement, Umgang mit Überlast/Prioritätsumkehr ...
\item $\rightarrow$ unterschiedliche Ressourcenverwaltung \item[$\rightarrow$] unterschiedliche Ressourcenverwaltung
\end{itemize*} \end{itemize*}
\subsubsection{Betriebssystemabstraktionen} \subsubsection{Betriebssystemabstraktionen}
@ -164,7 +164,7 @@
\item Erhöhung der Ausfallsicherheit ( $\rightarrow$ verfügbarkeitskritisch) \item Erhöhung der Ausfallsicherheit ( $\rightarrow$ verfügbarkeitskritisch)
\item Schutz vor Angriffen und Missbrauch ( $\rightarrow$ sicherheitskritisch) \item Schutz vor Angriffen und Missbrauch ( $\rightarrow$ sicherheitskritisch)
\item flexiblen und modularen Anpassen des BS ( $\rightarrow$ hochadaptiv) \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*} \end{itemize*}
\subsubsection{Betriebssysteme als Softwareprodukte} \subsubsection{Betriebssysteme als Softwareprodukte}
@ -173,7 +173,7 @@
\item besitzen differenzierte Aufgaben $\rightarrow$ funktionale Eigenschaften \item besitzen differenzierte Aufgaben $\rightarrow$ funktionale Eigenschaften
\item Anforderungen an Nutzung und Pflege $\rightarrow$ Evolutionseigenschaften \item Anforderungen an Nutzung und Pflege $\rightarrow$ Evolutionseigenschaften
\item können für Betriebssysteme höchst speziell sein \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*} \end{itemize*}
Grundlegende funktionale Eigenschaften von BS: Hardware- Grundlegende funktionale Eigenschaften von BS: Hardware-
@ -472,7 +472,7 @@
\item kann notwendigen Performanzbereich bestimmen \item kann notwendigen Performanzbereich bestimmen
\end{itemize*} \end{itemize*}
\item \textbf{Anwendungen} können Informationen über jeweils für sie notwendige Performanz liefern \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*} \end{itemize*}
\subsection{Speichereffizienz} \subsection{Speichereffizienz}
@ -523,7 +523,7 @@
\end{itemize*} \end{itemize*}
\item direkter Einfluss des Betriebssystems auf Hauptspeicherbelegung \item direkter Einfluss des Betriebssystems auf Hauptspeicherbelegung
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ Speicherbedarf des Kernels \item[$\rightarrow$] Speicherbedarf des Kernels
\item statische (min) Größe des Kernels (Anweisungen+Daten) \item statische (min) Größe des Kernels (Anweisungen+Daten)
\item dynamische Speicherreservierung durch Kernel \item dynamische Speicherreservierung durch Kernel
\item bei Makrokernel: Speicherbedarf von Gerätecontrollern \item bei Makrokernel: Speicherbedarf von Gerätecontrollern
@ -736,13 +736,13 @@
\begin{itemize*} \begin{itemize*}
\item Maskierung, Redundanz \item Maskierung, Redundanz
\item Isolation von Subsystemen \item Isolation von Subsystemen
\item $\rightarrow$ Isolationsmechanismen \item[$\rightarrow$] Isolationsmechanismen
\end{itemize*} \end{itemize*}
\item[Fehler] (fault) Ursache für fehlerhaften Systemzustand ( error ), z.B. Programmierfehler \item[Fehler] (fault) Ursache für fehlerhaften Systemzustand ( error ), z.B. Programmierfehler
\begin{itemize*} \begin{itemize*}
\item Ausfallverhalten spezifizieren \item Ausfallverhalten spezifizieren
\item Ausfälle zur Laufzeit erkennen und Folgen beheben, abschwächen... \item Ausfälle zur Laufzeit erkennen und Folgen beheben, abschwächen...
\item $\rightarrow$ Micro-Reboots \item[$\rightarrow$] Micro-Reboots
\end{itemize*} \end{itemize*}
\end{description*} \end{description*}
@ -763,7 +763,7 @@
\item[$\Rightarrow$] Kernelausfall (failure) \item[$\Rightarrow$] Kernelausfall (failure)
\end{itemize*} \end{itemize*}
\item Auswirkung: fehlerhafter Zustand weiterer Kernel-Subsysteme \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} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-treiber-kernel-fehler.png}
\end{itemize*} \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] 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 \item[\cmark] Kontrollfluss begrenzen: Funktionsaufrufe können i.A. keine AR-Grenzen überschreiten
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ BS-Zugriffssteuerung kann nicht durch Taskfehler ausgehebelt werden \item[$\rightarrow$] BS-Zugriffssteuerung kann nicht durch Taskfehler ausgehebelt werden
\item $\rightarrow$ unabsichtliche Terminierungsfehler(unendliche Rekursion) erschwert ... \item[$\rightarrow$] unabsichtliche Terminierungsfehler(unendliche Rekursion) erschwert ...
\end{itemize*} \end{itemize*}
\item keine Isolation zwischen Fehlern innerhalb des Kernels \item keine Isolation zwischen Fehlern innerhalb des Kernels
\end{itemize*} \end{itemize*}
@ -930,7 +930,7 @@
\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 Fazit: \item Fazit:
\begin{itemize*} \begin{itemize*}
@ -952,7 +952,7 @@
Analyse des Mach-Kernels: Analyse des Mach-Kernels:
\begin{enumerate*} \begin{enumerate*}
\item falsche Abstraktionen \item falsche Abstraktionen
\item unperformanteKernelimplementierung \item unperformante Kernelimplementierung
\item prozessorunabhängige Implementierung \item prozessorunabhängige Implementierung
\end{enumerate*} \end{enumerate*}
@ -964,9 +964,9 @@
\begin{tabular}{c|c|c} \begin{tabular}{c|c|c}
First generation & Second Generation & Third generation \\\hline First generation & Second Generation & Third generation \\\hline
Eg Mach & Eg L4 & seL4 \\ Eg Mach & Eg L4 & seL4 \\
\includegraphics[width=.3\linewidth]{Assets/AdvancedOperatingSystems-l4-first-g.png} & \includegraphics[width=.2\linewidth]{Assets/AdvancedOperatingSystems-l4-first-g.png} &
\includegraphics[width=.3\linewidth]{Assets/AdvancedOperatingSystems-L4-second-g.png} & \includegraphics[width=.2\linewidth]{Assets/AdvancedOperatingSystems-L4-second-g.png} &
\includegraphics[width=.3\linewidth]{Assets/AdvancedOperatingSystems-l4-third-g.png} \\ \includegraphics[width=.2\linewidth]{Assets/AdvancedOperatingSystems-l4-third-g.png} \\
180 syscalls & $\sim$ 7 syscalls & $\sim$ 3 syscalls \\ 180 syscalls & $\sim$ 7 syscalls & $\sim$ 3 syscalls \\
100 kLOC & $\sim$ 10 kLOC & 9 kLOC \\ 100 kLOC & $\sim$ 10 kLOC & 9 kLOC \\
100 $\mu s$ IPC & $\sim$ 1 $\mu s$ IPC & $0,2-1 \mu s$ IPC 100 $\mu s$ IPC & $\sim$ 1 $\mu s$ IPC & $0,2-1 \mu s$ IPC
@ -974,296 +974,173 @@
\subsubsection{Mikrokernel - Designprinzipien} \subsubsection{Mikrokernel - Designprinzipien}
\begin{itemize*} \begin{itemize*}
\item \item Was gehört in einen Mikrokern?
Was gehört in einen Mikrokern? \item Konzeptsicht $\rightarrow$ Funktionalität
\begin{itemize*} \item Implementierungssicht $\rightarrow$ Performanz
\item Liedtke: Unterscheidung zwischen Konzepten und deren Implementierung \item[$\rightarrow$] 1. Generation: durch Performanzentscheidungen aufgeweicht
\item bestimmende Anforderungen an beide: \begin{itemize*} \item Konzeptsicht $\rightarrow$ Funktionalität, \item Implementierungssicht $\rightarrow$ Performanz \end{itemize*} \item[$\rightarrow$] Effekt in Praxis gegenteilig: schlechte (IPC-) Performanz
\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:
\end{itemize*} \end{itemize*}
Designprinzipien für Mikrokernel-Konzept
\begin{enumerate*} \begin{enumerate*}
\item \item System interaktive und nicht vollständig vertrauenswürdige Applikationen unterstützen ( $\rightarrow$ HW-Schutz,-Multiplexing),
System interaktive und nicht vollständig vertrauenswürdige \item Hardware mit virtueller Speicherverwaltung und Paging
Applikationen unterstützen ( $\rightarrow$ HW-Schutz,
-Multiplexing),
\item
Hardware mit virtueller Speicherverwaltung und Paging
\end{enumerate*} \end{enumerate*}
Designprinzipien: Designprinzipien
\begin{description*}
\begin{enumerate*} \item[Autonomie] Subsystem muss so implementiert werden, dass es von keinem anderen Subsystem gestört oder korrumpiert werden kann
\item \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.
Autonomie: ,,Ein Subsystem (Server)muss so implementiert werden \end{description*}
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*}
L4: Speicherabstraktion L4: Speicherabstraktion
\begin{itemize*} \begin{itemize*}
\item \item Adressraum: Abbildung, die jede virtuelle Seite auf einen physischen Seitenrahmen abbildet oder als ,,nicht zugreifbar'' markiert
Adressraum: Abbildung, die jede virtuelle Seite auf einen physischen \item Implementierung über Seitentabellen, unterstützt durch MMU-Hardware
Seitenrahmen abbildet oder als ,,nicht zugreifbar'' markiert \item Aufgabe des Mikrokernels (Schicht aller Subsysteme): muss Hardware-Konzept des Adressraums verbergen und durch eigenes Adressraum-Konzept überlagern
\item \item Mikrokernel-Konzept des Adressraums:
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:
\begin{itemize*} \begin{itemize*}
\item muss Implementierung von beliebigen virtuellen Speicherverwaltungs-und -schutzkonzepten oberhalb des Mikrokernels (d.h. in den Subsystemen) erlauben \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 \item sollte einfach und dem Hardware-Konzept ähnlich sein
\end{itemize*} \end{itemize*}
\item \item Idee: abstrakte Speicherverwaltung
Idee: abstrakte Speicherverwaltung
\begin{itemize*} \begin{itemize*}
\item rekursive Konstruktion und Verwaltung der Adressräume auf Benutzer-(Server-)Ebene \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*}
\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 Hierarchische Adressräume
\begin{itemize*}
\item
Rekursive Konstruktion der Adressraumhierarchie
\begin{itemize*} \begin{itemize*}
\item Rekursive Konstruktion der Adressraumhierarchie
\item Server und Anwendungenkönnen damit ihren Klienten Seiten des eigenen Adressraumes zur Verfügung stellen \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 Realspeicher: Ur-Adressraum vom $\mu$Kernel verwaltet
\item Speicherverwaltung(en), Paging usw.: vollständig außerhalb des $\mu$-Kernels realisiert \item Speicherverwaltung, Paging... außerhalb des $\mu$-Kernels realisiert
%\item %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-adressraumhierarchie.png}
% %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-adressraumhierarchie.png}
\end{itemize*}
\end{itemize*} \end{itemize*}
L4: Threadabstraktion L4: Threadabstraktion
\begin{itemize*} \begin{itemize*}
\item \item Thread
Thread
\begin{itemize*} \begin{itemize*}
\item innerhalb eines Adressraumesablaufende Aktivität \item innerhalb eines Adressraumes ablaufende 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[$\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*} \end{itemize*}
\item \item Designentscheidung
Designentscheidung
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ Autonomieprinzip \item[$\rightarrow$] Autonomieprinzip
\item $\rightarrow$ Konsequenz: Adressraumisolation \item[$\rightarrow$] Konsequenz: Adressraumisolation
\item $\rightarrow$ entscheidender Grund zur Realisierung des Thread-Konzepts innerhalb des Mikrokernels \item[$\rightarrow$] entscheidender Grund zur Realisierung des Thread-Konzepts innerhalb des Mikrokernels
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
IPC IPC
\begin{itemize*} \begin{itemize*}
\item \item Interprozess-Kommunikation
Interprozess-Kommunikation
\begin{itemize*} \begin{itemize*}
\item Kommunikation über Adressraumgrenzen: vertrauenswürdig kontrollierte Aufhebung der Isolation \item Kommunikation über Adressraumgrenzen
\item $\rightarrow$ essenziell für (sinnvolles) Multitasking und -threading \item vertrauenswürdig kontrollierte Aufhebung der Isolation
\item[$\rightarrow$] essenziell für (sinnvolles) Multitasking und -threading
\end{itemize*} \end{itemize*}
\item \item Designentscheidung
Designentscheidung
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ Integritätsprinzip \item[$\rightarrow$] Integritätsprinzip
\item $\rightarrow$ wir haben schon: vertrauenswürdige Adressraumisolation im $\mu$Kernel \item[$\rightarrow$] vertrauenswürdige Adressraumisolation im $\mu$Kernel
\item $\rightarrow$ grundlegendes IPC-Konzepts innerhalb des Mikrokernels (flexibel und dynamisch durch Server erweiterbar, analog Adressraumhierarchie) \item[$\rightarrow$] grundlegendes IPC-Konzepts innerhalb des Mikrokernels
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
Identifikatoren Identifikatoren
\begin{itemize*} \begin{itemize*}
\item \item Thread-und Ressourcenbezeichner
Thread-und Ressourcenbezeichner
\begin{itemize*} \begin{itemize*}
\item müssen vertrauenswürdig vergeben (authentisch und i.A. persistent) und verwaltet(eindeutig und korrekt referenzierbar)werden \item müssen vertrauenswürdig vergeben und verwaltet werden
\item $\rightarrow$ essenziell für (sinnvolles) Multitasking und -threading \item[$\rightarrow$] essenziell für (sinnvolles) Multitasking und -threading
\item $\rightarrow$ essenziell für vertrauenswürdige Kernel-und Server-Schnittstellen \item[$\rightarrow$] essenziell für vertrauenswürdige Kernel-/Server-Schnittstellen
\end{itemize*} \end{itemize*}
\item \item Designentscheidung
Designentscheidung
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ Integritätsprinzip \item[$\rightarrow$] Integritätsprinzip
\item $\rightarrow$ ID-Konzept innerhalb des Mikrokernels (wiederum: durch Server erweiterbar) \item[$\rightarrow$] ID-Konzept innerhalb des Mikrokernels
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
Lessons Learned Lessons Learned
\begin{enumerate*} \begin{enumerate*}
\item \item Ein minimaler Mikrokernel
Ein minimaler Mikrokernel
\begin{itemize*} \begin{itemize*}
\item soll Minimalmenge an geeigneten Abstraktionenzur Verfügung stellen: \item stellt Minimalmenge geeigneter Abstraktionen verfügbar
\item flexibel genug, um Implementierung beliebiger Betriebssysteme zu ermöglichen \item flexibel, um Implementierung beliebiger BS zu ermöglichen
\item Nutzung umfangreicher Mengeverschiedener Hardware-Plattformen \item Nutzung verschiedener Hardware-Plattformen
\end{itemize*} \end{itemize*}
\item \item Geeignete, funktional minimale Mechanismen im $\mu$Kern:
Geeignete, funktional minimale Mechanismen im $\mu$Kern:
\begin{itemize*} \begin{itemize*}
\item Adressraum mit map-, flush-, grant-Operation \item Adressraum mit map-, flush-, grant-Operation
\item Threadsinklusive IPC \item Threadsinklusive IPC
\item eindeutige Identifikatoren \item eindeutige Identifikatoren
\end{itemize*} \end{itemize*}
\item \item Wahl der geeigneten Abstraktionen: kritisch für Verifizierbarkeit, Adaptivität und optimierte Performanz des Mikrokerns
Wahl der geeigneten Abstraktionen: \item Bisherigen $\mu$-Kernel-Abstraktionskonzepte: ungeeignete, zu viele, zu spezialisierte u. inflexible Abstraktionen
\begin{itemize*} \item Konsequenzen für Mikrokernel-Implementierung
\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
\begin{itemize*} \begin{itemize*}
\item müssen für jeden Prozessortyp neu implementiert werden \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*} \end{itemize*}
\item \item innerhalb eines Mikrokernels sind von Prozessorhardware abhängig
innerhalb eines Mikrokernels sind
\begin{enumerate*} \begin{enumerate*}
\def\labelenumii{\arabic{enumii}.}
\item grundlegende Implementierungsentscheidungen \item grundlegende Implementierungsentscheidungen
\item meiste Algorithmen u. Datenstrukturen \item meiste Algorithmen u. Datenstrukturen
\end{enumerate*} \end{enumerate*}
\begin{itemize*} \item Fazit: Mikrokernel mit akzeptabler Performanz hardwarespezifische Implementierung minimal erforderlicher vom Prozessortyp unabhängiger Abstraktionen
\item von Prozessorhardware abhängig %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-l4-ipc-performance.png}
\end{itemize*} \item L4 heute: Spezifikation Mikrokernels (nicht Implementierung)
\end{enumerate*} \end{enumerate*}
\begin{itemize*} %Einige Weiterentwicklungen:
\item %\begin{itemize*}
Fazit: % \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
\begin{itemize*} % \item University of New South Wales, Australien
\item Mikrokernelmit akzeptabler Performanz: hardwarespezifische Implementierung minimalerforderlicher, vom Prozessortyp unabhängiger Abstraktionen % \begin{itemize*}
%\item % \item Implementierung von L4 auf verschiedenen 64 - Bit-Plattformen, bekannt als L4/MIPS, L4/Alpha
% %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-l4-ipc-performance.png} % \item Implementierung in C (Wartbarkeit, Performanz)
\end{itemize*} % \item Mit L4Ka::Pistachio bisher schnellste Implementierung von botschaftenbasierterIPC
\end{itemize*} % \item 2009: seL4, erster formal verifizierter BS-Kernel
% \end{itemize*}
Heutige Bedeutung %\end{itemize*}
\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*}
Zwischenfazit Zwischenfazit
\begin{itemize*} \begin{itemize*}
\item \item Begrenzung von Fehlerausbreitung ($\rightarrow$ Folgen von errors)
Begrenzung von Fehlerausbreitung ( $\rightarrow$ \item konsequent modularisierte Architektur aus Subsystemen
Folgen von errors ): \item Isolationsmechanismen zwischen Subsystemen
\item \item statische Isolation auf Quellcodeebene $\rightarrow$ strukturierte Programmierung
konsequent modularisierte Architektur aus Subsystemen \item dynamische Isolation zur Laufzeit $\rightarrow$ private virtuelle Adressräume
\item \item Architektur, welche diese Mechanismen komponiert: Mikrokernel
Isolationsmechanismen zwischen Subsystemen \item[\cmark] Adressraumisolation für sämtlichen nichtvertrauenswürdigen Code
\item \item[\cmark] keine privilegierten Instruktionen in nvw. Code (Serverprozesse)
Konsequenzen für BS-Kernel: \item[\cmark] geringe Größe (potenziell: Verifizierbarkeit) des Kernels
\item \item[\cmark] neben Robustheit: Modularitätund Adaptivitätdes Kernels
statische Isolation auf Quellcodeebene $\rightarrow$ \item[\xmark] Behandlung von Ausfällen ( $\rightarrow$ abstürzende Gerätetreiber ...)
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*}
\end{itemize*} \end{itemize*}
\subsection{Micro-Reboots}
\subsection{3.5 Micro-Reboots}
\begin{itemize*} \begin{itemize*}
\item \item Beobachtungen am Ausfallverhalten von BS:
Beobachtungen am Ausfallverhalten von BS: \item Kernelfehler sind (potenziell) fatal für gesamtes System
\item \item Anwendungsfehler sind es nicht
Kernelfehler sind (potenziell) fatal für gesamtes System \item[$\rightarrow$] kleiner Kernel = geringeres Risiko von Systemausfällen
\item \item[$\rightarrow$] durch BS-Code in Serverprozessen: verbleibendes Risiko unabhängiger Teilausfälle von BS-Funktionalität (z.B. FS, Treiberprozesse, GUI, ...)
Anwendungsfehler sind es nicht \item Ergänzung zu Isolationsmechanismen:
\item \item Mechanismen zur Behandlung von Subsystem-Ausfällen
$\rightarrow$ kleiner Kernel = geringeres Risiko von \item = Mechanismen zur Behandlung Anwendungs-, Server- und Gerätetreiberfehlen
Systemausfällen \item[$\rightarrow$] Micro-Reboots
\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*} \end{itemize*}
Ansatz Ansatz
@ -2120,7 +1997,7 @@
Sicherheitsmechanismen: Datenstrukturen und Algorithmen, welche die Sicherheitsmechanismen: Datenstrukturen und Algorithmen, welche die
Sicherheitseigenschaften eines Betriebssystems implementieren. Sicherheitseigenschaften eines Betriebssystems implementieren.
\begin{itemize*} \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 Nutzerauthentisierung ( login - Dientsprogramm, Passwort-Hashing, ...)
\item Autorisierungsinformationen (Metainformationen über Rechte, MLS-Klassen, TE-Typen, ...) \item Autorisierungsinformationen (Metainformationen über Rechte, MLS-Klassen, TE-Typen, ...)
\item Autorisierungsmechanismen (Rechteprüfung, Politikadministration, ...) \item Autorisierungsmechanismen (Rechteprüfung, Politikadministration, ...)
@ -2144,7 +2021,7 @@
\item groß ( $\rightarrow$ Dateianzahl auf Fileserver) \item groß ( $\rightarrow$ Dateianzahl auf Fileserver)
\item dünn besetzt \item dünn besetzt
\item in Größe und Inhalt dynamisch veränderlich \item in Größe und Inhalt dynamisch veränderlich
\item $\rightarrow$ effiziente Datenstruktur? \item[$\rightarrow$] effiziente Datenstruktur?
\end{itemize*} \end{itemize*}
\item \item
Lösung: verteilte Implementierung der acm als Spaltenvektoren, deren Lösung: verteilte Implementierung der acm als Spaltenvektoren, deren
@ -2564,7 +2441,7 @@
\begin{itemize*} \begin{itemize*}
\item Einschränkung von erlaubten Typtransitionen (Welches Programm darf mit welchem Typ ausgeführt werden?) \item Einschränkung von erlaubten Typtransitionen (Welches Programm darf mit welchem Typ ausgeführt werden?)
\item weitere Abstraktionsschicht: rollenbasierte Regeln (RBAC) \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*} \end{itemize*}
\item \item
Ergebnis: Ergebnis:
@ -2686,7 +2563,7 @@
\item O setzt Vertrauen in korrekte (und nicht böswillige) Hardwarevoraus \item O setzt Vertrauen in korrekte (und nicht böswillige) Hardwarevoraus
\item O Dokumentation und Entwicklerunterstützung (im Ausbau ...) \item O Dokumentation und Entwicklerunterstützung (im Ausbau ...)
\item \xmark schützt mittels Enclaves einzelne Anwendungen, aber nicht das System \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*}
\end{itemize*} \end{itemize*}
@ -2703,7 +2580,7 @@
\item Verstehen des Referenzmonitorprinzips \item Verstehen des Referenzmonitorprinzips
\item frühe Forschungen zu Betriebssystemsicherheit in 1970er-1980er Jahren durch US-Verteidigungsministerium \item frühe Forschungen zu Betriebssystemsicherheit in 1970er-1980er Jahren durch US-Verteidigungsministerium
\item Schlüsselveröffentlichung: Anderson-Report(1972)[Ande72] \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*} \end{itemize*}
\item \item
Begriffe des Referenzmonitorprinzips kennen wir schon: Begriffe des Referenzmonitorprinzips kennen wir schon:
@ -2720,8 +2597,8 @@
\item \item
Idee: Idee:
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ sämtliche Autorisierungsentscheidungen durch einen zentralen (abstrakten) Mechanismus = Referenzmonitor \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 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 \item somit: Architekturbeschreibung, wie Zugriffe auf Ressourcen (z.B. Dateien) auf solche Zugriffe, die Sicherheitspolitik erlaubt, eingeschränkt werden
\end{itemize*} \end{itemize*}
\item \item
@ -2744,18 +2621,18 @@
\item \item
(RM 1) bei sämtlichen Subjekt/Objekt-Interaktionen involviert sind (RM 1) bei sämtlichen Subjekt/Objekt-Interaktionen involviert sind
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ Unumgehbarkeit ( total mediation ) \item[$\rightarrow$] Unumgehbarkeit ( total mediation )
\end{itemize*} \end{itemize*}
\item \item
(RM 2) geschützt sind vor unautorisierter Manipulation (RM 2) geschützt sind vor unautorisierter Manipulation
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ Manipulationssicherheit ( tamperproofness ) \item[$\rightarrow$] Manipulationssicherheit ( tamperproofness )
\end{itemize*} \end{itemize*}
\item \item
(RM 3) hinreichend klein und wohlstrukturiert sind, um formalen (RM 3) hinreichend klein und wohlstrukturiert sind, um formalen
Analysemethoden zugänglich zu sein Analysemethoden zugänglich zu sein
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ Verifizierbarkeit ( verifyability ) \item[$\rightarrow$] Verifizierbarkeit ( verifyability )
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
@ -4479,7 +4356,7 @@
\begin{itemize*} \begin{itemize*}
\item Trennung von Schutz und Abstraktion der Ressourcen \item Trennung von Schutz und Abstraktion der Ressourcen
\item Ressourcen-Schutz und -Multiplexing: verbleibt beim Betriebssystemkernel(dem Exokernel) \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*} \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*} \end{itemize*}
\item \item
@ -4543,7 +4420,7 @@
\begin{itemize*} \begin{itemize*}
\item Vorteil: im allgemeinen geringere Latenzzeiten, einfacheres und komfortableres Programmiermodell \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 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*} \end{itemize*}
\item \item
Exokernel-Betriebssysteme: entziehen(überwiegend) Ressourcen Exokernel-Betriebssysteme: entziehen(überwiegend) Ressourcen
@ -4552,7 +4429,7 @@
\begin{itemize*} \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 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 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*}
\end{itemize*} \end{itemize*}
@ -4579,7 +4456,7 @@
\item \item
In der Praxis: In der Praxis:
\begin{itemize*} \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 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 \item bei zustandsbehafteten Ressourcen ( $\rightarrow$ CPU): Exokernelkann diesen Zustand auf Hintergrundspeicher sichern $\rightarrow$ Management-Informationen zum Aufräumen durch Library-BS
\end{itemize*} \end{itemize*}
@ -4717,7 +4594,7 @@
\begin{itemize*} \begin{itemize*}
\item Adaptivität \item Adaptivität
\item Wartbarkeit, Sicherheit, Robustheit \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*} \end{itemize*}
\item \item
Idee: Idee:
@ -4885,14 +4762,14 @@
Kernel Mode ausgeführt werden dürfen (Befehle zur Realisierung von Kernel Mode ausgeführt werden dürfen (Befehle zur Realisierung von
E/A, Manipulation der MMU, ...) E/A, Manipulation der MMU, ...)
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ sensible Instruktionen \item[$\rightarrow$] sensible Instruktionen
\end{itemize*} \end{itemize*}
\item \item
$\exists$ Menge an Maschinenbefehlen, die Wechsel des $\exists$ Menge an Maschinenbefehlen, die Wechsel des
Privilegierungsmodus auslösen (x86: Trap ), wenn sie im User Mode Privilegierungsmodus auslösen (x86: Trap ), wenn sie im User Mode
ausgeführt werden ausgeführt werden
\begin{itemize*} \begin{itemize*}
\item $\rightarrow$ privilegierte Instruktionen \item[$\rightarrow$] privilegierte Instruktionen
\end{itemize*} \end{itemize*}
\item \item
Prozessor ist virtualisierbarfalls (notw. Bed.): sensible Prozessor ist virtualisierbarfalls (notw. Bed.): sensible
@ -5158,7 +5035,7 @@
dazu: dazu:
\begin{itemize*} \begin{itemize*}
\item Hypervisor: muss geeignetes Interface definieren (HV-Calls) \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!) \item bilden eine HV-API als Schnittstelle für Gast-Betriebssysteme (nicht für Nutzerprogramme!)
\end{itemize*} \end{itemize*}
\item \item
@ -5680,7 +5557,6 @@
\item \item
zum optimalen Einsatz zwingend erforderlich: zum optimalen Einsatz zwingend erforderlich:
\begin{enumerate*} \begin{enumerate*}
\def\labelenumii{\arabic{enumii}.}
\item Entwicklung Hardwarearchitektur \item Entwicklung Hardwarearchitektur
\item zusätzlich: Entwicklung geeigneter Systemsoftware \item zusätzlich: Entwicklung geeigneter Systemsoftware
\item zusätzlich: Entwicklung geeigneter Anwendungssoftware \item zusätzlich: Entwicklung geeigneter Anwendungssoftware
@ -5806,7 +5682,7 @@
\item parallelisierungsfähige Hardware \item parallelisierungsfähige Hardware
\item kausal unabhängige Threads \item kausal unabhängige Threads
\item passendes (und korrekt eingesetztes!) Programmiermodell, insbesondere Synchronisation! \item passendes (und korrekt eingesetztes!) Programmiermodell, insbesondere Synchronisation!
\item $\rightarrow$ Programmierer + Compiler \item[$\rightarrow$] Programmierer + Compiler
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}