Einleitung gekürzt
This commit is contained in:
parent
dbe70d6543
commit
ab46409451
BIN
Advanced Operating Systems - Cheatsheet.pdf
(Stored with Git LFS)
BIN
Advanced Operating Systems - Cheatsheet.pdf
(Stored with Git LFS)
Binary file not shown.
@ -122,239 +122,92 @@
|
||||
|
||||
\raggedright
|
||||
\begin{multicols}{3}\scriptsize % multicol parameters % These lengths are set only within the two main columns %\setlength{\columnseprule}{0.25pt} \setlength{\premulticols}{1pt} \setlength{\postmulticols}{1pt} \setlength{\multicolsep}{1pt} \setlength{\columnsep}{2pt}
|
||||
\section{Einführung}
|
||||
Betriebssysteme stecken nicht nur in Einzelplatzrechnern, sondern z.B. auch in:
|
||||
|
||||
\subsection{Funktionale und nichtfunktionale Eigenschaften}
|
||||
\begin{itemize*}
|
||||
\item Informationssystemen
|
||||
\item Anforderungen (Requirements): Funktionale und nichtfunktionale Eigenschaften (eines Produkts, z.B. Softwaresystems) entstehen durch Erfüllung von funktionalen und nichtfunktionalen Anforderungen
|
||||
\item funktionale Eigenschaft: was ein Produkt tun soll
|
||||
\item nichtfunktionale Eigenschaft (NFE): wie ein Produkt dies tun soll
|
||||
\item andere Bezeichnungen nichtfunktionaler Eigenschaften
|
||||
\begin{itemize*}
|
||||
\item Gesundheitswesen
|
||||
\item Finanzdienstleister
|
||||
\item Qualitäten bzw. Qualitätsattribute (eines Software-Produkts)
|
||||
\item Non-functional requirements/properties
|
||||
\item Constraints
|
||||
\item Quality of service(QoS) requirements
|
||||
\end{itemize*}
|
||||
\item
|
||||
Verkehrsmanagement-Systemen
|
||||
\begin{itemize*}
|
||||
\item Eisenbahn
|
||||
\item Flugwesen
|
||||
\item im Englischen: nichtfunktionale Eigenschaften eines Systems etc. informell auch als seine ,,ilities'' bezeichnet
|
||||
\item im Deutschen: (,,itäten'', ,,barkeiten'', ... möglich)
|
||||
\end{itemize*}
|
||||
\item
|
||||
Kommunikationssystemen
|
||||
\begin{itemize*}
|
||||
\item Mobilfunk
|
||||
\item Raumfahrt
|
||||
\end{itemize*}
|
||||
\item
|
||||
eingebettetenSystemen
|
||||
\begin{itemize*}
|
||||
\item Multimedia
|
||||
\item Fahrzeugsysteme
|
||||
\item Sensornetze
|
||||
\end{itemize*}
|
||||
\item
|
||||
... $\rightarrow$ verschiedenste Anforderungen!
|
||||
\end{itemize*}
|
||||
|
||||
Konsequenz: Spezialbetriebssysteme für Anforderungen wie ...
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Robustheit
|
||||
\item
|
||||
Echtzeitfähigkeit
|
||||
\item
|
||||
Energieeffizienz
|
||||
\item
|
||||
Sicherheit
|
||||
\item
|
||||
Adaptivität
|
||||
\item
|
||||
...
|
||||
\end{itemize*}
|
||||
|
||||
Gegenstand dieser Vorlesung: Konstruktionsrichtlinien für solche
|
||||
,,High-End Betriebssysteme''
|
||||
|
||||
|
||||
\subsection{Funktionale und nichtfunktionale
|
||||
Eigenschaften}
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Beispiel: Autokauf ,,Mit unserem Fahrzeug können Sie einkaufen
|
||||
fahren!''
|
||||
\item
|
||||
Beispiel: Handykauf ,,Mit unserem Telefon können Sie Ihre Freunde und
|
||||
Familie anrufen!''
|
||||
\item
|
||||
Anforderungen (Requirements)
|
||||
\begin{itemize*}
|
||||
\item Funktionale und nichtfunktionale Eigenschaften (eines Produkts, z.B. Softwaresystems) entstehen durch Erfüllung von funktionalen und nichtfunktionalen Anforderungen
|
||||
\end{itemize*}
|
||||
\item
|
||||
funktionale Eigenschaft
|
||||
\begin{itemize*}
|
||||
\item legt fest, was ein Produkt tun soll.
|
||||
\item Bsp Handykauf: Das Produkt soll Telefongespräche ermöglichen.
|
||||
\end{itemize*}
|
||||
\item
|
||||
eine nichtfunktionale Eigenschaft (NFE)
|
||||
\begin{itemize*}
|
||||
\item legt fest, wie es dies tun soll, also welche sonstigen Eigenschaften das Produkt haben soll.
|
||||
\item Bsp Handykauf: Das Produkt soll klein, leicht, energiesparend, strahlungsarm, umweltfreundlich,... sein.
|
||||
\end{itemize*}
|
||||
\item
|
||||
andere Bezeichnungen nichtfunktionaler Eigenschaften
|
||||
\begin{itemize*}
|
||||
\item Qualitäten bzw. Qualitätsattribute (eines Software-Produkts): \begin{itemize*} \item Nichtfunktionale Anforderungen bzw. Eigenschaften eines Software-Systems bzw. -Produkts oft auch als seine Qualitäten bezeichnet. \item einzelne realisierte Eigenschaft ist demzufolge ein Qualitätsattribut (quality property) dieses Systems bzw. Produkts. \end{itemize*}
|
||||
\item Weitere in der Literatur zu findende Begriffe in diesem Zusammenhang: \begin{itemize*} \item Non-functionalrequirements/properties \item Constraints \item Quality ofservice(QoS) requirements \item u.a. \end{itemize*}
|
||||
\end{itemize*}
|
||||
\item
|
||||
,,\textasciitilde ilities''
|
||||
\begin{itemize*}
|
||||
\item im Englischen: nichtfunktionale Eigenschaften eines Systems etc. informell auch als seine ,,ilities'' bezeichnet, hergeleitet von Begriffen wie \begin{itemize*} \item Stability \item Portability \item ... \end{itemize*}
|
||||
\item im Deutschen: ( ,,itäten'',,,barkeiten'', ... möglich aber sprachästhetisch fragenswert) \begin{itemize*} \item Portab-ilität , Skalier-barkeit, aber: Offen-heit , Performanz, ... \end{itemize*}
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{Konsequenzen für
|
||||
Betriebssysteme}
|
||||
|
||||
|
||||
\subsubsection{Hardwarebasis}
|
||||
|
||||
Einst: Einprozessor-Systeme
|
||||
|
||||
Heute:
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Mehrprozessor-Systeme
|
||||
\item
|
||||
hochparallele Systeme
|
||||
\item
|
||||
neue Synchronisationsmechanismen erforderlich
|
||||
\item
|
||||
$\rightarrow$ unterschiedliche Hardware und deren
|
||||
Multiplexing aufgrund unterschiedlicher nichtfunktionaler
|
||||
Eigenschaften
|
||||
\item Einst: Einprozessor-Systeme
|
||||
\item Heute: Mehrprozessor-/hochparallele Systeme
|
||||
\item neue Synchronisationsmechanismen erforderlich
|
||||
\item $\rightarrow$ unterschiedliche Hardware und deren Multiplexing aufgrund unterschiedlicher nichtfunktionaler Eigenschaften
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsubsection{Betriebssystemarchitektur}
|
||||
|
||||
Einst: Monolithische und Makrokernel-Architekturen
|
||||
|
||||
Heute:
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Mikrokernel(-basierte) Architekturen
|
||||
\item
|
||||
Exokernelbasierte Architekturen ( Library-Betriebssysteme )
|
||||
\item
|
||||
Virtualisierungsarchitekturen
|
||||
\item
|
||||
Multikernel-Architekturen
|
||||
\item
|
||||
$\rightarrow$ unterschiedliche Architekturen aufgrund
|
||||
\item Einst: Monolithische und Makrokernel-Architekturen
|
||||
\item Heute: Mikrokernel(-basierte) Architekturen
|
||||
\item Exokernelbasierte Architekturen ( Library-Betriebssysteme )
|
||||
\item Virtualisierungsarchitekturen
|
||||
\item Multikernel-Architekturen
|
||||
\item $\rightarrow$ unterschiedliche Architekturen aufgrund
|
||||
unterschiedlicher nichtfunktionaler Eigenschaften
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsubsection{Ressourcenverwaltung}
|
||||
|
||||
Einst: sog. Batch-Betriebssysteme: Stapelverarbeitung von Jobs (FIFO,
|
||||
Zeitgarantie: irgendwann)
|
||||
|
||||
Heute:
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Echtzeitgarantien für Multimedia und Safety-kritische Anwendungen
|
||||
(Unterhaltung, Luft-und Raumfahrt, autonomes Fahren)
|
||||
\item
|
||||
echtzeitfähige Scheduler, Hauptspeicherverwaltung, Ereignismanagement,
|
||||
Umgangmit Überlast und Prioritätsumkehr ...
|
||||
\item
|
||||
$\rightarrow$ unterschiedliche Ressourcenverwaltung
|
||||
aufgrund unterschiedlicher nichtfunktionaler Eigenschaften
|
||||
\item Einst: Batch-Betriebssysteme, Stapelverarbeitung von Jobs (FIFO)
|
||||
\item Heute: Echtzeitgarantien für Multimedia und Safety-kritische Anwendungen
|
||||
\item echtzeitfähige Scheduler, Hauptspeicherverwaltung, Ereignismanagement, Umgang mit Überlast und Prioritätsumkehr ...
|
||||
\item $\rightarrow$ unterschiedliche Ressourcenverwaltung aufgrund unterschiedlicher nichtfunktionaler Eigenschaften
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsubsection{Betriebssystemabstraktionen}
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
zusätzliche Abstraktionen und deren Verwaltung ...
|
||||
\item zusätzliche Abstraktionen und deren Verwaltung zur ...
|
||||
\begin{itemize*}
|
||||
\item ... zur Reservierung von Ressourcen (\$\textbackslash rightarrow\$ eingebettete Systeme)
|
||||
\item ... zur Realisierung von QoS-Anforderungen (\$\textbackslash rightarrow\$ Multimediasysteme)
|
||||
\item ... zur Erhöhung der Ausfallsicherheit (\$\textbackslash rightarrow\$ verfügbarkeitskritische Systeme)
|
||||
\item ... zum Schutz vor Angriffen und Missbrauch (\$\textbackslash rightarrow\$ sicherheitskritische Systeme)
|
||||
\item ... zum flexiblen und modularen Anpassen des Betriebssystems (\$\textbackslash rightarrow\$ hochadaptive Systeme)
|
||||
\item Reservierung von Ressourcen ( $\rightarrow$ eingebettete Systeme)
|
||||
\item Realisierung von QoS-Anforderungen ( $\rightarrow$ Multimediasysteme)
|
||||
\item Erhöhung der Ausfallsicherheit ( $\rightarrow$ verfügbarkeitskritische Systeme)
|
||||
\item Schutz vor Angriffen und Missbrauch ( $\rightarrow$ sicherheitskritische Systeme)
|
||||
\item flexiblen und modularen Anpassen des Betriebssystems ( $\rightarrow$ hochadaptive Systeme)
|
||||
\end{itemize*}
|
||||
\item
|
||||
$\rightarrow$ höchst diverse Abstraktionen von
|
||||
Hardware aufgrund unterschiedlicher nichtfunktionaler Eigenschaften
|
||||
\item $\rightarrow$ höchst diverse Abstraktionen von Hardware aufgrund unterschiedlicher nichtfunktionaler Eigenschaften
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsubsection{Betriebssysteme als
|
||||
Softwareprodukte}
|
||||
|
||||
\subsubsection{Betriebssysteme als Softwareprodukte}
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Betriebssystem:
|
||||
\item Betriebssystem:
|
||||
\begin{itemize*}
|
||||
\item eine endliche Menge von Quellcode, indiziert durch Zeilennummern: MACOSX = \$\{0, 1, 2, ..., 4399822, ...\}\$
|
||||
\item ein komplexes Softwareprodukt ...welches insbesondere allgemeinen Qualitätsanforderungen an den Lebenszyklusvon Softwareprodukten unterliegt!
|
||||
\item eine endliche Menge von Quellcode
|
||||
\item ein komplexes Softwareprodukt
|
||||
\end{itemize*}
|
||||
\item
|
||||
an jedes Softwareprodukt gibt es Anforderungen an seine Nutzung und
|
||||
Pflege $\rightarrow$ Evolutionseigenschaften
|
||||
\item
|
||||
diese können für Betriebssysteme höchst speziell sein
|
||||
(Korrektheitsverifikation, Wartung, Erweiterung, ...)
|
||||
\item
|
||||
$\rightarrow$ spezielle Anforderungen an das
|
||||
Softwareprodukt Betriebssystem aufgrund unterschiedlicher
|
||||
nichtfunktionaler Eigenschaften
|
||||
\item Anforderungen an Nutzung und Pflege $\rightarrow$ Evolutionseigenschaften
|
||||
\item können für Betriebssysteme höchst speziell sein (Korrektheitsverifikation, Wartung, Erweiterung, ...)
|
||||
\item $\rightarrow$ spezielle Anforderungen an das Softwareprodukt Betriebssystem aufgrund unterschiedlicher nichtfunktionaler Eigenschaften
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{NFE von Betriebssystemen}
|
||||
|
||||
Funktionale Eigenschaften (= Funktionen, Aufgaben) ... von
|
||||
Betriebssystemen:
|
||||
|
||||
Funktionale Eigenschaften (= Funktionen, Aufgaben) ...
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Betriebssysteme: sehr komplexe Softwareprodukte
|
||||
\item
|
||||
Ein Grund hierfür: besitzen Reihe von differenzierten Aufgaben - also
|
||||
funktionale Eigenschaften
|
||||
\item Betriebssysteme: sehr komplexe Softwareprodukte
|
||||
\item Ein Grund hierfür: besitzen Reihe von differenzierten Aufgaben - also funktionale Eigenschaften
|
||||
\end{itemize*}
|
||||
|
||||
Grundlegende funktionale Eigenschaften von Betriebssystemen:
|
||||
|
||||
\begin{enumerate*}
|
||||
\item
|
||||
\textbf{Hardware-Abstraktion} (Anwendungen/Programmierern eine
|
||||
angenehme Ablaufumgebung auf Basis der Hardware bereitstellen)
|
||||
\item
|
||||
\textbf{Hardware-Multiplexing} (gemeinsame Ablaufumgebung zeitlich
|
||||
oder logisch getrennt einzelnen Anwendungen zuteilen)
|
||||
\item
|
||||
\textbf{Hardware-Schutz} (gemeinsame Ablaufumgebung gegen Fehler und
|
||||
Manipulation durch Anwendungen schützen)
|
||||
\item \textbf{Hardware-Abstraktion} (Anwendungen/Programmierern eine angenehme Ablaufumgebung auf Basis der Hardware bereitstellen)
|
||||
\item \textbf{Hardware-Multiplexing} (gemeinsame Ablaufumgebung zeitlich oder logisch getrennt einzelnen Anwendungen zuteilen)
|
||||
\item \textbf{Hardware-Schutz} (gemeinsame Ablaufumgebung gegen Fehler und Manipulation durch Anwendungen schützen)
|
||||
\end{enumerate*}
|
||||
|
||||
Nichtfunktionale Eigenschaften (Auswahl) von Betriebssystemen:
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Laufzeiteigenschaften
|
||||
\item Laufzeiteigenschaften
|
||||
\begin{itemize*}
|
||||
\item Sparsamkeit und Effizienz
|
||||
\item Robustheit
|
||||
@ -364,8 +217,7 @@
|
||||
\item Adaptivität
|
||||
\item Performanz
|
||||
\end{itemize*}
|
||||
\item
|
||||
Evolutionseigenschaften
|
||||
\item Evolutionseigenschaften
|
||||
\begin{itemize*}
|
||||
\item Wartbarkeit
|
||||
\item Portierbarkeit
|
||||
@ -375,72 +227,42 @@
|
||||
\end{itemize*}
|
||||
|
||||
Klassifizierung: Nichtfunktionale Eigenschaften unterteilbar in:
|
||||
|
||||
\begin{enumerate*}
|
||||
\item
|
||||
Laufzeiteigenschaften (execution qualities)
|
||||
\item Laufzeiteigenschaften (execution qualities)
|
||||
\begin{itemize*}
|
||||
\item zur Laufzeit eines Systems beobachtbar
|
||||
\item Beispiele: ,,security'' (Sicherheit), ,,usability'' (Benutzbarkeit), ,,performance'' (Performanz), ...
|
||||
\end{itemize*}
|
||||
\item
|
||||
Evolutionseigenschaften (evolution qualities)
|
||||
\item Evolutionseigenschaften (evolution qualities)
|
||||
\begin{itemize*}
|
||||
\item charakterisieren (Weiter-) Entwicklung- und Betrieb eines Systems
|
||||
\item Beispiele: ,,testability'' (Testbarkeit), ,,extensibility'' (Erweiterbarkeit) usw.
|
||||
\end{itemize*}
|
||||
\item liegen in statischer Struktur eines Softwaresystems begründet
|
||||
\end{enumerate*}
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
liegen in statischer Struktur eines Softwaresystems begründet
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{Inhalte der Vorlesung}
|
||||
|
||||
Auswahl sehr häufiger NFE von Betriebssystemen:
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Sparsamkeit und Effizienz
|
||||
\item
|
||||
Robustheit
|
||||
\item
|
||||
Verfügbarkeit
|
||||
\item
|
||||
Sicherheit (Security)
|
||||
\item
|
||||
Echtzeitfähigkeit
|
||||
\item
|
||||
Adaptivität
|
||||
\item
|
||||
Performanz
|
||||
\item Sparsamkeit und Effizienz
|
||||
\item Robustheit
|
||||
\item Verfügbarkeit
|
||||
\item Sicherheit (Security)
|
||||
\item Echtzeitfähigkeit
|
||||
\item Adaptivität
|
||||
\item Performanz
|
||||
\end{itemize*}
|
||||
|
||||
Diskussion jeder Eigenschaft: (Bsp.: Echtzeitfähigkeit)
|
||||
|
||||
Diskussion jeder Eigenschaft
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Motivation, Anwendungsgebiete, Begriffsdefinition(en) (Bsp.:
|
||||
Multimedia- und eingebettete Systeme)
|
||||
\item
|
||||
Mechanismen und Abstraktionen des Betriebssystems (Bsp.: Fristen,
|
||||
Deadline-Scheduler)
|
||||
\item
|
||||
unterstützende Betriebssystem-Architekturkonzepte (Bsp.: Mikrokernel)
|
||||
\item
|
||||
ein typisches Beispiel-Betriebssystem (Bsp.: QNX)
|
||||
\item
|
||||
Literaturliste
|
||||
\item Motivation, Anwendungsgebiete, Begriffsdefinition
|
||||
\item Mechanismen und Abstraktionen des Betriebssystems
|
||||
\item unterstützende Betriebssystem-Architekturkonzepte
|
||||
\item ein typisches Beispiel-Betriebssystem
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\section{Sparsamkeit und Effizienz}
|
||||
|
||||
|
||||
\subsection{Motivation}
|
||||
|
||||
Sparsamkeit (Arbeitsdefinition): Die Eigenschaft eines Systems, seine
|
||||
Funktion mit minimalem Ressourcenverbrauchauszuüben.
|
||||
|
||||
@ -769,7 +591,7 @@
|
||||
Energiebedarf baulich bedingter Leckströme
|
||||
\item
|
||||
Fortschreitende Hardware-Miniaturisierung
|
||||
\$\textbackslash Rightarrow\$ zunehmender Anteil von
|
||||
$\rightarrow$ zunehmender Anteil von
|
||||
\$P\_\{leakage\}\$ an P
|
||||
\item
|
||||
Beispielhafte Größenordnungen zum Einsparpotenzial: \textbar{}
|
||||
@ -1303,7 +1125,7 @@
|
||||
\item
|
||||
Adaptivität (zur Kompilier-und Laufzeit) des Kernels: gezielte
|
||||
Anpassung an sich ändernde Umgebungsbedingungen möglich
|
||||
(\$\textbackslash rightarrow\$ Cassini-Huygens-Mission)
|
||||
( $\rightarrow$ Cassini-Huygens-Mission)
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
@ -1397,7 +1219,7 @@
|
||||
\begin{itemize*}
|
||||
\item \cmark vglw. geringe Kosten von Kernelcode (Energie, Speicher)
|
||||
\item \cmark VMM nicht zwingend erforderlich
|
||||
\item \cmark Multitasking (\$\textbackslash rightarrow\$ Prozessmanagement!)nicht zwingend erforderlich
|
||||
\item \cmark Multitasking ( $\rightarrow$ Prozessmanagement!)nicht zwingend erforderlich
|
||||
\item \xmark Kernel (inkl. Treibern) jederzeit im Speicher
|
||||
\item \xmark Robustheit, Sicherheit, Adaptivität
|
||||
\end{itemize*}
|
||||
@ -1405,7 +1227,7 @@
|
||||
Mikrokernel:
|
||||
\begin{itemize*}
|
||||
\item \cmark Robustheit, Sicherheit, Adaptivität
|
||||
\item \cmark Kernelspeicherbedarf gering, Serverprozesse nur wenn benötigt (\$\textbackslash rightarrow\$ Adaptivität)
|
||||
\item \cmark Kernelspeicherbedarf gering, Serverprozesse nur wenn benötigt ( $\rightarrow$ Adaptivität)
|
||||
\item \xmark hohe IPC-Kosten von Serverprozessen
|
||||
\item \xmark Kontextwechselkosten von Serverprozessen
|
||||
\item \xmark VMM, Multitasking i.d.R. erforderlich
|
||||
@ -1424,7 +1246,7 @@
|
||||
\item ,,TinyOS'' ist ein quelloffenes, BSD-lizenziertes Betriebssystem
|
||||
\item das für drahtlose Geräte mit geringem Stromverbrauch, wie sie in
|
||||
\begin{itemize*}
|
||||
\item Sensornetzwerke, (\$\textbackslash rightarrow\$ Smart Dust)
|
||||
\item Sensornetzwerke, ( $\rightarrow$ Smart Dust)
|
||||
\item Allgegenwärtiges Computing,
|
||||
\item Personal Area Networks,
|
||||
\item intelligente Gebäude,
|
||||
@ -1445,7 +1267,7 @@
|
||||
\item $\rightarrow$ keine Kontextwechsel bei Taskwechsel
|
||||
\item Multitasking realisiert durch Programmiermodell
|
||||
\item nicht-präemptives FIFO-Scheduling
|
||||
\item kein Paging\$\textbackslash rightarrow\$ keine Seitentabellen, keine MMU
|
||||
\item kein Paging $\rightarrow$ keine Seitentabellen, keine MMU
|
||||
\end{itemize*}
|
||||
\item
|
||||
in Zahlen:
|
||||
@ -1661,7 +1483,7 @@
|
||||
\item
|
||||
Umgang mit ...
|
||||
\begin{itemize*}
|
||||
\item faults: \begin{itemize*} \item Korrektheit testen \item Korrektheit beweisen(\$\textbackslash rightarrow\$ formale Verifikation) \end{itemize*}
|
||||
\item faults: \begin{itemize*} \item Korrektheit testen \item Korrektheit beweisen( $\rightarrow$ formale Verifikation) \end{itemize*}
|
||||
\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*}
|
||||
@ -1807,7 +1629,7 @@
|
||||
klar definierte Modulschnittstellen(z.B. virtualfilesystem, VFS )
|
||||
\item
|
||||
Module zur Kernellaufzeit dynamisch einbindbar
|
||||
(\$\textbackslash rightarrow\$ Adaptivität)
|
||||
( $\rightarrow$ Adaptivität)
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
@ -2048,7 +1870,7 @@
|
||||
IPC-und E/A-Dienste, einschließlich Gerätetreiber
|
||||
\end{enumerate*}
|
||||
|
||||
unterstützte Abstraktionen (\$\textbackslash rightarrow\$ API,
|
||||
unterstützte Abstraktionen ( $\rightarrow$ API,
|
||||
Systemaufrufe):
|
||||
|
||||
\begin{enumerate*}
|
||||
@ -2211,7 +2033,7 @@
|
||||
\begin{enumerate*}
|
||||
\item
|
||||
System interaktive und nicht vollständig vertrauenswürdige
|
||||
Applikationen unterstützen (\$\textbackslash rightarrow\$ HW-Schutz,
|
||||
Applikationen unterstützen ( $\rightarrow$ HW-Schutz,
|
||||
-Multiplexing),
|
||||
\item
|
||||
Hardware mit virtueller Speicherverwaltung und Paging
|
||||
@ -2632,13 +2454,13 @@
|
||||
\item
|
||||
Beziehung:
|
||||
\begin{itemize*}
|
||||
\item Verbesserung von Robustheit \$\textbackslash Rightarrow\$ Verbesserung von Verfügbarkeit
|
||||
\item Verbesserung von Robustheit $\rightarrow$ Verbesserung von Verfügbarkeit
|
||||
\item Robustheitsmaßnahmen hinreichend , nicht notwendig (hochverfügbare Systeme können sehr wohl von Ausfällen betroffen sein...)
|
||||
\end{itemize*}
|
||||
\item
|
||||
eine weitere komplementäre NFE:
|
||||
\begin{itemize*}
|
||||
\item Robustheit \$\textbackslash Rightarrow\$ Sicherheit (security)
|
||||
\item Robustheit $\rightarrow$ Sicherheit (security)
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
@ -2848,7 +2670,7 @@
|
||||
\item
|
||||
illegitime Ressourcennutzung, Ziel i.d.R.: hocheffektive Folgeangriffe
|
||||
\item
|
||||
Manipulationvon Inhalten (\$\textbackslash rightarrow\$
|
||||
Manipulationvon Inhalten ( $\rightarrow$
|
||||
Desinformation)
|
||||
\end{itemize*}
|
||||
|
||||
@ -2861,9 +2683,9 @@
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Verlust der Kontrolle über kritisches Wissen
|
||||
(\$\textbackslash rightarrow\$ Risikotechnologien)
|
||||
( $\rightarrow$ Risikotechnologien)
|
||||
\item
|
||||
immense wirtschaftliche Schäden (\$\textbackslash rightarrow\$
|
||||
immense wirtschaftliche Schäden ( $\rightarrow$
|
||||
Technologieführer, Patentinhaber)
|
||||
\item
|
||||
z.B. Diebstahl von industriellem Know-How
|
||||
@ -2892,7 +2714,7 @@
|
||||
Registrierkassen)
|
||||
\item
|
||||
Erpressung von ausgewählten (oder schlicht großen ) Zielgruppen durch
|
||||
vollendete, reversible Sabotage (\$\textbackslash rightarrow\$
|
||||
vollendete, reversible Sabotage ( $\rightarrow$
|
||||
Verschlüsselung von Endanwenderinformationen)
|
||||
\end{itemize*}
|
||||
|
||||
@ -3008,7 +2830,7 @@
|
||||
\item
|
||||
physisch, organisatorisch, infrastrukturell
|
||||
\item
|
||||
menschlich (\$\textbackslash rightarrow\$ Erpressung,
|
||||
menschlich ( $\rightarrow$ Erpressung,
|
||||
socialengineering )
|
||||
\end{itemize*}
|
||||
|
||||
@ -3027,7 +2849,7 @@
|
||||
|
||||
Beides führt zu operationellen Risiken beim Betrieb eines IT-Systems
|
||||
|
||||
\$\textbackslash rightarrow\$ Aufgabe der Betriebssystemsicherheit:
|
||||
$\rightarrow$ Aufgabe der Betriebssystemsicherheit:
|
||||
Auswirkungen operationeller Risiken reduzieren (wo diese nicht vermieden
|
||||
werden können...)
|
||||
|
||||
@ -3050,7 +2872,7 @@
|
||||
\textbar{} \textbar{} Sicherheitsziele \textbar{} Welche
|
||||
Sicherheitsanforderungen muss das Betriebssystem erfüllen? \textbar{}
|
||||
\textbar{} Sicherheitspolitik \textbar{} Durch welche Strategien soll es
|
||||
diese erfüllen? (\$\textbackslash rightarrow\$ Regelwerk) \textbar{}
|
||||
diese erfüllen? ( $\rightarrow$ Regelwerk) \textbar{}
|
||||
\textbar{} Sicherheitsmechanismen \textbar{} Wie implementiert das
|
||||
Betriebssystem seine Sicherheitspolitik? \textbar{} \textbar{}
|
||||
Sicherheitsarchitektur \textbar{} Wo implementiert das Betriebssystem
|
||||
@ -3181,7 +3003,7 @@
|
||||
jedes Objekt hat einen Eigentümer
|
||||
\item
|
||||
Eigentümer legen Zugriffsrechte an Objekten fest
|
||||
(\$\textbackslash rightarrow\$ DAC)
|
||||
( $\rightarrow$ DAC)
|
||||
\item
|
||||
es gibt drei Zugriffsrechte: read, write, execute
|
||||
\item
|
||||
@ -3243,7 +3065,7 @@
|
||||
Änderungsbeispiel: kühnhauser nimmt krause in Gruppe vsbs auf ...
|
||||
\item
|
||||
Rechteausbreitung ( privilegeescalation ), hier verursacht durch eine
|
||||
legale Nutzeraktion (\$\textbackslash rightarrow\$ DAC)
|
||||
legale Nutzeraktion ( $\rightarrow$ DAC)
|
||||
\begin{itemize*}
|
||||
\item (Sicherheitseigenschaft: HRU Safety , $\rightarrow$ ,,Systemsicherheit'')
|
||||
\end{itemize*}
|
||||
@ -3271,10 +3093,10 @@
|
||||
\item
|
||||
sämtliche DAC-Zugriffsrechte (die gibt es auch) müssen mit einer
|
||||
Hierarchie der Integritätsklassen konsistent sein
|
||||
(\$\textbackslash rightarrow\$ ein bisschen MAC)
|
||||
( $\rightarrow$ ein bisschen MAC)
|
||||
\item
|
||||
Nutzer können diese Konsistenzanforderung selektiv außer Kraft setzen
|
||||
(\$\textbackslash rightarrow\$ DAC)
|
||||
( $\rightarrow$ DAC)
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
@ -3320,7 +3142,7 @@
|
||||
{[}BeLa76{]}
|
||||
\item
|
||||
elevation-Mechanismus: verändert nach Nutzeranfrage
|
||||
(\$\textbackslash rightarrow\$ DAC) sowohl acm als auch
|
||||
( $\rightarrow$ DAC) sowohl acm als auch
|
||||
\$\textbackslash leq\textbackslash rightarrow\$ konsistenzerhaltend?
|
||||
\item
|
||||
andere BS-Operationen: verändern unmittelbar nur acm (z.B. mittels
|
||||
@ -3359,7 +3181,7 @@
|
||||
Rechten assoziieren $\rightarrow$ Implementierung der
|
||||
Zugriffsmatrix ( acm ), diese ist:
|
||||
\begin{itemize*}
|
||||
\item groß (\$\textbackslash rightarrow\$ Dateianzahl auf Fileserver)
|
||||
\item groß ( $\rightarrow$ Dateianzahl auf Fileserver)
|
||||
\item dünn besetzt
|
||||
\item in Größe und Inhalt dynamisch veränderlich
|
||||
\item $\rightarrow$ effiziente Datenstruktur?
|
||||
@ -3449,7 +3271,7 @@
|
||||
\begin{itemize*}
|
||||
\item
|
||||
jeder Nutzer wird durch Eintrag in einer Systemdatei ( /etc/group )
|
||||
einer oder mehreren Gruppen zugeordnet(\$\textbackslash rightarrow\$
|
||||
einer oder mehreren Gruppen zugeordnet( $\rightarrow$
|
||||
ACL: ,, g '' Rechte)
|
||||
\end{itemize*}
|
||||
|
||||
@ -3561,7 +3383,7 @@
|
||||
Programmeigentümers (im Bsp.: root ) seine Rechte bestimmt
|
||||
\item
|
||||
Technik: eine von UID abweichende Prozess-Metainformation
|
||||
(\$\textbackslash rightarrow\$ PCB) effektive UID (eUID) wird
|
||||
( $\rightarrow$ PCB) effektive UID (eUID) wird
|
||||
tatsächlich zur Autorisierung genutzt
|
||||
\item
|
||||
\texttt{-rws\ rws\ r-x\ 1\ root\ root\ 2\ 2011-10-01\ 16:00\ print}
|
||||
@ -3728,7 +3550,7 @@
|
||||
\subparagraph{Autorisierungsregeln}
|
||||
|
||||
... werden systemweit festgelegt in dessen Sicherheitspolitik
|
||||
(\$\textbackslash rightarrow\$ MAC):
|
||||
( $\rightarrow$ MAC):
|
||||
|
||||
Access Vector Rules
|
||||
|
||||
@ -3790,7 +3612,7 @@
|
||||
Ergebnis:
|
||||
\begin{itemize*}
|
||||
\item \cmark extrem feingranulare, anwendungsspezifische Sicherheitspolitik zur Vermeidung von privilege escalation Angriffen
|
||||
\item \cmark obligatorische Durchsetzung (\$\textbackslash rightarrow\$ MAC, zusätzlich zu Standard-Unix-DAC)
|
||||
\item \cmark obligatorische Durchsetzung ( $\rightarrow$ MAC, zusätzlich zu Standard-Unix-DAC)
|
||||
\item O Softwareentwicklung: Legacy-Linux-Anwendungen laufen ohne Einschränkung, jedoch
|
||||
\item \xmark Politikentwicklung und -administrationkomplex!
|
||||
\end{itemize*}
|
||||
@ -3800,7 +3622,7 @@
|
||||
\subparagraph{Weitere Informationen zu
|
||||
SELinux}
|
||||
|
||||
\$\textbackslash rightarrow\$ MAC-Mechanismen ala SELinux sind
|
||||
$\rightarrow$ MAC-Mechanismen ala SELinux sind
|
||||
heutzutage in vielerlei Software bereits zu finden:
|
||||
|
||||
\begin{itemize*}
|
||||
@ -4394,7 +4216,7 @@
|
||||
\item
|
||||
typisch für
|
||||
\begin{itemize*}
|
||||
\item unregelmäßig auftretende Ereignisse, z.B.: \begin{itemize*} \item Überfahren der Spurgrenzen, Unterschreiten des Sicherheitsabstands $\rightarrow$ Reaktion des Fahrassistenzsystems \item Nutzereingaben in Multimediasystemen (\$\textbackslash rightarrow\$ Spielkonsole) \end{itemize*}
|
||||
\item unregelmäßig auftretende Ereignisse, z.B.: \begin{itemize*} \item Überfahren der Spurgrenzen, Unterschreiten des Sicherheitsabstands $\rightarrow$ Reaktion des Fahrassistenzsystems \item Nutzereingaben in Multimediasystemen ( $\rightarrow$ Spielkonsole) \end{itemize*}
|
||||
\end{itemize*}
|
||||
\item
|
||||
Prozessaktivierung
|
||||
@ -4500,7 +4322,7 @@
|
||||
\end{itemize*}
|
||||
\begin{enumerate*}
|
||||
|
||||
\item Wie müssen die Ressourcen verwaltet werden? (\$\textbackslash rightarrow\$ CPU, Speicher, E/A, ...)
|
||||
\item Wie müssen die Ressourcen verwaltet werden? ( $\rightarrow$ CPU, Speicher, E/A, ...)
|
||||
\item Sind neue Abstraktionen, Paradigmen (Herangehensweisen) und entsprechende Komponenten erforderlich (oder günstig)?
|
||||
\end{enumerate*}
|
||||
\item
|
||||
@ -4694,9 +4516,9 @@
|
||||
\end{itemize*}
|
||||
\item Beweis: Obere Auslastungsgrenze bei EDF
|
||||
\begin{itemize*}
|
||||
\item Behauptung: Jede Menge von n periodischen Tasks ist mit EDF planbar \$\textbackslash Leftrightarrow\$: \$U=\textbackslash sum\_\{i=1\}\^{}n \textbackslash frac\{C\_i\}\{T\_i\}\textbackslash leq 1\$
|
||||
\item \$\textbackslash Leftarrow\$: \$U\textgreater1\$ übersteigt die verfügbare Prozessorzeit; folglich kann niemals eine Prozessmenge mit dieser (oder höherer) Gesamtauslastung planbar sein.
|
||||
\item \$\textbackslash Rightarrow\$: Beweis durch Widerspruch. Annahme: \$U\textbackslash leq 1\$ und die Prozessmenge ist nicht planbar. Dies führt zu einem Schedule mit Fristverletzung zu einem Zeitpunkt \$t\_2\$, z.B.:
|
||||
\item Behauptung: Jede Menge von n periodischen Tasks ist mit EDF planbar $\leftrightarrow$: \$U=\textbackslash sum\_\{i=1\}\^{}n \textbackslash frac\{C\_i\}\{T\_i\}\textbackslash leq 1\$
|
||||
\item $\leftarrow$: \$U\textgreater1\$ übersteigt die verfügbare Prozessorzeit; folglich kann niemals eine Prozessmenge mit dieser (oder höherer) Gesamtauslastung planbar sein.
|
||||
\item $\rightarrow$: Beweis durch Widerspruch. Annahme: \$U\textbackslash leq 1\$ und die Prozessmenge ist nicht planbar. Dies führt zu einem Schedule mit Fristverletzung zu einem Zeitpunkt \$t\_2\$, z.B.:
|
||||
%\begin{itemize*} \item \includegraphics{Assets/AdvancedOperatingSystems-echtzeit-scheduling-edf2.png} \end{itemize*}
|
||||
\item Beobachtungen an diesem Schedule:
|
||||
\begin{itemize*}
|
||||
@ -5144,7 +4966,7 @@
|
||||
\item
|
||||
Hauptrisiko: kritische Prozesse können Fristen nicht einhalten
|
||||
$\rightarrow$ Gefährdung funktionaler und anderer
|
||||
nichtfkt. Eigenschaften (\$\textbackslash rightarrow\$ harte Fristen!)
|
||||
nichtfkt. Eigenschaften ( $\rightarrow$ harte Fristen!)
|
||||
\item
|
||||
Stichwort: ,,graceful degradation'' (,,würdevolle'' Verschlechterung)
|
||||
statt unkontrollierbarer Situation $\rightarrow$
|
||||
@ -5266,7 +5088,7 @@
|
||||
\begin{enumerate*}
|
||||
|
||||
\item keine Ressourcen-Zuordnung ,,on-demand'' (d.h. in dem Moment, wo sie benötigt werden) sondern ,,Pre-Allokation'' (= Vorab-Zuordnung)
|
||||
\item keine dynamische Ressourcenzuordnung (z.B. Hauptspeicher), sondern Zuordnung maximal benötigter Menge bei Pre-Allokation (\$\textbackslash rightarrow\$ BS mit ausschließlich statischer Hauptspeicherallokation: TinyOS)
|
||||
\item keine dynamische Ressourcenzuordnung (z.B. Hauptspeicher), sondern Zuordnung maximal benötigter Menge bei Pre-Allokation ( $\rightarrow$ BS mit ausschließlich statischer Hauptspeicherallokation: TinyOS)
|
||||
\end{enumerate*}
|
||||
\end{itemize*}
|
||||
|
||||
@ -5306,7 +5128,7 @@
|
||||
\item
|
||||
Primärziel: Wahrung der Echtzeitgarantien
|
||||
\begin{itemize*}
|
||||
\item naheliegend: EA-Schedulingnach Fristen \$\textbackslash Rightarrow\$ EDF (wie Prozessor)
|
||||
\item naheliegend: EA-Schedulingnach Fristen $\rightarrow$ EDF (wie Prozessor)
|
||||
\item für Zugriffsreihenfolge auf Datenblöcke: lediglich deren Fristen maßgebend (weitere Regeln existieren nicht!)
|
||||
\end{itemize*}
|
||||
\item
|
||||
@ -5330,7 +5152,7 @@
|
||||
\end{enumerate*}
|
||||
\end{itemize*}
|
||||
|
||||
\$\textbackslash rightarrow\$ realisierte Strategien:
|
||||
$\rightarrow$ realisierte Strategien:
|
||||
|
||||
\begin{enumerate*}
|
||||
\item
|
||||
@ -5552,7 +5374,7 @@
|
||||
\item modularer Makrokernel
|
||||
\item Konkurrenzprodukt zu VRTX
|
||||
\item Erfolgsfaktor: POSIX-konforme API
|
||||
\item ähnlich QNX: ,,skalierbarer'' Kernel,zuschneidbarauf Anwendungsdomäne (\$\textbackslash rightarrow\$ Adaptivitätsansatz)
|
||||
\item ähnlich QNX: ,,skalierbarer'' Kernel,zuschneidbarauf Anwendungsdomäne ( $\rightarrow$ Adaptivitätsansatz)
|
||||
\end{itemize*}
|
||||
\item
|
||||
Anwendung:
|
||||
@ -5621,7 +5443,7 @@
|
||||
$\rightarrow$ Adaptivität als komplementäre NFE zur
|
||||
Förderung von
|
||||
\begin{itemize*}
|
||||
\item Robustheit: funktionale Adaptivitätdes BS reduziert Kernelkomplexität (\$\textbackslash rightarrow\$ kleiner, nicht adaptiver $\mu$Kernel)
|
||||
\item Robustheit: funktionale Adaptivitätdes BS reduziert Kernelkomplexität ( $\rightarrow$ kleiner, nicht adaptiver $\mu$Kernel)
|
||||
\item Sicherheit: wie Robustheit:TCB-Größe $\rightarrow$ Verifizierbarkeit, außerdem: adaptive Reaktion auf Bedrohungen
|
||||
\item Echtzeitfähigkeit: adaptive Scheduling-Strategie (vgl. RC), adapt. Überlastbehandlung, adapt. Interruptbehandlungs-und Pinning-Strategien
|
||||
\item Performanz: Last-und Hardwareadaptivität
|
||||
@ -5720,7 +5542,7 @@
|
||||
\item
|
||||
Funktion des Exokernels:
|
||||
\begin{itemize*}
|
||||
\item Prinzip: definiert Low-level-Schnittstelle \begin{itemize*} \item ,,low-level'' = so hardwarenah wie möglich, bspw. die logische Schnittstelle eines elektronischen Schaltkreises/ICs (\$\textbackslash rightarrow\$ Gerätetreiber \$\textbackslash subseteq\$ Library-BS!) \item Bsp.: der Exokernelmuss den Hauptspeicher schützen, aber nicht verstehen, wie dieser verwaltet wird $\rightarrow$ Adressierung ermöglichen ohne Informationen über Seiten, Segmente, Paging-Attribute, ... \end{itemize*}
|
||||
\item Prinzip: definiert Low-level-Schnittstelle \begin{itemize*} \item ,,low-level'' = so hardwarenah wie möglich, bspw. die logische Schnittstelle eines elektronischen Schaltkreises/ICs ( $\rightarrow$ Gerätetreiber \$\textbackslash subseteq\$ Library-BS!) \item Bsp.: der Exokernelmuss den Hauptspeicher schützen, aber nicht verstehen, wie dieser verwaltet wird $\rightarrow$ Adressierung ermöglichen ohne Informationen über Seiten, Segmente, Paging-Attribute, ... \end{itemize*}
|
||||
\item Library-Betriebssysteme: implementieren darauf jeweils geeignete anwendungsnahe Abstraktionen \begin{itemize*} \item Bsp.: Adressraumsemantik, Seitentabellenlayout und -verwaltung, Paging-und Locking-Verfahren, ... \end{itemize*}
|
||||
\item Anwendungsprogrammierer: wählen geeignete Library-Betriebssysteme bzw. schreiben ihre eigenen Exokernelmechanismen
|
||||
\end{itemize*}
|
||||
@ -5745,9 +5567,9 @@
|
||||
|
||||
\begin{itemize*}
|
||||
\item
|
||||
Schutzmechanismus, der Autorisierung (\$\textbackslash rightarrow\$
|
||||
Schutzmechanismus, der Autorisierung ( $\rightarrow$
|
||||
Library-BS)zur Benutzung einer Ressource von tatsächlicher Benutzung
|
||||
(\$\textbackslash rightarrow\$ Exokernel) trennt
|
||||
( $\rightarrow$ Exokernel) trennt
|
||||
\item
|
||||
implementiert für den Exokernelerforderliches Zuordnungswissenvon
|
||||
(HW-)Ressource zu Mangement-Code (der im Library-BS implementiert ist)
|
||||
@ -5782,7 +5604,7 @@
|
||||
\end{itemize*}
|
||||
\item
|
||||
Exokernel-Betriebssysteme: entziehen(überwiegend) Ressourcen
|
||||
,,sichtbar''\$\textbackslash rightarrow\$ Dialog zwischen Exokernel
|
||||
,,sichtbar'' $\rightarrow$ Dialog zwischen Exokernel
|
||||
und Library-BS
|
||||
\begin{itemize*}
|
||||
\item Vorteil: effizientes Management durch Library-BS möglich (z.B. Prozessor: nur tatsächlich benötigte Register werden bei Entzug gespeichert)
|
||||
@ -5816,7 +5638,7 @@
|
||||
\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 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 (\$\textbackslash 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*}
|
||||
|
||||
@ -5904,7 +5726,7 @@
|
||||
z.B. Library-BS zum Dateisystem-Management: C-FFS
|
||||
\begin{itemize*}
|
||||
\item hochperformant (im Vergleich mit Makrokernel-Dateisystem-Management)
|
||||
\item Abstraktionen und Operationen auf Exokernel-Basis (u.a.): Inodes, Verzeichnisse, physische Dateirelokation(\$\textbackslash rightarrow\$ zusammenhängendes Lesen)
|
||||
\item Abstraktionen und Operationen auf Exokernel-Basis (u.a.): Inodes, Verzeichnisse, physische Dateirelokation( $\rightarrow$ zusammenhängendes Lesen)
|
||||
\item Secure Bindings für Metadaten-Modifikation
|
||||
\end{itemize*}
|
||||
\item
|
||||
@ -5938,9 +5760,9 @@
|
||||
Ergebnisse:
|
||||
\begin{itemize*}
|
||||
\item hochperformanteHardwarebenutzung durch spezialisierte Anwendungen
|
||||
\item funktional kleiner Exokernel(\$\textbackslash rightarrow\$ Sparsamkeit, Korrektheit des Kernelcodes )
|
||||
\item funktional kleiner Exokernel( $\rightarrow$ Sparsamkeit, Korrektheit des Kernelcodes )
|
||||
\item flexible Nutzung problemgerechterHW-Abstraktionen ( readymade Lib. OS)
|
||||
\item keine Isolation von Anwendungen (\$\textbackslash rightarrow\$ Parallelisierbarkeit: teuer und mit schwachen Garantien; $\rightarrow$ Robustheit und Sicherheit der Anwendungen: nicht umsetzbar)
|
||||
\item keine Isolation von Anwendungen ( $\rightarrow$ Parallelisierbarkeit: teuer und mit schwachen Garantien; $\rightarrow$ Robustheit und Sicherheit der Anwendungen: nicht umsetzbar)
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
@ -6755,9 +6577,9 @@
|
||||
\item
|
||||
Ergebnis: Kombination von Vorteilen zweier Welten
|
||||
\begin{itemize*}
|
||||
\item Virtualisierungs vorteile: Sicherheit, Robustheit (\$\textbackslash rightarrow\$ Xen - Prinzip genau einer vertrauenswürdigen, isolierten Domäne \$dom\_0\$)
|
||||
\item Virtualisierungs vorteile: Sicherheit, Robustheit ( $\rightarrow$ Xen - Prinzip genau einer vertrauenswürdigen, isolierten Domäne \$dom\_0\$)
|
||||
\item Exokernelvorteile: Wartbarkeit, Sparsamkeit
|
||||
\item nicht: Exokernelvorteil der hardwarenahen Anwendungsentwicklung... (\$\textbackslash rightarrow\$ Performanz und Echzeitfähigkeit )
|
||||
\item nicht: Exokernelvorteil der hardwarenahen Anwendungsentwicklung... ( $\rightarrow$ Performanz und Echzeitfähigkeit )
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user