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