diff --git a/Advanced Operating Systems - Cheatsheet.pdf b/Advanced Operating Systems - Cheatsheet.pdf index b4dba59..b2f5f28 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:f386d1ee190661b563dbfe9f0411181f28922f910eac8d0ae54b4517e3fe52e1 -size 447145 +oid sha256:c1d753e70d2479266395d1a33a4f055bce5e958f82e096f504d0863bfe1c58b9 +size 435554 diff --git a/Advanced Operating Systems - Cheatsheet.tex b/Advanced Operating Systems - Cheatsheet.tex index 3033d88..661f8ef 100644 --- a/Advanced Operating Systems - Cheatsheet.tex +++ b/Advanced Operating Systems - Cheatsheet.tex @@ -266,7 +266,7 @@ \item Idee: Vorziehen möglichst vieler E/A-Anforderungen an Festplatte + zeitlich gleichmäßige Verteilung verbleibender \item Umsetzung: Caching dieser vorausschauend gelesenen Blöcke in ungenutzten PageCache \end{itemize*} - \item Folge: Inaktivität überwiegend sehr kurz $\rightarrow$ Energieeffizienz ...? + \item[$\rightarrow$] Inaktivität überwiegend sehr kurz $\rightarrow$ Energieeffizienz ...? \item Zugriffs-/Festplattenoperationen \begin{itemize*} \item access(x) ... greife auf Inhalt von Festplattenblock x im PageCache zu @@ -1365,793 +1365,332 @@ \end{itemize*} \subsection{Sicherheitspolitiken} - \begin{itemize*} - \item - Herausforderung: korrekte Durchsetzung von Sicherheitspolitiken - \item - Vorgehensweise: Security Engineering + \item Herausforderung: korrekte Durchsetzung von Sicherheitspolitiken + \item Vorgehensweise: Security Engineering \end{itemize*} + \begin{description} + \item[Sicherheitsziele] Welche Sicherheitsanforderungen muss BS erfüllen? + \item[Sicherheitspolitik] Durch welche Strategien soll es diese erfüllen? + \item[Sicherheitsmechanismen] Wie implementiert BS Sicherheitspolitik? + \item[Sicherheitsarchitektur] Wo implementiert BS S.-mechanismen? + \end{description} - | | | - ---------------------- - | - ----------------------------------------------------------------------------------------- - | | Sicherheitsziele | Welche - Sicherheitsanforderungen muss das Betriebssystem erfüllen? | - | Sicherheitspolitik | Durch welche Strategien soll es - diese erfüllen? ( $\rightarrow$ Regelwerk) | - | Sicherheitsmechanismen | Wie implementiert das - Betriebssystem seine Sicherheitspolitik? | | - Sicherheitsarchitektur | Wo implementiert das Betriebssystem - seine Sicherheitsmechanismen (und deren Interaktion)? | - - - \subparagraph{Sicherheitspolitiken und - -modelle} - - Kritischfür korrekten Entwurf, Spezifikation, Implementierung der - Betriebssystem-Sicherheitseigenschaften! - - Begriffsdefinitionen: - + \subsubsection{Sicherheitspolitiken und -modelle} + Kritisch für korrekten Entwurf, Spezifikation, Implementierung \begin{itemize*} - \item - Sicherheitspolitik (Security Policy): Eine Menge von Regeln, die zum - Erreichen eines Sicherheitsziels dienen. - \item - Sicherheitsmodell (Security Model): Die formale Darstellung einer - Sicherheitspolitik zum Zweck + \item Sicherheitspolitik (Policy): Menge von Regeln, zum Erreichen eines Sicherheitsziels + \item Sicherheitsmodell: formale Darstellung zur \begin{itemize*} - \item der Verifikation ihrer Korrektheit - \item der Spezifikation ihrer Implementierung. + \item Verifikation ihrer Korrektheit + \item Spezifikation ihrer Implementierung \end{itemize*} \end{itemize*} - - \subparagraph{Zugriffssteuerungspolitiken} - - ... geben Regeln vor, welche durch Zugriffssteuerungsmechanismen in BS - durchgesetzt werden müssen. - - Zugriffssteuerung (access control): Steuerung, welcher Nutzer oder - Prozess mittels welcher Operationen auf welche BS-Ressourcen zugreifen - darf (z.B.: Anwender darf Textdateien anlegen, Administrator darf - Dateisysteme montieren und System-Logdateien löschen, systemd - Prozess - darf Prozessdeskriptoren manipulieren, ...) - - Zugriffssteuerungspolitik: konkrete Regeln, welche die Zugriffssteuerung - in einem BS beschreiben - - Zugriffssteuerungsmodell: Sicherheitsmodell einer - Zugriffssteuerungspolitik - - Zugriffssteuerungsmechanismus: Implementierung einer - Zugriffssteuerungspolitik - - - \subparagraph{Beispiele für - BS-Zugriffssteuerungspolitiken} - - klassifiziert nach Semantik der Politikregeln: - - \begin{itemize*} - \item - IBAC (Identity-basedAccess Control): Politik spezifiziert, welcher - Nutzer an welchen Ressourcen bestimmte Rechte hat. + \subsubsection{Zugriffssteuerungspolitiken} + \begin{description*} + \item[Zugriffssteuerung] (access control) Steuerung, welcher Nutzer oder Prozess mittels welcher Operationen auf welche BS-Ressourcen zugreifen darf + \item[Zugriffssteuerungspolitik] konkrete Regeln, welche die Zugriffssteuerung in einem BS beschreiben + \item[IBAC] (Identity-based AC) Politik spezifiziert, welcher Nutzer an welchen Ressourcen bestimmte Rechte hat \begin{itemize*} - \item Bsp.: ,,Nutzer Anna darf Brief.docx lesen, aber nicht schreiben.'' + \item Bsp.: ,,Nutzer Anna darf Brief.docx lesen'' \end{itemize*} - \item - TE (Type-Enforcement): Politik spezifiziert Rechte durch zusätzliche - Abstraktion (Typen): welcher Nutzertyp an welchem Ressourcentyp - bestimmte Rechte hat. + \item[TE] (Type-Enforcement) Politik spezifiziert Rechte durch zusätzliche Abstraktion (Typen): welcher Nutzertyp an welchem Ressourcentyp bestimmte Rechte hat \begin{itemize*} - \item Bsp.: ,,Nutzer vom Typ Administrator dürfen Dateien vom Typ Log lesen und schreiben.'' + \item Bsp.: ,,Nutzer vom Typ Administrator darf...'' \end{itemize*} - \item - MLS (Multi-Level Security): Politik spezifiziert Rechte, indem aus - Nutzern und Ressourcen hierarchische Klassen (Ebenen, ,,Levels'') - gleicher Kritikalität im Hinblick auf Sicherheitsziele gebildet - werden. + \item[MLS] (Multi-Level Security) Politik spezifiziert Rechte, indem aus Nutzern und Ressourcen hierarchische Klassen (Ebenen, ,,Levels'') gleicher Kritikalität im Hinblick auf Sicherheitsziele gebildet werden \begin{itemize*} - \item Bsp.: ,,Nutzer der Klasse nicht vertrauenswürdig dürfen Dateien der Klasse vertraulich nicht lesen.'' + \item Bsp.: ,,Nutzer der Klasse nicht vertrauenswürdig...'' \end{itemize*} - \item - DAC (Discretionary Access Control, auch: wahlfreie Zugriffssteuerung - ): Aktionen der Nutzer setzen die Sicherheitspolitik (oder wesentliche - Teile davon) durch. Typisch: Begriff des Eigentümers von - BS-Ressourcen. + \item[DAC] (Discretionary AC): Aktionen der Nutzer setzen die Sicherheitspolitik durch. Typisch: Begriff des Eigentümers von BS-Ressourcen \begin{itemize*} - \item Bsp.: ,,Der Eigentümer einer Datei bestimmt (bzw. ändert), welcher Nutzer welche Rechte daran hat.'' + \item Bsp.: ,,Der Eigentümer einer Datei ändert...'' \end{itemize*} - \item - MAC (MandatoryAccess Control, auch: obligatorische Zugriffssteuerung - ): Keine Beteiligung der Nutzer an der Durchsetzungeiner (zentral - administrierten) Sicherheitspolitik. + \item[MAC] (Mandatory AC, obligatorische Zugriffssteuerung) Keine Beteiligung der Nutzer an der Durchsetzung einer (zentral administrierten) Sicherheitspolitik \begin{itemize*} - \item Bsp.: ,,Anhand ihres Dateisystempfads bestimmt das Betriebssystem, welcher Nutzer welche Rechte an einer Datei hat.'' + \item Bsp.: ,,Anhand des Dateisystempfads bestimmt BS...'' \end{itemize*} - \end{itemize*} - - - \subparagraph{Einige Beispiele ...} - - %\begin{longtable}[]{@{}lll@{}} - %\toprule - %& DAC & MAC\\ - %\midrule - %\endhead - %IBAC & Unixoide,Linux, Windows & Linux AppArmor, Mac OS - %Seatbelt\\ - %TE & - & SELinuxEnterprise Linux (RHEL), RedHat\\ - %MLS & Windows UAC & SELinux, TrustedBSD\\ - %\bottomrule - %\end{longtable} - - ... und ein Verdacht Eindruck der Effektivität von DAC: ,,[...] so - the theory goes. By extension, yes, there may be less malware, but that - will depend on whether users keep UAC enabled, which depends on whether - developers write software that works with it and that users stop viewing - prompts as fast-clicking exercises and actually consider whether an - elevation request is legitimate.'' (Jesper M. Johansson, TechNet - Magazine) - [https://technet.microsoft.com/en-us/library/2007.09.securitywatch.aspx, - Stand: 10.11.2017] - + \end{description*} \subsubsection{Traditionell: DAC, IBAC} - Auszug aus der Unix-Sicherheitspolitik: - \begin{itemize*} - \item - es gibt Subjekte (Nutzer, Prozesse) und Objekte (Dateien, Sockets ...) - \item - jedes Objekt hat einen Eigentümer - \item - Eigentümer legen Zugriffsrechte an Objekten fest - ( $\rightarrow$ DAC) - \item - es gibt drei Zugriffsrechte: read, write, execute - \item - je Objekt gibt es drei Klassen von Subjekten, für die individuell - Zugriffsrechte vergeben werden können: Eigentümer (,,u''), Gruppe - (,,g''), Rest der Welt (,,o'') + \item es gibt Subjekte (Nutzer/Prozesse) und Objekte (Dateien,\dots) + \item jedes Objekt hat einen Eigentümer + \item Eigentümer legen Zugriffsrechte an Objekten fest ($\rightarrow$ DAC) + \item es gibt drei Zugriffsrechte: read, write, execute + \item je Objekt gibt es drei Klassen von Subjekten, mit individuellen Zugriffsrechten: Eigentümer, Gruppe, Rest \end{itemize*} - In der Praxis: - + In der Praxis \begin{itemize*} - \item - identitätsbasierte (IBAC), wahlfreie Zugriffssteuerung (DAC) - \item - hohe individuelle Freiheit der Nutzer bei Durchsetzung der Politik - \item - hohe Verantwortung ( ,,Welche Nutzer werden jemals in Gruppe vsbs - sein...?'' ) + \item identitätsbasierte (IBAC), wahlfreie Zugriffssteuerung (DAC) + \item hohe individuelle Freiheit der Nutzer bei Durchsetzung der Politik + \item hohe Verantwortung \end{itemize*} - %\begin{Shaded} - %\begin{Highlighting}[] - %\ExtensionTok{{-}rw{-}}\NormalTok{ rw{-} r{-}{-} 1 amthor vsbs 397032 2017{-}11{-}19 12:12 paper.pdf} - %\end{Highlighting} - %\end{Shaded} - - - \subparagraph{Modellierung: - Zugriffsmatrix} - - %\begin{longtable}[]{@{}lllll@{}} - %\toprule - %acm & paper.pdf & aos-05.pptx & gutachten.tex & - %worse-engine\\ - %\midrule - %\endhead - %kühnhauser & rw & - & rw & rx\\ - %schlegel & rw & - & - & rx\\ - %amthor & rw & rw & - & rx\\ - %krause & r & - & - & -\\ - %\bottomrule - %\end{longtable} - + \subsubsection{Modellierung: Zugriffsmatrix} \begin{itemize*} - \item - acm (access control matrix): Momentaufnahme der globalen - Rechteverteilung zu einem definierten ,,Zeitpunkt t'' - \item - Korrektheitskriterium: Wie kann sich dies nach t möglicherweise - ändern...? (HRU-Sicherheitsmodell)[HaRU76] + \item Access Control Matrix (acm): Momentaufnahme der globalen Rechteverteilung zu einem definierten Zeitpunkt t + \item Korrektheitskriterium: Wie kann sich dies nach t möglicherweise ändern...? + \item Rechteausbreitung (privilege escalation): verursacht z.B. durch Nutzeraktion ($\rightarrow$ DAC) + \item Sicherheitseigenschaft: HRU Safety $\rightarrow$ Systemsicherheit \end{itemize*} - - \subparagraph{Modellkorrektheit: - Rechteausbreitung} - - \begin{itemize*} - \item - Änderungsbeispiel: kühnhauser nimmt krause in Gruppe vsbs auf ... - \item - Rechteausbreitung ( privilegeescalation ), hier verursacht durch eine - legale Nutzeraktion ( $\rightarrow$ DAC) - \begin{itemize*} - \item (Sicherheitseigenschaft: HRU Safety , $\rightarrow$ ,,Systemsicherheit'') - \end{itemize*} - \end{itemize*} - - \subsubsection{Modern: MAC, MLS} - - Sicherheitspolitik der Windows UAC ( user account control): - + Sicherheitspolitik der Windows UAC (user account control) \begin{itemize*} - \item - es gibt Subjekte (Prozesse) und Objekte (Dateisystemknoten) - \item - jedem Subjekt ist eine Integritätsklasse zugewiesen: - \begin{itemize*} - \item Low: nicht vertrauenswürdig (z.B. Prozesse aus ausführbaren Downloads) - \item Medium: reguläre Nutzerprozesse, die ausschließlich Nutzerdaten manipulieren - \item High: Administratorprozesse, die Systemdaten manipulieren können - \item System: (Hintergrund-) Prozesse, die ausschließlich Betriebssystemdienste auf Anwenderebene implementieren (etwa der Login-Manager) - \end{itemize*} - \item - jedem Objekt ist analog eine dieser Integritätsklassen zugewiesen - (Kritikalität von z.B. Nutzerdaten vs. Systemdaten) - \item - sämtliche DAC-Zugriffsrechte (die gibt es auch) müssen mit einer - Hierarchie der Integritätsklassen konsistent sein - ( $\rightarrow$ ein bisschen MAC) - \item - Nutzer können diese Konsistenzanforderung selektiv außer Kraft setzen - ( $\rightarrow$ DAC) + \item es gibt Subjekte (Prozesse) und Objekte (Dateisystemknoten) + \item jedem Subjekt ist eine Integritätsklasse zugewiesen: + \begin{description*} + \item[Low] nicht vertrauenswürdig + \item[Medium] reguläre Nutzerprozesse, die Nutzerdaten manipulieren + \item[High] Administratorprozesse, die Systemdaten manipulieren + \item[System] (Hintergrund-) Prozesse, die ausschließlich Betriebssystemdienste auf Anwenderebene implementieren + \end{description*} + \item jedem Objekt ist analog eine dieser Integritätsklassen zugewiesen + \item sämtliche DAC-Zugriffsrechte müssen mit einer Hierarchie der Integritätsklassen konsistent sein ( $\rightarrow$ MAC) + \item Nutzer können Konsistenzanforderung selektiv außer Kraft setzen ($\rightarrow$ DAC) \end{itemize*} + MAC-Modellierung: Klassenhierarchie - \subparagraph{MAC-Modellierung: - Klassenhierarchie} - - Beispiel: Modelliert durch Relation $\leq$: gleich oder - kritischer als - - $\leq=\{( High , Medium ), ( High , Low ), ( Medium , Low - ), ( High , High ), ( Medium , Medium ), ( Low , Low )\}$ - + Beispiel Relation: $\leq=\{(High,Medium), (High,Low), (Medium,Low), (High,High), (Low,Low)\}$ \begin{itemize*} - \item - repräsentiert Kritikalität hinsichtlich des Sicherheitsziels - Integrität (Biba-Sicherheitsmodell) [Biba77] - \item - wird genutzt, um legale Informationsflüsse zwischen Subjekten und - Objekten zu modellieren $\rightarrow$ Schutz vor - illegalem Überschreiben - \item - leitet Zugriffsrechte aus Informationsflüssen ab: - \begin{itemize*} - \item Prozess Datei: schreiben - \item Prozess Datei: lesen - \end{itemize*} + \item repräsentiert Kritikalität hinsichtlich der Integrität + \item modelliert legale Informationsflüsse zwischen Subjekten und Objekten $\rightarrow$ Schutz vor illegalem Überschreiben + \item leitet Zugriffsrechte aus Informationsflüssen ab: lesen/schreiben \end{itemize*} - - \subparagraph{DAC-Modellierung: - Zugriffsmatrix} - + %\subparagraph{DAC-Modellierung: Zugriffsmatrix} %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-dac-zugriffsmatrix.png} - - \subparagraph{Modellkorrektheit: - Konsistenz} - + \subparagraph{Modellkorrektheit: Konsistenz} \begin{itemize*} - \item - Korrektheitskriterium: Garantiert die Politik, dass acm mit - $\leq$ jederzeit konsistent ist? ( BLP Security ) - [BeLa76] - \item - elevation-Mechanismus: verändert nach Nutzeranfrage - ( $\rightarrow$ DAC) sowohl acm als auch - $\leq\rightarrow$ konsistenzerhaltend? - \item - andere BS-Operationen: verändern unmittelbar nur acm (z.B. mittels - Dateisystemmanagement) $\rightarrow$ - konsistenzerhaltend? + \item Korrektheitskriterium: Garantiert die Politik, dass acm mit $\leq$ jederzeit konsistent ist? ( BLP Security ) + \item elevation-Mechanismus: verändert nach Nutzeranfrage ($\rightarrow$ DAC) sowohl acm als auch $\leq\rightarrow$ konsistenzerhaltend? + \item anders: verändern unmittelbar nur acm $\rightarrow$ konsistenzerhaltend? \end{itemize*} - \subsection{Autorisierungsmechanismen} - - Begriffsdefinitionen: - \begin{itemize*} - \item - Sicherheitsmechanismen: Datenstrukturen und Algorithmen, welche die - Sicherheitseigenschaften eines Betriebssystems implementieren. + \item Sicherheitsmechanismen: Datenstrukturen und Algorithmen, welche Sicherheitseigenschaften eines BS implementieren + \item[$\rightarrow$] Sicherheitsmechanismen benötigt man zur Herstellung jeglicher Sicherheitseigenschaften + \item Auswahl im Folgenden: Autorisierungsmechanismen und -informationen \begin{itemize*} - \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, ...) - \item kryptografische Mechanismen (Verschlüsselungsalgorithmen, Hashfunktionen, ...) + \item Nutzerauthentisierung (Passwort-Hashing, ...) + \item Autorisierungsinformationen (Metainformationen...) + \item Autorisierungsmechanismen (Rechteprüfung, ...) + \item kryptografische Mechanismen (Hashfunktionen, ...) \end{itemize*} - \item - Auswahl im Folgenden: Autorisierungsmechanismen und -informationen \end{itemize*} - \subsubsection{Traditionell: ACLs, SUID} - Autorisierungsinformationen: - \begin{itemize*} - \item - müssen Subjekte (Nutzer) bzw. Objekte (Dateien, Sockets ...) mit - Rechten assoziieren $\rightarrow$ Implementierung der - Zugriffsmatrix ( acm ), diese ist: + \item müssen Subjekte (Nutzer) bzw. Objekte (Dateien, Sockets ...) mit Rechten assoziieren $\rightarrow$ Implementierung der Zugriffsmatrix (acm), diese ist: \begin{itemize*} - \item groß ( $\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? \end{itemize*} - \item - Lösung: verteilte Implementierung der acm als Spaltenvektoren, deren - Inhalt in den Objekt-Metadaten repräsentiert wird: - Zugriffssteuerungslisten ( Access Control Lists , ACLs) + \item Lösung: verteilte Implementierung der acm als Spaltenvektoren, deren Inhalt in den Objekt-Metadaten repräsentiert wird: Zugriffssteuerungslisten (ACLs) \end{itemize*} - - \subparagraph{ACLs: - Linux-Implementierung} - + \subparagraph{ACLs: Linux-Implementierung} \begin{itemize*} - \item - objektspezifischer Spaltenvektor = Zugriffssteuerungsliste - \item - Dateisystem-Metainformationen: implementiert in I-Nodes + \item objektspezifischer Spaltenvektor = Zugriffssteuerungsliste + \item Dateisystem-Metainformationen: implementiert in I-Nodes \end{itemize*} - %\begin{Shaded} - %\begin{Highlighting}[] - %\ExtensionTok{{-}rw{-}}\NormalTok{ rw{-} r{-}{-} 1 amthor vsbs 397032 2017{-}11{-}19 12:12 paper.pdf} - %\end{Highlighting} - %\end{Shaded} - - - \paragraph{ACLs: - Linux-Implementierung} - - Modell einer Unix acm ... | | lesen | - schreiben | ausführen | | - --------------------- | - ----- | --------- | - --------- | | Eigentümer (,,u'') - | ja | ja | ja | | Rest der - Welt (,,o'') | ja | nein | ja | - | Gruppe (,,g'') | ja | nein | ja - | - + Modell einer Unix acm ... + \begin{tabular}{c|c|c|c} + & lesen & schreiben & ausführen \\\hline + Eigentümer (u) & ja & ja & ja \\ + Gruppe (g) & ja & nein & ja \\ + Rest (o) & ja & nein & ja + \end{tabular} \begin{itemize*} - \item - 3 - elementige Liste - \item - 3 - elementige Rechtemenge - \item - $\rightarrow$ 9 Bits - \item - dessen Implementierung kodiert in 16-Bit-Wort: 1 1 1 1 0 1 1 0 1 - \item - ... und dessen Visualisierung in Linux: + \item 3-elementige Liste, 3-elementige Rechtemenge + \item[$\rightarrow$] 9 Bits + \item Implementierung kodiert in 16-Bit-Wort: 1 1 1 1 0 1 1 0 1 \end{itemize*} - %\begin{Shaded} - %\begin{Highlighting}[] - %\NormalTok{$ }\FunctionTok{ls}\NormalTok{ {-}alF} - %\ExtensionTok{drwxr{-}xr{-}x}\NormalTok{ 2 amthor amthor 4096 2017{-}11{-}16 12:01 ./} - %\ExtensionTok{drwxr{-}xr{-}x}\NormalTok{ 31 amthor amthor 4096 2017{-}11{-}07 12:42 ../} - %\ExtensionTok{{-}rw{-}rw{-}r{-}{-}}\NormalTok{ 1 amthor vsbs 397032 2017{-}11{-}19 12:12 paper.pdf} - %\ExtensionTok{{-}rw{-}{-}{-}{-}{-}{-}{-}}\NormalTok{ 1 amthor amthor 120064 2017{-}02{-}07 07:56 draft.tex} - %\end{Highlighting} - %\end{Shaded} - - - \subparagraph{Autorisierungsmechanismen: - ACL-Auswertung} - - Subjekte = Nutzermenge eines Linux-Systems... besteht aus Anzahl - registrierter Nutzer - + \subparagraph{Autorisierungsmechanismen: ACL-Auswertung} + Subjekte = Nutzermenge besteht aus Anzahl registrierter Nutzer \begin{itemize*} - \item - jeder hat eindeutige UID (userID), z.B. integer- Zahl - \item - Dateien, Prozesse und andere Ressourcenwerden mit UID des - Eigentümersversehen + \item jeder hat eindeutige UID (userID), z.B. integer- Zahl + \item Dateien \& Prozesse mit UID des Eigentümers versehen \begin{itemize*} \item bei Dateien: Teil des I-Nodes - \item bei Prozessen: Teil des PCB (vgl. Grundlagen ,,Betriebssysteme'') - \item standardmäßiger Eigentümer: derjenige, eine Ressource erzeugt hat + \item bei Prozessen: Teil des PCB + \item standardmäßiger Eigentümer: der Ressource erzeugt hat \end{itemize*} \end{itemize*} Nutzergruppen (groups) - \begin{itemize*} - \item - jeder Nutzer wird durch Eintrag in einer Systemdatei ( /etc/group ) - einer oder mehreren Gruppen zugeordnet( $\rightarrow$ - ACL: ,, g '' Rechte) + \item jeder Nutzer durch Eintrag in Systemdatei (/etc/group) einer/mehreren Gruppen zugeordnet ($\rightarrow$ ACL: g Rechte) \end{itemize*} Superuser oder root... hat grundsätzlich uneingeschränkte Rechte. - \begin{itemize*} - \item - UID = 0 - \item - darf insbesondere alle Dateien im System lesen, schreiben, ausführen; - unabhängig von ACL + \item UID = 0 + \item darf alle Dateien im System lesen, schreiben, ausführen + \item unabhängig von ACL \end{itemize*} - \subparagraph{ACL-Implementierung} - - \begin{itemize*} - \item - ACLs: - \begin{itemize*} - \item in welchen Kerneloperationen? - \item welche Kernelschnittstellen (Rechte prüfen, ändern)? - \item welche Datenstrukturen, wo gespeichert? - \end{itemize*} - \item - acm und ACLs: - \begin{itemize*} - \item Vorteile der Listenimplementierung? - \item Nachteile ggü. zentral implementierter Matrix? (DAC vs. MAC, Administration, Analyse ...) - \end{itemize*} - \item - $\rightarrow$ Übung 2 - \end{itemize*} - - - \subparagraph{Nutzerrechte $\rightarrow$ - Prozessrechte} - - bisher: Linux-Sicherheitspolitik formuliert Nutzerrechte an Dateien - (verteilt gespeichert in ACLs) + Nutzerrechte $\rightarrow$ Prozessrechte Durchsetzung: basiert auf Prozessrechten - \begin{itemize*} - \item - Annahme: Prozesse laufen mit UID des Nutzers, welcher sie gestartet - hat und repräsentieren Nutzerintention und Nutzerberechtigungen i.S.d. - Sicherheitspolitik - \item - technisch bedeutet dies: ein Nutzer beauftragt einen anderen Prozess, - sich zu dublizieren( fork() ) und das gewünschte Programm auszuführen - ( exec*() ) - \item - Vererbungsprinzip: - %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-acl-vererbungsprinzip.png} + \item Annahme: Prozesse laufen mit UID des Nutzers, der sie gestartet hat und repräsentieren Nutzerberechtigungen + \item technisch: Nutzer beauftragt anderen Prozess, sich zu dublizieren (fork()) und gewünschte Programm auszuführen (exec*()) + \item Vererbungsprinzip %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-acl-vererbungsprinzip.png} \end{itemize*} + \subparagraph{Autorisierungsmechanismen: Set-UID} - \subparagraph{Autorisierungsmechanismen: - Set-UID} - - konsequente Rechtevererbung: - + konsequente Rechtevererbung \begin{itemize*} - \item - Nutzer können im Rahmen der DAC-Politik ACLs manipulieren - \item - Nutzer können (i.A.) jedoch keine Prozess-UIDs manipulieren - \item - $\rightarrow$ und genau so sollte es gem. - Unix-Sicherheitspolitik auch sein! + \item Nutzer können im Rahmen der DAC-Politik ACLs manipulieren + \item Nutzer können (i.A.) jedoch keine Prozess-UIDs manipulieren + \item $\rightarrow$ und genau so sollte es gem. Unix-Sicherheitspolitik auch sein! \end{itemize*} - Hintergrund: - + Hintergrund \begin{itemize*} - \item - Unix-Philosophie ,, everythingisa file '': BS-Ressourcen wie Sockets, - IPC-Instanzen, E/A-Gerätehandler als Datei repräsentiert - $\rightarrow$ identische Schutzmechanismen zum - regulären Dateisystem - \item - somit: Autorisierungsmechanismen zur Begrenzung des Zugriffs auf - solche Geräte nutzbar (Bsp.: Zugriffe verschiedener Prozesse auf einem - Drucker müssen koordiniert, ggf. eingeschränkt werden) - \item - dazu muss + \item Unix-Philosophie ,, everything is a file '': BS-Ressourcen wie Sockets, E/A-Gerätehandler als Datei repräsentiert $\rightarrow$ identische Schutzmechanismen zum regulären Dateisystem + \item somit: Autorisierungsmechanismen zur Begrenzung des Zugriffs auf solche Geräte nutzbar \begin{itemize*} - \item \emph{root} bzw. zweckgebundener Nutzer Eigentümer des Druckers sein + \item \emph{root} bzw. zweckgebundener Nutzer muss Eigentümer sein \item ACL als \texttt{rw-\ ---\ ---} gesetzt sein + \item[$\rightarrow$] Nutzerprozesse könnten z.B. nicht drucken ... + \end{itemize*} + \item Lösung: Mechanismus zur Rechtedelegation + \begin{itemize*} + \item durch weiteres Recht in ACL: SUID-Bit (setUID) + \item Programmausführung modifiziert Kindprozess, so dass UID des Programmeigentümers seine Rechte bestimmt + \item Technik: von UID abweichende Prozess-Metainformation ($\rightarrow$ PCB) effektive UID (eUID) wird tatsächlich zur Autorisierung genutzt \end{itemize*} - \end{itemize*} - - Folge: - - \begin{itemize*} - \item - Nutzerprozesse könnten z.B. nicht drucken ... - \end{itemize*} - - Lösung: Mechanismus zur Rechtedelegation - - \begin{itemize*} - \item - implementiert durch ein weiteres ,,Recht'' in ACL: SUID-Bit (,, - setUID'' ) - \item - Programmausführung modifiziert Kindprozess, so dass UID des - Programmeigentümers (im Bsp.: root ) seine Rechte bestimmt - \item - Technik: eine von UID abweichende Prozess-Metainformation - ( $\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} \end{itemize*} Strategie für sicherheitskritische Linux-Programme - \begin{itemize*} - \item - Eigentümer: root - \item - SUID-Bit: gesetzt - \item - per eUID delegiert root seine Rechte an genau solche Kindprozesse, die - SUID-Programme ausführen - \item - Folge: Nutzerprozesse können Systemprogramme (und nur diese) ohne - permanente root - Rechte ausführen + \item Eigentümer \emph{root}, SUID-Bit gesetzt + \item per eUID delegiert root seine Rechte an genau solche Kindprozesse, die SUID-Programme ausführen + \item[$\rightarrow$] Nutzerprozesse können Systemprogramme ohne permanente root-Rechte ausführen \end{itemize*} Weiteres Beispiel: passwd - \begin{itemize*} - \item - ermöglicht Nutzern Ändern des (eigenen) Anmeldepassworts - \item - Schreibzugriff auf /etc/shadow (Password-Hashes) erforderlich ... - Schutz der Integrität anderer Nutzerpasswörter? - \item - Lösung: `-rws rws r-x 1 root root 1 2005-01-20 10:00 passwd\$ - \item - passwd - Programm (und nur dieses!) wird mit root-Rechten ausgeführt - ()... und passwd schreibt ja nur unseren eigenen Passwort-Hash) + \item ermöglicht Nutzern Ändern des (eigenen) Anmeldepassworts + \item Schreibzugriff auf /etc/shadow (Password-Hashes) erforderlich + \item Lösung: `-rws rws r-x 1 root root 1 2005-01-20 10:00 passwd\$ + \item passwd-Programm wird mit root-Rechten ausgeführt und passwd schreibt nur eigenen Passwort-Hash \end{itemize*} - - \subparagraph{Beispiel passwd} - + \subsection{Modern: SELinux} \begin{itemize*} - \item - Problem: privilegierter Zugriff durch unprivilegierte Anwendung - %\begin{itemize*} - %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-passwd-problem.png} - %\end{itemize*} - \item - Standard Linux Lösung: - %\begin{itemize*} - %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-passwd-lösung.png} - %\end{itemize*} - \end{itemize*} - - \subsubsection{Modern: SELinux} - - \begin{itemize*} - \item - Ursprung - \begin{itemize*} - \item Anfang 2000er Jahre: sicherheitsfokussiertes Betriebssystemprojekt für US-amerikanische NSA [LoSm01] - \item Implementierung des (eigentlich)$\mu$Kernel-Architekturkonzepts Flask - \item heute: Open Source, Teil des mainline Linux Kernels - \end{itemize*} - \item - Klassische UNIXoide: Sicherheitspolitik fest im Kernel implementiert - \begin{itemize*} - \item I-Nodes, PCBs, ACLs, UID, GID, SUID, ... - \end{itemize*} - \item - Idee SELinux: Sicherheitspolitikals eigene BS-Abstraktion + \item 2000er: sicherheitsfokussiertes Betriebssystemprojekt für NSA + \item Implementierung des $\mu$Kernel-Architekturkonzepts Flask + \item heute: Open Source, Teil des mainline Linux Kernels + \item Klassische UNIXoide: Sicherheitspolitik fest im Kernel + \item Idee SELinux: Sicherheitspolitikals eigene BS-Abstraktion \begin{itemize*} \item zentrale Datenstruktur für Regeln, die erlaubte Zugriffe auf ein SELinux-System definiert \item erlaubt Modifikation und Anpassung an verschiedene Sicherheitsanforderungen $\rightarrow$ NFE Adaptivität ... \end{itemize*} \end{itemize*} - - \subparagraph{SELinux-Sicherheitsmechanismen} - BS-Komponenten - \begin{itemize*} - \item - Auswertung der Sicherheitspolitik: Security- Server , implementiert - als Linux-Kernelmodul(Technik: LSM, Linux Security Module ); - $\rightarrow$ entscheidet über alle Zugriffe auf alle - Objekte - \item - Durchsetzung der Sicherheitspolitik : LSM Hooks (generische - Anfrage-Schnittstellen in allen BS-Funktionen) - \item - Administration der Sicherheitspolitik: geschrieben in Textform, muss - zur Laufzeit in Security Server installiert werden + \item Auswertung: Security-Server, implementiert als Linux-Kernelmodul $\rightarrow$ entscheidet über alle Zugriffe auf alle Objekte + \item Durchsetzung der Sicherheitspolitik: LSM Hooks + \item Administration: geschrieben in Textform, muss zur Laufzeit in Security Server installiert werden \end{itemize*} - %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-selinux-security-server.png} - %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-selinux-sicherheitspolitik-installieren.png} - - \subparagraph{SELinux-Sicherheitspolitik} - - Repräsentation der Sicherheitspolitik: - + Repräsentation der Sicherheitspolitik \begin{itemize*} - \item - physisch: in spezieller Datei, die alle Regeln enthält (in - maschinenlesbarer Binärdarstellung), die der Kernel durchsetzen muss - \item - diese Datei wird aus Menge von Quelldateien in einer - Spezifikationssprache für SELinux-Sicherheitspolitiken kompiliert - \item - diese ermöglicht anforderungsspezifische SELinux-Politiken: können - (und müssen) sich von einem SELinux-System zum anderen wesentlich - unterscheiden - \item - Politik wird während des Boot-Vorgangs in Kernel geladen + \item physisch: in spezieller Datei, die alle Regeln enthält, die der Kernel durchsetzen muss + \item Datei wird aus Menge von Quelldateien in einer Spezifikationssprache für SELinux-Sicherheitspolitiken kompiliert + \item ermöglicht anforderungsspezifische SELinux-Politiken: können sich von SELinux-System zum anderen wesentlich unterscheiden + \item Politik wird während des Boot-Vorgangs in Kernel geladen \end{itemize*} - - \subparagraph{Politiksemantik} - - Regeln einer SELinux-Sicherheitspolitiken, Semantische - Konzepte(Auswahl): - + Semantische Konzepte (Auswahl) \begin{itemize*} - \item - Type Enforcement (TE) - \item - Typisierung von + \item Type Enforcement (TE): Typisierung von \begin{itemize*} \item Subjekten: Prozesse - \item Objekten der Klassen: Dateien, Sockets, EA-Geräteschnittstellen, ... + \item Objekten der Klassen: Dateien, Sockets, Geräteschnittstellen, ... \end{itemize*} - \item - Rechte delegation durch Retypisierung(vgl. Unix-SUID!) + \item Rechte delegation durch Retypisierung (vgl. Unix-SUID) %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-selinux-retypisierung.png} \end{itemize*} - \subparagraph{Autorisierungsinformationen} - - Security Context: Respräsentiert SELinux-Autorisierungsinformationen für - jedes Objekt: - - %\begin{Shaded} - %\begin{Highlighting}[] - %\NormalTok{$ }\FunctionTok{ps}\NormalTok{ {-}Z} - %\ExtensionTok{cox}\NormalTok{:doctor_r:shell_t:s0{-}s0:c0.c255 4056 pts/2 00:00:00 bash} - %\NormalTok{$ }\FunctionTok{ls}\NormalTok{ {-}Z /etc/shadow} - %\ExtensionTok{system_u}\NormalTok{:object_r:shadow_t:s0 /etc/shadow} - %\end{Highlighting} - %\end{Shaded} - - \begin{itemize*} - \item - Semantik: - \begin{itemize*} - \item Prozess bash läuft (momentan) mit Typ \texttt{shell\_t} - \item Datei shadow hat (momentan) den Typen \texttt{shadow\_t}. - \end{itemize*} - \end{itemize*} - + Security Context: Respräsentiert SELinux-Autorisierungsinformationen für jedes Objekt (Semantik: Prozess bash läuft mit Typ \texttt{shell\_t}) \subparagraph{Autorisierungsregeln} - - ... werden systemweit festgelegt in dessen Sicherheitspolitik - ( $\rightarrow$ MAC): + ... werden systemweit festgelegt in dessen Sicherheitspolitik ($\rightarrow$ MAC) Access Vector Rules - \begin{itemize*} - \item - definieren Autorisierungsregeln basierend auf Subjek-/Objekttypen - \item - Zugriffe müssen explizit gewährt werden ( default-deny ) - + \item Autorisierungsregeln basierend auf Subjek-/Objekttypen + \item Zugriffe müssen explizit gewährt werden (default-deny) %\begin{Shaded} %\begin{Highlighting}[] %\ExtensionTok{allow}\NormalTok{ shell_t passwd_exec_t : file \{ execute \};} %\ExtensionTok{allow}\NormalTok{ passwd_t shadow_t : file \{ read write \};} %\end{Highlighting} %\end{Shaded} - \item - Semantik: Erlaube( ''allow'' ) ... + \item Semantik: Erlaube (''allow'') ... \begin{itemize*} \item jedem Prozess mit Typ \texttt{shell\_t} - \item ausführenden Zugriff (benötigt die Berechtigung \texttt{execute}), + \item ausführenden Zugriff (benötigt die Berechtigung \texttt{execute}) \item auf Dateien (also Objekte der Klassefile) - \item mit Typ \texttt{passwd\_exec\_t}. + \item mit Typ \texttt{passwd\_exec\_t} \end{itemize*} \end{itemize*} - - \subparagraph{Autorisierungsmechanismen: passwd - Revisited} - - Klassischer Anwendungsfall für SELinux-TE: Passwort ändern - - Lösung: Retypisierung bei Ausführung - + \subparagraph{Autorisierungsmechanismen: passwd Revisited} \begin{itemize*} - \item - Prozess wechselt in einen aufgabenspezifischen Typ \texttt{passwd\_t} - \item - $\rightarrow$ massiv verringertes - Missbrauchspotenzial! + \item Lösung: Retypisierung bei Ausführung + \item Prozess wechselt in einen aufgabenspezifischen Typ \texttt{passwd\_t} + \item[$\rightarrow$] massiv verringertes Missbrauchspotenzial! %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-passwd-lösung2.png} \end{itemize*} - - \subparagraph{SELinux: weitere - Politiksemantiken} - + SELinux: weitere Politiksemantiken \begin{itemize*} - \item - hier nur gezeigt: Überblick über TE - \item - außerdem relevant für SELinux-Politiken (und deren Administration...): + \item hier gezeigt: Überblick über TE + \item außerdem relevant für SELinux-Politiken (und deren Administration) \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) - \end{itemize*} - \item - Ergebnis: - \begin{itemize*} - \item \cmark extrem feingranulare, anwendungsspezifische Sicherheitspolitik zur Vermeidung von privilege escalation Angriffen - \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! + \item[$\rightarrow$] Schutz gegen nicht vertrauenswürdige Nutzer \end{itemize*} + \item[\cmark] extrem feingranulare, anwendungsspezifische Sicherheitspolitik zur Vermeidung von privilege escalation Angriffen + \item[\cmark] obligatorische Durchsetzung ( $\rightarrow$ MAC, zusätzlich zu DAC) + \item[O] Softwareentwicklung: Legacy-Linux-Anwendungen ohne Einschränkung + \item[\xmark] Politikentwicklung und -administration komplex + \item[$\rightarrow$] MAC-Mechanismen ala SELinux sind heutzutage in vielerlei Software bereits zu finden \end{itemize*} - - \subparagraph{Weitere Informationen zu - SELinux} - - $\rightarrow$ MAC-Mechanismen ala SELinux sind - heutzutage in vielerlei Software bereits zu finden: - - \begin{itemize*} - \item - Datenbanksoftware (SEPostgreSQL) - \item - Betriebssysteme für mobile Geräte (FlaskDroid) - \item - sehr wahrscheinlich: zukünftige, sicherheitsorientierte BS... - \end{itemize*} - - \subsection{Isolationsmechanismen} \begin{itemize*} - \item - bekannt: Isolationsmechanismen für robuste Betriebssysteme + \item bekannt: Isolationsmechanismen für robuste Betriebssysteme \begin{itemize*} \item strukturierte Programmierung \item Adressraumisolation \end{itemize*} - \item - nun: Isolationsmechanismen für sichere Betriebssysteme + \item nun: Isolationsmechanismen für sichere Betriebssysteme \begin{itemize*} \item all die obigen... \item kryptografische Hardwareunterstützung: Intel SGX Enclaves @@ -2164,17 +1703,13 @@ \subparagraph{Intel SGX} \begin{itemize*} - \item - SGX: Software Guard Extensions [CoDe16] - \item - Ziel: Schutz von sicherheitskritischen Anwendungen durch vollständige, + \item SGX: Software Guard Extensions [CoDe16] + \item Ziel: Schutz von sicherheitskritischen Anwendungen durch vollständige, hardwarebasierte Isolation - \item - $\rightarrow$ strenggenommen kein BS-Mechanismus: + \item $\rightarrow$ strenggenommen kein BS-Mechanismus: Anwendungen müssen dem BS nicht mehr vertrauen! (AR-Schutz, Wechsel von Privilegierungsebenen, ...) - \item - Annahmen/Voraussetzungen: + \item Annahmen/Voraussetzungen: \begin{enumerate*} \item sämtliche Software nicht vertrauenswürdig (potenziell durch Angreifer kontrolliert) @@ -2188,31 +1723,25 @@ \subparagraph{Enclaves} \begin{itemize*} - \item - Idee: geschützter Speicherbereich für Teilmenge der Seiten (Code und + \item Idee: geschützter Speicherbereich für Teilmenge der Seiten (Code und Daten) einer Task: Enclave Page Cache (EPC) - \item - Prozessor (und nur dieser) ver-und entschlüsselt EPC-Seiten + \item Prozessor (und nur dieser) ver-und entschlüsselt EPC-Seiten %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-SGX-enclaves.png} - \item - Enclaves: Erzeugung + \item Enclaves: Erzeugung \begin{itemize*} \item Erzeugen: App. $\rightarrow$ Syscall $\rightarrow$ BS-Instruktion an CPU (ECREATE) \item Seiten hinzufügen: App. $\rightarrow$ Syscall $\rightarrow$ BS-Instruktion an CPU (EADD) \begin{itemize*} \item Metainformationen für jede hinzugefügte Seite als Teil der EPC-Datenstruktur (u.a.: Enklave - ID, Zugriffsrechte, vAR-Adresse) \end{itemize*} \item Initialisieren: App. $\rightarrow$ Syscall $\rightarrow$ BS-Instruktion an CPU (EINIT) \begin{itemize*} \item finalisiert gesamten Speicherinhalt für diese Enclave \item CPU erzeugt Hashwert = eindeutige Signatur des Enclave - Speicherinhalts \item falls BS bis zu diesem Punkt gegen Integrität der Anwendung verstoßen hat: durch Vergleich mit von dritter Seite generiertem Hashwert feststellbar! \end{itemize*} \end{itemize*} - \item - Enclave - Zustandsmodell (vereinfacht) : + \item Enclave - Zustandsmodell (vereinfacht) : %\begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-SGX-enclaves-model.png} %\end{itemize*} - \item - Zugriff: App. $\rightarrow$ CPU-Instruktionen in User + \item Zugriff: App. $\rightarrow$ CPU-Instruktionen in User Mode (EENTER, EEXIT) \begin{itemize*} \item CPU erfordert, dass EPC-Seiten in vARder zugreifenden Task - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-SGX-enlaves-zugriff.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-SGX-enlaves-zugriff.png} \end{itemize*} \end{itemize*} @@ -2220,21 +1749,17 @@ \subparagraph{SGX: Licht und Schatten} \begin{itemize*} - \item - Einführung 2015 in Skylake - Mikroarchitektur - \item - seither in allen Modellen verbaut, jedoch nicht immer aktiviert - \item - Nutzer bislang: Demos und Forschungsprojekte, Unterstützung durch + \item Einführung 2015 in Skylake - Mikroarchitektur + \item seither in allen Modellen verbaut, jedoch nicht immer aktiviert + \item Nutzer bislang: Demos und Forschungsprojekte, Unterstützung durch einige Cloud-Anbieter, (noch) keine größeren Märkte erschlossen - \item - Konzept hardwarebasierter Isolation ... + \item Konzept hardwarebasierter Isolation ... \begin{itemize*} - \item \cmark liefert erstmals die Möglichkeit zur Durchsetzung von Sicherheitspolitiken auf Anwendungsebene - \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[\cmark] liefert erstmals die Möglichkeit zur Durchsetzung von Sicherheitspolitiken auf Anwendungsebene + \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*} \end{itemize*} \end{itemize*} @@ -2245,16 +1770,14 @@ Struktur und Interaktion) der Sicherheitsmechanismen eines IT-Systems. \begin{itemize*} - \item - Voraussetzung zum Verstehen jeder Sicherheitsarchitektur: + \item Voraussetzung zum Verstehen jeder Sicherheitsarchitektur: \begin{itemize*} \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 \end{itemize*} - \item - Begriffe des Referenzmonitorprinzips kennen wir schon: + \item Begriffe des Referenzmonitorprinzips kennen wir schon: \begin{itemize*} \item Abgrenzung passiver Ressourcen (in Form einzelner Objekte, z.B. Dateien) \item von Subjekten (aktiven Elementen, z.B. laufenden Programmen, Prozessen) durch Betriebssystem @@ -2265,21 +1788,18 @@ \subsubsection{Referenzmonitorprinzip} \begin{itemize*} - \item - Idee: + \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 somit: Architekturbeschreibung, wie Zugriffe auf Ressourcen (z.B. Dateien) auf solche Zugriffe, die Sicherheitspolitik erlaubt, eingeschränkt werden \end{itemize*} - \item - Autorisierungsentscheidungen + \item Autorisierungsentscheidungen \begin{itemize*} \item basieren auf sicherheitsrelevanten Eigenschaften jedes Subjekts und jedes Objekts \item einige Beispiele kennen wir schon: \begin{itemize*} \item Nutzname, Unix-Gruppe \item Prozess-ID, INode-Nummer \item SELinux-Typ \end{itemize*} \end{itemize*} - \item - Architekturkomponenten in a nutshell: + \item Architekturkomponenten in a nutshell: %\begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-Referenzmonitorprinzip.png} %\end{itemize*} @@ -2289,18 +1809,15 @@ Architekturkomponenten, die \begin{itemize*} - \item - (RM 1) bei sämtlichen Subjekt/Objekt-Interaktionen involviert sind + \item (RM 1) bei sämtlichen Subjekt/Objekt-Interaktionen involviert sind \begin{itemize*} \item[$\rightarrow$] Unumgehbarkeit ( total mediation ) \end{itemize*} - \item - (RM 2) geschützt sind vor unautorisierter Manipulation + \item (RM 2) geschützt sind vor unautorisierter Manipulation \begin{itemize*} \item[$\rightarrow$] Manipulationssicherheit ( tamperproofness ) \end{itemize*} - \item - (RM 3) hinreichend klein und wohlstrukturiert sind, um formalen + \item (RM 3) hinreichend klein und wohlstrukturiert sind, um formalen Analysemethoden zugänglich zu sein \begin{itemize*} \item[$\rightarrow$] Verifizierbarkeit ( verifyability ) @@ -2315,42 +1832,32 @@ Referenzmonitors [Jaeg11] und können über Begriffe, wie \begin{itemize*} - \item - Subjekte - \item - Objekte - \item - Regeln einer Sicherheitspolitik charakterisiert sowie auf - \item - Unumgehbarkeit - \item - Manipulationssicherheit - \item - Verifizierbarkeit ihrer Sicherheitsarchitektur hin untersucht werden + \item Subjekte + \item Objekte + \item Regeln einer Sicherheitspolitik charakterisiert sowie auf + \item Unumgehbarkeit + \item Manipulationssicherheit + \item Verifizierbarkeit ihrer Sicherheitsarchitektur hin untersucht werden \end{itemize*} Beispiel: Standard- Linux \begin{itemize*} - \item - Subjekte (generell Prozesse) + \item Subjekte (generell Prozesse) \begin{itemize*} \item haben reale (und effektive) Nutzer-Identifikatoren (UIDs) \end{itemize*} - \item - Objekte (verschiedene Systemressourcen, genutzt für Speicherung, + \item Objekte (verschiedene Systemressourcen, genutzt für Speicherung, Kommunikation: Dateien, Directories, Sockets, SharedMemory usw.) \begin{itemize*} \item haben ACLs (,,rwxrw----'') \end{itemize*} - \item - Regeln der Sicherheitspolitik, die durch den Referenzmonitor (hier + \item Regeln der Sicherheitspolitik, die durch den Referenzmonitor (hier Kernel) unterstützt werden \begin{itemize*} \item hart codiert, starr \end{itemize*} - \item - Sicherheitsattribute, die durch diese Regeln zur Prüfung genutzt + \item Sicherheitsattribute, die durch diese Regeln zur Prüfung genutzt werden (z.B. Zugriffsmodi) \begin{itemize*} \item Objekten zugeordnet @@ -2361,12 +1868,9 @@ Man beurteile die Politikimplementierung in dieser Architektur bzgl.: \begin{itemize*} - \item - Unumgehbarkeit - \item - Manipulationssicherheit - \item - Verifizierbarkeit + \item Unumgehbarkeit + \item Manipulationssicherheit + \item Verifizierbarkeit \end{itemize*} @@ -2382,11 +1886,9 @@ Server} \begin{itemize*} - \item - Security Server: Laufzeitumgebung für Politik in Schutzdomäne des + \item Security Server: Laufzeitumgebung für Politik in Schutzdomäne des Kerns - \item - Objektmanager: implementiert in allen BS-Dienstenmittels,, Linux + \item Objektmanager: implementiert in allen BS-Dienstenmittels,, Linux Security Module Framework '' \begin{itemize*} \item jedes Subsystemvon SELinux , das zuständig für \begin{enumerate*} \item Erzeugung neuer Objekte \item Zugriff auf existierende Objekte \end{enumerate*} @@ -2397,10 +1899,8 @@ SELinux-Architektur: Objektklassen \begin{itemize*} - \item - Objektmanager zur Verwaltung verschiedener Objektklassen - \item - spiegeln Diversität und Komplexität von Linux BS-Abtraktionen wider: + \item Objektmanager zur Verwaltung verschiedener Objektklassen + \item spiegeln Diversität und Komplexität von Linux BS-Abtraktionen wider: \begin{itemize*} \item Dateisysteme: file, dir, fd, filesystem, ... \item Netzwerk: netif, socket, tcp\_socket, udp\_socket, ... @@ -2413,29 +1913,22 @@ Dateisystem als Objektmanager \begin{itemize*} - \item - Durch Analyse von Linux - Dateisystem und zugehöriger API wurden zu + \item Durch Analyse von Linux - Dateisystem und zugehöriger API wurden zu überwachenden Objektklassen identifiziert: \begin{itemize*} \item ergibt sich unmittelbar aus Linux-API: \begin{itemize*} \item Dateien \item Verzeichnisse \item Pipes \end{itemize*} \item feingranularere Objektklassen für durch Dateien repräsentierte Objekte (Unix-Prinzip: ,,everythingisa file''!): \begin{itemize*} \item reguläre Dateien \item symbolische Links \item zeichenorientierte Geräte \item blockorientierte Geräte \item FIFOs \item Unix-Domain Sockets (lokale Sockets) \end{itemize*} \end{itemize*} - \item - Permissions (Zugriffsrechte) - \item - für jede Objektklasse: Menge an Permissions definiert, um Zugriffe auf + \item Permissions (Zugriffsrechte) + \item für jede Objektklasse: Menge an Permissions definiert, um Zugriffe auf Objekte dieser Klasse zu kontrollieren - \item - Permissions: abgeleitet aus Dienstleistungen, die Linux-Dateisystem + \item Permissions: abgeleitet aus Dienstleistungen, die Linux-Dateisystem anbietet - \item - $\rightarrow$ Objektklassen gruppieren verschiedene + \item $\rightarrow$ Objektklassen gruppieren verschiedene Arten von Zugriffsoperationen auf verschiende Arten von Objekten - \item - z.B. Permissions für alle ,,Datei''-Objektklassen (Auswahl ...): read, + \item z.B. Permissions für alle ,,Datei''-Objektklassen (Auswahl ...): read, write, append, create, execute, unlink - \item - für ,,Verzeichnis''-Objektklasse: add\_name, remove\_name, reparant, + \item für ,,Verzeichnis''-Objektklasse: add\_name, remove\_name, reparant, search, rmdir \end{itemize*} @@ -2447,19 +1940,16 @@ Computing Base ) \begin{itemize*} - \item - = die Hard-und Softwarefunktionen eines IT-Systems, die notwendig und + \item = die Hard-und Softwarefunktionen eines IT-Systems, die notwendig und hinreichend sind, um alle Sicherheitsregeln durchzusetzen. - \item - besteht üblicherweise aus + \item besteht üblicherweise aus \begin{enumerate*} \item Laufzeitumgebung der Hardware(nicht E/A-Geräte) \item verschiedenen Komponenten des Betriebssystem-Kernels \item Benutzerprogrammen mit sicherheitsrelevanten Rechten (bei Standard-UNIX/Linux-Systemen: diejenigen mit root-Rechten) \end{enumerate*} - \item - Betriebssystemfunktionen, die Teil der TCB sein müssen, beinhalten + \item Betriebssystemfunktionen, die Teil der TCB sein müssen, beinhalten Teile \begin{itemize*} \item des Prozessmanagements @@ -2501,38 +1991,28 @@ Spektrum von Echtzeitsystemen: \begin{enumerate*} - \item - Regelungssysteme: z.B. eingebettete Systeme (exakter: Steuerungs-, + \item Regelungssysteme: z.B. eingebettete Systeme (exakter: Steuerungs-, Regelungs-u. Überwachungssysteme = ,,SRÜ''-Systeme) - \item - Endanwender-Rechnersysteme: z.B. Multimediasysteme - \item - Lebewesen: Menschen, Tiere + \item Endanwender-Rechnersysteme: z.B. Multimediasysteme + \item Lebewesen: Menschen, Tiere \end{enumerate*} Beispiel Regelungssystem: ,,Fly-by-Wire''-Fluglage-Regelungssystem (Schema) \begin{enumerate*} - \item - Flugzeugbewegung - \item - Sensoren + Einstellmöglichkeiten des Piloten - \item - Echtzeit-Datenverarbeitung (durch Echtzeit-Rechnersystem) - \item - Aktoren setzen Berechnung um - \item - Einstellung von Regelflächen - \item - Aerodynamik und Flug Mechanik führt zu Flugzeugbewegung (1.) + \item Flugzeugbewegung + \item Sensoren + Einstellmöglichkeiten des Piloten + \item Echtzeit-Datenverarbeitung (durch Echtzeit-Rechnersystem) + \item Aktoren setzen Berechnung um + \item Einstellung von Regelflächen + \item Aerodynamik und Flug Mechanik führt zu Flugzeugbewegung (1.) \end{enumerate*} Beispiel Überwachungssysteme \begin{itemize*} - \item - Luftraumüberwachung: + \item Luftraumüberwachung: \begin{itemize*} \item Ortsfeste Radarstation \item Mobile Radarstation @@ -2540,44 +2020,33 @@ \item Flugplatzradar Netzfunkstellen \item Zentrale \end{itemize*} - \item - Umweltüberwachung: Stickstoffdioxidkonzentration über Europa - \item - Vorgeburtliche Gesundheitsüberwachung: Herzschlagsüberwachungssystem + \item Umweltüberwachung: Stickstoffdioxidkonzentration über Europa + \item Vorgeburtliche Gesundheitsüberwachung: Herzschlagsüberwachungssystem für Mutter und Kind \end{itemize*} Beispiel Multimediasystem \begin{itemize*} - \item - zeitabhängige Datenwiedergabe - \item - Bildwiedergabe bei Mediendatenströmen - \item - Durchführung der Schritte durch Multimedia-Task binnen $t_{i+1} - + \item zeitabhängige Datenwiedergabe + \item Bildwiedergabe bei Mediendatenströmen + \item Durchführung der Schritte durch Multimedia-Task binnen $t_{i+1} - t_i$ - \item - Frist für Rendering in Multimedia-Tasks: festgelegt durch periodische + \item Frist für Rendering in Multimedia-Tasks: festgelegt durch periodische Bildrate (24~48 fps $\rightarrow$ 1/24 ... 1/48 s) - \item - $\rightarrow$ Berücksichtigung bei Scheduling, + \item $\rightarrow$ Berücksichtigung bei Scheduling, Interruptbehandlung, Speicherverwaltung, ... erforderlich! \end{itemize*} Zwischenfazit [Buttazzo97] \begin{itemize*} - \item - Murphy`s General Law: If something can go wrong, it will got wrong. - \item - Murphy`s Constant: Damage to an object is proportional to its value. - \item - Johnson`s First Law: If a system stops working, it will do it at the + \item Murphy`s General Law: If something can go wrong, it will got wrong. + \item Murphy`s Constant: Damage to an object is proportional to its value. + \item Johnson`s First Law: If a system stops working, it will do it at the worst possible time. - \item - Sodd`sSecond Law: Sooner or later, the worst possible combination of + \item Sodd`sSecond Law: Sooner or later, the worst possible combination of circumstances will happen. \end{itemize*} @@ -2589,22 +2058,17 @@ bevor wir uns über Echtzeit-Betriebssystemen unterhalten: \begin{enumerate*} - \item - Wie ist die Eigenschaft Echtzeit definiert? - \item - Was sind (rechnerbasierte) Echtzeitsysteme? - \item - Wie können Echtzeitanwendungen beschrieben werden? - \item - Welche grundsätzlichen Typen von Echtzeitprozessen gibt es/wodurch + \item Wie ist die Eigenschaft Echtzeit definiert? + \item Was sind (rechnerbasierte) Echtzeitsysteme? + \item Wie können Echtzeitanwendungen beschrieben werden? + \item Welche grundsätzlichen Typen von Echtzeitprozessen gibt es/wodurch werden diese charakterisiert? \end{enumerate*} Antwortzeit: \begin{itemize*} - \item - Alle Definitionen -die zitierten u. andere - betrachten eine + \item Alle Definitionen -die zitierten u. andere - betrachten eine ,,responsetime'' (Antwortzeit, Reaktionszeit) als das Zeitintervall, das ein System braucht, um (irgend)eine Ausgabe als Reaktion auf (irgend)eine Eingabe zu erzeugen. @@ -2613,12 +2077,10 @@ Frist \begin{itemize*} - \item - Bei Echtzeitsystemen ist genau dieses $\Delta t$ + \item Bei Echtzeitsystemen ist genau dieses $\Delta t$ kritisch, d.h. je nach Art des Systems darf dieses auf keinen Fall zu groß werden. - \item - Genauer spezifizierbar wird dies durch Einführung einer Frist + \item Genauer spezifizierbar wird dies durch Einführung einer Frist (deadline, due time) $d$, die angibt bis zu welchem Zeitpunkt spätestmöglich die Reaktion erfolgt sein muss, bzw. wie groß das Intervall $\Delta t$ maximal sein darf. @@ -2627,13 +2089,11 @@ Echtzeitfähigkeit und Korrektheit \begin{itemize*} - \item - Wird genau dieses maximale Zeitintervall in die Spezifikation eines + \item Wird genau dieses maximale Zeitintervall in die Spezifikation eines Systems einbezogen, bedeutet dies, dass ein Echtzeitsystem nur dann korrekt arbeitet, wenn seine Reaktion bis zur spezifizierten Frist erfolgt. - \item - Die Frist trennt also korrektes von inkorrektem Verhalten des Systems. + \item Die Frist trennt also korrektes von inkorrektem Verhalten des Systems. \end{itemize*} %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeitfähigkeit.png} @@ -2641,8 +2101,7 @@ Harte und weiche Echtzeitsysteme \begin{itemize*} - \item - Praktische Anwendungen erfordern oft Unterscheidung in harte und + \item Praktische Anwendungen erfordern oft Unterscheidung in harte und weiche Echtzeitsysteme: \begin{itemize*} \item hartes Echtzeitsystem: keine Frist darf jemals überschritten werden (sonst: katastrophale Konsequenzen) @@ -2655,11 +2114,9 @@ Echtzeit-Prozessen} \begin{itemize*} - \item - reale Echtzeitanwendungen beinhalten periodische oder aperiodische + \item reale Echtzeitanwendungen beinhalten periodische oder aperiodische Prozesse (oder Mischung aus beiden) - \item - typische Unterscheidung: + \item typische Unterscheidung: \begin{itemize*} \item Periodische Prozesse \begin{itemize*} \item zeitgesteuert (typisch: periodische Sensorauswertung) \item oft: kritische Aktivitäten $\rightarrow$ harte Fristen \end{itemize*} \item Aperiodische Prozesse \begin{itemize*} \item ereignisgesteuert \item Abhängig von Anwendung: harte oder weiche Fristen, ggf. sogar Nicht-Echtzeit \end{itemize*} @@ -2670,10 +2127,8 @@ \subsubsection{Periodische Prozesse} \begin{itemize*} - \item - bei Echtzeit-Anwendungen: häufigster Fall - \item - typisch für: + \item bei Echtzeit-Anwendungen: häufigster Fall + \item typisch für: \begin{enumerate*} \item periodische Analyse von Sensor-Daten (z.B. Umweltüberwachung) @@ -2681,8 +2136,7 @@ \item Erzeugung oder Verarbeitung einzelner Dateneinheiten eines multimedialen Datenstroms \item ... \end{enumerate*} - \item - Prozessaktivierung + \item Prozessaktivierung \begin{itemize*} \item ereignisgesteuert oder zeitgesteuert \item Prozesse, die Eingangsdaten verarbeiten: meist ereignisgesteuert, z.B. wenn neues Datenpaket eingetroffen @@ -2693,22 +2147,17 @@ Periodische Prozesse \begin{itemize*} - \item - Fristen: + \item Fristen: \begin{itemize*} \item hart oder weich (anwendungsabhängig) \begin{itemize*} \item innerhalb einer Anwendung sind sowohl Prozesse mit harten oder weichen Fristen möglich \item Frist: spätestens am Ende der aktuellen Periode, möglich auch frühere Frist \end{itemize*} - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-periodisch-frist.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-periodisch-frist.png} \end{itemize*} - \item - Modellierung: + \item Modellierung: \begin{itemize*} \item unendliche Folge identischer Aktivierungen: Instanzen, aktiviert mit konstanter Rate (Periode) - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-periodisch-modellierung.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-periodisch-modellierung.png} \end{itemize*} - \item - Aufgaben des Betriebssystems: + \item Aufgaben des Betriebssystems: \begin{itemize*} \item WennalleSpezifikationeneingehaltenwerden-muss Betriebssystem garantieren, dass \begin{enumerate*} \item zeitgesteuerte periodische Prozesse: mit ihrer spezifizierten Rate aktiviert werden und ihre Frist einhalten können \item ereignisgesteuerte periodische Prozesse: ihre Frist einhalten können \end{enumerate*} \end{itemize*} @@ -2718,32 +2167,26 @@ \subsubsection{Aperiodische Prozesse} \begin{itemize*} - \item - typisch für + \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 ( $\rightarrow$ Spielkonsole) \end{itemize*} \end{itemize*} - \item - Prozessaktivierung + \item Prozessaktivierung \begin{itemize*} \item ereignisgesteuert \end{itemize*} - \item - Fristen + \item Fristen \begin{itemize*} \item oft weich(aber anwendungsabhängig) \end{itemize*} - \item - Aufgabendes Betriebssystems + \item Aufgabendes Betriebssystems \begin{itemize*} \item bei Einhaltung der Prozessspezifikationen muss Betriebssystem auch hier für Einhaltung der Fristen sorgen \end{itemize*} - \item - Modellierung + \item Modellierung \begin{itemize*} \item bestehen ebenfalls aus (maximal unendlicher) Folge identischer Aktivierungen (Instanzen); aber: Aktivierungszeitpunkte nicht regelmäßig (möglich: nur genau eine Aktivierung) - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-aperiodisch-modellierung.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-aperiodisch-modellierung.png} \end{itemize*} \end{itemize*} @@ -2753,52 +2196,43 @@ \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-parameter-instanz.png} - \item - $a_i$: Ankunftszeitpunkt (arrival time); auch r ... request + \item $a_i$: Ankunftszeitpunkt (arrival time); auch r ... request time/release time \begin{itemize*} \item Zeitpunkt, zu dem ein Prozess ablauffähig wird \end{itemize*} - \item - $s_i$: Startzeitpunkt (start time) + \item $s_i$: Startzeitpunkt (start time) \begin{itemize*} \item Zeitpunkt, zu dem ein Prozess mit der Ausführung beginnt \end{itemize*} - \item - $f_i$: Beendigungszeitpunkt (finishing time) + \item $f_i$: Beendigungszeitpunkt (finishing time) \begin{itemize*} \item Zeitpunkt, an dem ein Prozess seine Ausführung beendet \end{itemize*} - \item - $d_i$: Frist (deadline, due time) + \item $d_i$: Frist (deadline, due time) \begin{itemize*} \item Zeitpunkt, zu dem ein Prozess seine Ausführung spätestens beenden sollte \end{itemize*} - \item - $C_i$: Bearbeitungszeit(bedarf) (computation time) + \item $C_i$: Bearbeitungszeit(bedarf) (computation time) \begin{itemize*} \item Zeitquantum, das Prozessor zur vollständigen Bearbeitung der aktuellen Instanz benötigt (Unterbrechungen nicht eingerechnet) \end{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-parameter-instanz2.png} - \item - $L_i$: Unpünktlichkeit (lateness): $L_i= f_i - d_i$ + \item $L_i$: Unpünktlichkeit (lateness): $L_i= f_i - d_i$ \begin{itemize*} \item Zeitbetrag, um den ein Prozess früher oder später als seine Frist beendet wird (wenn Prozess vor seiner Frist beendet, hat $L_i$ negativen Wert) \end{itemize*} - \item - $E_i$: Verspätung (exceeding time, tardiness): $E_i= max(0, + \item $E_i$: Verspätung (exceeding time, tardiness): $E_i= max(0, L_i)$ \begin{itemize*} \item Zeitbetrag, den ein Prozess noch nach seiner Frist aktiv ist \end{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-parameter-instanz3.png} - \item - $X_i$: Spielraum (Laxity, Slacktime): $X_i = d_i - a_i - C_i$ + \item $X_i$: Spielraum (Laxity, Slacktime): $X_i = d_i - a_i - C_i$ \begin{itemize*} \item maximales Zeitquantum, um das Ausführung eines Prozesses verzögert werden kann, damit dieser noch bis zu seiner Frist beendet werden kann ($f_i=d_i$) \end{itemize*} - \item - außerdem: + \item außerdem: \begin{itemize*} \item criticality: Parameter zur Beschreibung der Konsequenzen einer Fristüberschreitung (typischerweise ,,hart'' oder ,,weich'') \item $V_i$ ...Wert (value): Parameter zum Ausdruck der relativen Wichtigkeit eines Prozesses bezogen auf andere Prozesse der gleichen Anwendung @@ -2810,15 +2244,13 @@ Betriebssysteme} \begin{itemize*} - \item - Hauptfragestellungen + \item Hauptfragestellungen \begin{enumerate*} \item Was muss BS zu tun, um Echtzeitprozesse zu ermöglichen? Welche Teilprobleme müssen beachtet werden? \item Welche Mechanismen müssen hierfür anders als bei nicht-echtzeitfähigen Betriebssystemen implementiert werden, und wie? \end{enumerate*} - \item - Grundlegender Gedanke + \item Grundlegender Gedanke \begin{itemize*} \item Abgeleitet aus den Aufgaben eines Betriebssystems sind folgende Fragestellungenvon Interesse: \end{itemize*} @@ -2827,8 +2259,7 @@ \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 - Prozess-Metainformationen + \item Prozess-Metainformationen \begin{enumerate*} \item Frist @@ -2836,8 +2267,7 @@ \item abgeleitet davon: Spielraum, Unpünktlichkeit, Verspätung, ... \item im Zusammenhang damit: Prioritätsumkehr, Überlast \end{enumerate*} - \item - Ressourcen-Management + \item Ressourcen-Management \begin{itemize*} \item Wie müssen Ressourcen verwaltet werden, damit Fristen eingehalten werden können? \end{itemize*} @@ -2846,16 +2276,14 @@ Wir betrachten i.F. \begin{enumerate*} - \item - Algorithmen, die Rechnersysteme echtzeitfähig machen -einschließlich + \item Algorithmen, die Rechnersysteme echtzeitfähig machen -einschließlich des Betriebssystems: \begin{itemize*} \item grundlegende Algorithmen zum Echtzeitscheduling \item Besonderheiten der Interruptbehandlung \item Besonderheiten der Speicherverwaltung \end{itemize*} - \item - Probleme, die behandelt werden müssen, um Echtzeitfähigkeit nicht zu + \item Probleme, die behandelt werden müssen, um Echtzeitfähigkeit nicht zu be- oder verhindern: \begin{itemize*} \item Prioritätsumkehr @@ -2868,18 +2296,15 @@ \subsubsection{Echtzeitscheduling} \begin{itemize*} - \item - Scheduling: + \item Scheduling: \begin{itemize*} \item Schedulingvon Prozessen/Threads als wichtigster Einflussfaktor auf Zeitverhalten des Gesamtsystems \end{itemize*} - \item - Echtzeit-Scheduling: + \item Echtzeit-Scheduling: \begin{itemize*} \item benötigt: Scheduling-Algorithmen, die Scheduling unter Berücksichtigung der ( unterschiedlichen ) Fristen der Prozesse durchführen können \end{itemize*} - \item - Fundamentale Algorithmen: + \item Fundamentale Algorithmen: \begin{itemize*} \item wichtigste Strategien: \end{itemize*} @@ -2896,29 +2321,22 @@ Annahmen der Scheduling-Strategien \begin{itemize*} - \item - A1: Alle Instanzen eines periodischen Prozesses $t_i$ treten + \item A1: Alle Instanzen eines periodischen Prozesses $t_i$ treten regelmäßig und mit konstanter Rate auf (= werden aktiviert ). Das Zeitintervall $T_i$ zwischen zwei aufeinanderfolgenden Aktivierungen heißt Periode des Prozesses. - \item - A2: Alle Instanzen eines periodischen Prozesses $t_i$ haben den + \item A2: Alle Instanzen eines periodischen Prozesses $t_i$ haben den gleichen Worst-Case-Rechenzeitbedarf $C_i$. - \item - A3: Alle Instanzen eines periodischen Prozesses $t_i$ haben die + \item A3: Alle Instanzen eines periodischen Prozesses $t_i$ haben die gleiche relative Frist $D_i$, welche gleich der Periodendauer $T_i$ ist. - \item - A4: Alle Prozessesind kausal unabhängig voneinander (d.h. keine + \item A4: Alle Prozessesind kausal unabhängig voneinander (d.h. keine Vorrang- und Betriebsmittel-Restriktionen) - \item - A5: Kein Prozess kann sich selbst suspendieren, z.B. bei + \item A5: Kein Prozess kann sich selbst suspendieren, z.B. bei E/A-Operationen. - \item - A6: Alle Prozesse werden mit ihrer Aktivierung sofort rechenbereit ( + \item A6: Alle Prozesse werden mit ihrer Aktivierung sofort rechenbereit ( release time = arrival time ). - \item - A7: Jeglicher Betriebssystem-Overhead (Kontextwechsel, + \item A7: Jeglicher Betriebssystem-Overhead (Kontextwechsel, Scheduler-Rechenzeit) wird vernachlässigt. \end{itemize*} @@ -2927,13 +2345,11 @@ Ratenmonotones Scheduling (RM) \begin{itemize*} - \item - Voraussetzung: + \item Voraussetzung: \begin{itemize*} \item periodisches Bereitwerden der Prozesse/Threads, d.h. periodische Prozesse bzw. Threads \end{itemize*} - \item - Strategie RM: + \item Strategie RM: \begin{itemize*} \item Prozess (Thread) mit höchster Ankunftsrate bekommt höchste statische Priorität (Kriterium: Wie oft pro Zeiteinheit wird Prozess bereit?) \item Scheduling-Zeitpunkt: nur einmal zu Beginn (bzw. wenn neuer periodischer Prozess auftritt) @@ -2945,39 +2361,32 @@ \item $t_1, t_2$: Anforderungen von Prozessorzeit durch zwei periodische Prozesse \item darunter: Prozessorzuteilung nach RM \end{itemize*} - \item - Optimalität von RM + \item Optimalität von RM \begin{itemize*} \item Unter allen Verfahren mit festen (statischen)Prioritäten ist RM optimaler Algorithmus in dem Sinne, dass kein anderes Verfahren dieser Klasse eine Prozessmenge einplanen kann, die nicht auch von RM geplant werden kann. [Liu\&Layland73] \end{itemize*} - \item - Prozessor-Auslastungsfaktor + \item Prozessor-Auslastungsfaktor \begin{itemize*} \item Bei gegebener Menge von n periodischen Prozessen gilt: $U=\sum_{i=1}^n \frac{C_i}{T_i}$ \item mit $\frac{C_i}{T_i}$ Anteil an Prozessorzeit für jeden periodischen Prozess $t_i$ \item und $U$ Summe der Prozessorzeit zur Ausführung der gesamten Prozessmenge (,,utilization factor'') \end{itemize*} - \item - Prozessorlast + \item Prozessorlast \begin{itemize*} \item $U$ ist folglich Maß für die durch Prozessmenge verursachte Last am Prozessor $\rightarrow$ Auslastungsfaktor \end{itemize*} - \item - Planbarkeitsanalyse einer Prozessmenge + \item Planbarkeitsanalyse einer Prozessmenge \begin{itemize*} \item im allgemeinen Fall kann RM einen Prozessor nicht zu 100\% auslasten \item von besonderem Interesse: kleinste obere Grenze des Auslastungsfaktors $U_{lub}$ (lub: ,,least upper bound'') \end{itemize*} - \item - Beispiel für $n=2$ + \item Beispiel für $n=2$ \begin{itemize*} - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-scheduling-rm2.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-scheduling-rm2.png} \item Obere Grenze des Prozessor-Auslastungsfaktors für zwei periodische Prozesse als Funktion des Verhältnisses ihrer Perioden. \item (Abb. nach [Buttazzo97] Bild 4.7, S. 90) \end{itemize*} - \item - Obere Auslastungsgrenze bei RM + \item Obere Auslastungsgrenze bei RM \begin{itemize*} \item nach [Buttazzo97] (S. 89-91) erhält man bei n Prozessen für RM: $U_{lub}=n(2^{\frac{1}{n}}-1)$ \item für $n\rightarrow\infty$ konvergiert $U_{lub}$ zu $ln\ 2 \approx 0,6931...$ @@ -3045,22 +2454,19 @@ Prozesse darunter: Prozessorzuteilung nach EDF bzw. RM \begin{itemize*} - \item - gut erkennbar: deutliche Unterschiede bei Scheduling mit statischem + \item gut erkennbar: deutliche Unterschiede bei Scheduling mit statischem (RM) vs. dynamischem Algorithmus (EDF). \end{itemize*} Vergleich: Anzahl Prozesswechsel \begin{itemize*} - \item - Häufigkeit von Prozesswechseln im Beispiel: + \item Häufigkeit von Prozesswechseln im Beispiel: \begin{itemize*} \item RM: 16 \item EDF: 12 \end{itemize*} - \item - Ursache: dynamische Prioritätenvergabe führt dazu, dass Instanz II von + \item Ursache: dynamische Prioritätenvergabe führt dazu, dass Instanz II von $t_2$ die gleiche Priorität wie Instanz A von $t_1$ hat (usw.) $\rightarrow$ keine unnötige Verdrängung \end{itemize*} @@ -3068,13 +2474,10 @@ Vergleich: 100\% Prozessorauslastung \begin{itemize*} - \item - EDF: erzeugt auch bei Prozessorauslastung bis 100\% (immer) korrekte + \item EDF: erzeugt auch bei Prozessorauslastung bis 100\% (immer) korrekte Schedules - \item - RM: kann das im allgemeinen Fall nicht - \item - Bedeutung von 100\% Prozessorauslastung in der Praxis: Überwiegend + \item RM: kann das im allgemeinen Fall nicht + \item Bedeutung von 100\% Prozessorauslastung in der Praxis: Überwiegend müssen Systeme mit harten Echtzeitanforderungen auch weiche Echtzeit- sowie Nicht-Echtzeit-Prozesse unterstützen. Daher: Belegungslücken am Prozessor für die letzteren beiden nutzbar. @@ -3083,36 +2486,30 @@ Vergleich: Implementierung \begin{itemize*} - \item - RM + \item RM \begin{itemize*} \item statisch: jeweils eine Warteschlange pro Priorität: \item Einfügen und Entfernen von Tasks: $O(1)$ - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-scheduling-rm-statisch.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-scheduling-rm-statisch.png} \end{itemize*} - \item - EDF + \item EDF \begin{itemize*} \item dynamisch: balancierter Binärbaum zur Sortierung nach Prioritäten: \item Einfügen und Entfernen von Tasks: $O(log\ n)$ - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-scheduling-edf-dynamisch.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-echtzeit-scheduling-edf-dynamisch.png} \end{itemize*} \end{itemize*} Scheduling in Multimedia-Anwendungen \begin{itemize*} - \item - Konkretisierung des Betrachtungswinkels + \item Konkretisierung des Betrachtungswinkels \begin{itemize*} \item RM und EDF wurden entwickelt insbesondere für Echtzeit-Regelsysteme $\rightarrow$ ohne Berücksichtigung von Multimediasystemen \item Multimediasysteme $\rightarrow$ andere Probleme, schwächere Annahmen: spezialisierte Scheduling-Algorithmen \item gehen meist auch von EDF und/oder RM als Grundlage aus \end{itemize*} - \item - Betrachteter Algorithmus: + \item Betrachteter Algorithmus: \begin{itemize*} \item Beispielfür spezialisierten Scheduling-Algorithmus: \begin{itemize*} \item RC-Algorithmus - entwickelt an University of Texas \item Anpassung von EDF an Charakteristika von Multimedia-Anwendungen \end{itemize*} \end{itemize*} @@ -3121,27 +2518,23 @@ Prozesstypen in Multimedia-Anwendungen \begin{enumerate*} - \item - Echte Multimedia-Prozesse + \item Echte Multimedia-Prozesse \end{enumerate*} \begin{itemize*} - \item - periodische Prozesse: weiche Fristen + \item periodische Prozesse: weiche Fristen \begin{enumerate*} \item pünktliche periodische Prozesse mit konstantem Prozessorzeitbedarf $C$ für jede Instanz (unkomprimierte Audio- und Videodaten) \item pünktliche periodische Prozesse mit unterschiedlichem $C$ einzelner Instanzen (komprimierte Audio- und Videodaten) \item unpünktliche periodische Prozesse: \begin{itemize*} \item verspätete Prozesse \item verfrühte Prozesse \end{itemize*} \end{enumerate*} - \item - aperiodische-Prozesse aus Multimedia-Anwendungen: weiche Fristen + \item aperiodische-Prozesse aus Multimedia-Anwendungen: weiche Fristen \end{itemize*} \begin{enumerate*} - \item - Prozesse nebenläufiger Nicht-Multimedia-Anwendungen + \item Prozesse nebenläufiger Nicht-Multimedia-Anwendungen \begin{itemize*} \item interaktive Prozesse : keine Fristen , aber: keine zu langen Antwortzeiten Ansatz (z.B.): maximal tolerierbare Verzögerung \item Hintergrund-Prozesse : zeitunkritisch, keine Fristen, aber : dürfen nicht verhungern @@ -3155,23 +2548,19 @@ Problem: Abweichungen von Lastspezifikation \begin{itemize*} - \item - gibt Prozessor nicht frei - \item - verspätete periodische Prozesse + \item gibt Prozessor nicht frei + \item verspätete periodische Prozesse \end{itemize*} \subsubsection{RC Algorithmus} \begin{itemize*} - \item - Ziel + \item Ziel \begin{itemize*} \item spezifikationstreue Prozesse nicht bestrafen durch Fristüberschreitung aufgrund abweichender Prozesse \end{itemize*} - \item - Idee + \item Idee \begin{itemize*} \item grundsätzlich: Schedulingnach frühester Fristaufsteigend (= EDF) $\rightarrow$ für eine vollständig spezifikationstreue Prozessmenge verhält sich RC wie reines EDF \item Frist einer Instanz wird dynamisch angepasst:basierend auf derjenigen Periode, in der sie eigentlich sein sollte lt. Spezifikation der Prozessornutzung ($U_i$, hier: ,,Rate''): $U_i=\frac{C_i}{T_i}$ @@ -3183,16 +2572,14 @@ \paragraph{RC Algorithmus: Strategie} \begin{itemize*} - \item - Variablen + \item Variablen \begin{itemize*} \item $a_i$: Ankunftszeit der zuletzt bereitgewordenen Instanz von $t_i$ \item $t_i^{virt}$: virtuelle Zeit in aktueller Periode, die $t_i$ bereits verbraucht hat \item $c_i^{virt}$: Netto-Rechenzeit, die $t_i$ in aktueller Periode bereits verbraucht hat \item $d_i$: dynamische Frist von $t_i$, nach der sich dessen Priorität berechnet (EDF) \end{itemize*} - \item - Strategie + \item Strategie \begin{itemize*} \item für eine bereite (lauffähige) Instanz von $t_i$: adaptiere dynamisch $d_i$ basierend auf $t_i^{virt}$ \item für eine bereit gewordene (neu angekommene oder zuvor blockierte) Instanzvon $t_i$: aktualisiere $t_i^{virt}$ auf akt. Systemzeit $(t)\rightarrow$ etwaiger ''Zeitkredit'' verfällt @@ -3239,18 +2626,15 @@ Zeitpunkte, zu denen der Scheduler aktiv wird: \begin{enumerate*} - \item - aktuell laufender Prozess $t_i$ blockiert: + \item aktuell laufender Prozess $t_i$ blockiert: \begin{itemize*} \item $RC(t_i)$ \end{itemize*} - \item - Prozesse $t_i..._j$ werden bereit: + \item Prozesse $t_i..._j$ werden bereit: \begin{itemize*} \item $for\ x\in[i,j]: RC(t_x)$ \end{itemize*} - \item - periodischer ,,clock tick'' (SchedulingInterrupt): + \item periodischer ,,clock tick'' (SchedulingInterrupt): \begin{itemize*} \item $t_i$ := aktuell ausgeführter Prozess \item $RC(t_i)$ @@ -3287,17 +2671,13 @@ Auswirkung auf verschiedene Prozesstypen: \begin{itemize*} - \item - ,,pünktliche'' Prozesse: Einhaltung der Frist in jeder Periode + \item ,,pünktliche'' Prozesse: Einhaltung der Frist in jeder Periode garantiert (unabhängig von Verhalten anderer Prozesse) - \item - ,,verspätete'' Prozesse: nur aktuelle Periode betrachtet, Nachholen + \item ,,verspätete'' Prozesse: nur aktuelle Periode betrachtet, Nachholen ,,ausgelassener Perioden'' nicht möglich - \item - ,,gierige'' Prozesse: Prozessorentzug, sobald andere lauffähige + \item ,,gierige'' Prozesse: Prozessorentzug, sobald andere lauffähige Prozesse frühere Fristen aufweisen - \item - nicht-periodische Hintergrundprozesse: pro ,,Periode'' wird + \item nicht-periodische Hintergrundprozesse: pro ,,Periode'' wird spezifizierte Prozessorrate garantiert (z.B. kleine Raten bei großen ,,Periodendauern'' wählen.) \end{itemize*} @@ -3307,8 +2687,7 @@ Prozessmengen} \begin{itemize*} - \item - Hintergrund-Scheduling: + \item Hintergrund-Scheduling: \begin{itemize*} \item Prinzip: %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-gemischte-prozessmenge.png} \item rechenbereite Prozesse auf 2 Warteschlangen aufgeteilt (einfache Variante eines Mehr-Ebenen-Scheduling ) @@ -3322,19 +2701,16 @@ Nachteile} \begin{itemize*} - \item - Hauptvorteil: + \item Hauptvorteil: \begin{itemize*} \item einfache Implementierung \end{itemize*} - \item - Nachteile: + \item Nachteile: \begin{itemize*} \item Antwortzeit \textbf{aperiodischer Prozesse} kann zu lang werden (insbesondere bei hoher aperiodischer Last) $\rightarrow$ Verhungern möglich! \item geeignet nur für relativ zeitunkritische aperiodische Prozesse \end{itemize*} - \item - Beispiel: Hintergrund-Scheduling mit RM + \item Beispiel: Hintergrund-Scheduling mit RM %\begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-hintergrund-scheduling.png} %\end{itemize*} @@ -3345,8 +2721,7 @@ Server-Prozess} \begin{itemize*} - \item - Scheduling mit Server-Prozessen: + \item Scheduling mit Server-Prozessen: \begin{itemize*} \item Prinzip: periodisch aktivierter Prozess benutzt zur Ausführung aperiodischer Prozessoranforderungen \item Beschreibung Server-Prozess: durch Parameter äquivalent zu wirklichem periodischen Prozess: \begin{itemize*} \item Periodendauer $T_S$ \item ,,Prozessorzeitbedarf'' $C_S$; jetzt Kapazitätdes Server-Prozesses \end{itemize*} @@ -3365,23 +2740,17 @@ Slack-Stealing} \begin{itemize*} - \item - Prinzip: Es existiert passiver Prozess ,,slack stealer'' (kein + \item Prinzip: Es existiert passiver Prozess ,,slack stealer'' (kein periodischer Server) - \item - versucht so viel Zeit wie möglich für aperiodische Anforderungen zu + \item versucht so viel Zeit wie möglich für aperiodische Anforderungen zu sammeln - \item - realisiert durch ,,slackstealing''(= Spielraum-Stehlen) bei + \item realisiert durch ,,slackstealing''(= Spielraum-Stehlen) bei periodischen Prozessen - \item - letztere auf Zeit-Achse so weit nach hinten geschoben, dass Frist und + \item letztere auf Zeit-Achse so weit nach hinten geschoben, dass Frist und Beendigungszeitpunkt zusammenfallen - \item - Sinnvoll, da normalerweise Beenden periodischer Prozesse vor ihrer + \item Sinnvoll, da normalerweise Beenden periodischer Prozesse vor ihrer Frist keinerlei Vorteile bringt - \item - Resultat: Verbesserung der Antwortzeiten für aperiodische + \item Resultat: Verbesserung der Antwortzeiten für aperiodische Anforderungen %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-slack-stealing.png} \end{itemize*} @@ -3398,15 +2767,13 @@ \paragraph{Problem} \begin{itemize*} - \item - Prinzip \emph{kritischer Abschnitt} (Grundlagen BS): + \item Prinzip \emph{kritischer Abschnitt} (Grundlagen BS): \begin{itemize*} \item Sperrmechanismen stellen wechselseitigen Ausschluss bei der Benutzung exklusiver Betriebsmittel durch nebenläufige Prozesse sicher \item Benutzung von exklusiven sowie nichtentziehbaren Betriebsmitteln: kritischer Abschnitt - \item Folge: Wenn ein Prozess einen kritischen Abschnitt betreten hat, darf er aus diesem nicht verdrängt werden (durch anderen Prozess, der dasselbe Betriebsmittel nutzen will) + \item[$\rightarrow$] Wenn ein Prozess einen kritischen Abschnitt betreten hat, darf er aus diesem nicht verdrängt werden (durch anderen Prozess, der dasselbe Betriebsmittel nutzen will) \end{itemize*} - \item - Konflikt: kritische Abschnitte vs. Echtzeit-Prioritäten + \item Konflikt: kritische Abschnitte vs. Echtzeit-Prioritäten \begin{itemize*} \item Falls ein weiterer Prozess mit höherer Priorität ablauffähig wird und im gleichen kritischen Abschnitt arbeiten will, muss er warten bis niederpriorisierter Prozess kritischen Abschnitt verlassen hat \item (zeitweise) Prioritätsumkehr möglich! d.h. aus einer (Teil-) Menge von Prozessen muss derjenige mit höchster Priorität auf solche mit niedrigerer Priorität warten @@ -3419,11 +2786,9 @@ \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-prioritätsumkehr-ursache.png} - \item - Prioritätsumkehr bei Blockierung an nichtentziehbarem, exklusivem + \item Prioritätsumkehr bei Blockierung an nichtentziehbarem, exklusivem Betriebsmittel - \item - $\rightarrow$ unvermeidlich + \item $\rightarrow$ unvermeidlich \end{itemize*} @@ -3431,11 +2796,9 @@ Prioritätsumkehr} \begin{itemize*} - \item - Kritisch bei zusätzlichen Prozessen mittlerer Priorität + \item Kritisch bei zusätzlichen Prozessen mittlerer Priorität %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-prioritätsumkehr-folgen.png} - \item - Lösung: Priority Inheritance Protocol (PIP) + \item Lösung: Priority Inheritance Protocol (PIP) \end{itemize*} @@ -3443,29 +2806,24 @@ Prioritätsvererbung} \begin{itemize*} - \item - ![Abb. nach [Buttazzo97] , Bild 7.6, S.188] - \item - ePrio ... effektive Priorität + \item ![Abb. nach [Buttazzo97] , Bild 7.6, S.188] + \item ePrio ... effektive Priorität \end{itemize*} \subsubsection{Überlast} \begin{itemize*} - \item - Definition: kritische Situation - bei der die benötigte Menge an + \item Definition: kritische Situation - bei der die benötigte Menge an Prozessorzeit die Kapazität des vorhandenen Prozessors übersteigt $(U\textgreater1)$ \begin{itemize*} - \item Folge: nicht alle Prozesse können Fristen einhalten + \item[$\rightarrow$] nicht alle Prozesse können Fristen einhalten \end{itemize*} - \item - Hauptrisiko: kritische Prozesse können Fristen nicht einhalten + \item Hauptrisiko: kritische Prozesse können Fristen nicht einhalten $\rightarrow$ Gefährdung funktionaler und anderer nichtfkt. Eigenschaften ( $\rightarrow$ harte Fristen!) - \item - Stichwort: ,,graceful degradation'' (,,würdevolle'' Verschlechterung) + \item Stichwort: ,,graceful degradation'' (,,würdevolle'' Verschlechterung) statt unkontrollierbarer Situation $\rightarrow$ Wahrung von Determinismus \end{itemize*} @@ -3475,13 +2833,11 @@ Prozesses} \begin{itemize*} - \item - Minimallösung: (lebenswichtig für Echtzeit-System) + \item Minimallösung: (lebenswichtig für Echtzeit-System) \begin{itemize*} \item Unterscheidung zwischen Zeitbeschränkungen (Fristen) und tatsächlicher Wichtigkeit eines Prozesses für System \end{itemize*} - \item - Allgemein gilt: + \item Allgemein gilt: \begin{itemize*} \item Wichtigkeit eines Prozesses ist unabhängig von seiner Periodendauer und irgendwelchen Fristen \item z.B. kann ein Prozess trotz späterer Frist viel wichtiger als anderer mit früherer Frist sein. @@ -3494,20 +2850,17 @@ Analogien} \begin{enumerate*} - \item - Weglassen weniger wichtiger Aktionen + \item Weglassen weniger wichtiger Aktionen \begin{itemize*} \item ohne Frühstück aus dem Haus... \item kein Zähneputzen ... \item Wichtung vom Problem bzw. Aktivitätsträgern (hier: Personen) abhängig! \end{itemize*} - \item - Verkürzen von Aktivitäten + \item Verkürzen von Aktivitäten \begin{itemize*} \item Katzenwäsche... \end{itemize*} - \item - Kombinieren + \item Kombinieren \begin{itemize*} \item kein Frühstück + Katzenwäsche + ungekämmt \end{itemize*} @@ -3519,14 +2872,11 @@ Behandlung: \begin{itemize*} - \item - zusätzlicher Parameter V (Wert) für jeden Prozess/Thread einer + \item zusätzlicher Parameter V (Wert) für jeden Prozess/Thread einer Anwendung - \item - spezifiziert relative Wichtigkeit eines Prozesses (od. Thread) im + \item spezifiziert relative Wichtigkeit eines Prozesses (od. Thread) im Verhältnis zu anderen Prozessen (Threads) der gleichen Anwendung - \item - bei Scheduling: V stellt zusätzliche Randbedingung (primär: Priorität + \item bei Scheduling: V stellt zusätzliche Randbedingung (primär: Priorität aufgrund von Frist, sekundär: Wichtigkeit) \end{itemize*} @@ -3535,14 +2885,11 @@ Prozessanteil} \begin{itemize*} - \item - Aufteilung der Gesamtberechnung $(C_{ges})$ eines Prozesses in + \item Aufteilung der Gesamtberechnung $(C_{ges})$ eines Prozesses in zwei Phasen - \item - einfache Möglichkeit der Nutzung des Konzepts des anpassbaren + \item einfache Möglichkeit der Nutzung des Konzepts des anpassbaren Prozessorzeitbedarfs - \item - Prinzip: + \item Prinzip: \begin{itemize*} \item Bearbeitungszeitbedarf eines Prozesses zerlegt in \begin{enumerate*} \item obligatorischer Teil (Pflichtteil, $C_{ob}$): muss unbedingt u. immer ausgeführt werden $\rightarrow$ liefert bedingt akzeptables Ergebnis \item optionaler Teil $(C_{opt})$: nur bei ausreichender Prozessorkapazität ausgeführt $\rightarrow$ verbessert durch obligatorischen Teil erzieltes Ergebnis \end{enumerate*} \item Prinzip in unterschiedlicher Weise verfeinerbar @@ -3554,18 +2901,15 @@ \subsubsection{Echtzeit-Interruptbehandlung} \begin{enumerate*} - \item - Fristüberschreitung durch ungeeignete Interruptbearbeitung + \item Fristüberschreitung durch ungeeignete Interruptbearbeitung %\begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-interruptbehandlung-fristüberschreitung.png} %\end{itemize*} - \item - Lösung für Echtzeitsysteme ohne Fristüberschreitung + \item Lösung für Echtzeitsysteme ohne Fristüberschreitung \begin{itemize*} \item Interrupt wird zunächst nur registriert (deterministischer Zeitaufwand) \item tatsächliche Bearbeitung der Interruptroutine muss durch Scheduler eingeplant werden $\rightarrow$ Pop-up Thread - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-interruptbehandlung-lösung.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-interruptbehandlung-lösung.png} \end{itemize*} \end{enumerate*} @@ -3573,14 +2917,12 @@ \subsubsection{Echtzeit-Speicherverwaltung} \begin{itemize*} - \item - Prinzip: + \item Prinzip: \begin{itemize*} \item Hauptanliegen: auch hier Fristen einhalten \item wie bei Interrupt-Bearbeitung und Prioritätsumkehr: unkontrollierbare Verzögerungen der Prozessbearbeitung (= zeitlicher Nichtdeterminismus) vermeiden! \end{itemize*} - \item - Ressourcenzuordnung, deswegen: + \item Ressourcenzuordnung, deswegen: \begin{enumerate*} \item keine Ressourcen-Zuordnung ,,on-demand'' (d.h. in dem Moment, wo sie benötigt werden) sondern ,,Pre-Allokation'' (= Vorab-Zuordnung) @@ -3592,8 +2934,7 @@ \paragraph{Hauptspeicherverwaltung} \begin{itemize*} - \item - bei Anwendung existierender Paging-Systeme + \item bei Anwendung existierender Paging-Systeme \begin{itemize*} \item durch unkontrolliertes Ein-/Auslagern ,,zeitkritischer'' Seiten (-inhalte): unkontrollierbare Zeitverzögerungen möglich! \item Technik hier: ,,Festnageln'' von Seiten im Speicher (Pinning, Memory Locking) @@ -3604,43 +2945,35 @@ \paragraph{Sekundärspeicherverwaltung} \begin{itemize*} - \item - Beispiel 1: FCFS Festplattenscheduling + \item Beispiel 1: FCFS Festplattenscheduling \begin{itemize*} \item Anforderungsreihenfolge = 98, 183, 37, 122, 14, 124, 65, 67 \item Zuletzt gelesener Block: 53 - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-sekundärspeicherverwaltung-fcfs.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-sekundärspeicherverwaltung-fcfs.png} \end{itemize*} - \item - Beispiel 2: EDF Festplattenscheduling + \item Beispiel 2: EDF Festplattenscheduling \begin{itemize*} \item Anforderungsreihenfolge $t_1 = 98, 37, 124, 65$ \item Anforderungsreihenfolge $t_2 = 183, 122, 14, 67$ \item Zuletzt gelesener Block: 53 | | $a_i$ | $d_i$ | | ----- | ----- | ----- | | $t_1$ | 0 | 3 | | $t_2$ | 0 | 9 | - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-sekundärspeicherverwaltung-edf.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-sekundärspeicherverwaltung-edf.png} \end{itemize*} - \item - Primärziel: Wahrung der Echtzeitgarantien + \item Primärziel: Wahrung der Echtzeitgarantien \begin{itemize*} \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 - Resultat bei HDDs: + \item Resultat bei HDDs: \begin{itemize*} \item ineffiziente Bewegungen der Lese-/Schreibköpfe -ähnlich FCFS \item nichtdeterministische Positionierzeiten \item geringer Durchsatz \end{itemize*} - \item - Fazit: + \item Fazit: \begin{itemize*} \item Echtzeit-Festplattenscheduling $\rightarrow$ Kompromiss zwischen Zeitbeschränkungen und Effizienz \end{itemize*} - \item - bekannte Lösungen: + \item bekannte Lösungen: \begin{enumerate*} \item Modifikation von EDF @@ -3651,23 +2984,18 @@ $\rightarrow$ realisierte Strategien: \begin{enumerate*} - \item - SCAN-EDF (SCAN: Kopfbewegung nur in eine Richtung bis + \item SCAN-EDF (SCAN: Kopfbewegung nur in eine Richtung bis Mitte-/Randzylinder; EDF über alle angefragten Blöcke \emph{in dieser Richtung} ) - \item - Group Sweeping (SCAN mit nach Fristen gruppenweiser Bedienung) - \item - Mischstrategien + \item Group Sweeping (SCAN mit nach Fristen gruppenweiser Bedienung) + \item Mischstrategien \end{enumerate*} \begin{itemize*} - \item - Vereinfachung: + \item Vereinfachung: \begin{itemize*} \item o.g. Algorithmen i.d.R. zylinderorientiert $\rightarrow$ berücksichtigen bei Optimierung nur Positionierzeiten (Grund: Positionierzeit meist $>>$ Latenzzeit) - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-sekundärspeicherverwaltung-festplatte.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-sekundärspeicherverwaltung-festplatte.png} \end{itemize*} \end{itemize*} @@ -3676,8 +3004,7 @@ Synchronisation} \begin{itemize*} - \item - zeitlichen Nichtdeterminismus vermeiden: + \item zeitlichen Nichtdeterminismus vermeiden: \begin{enumerate*} \item Interprozess-Kommunikation @@ -3705,16 +3032,13 @@ Kommunikation zwischen 1 Sender und n Empfängern: \begin{itemize*} - \item - nach erstem Schreibzugriff: garantiert niemals undefinierte + \item nach erstem Schreibzugriff: garantiert niemals undefinierte Wartezeiten durch Blockierung von Sender/Empfänger - \item - Lesen/Überschreiben in zyklischer Reihenfolge: + \item Lesen/Überschreiben in zyklischer Reihenfolge: %\begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-kommunikation-zyklisch-cab.png} %\end{itemize*} - \item - Implementierung: + \item Implementierung: \begin{itemize*} \item MRW: Most-Recently-Written; Zeiger auf jüngstes, durch Sender vollständig geschriebenes Element \item LRW: Least-Recently-Written; Zeiger auf ältestes durch Sender geschriebenes Element @@ -3722,34 +3046,27 @@ \item Regeln für Sender: \begin{itemize*} \item muss \textbf{nach} jedem Schreiben \emph{MRW} auf geschriebenes Element setzen \item muss \textbf{bevor} \emph{LRW} geschrieben wird \emph{LRW} inkrementieren \end{itemize*} \item Regel für Empfänger: muss immer nach Lesen von \emph{MRW} als nächstes \emph{LRW} anstelle des Listennachbarn lesen \end{itemize*} - \item - Sender-Regeln: + \item Sender-Regeln: \begin{itemize*} \item anschaulich, ohne aktiven Empfänger - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-cab-sender-regel.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-cab-sender-regel.png} \end{itemize*} - \item - Empfänger-Regel: + \item Empfänger-Regel: \begin{itemize*} \item anschaulich, ohne aktiven Sender - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-cab-empfänger.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-cab-empfänger.png} \end{itemize*} \end{itemize*} Sonderfall 1: Empfänger schneller als Sender \begin{itemize*} - \item - nach Zugriff auf MRW muss auf Lesesequenz bei LRW fortgesetzt werden + \item nach Zugriff auf MRW muss auf Lesesequenz bei LRW fortgesetzt werden $\rightarrow$ transparenter Umgang mit nicht-vollem Puffer - \item - Abschwächung der Ordnungsgarantien:Empfänger weiß nur, dass Aktualität + \item Abschwächung der Ordnungsgarantien:Empfänger weiß nur, dass Aktualität der Daten zwischen LRW und MRW liegt - \item - Empfänger (nach min. einem geschriebenen Element) niemals durch leeren + \item Empfänger (nach min. einem geschriebenen Element) niemals durch leeren Puffer blockiert %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-cab-sonderfall-1.png} \end{itemize*} @@ -3757,15 +3074,12 @@ Sonderfall 2: Sender schneller als Empfänger \begin{itemize*} - \item - Schreiben in Puffer grundsätzlich in Reihenfolge der Elemente + \item Schreiben in Puffer grundsätzlich in Reihenfolge der Elemente $\rightarrow$ keine blockierenden Puffergrenzen $\rightarrow$ niemals Blockierung des Senders - \item - keine Vollständigkeitsgarantien:Empfänger kann nicht sicher sein, eine + \item keine Vollständigkeitsgarantien:Empfänger kann nicht sicher sein, eine temporal stetige Sequenz zu lesen - \item - $\rightarrow$ Szenarien, in denen Empfänger sowieso + \item $\rightarrow$ Szenarien, in denen Empfänger sowieso nur an aktuellsten Daten interessiert (z.B. Sensorwerte) %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-cab-sonderfall-2.png} \end{itemize*} @@ -3773,13 +3087,10 @@ Konkurrierende Zugriffe: \begin{itemize*} - \item - ... sind durch Empfänger immer unschädlich (da lesend) - \item - ... müssen vom Sender nach Inkrementieren von LRW nicht-blockierend + \item ... sind durch Empfänger immer unschädlich (da lesend) + \item ... müssen vom Sender nach Inkrementieren von LRW nicht-blockierend erkannt werden (klassisches Semaphormodell ungeeignet) - \item - schnellerer Sender überspringtein gesperrtes Element durch erneutes + \item schnellerer Sender überspringtein gesperrtes Element durch erneutes Inkrementieren von LRW , muss MRW trotzdem nachziehen %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-cab-konkurrierende-zugriffe.png} \end{itemize*} @@ -3789,14 +3100,12 @@ Beispiel-Betriebssysteme} \begin{itemize*} - \item - Architekturprinzipien: + \item Architekturprinzipien: \begin{itemize*} \item müssen Echtzeitmechanismen unterstützen; ermöglicht entsprechende Strategien zur Entwicklungs-oder Laufzeit (CPU-Scheduler, EA-Scheduler, IPC ...) \item müssen funktional geringe Komplexität aufweisen $\rightarrow$ theoretische und praktische Beherrschung von Nichtdeterminismus \begin{itemize*} \item Theoretisch: Modellierung und Analyse (vgl. Annahmen für Scheduling-Planbarkeitsanalyse) \item Praktisch: Implementierung (vgl. RC-Scheduler, Prioritätsvererbung) \end{itemize*} \end{itemize*} - \item - Konsequenzen: + \item Konsequenzen: \begin{itemize*} \item Architekturen für komplementäre NFE: \begin{itemize*} \item Sparsamkeit $\rightarrow$ hardwarespezifische Kernelimplementierung \item Adaptivität $\rightarrow$ $\mu$Kernel, Exokernel \end{itemize*} \item zu vermeiden: \begin{itemize*} \item starke Hardwareabstraktion $\rightarrow$ Virtualisierungsarchitekturen \item Kommunikation und Synchronisationskosten $\rightarrow$ verteilte BS \item Hardwareunabhängigkeit und Portabilität $\rightarrow$ vgl. Mach \end{itemize*} @@ -3806,16 +3115,14 @@ Auswahl: Beispiel-Betriebssysteme \begin{itemize*} - \item - wir kennen schon: + \item wir kennen schon: \begin{itemize*} \item funktional kleine Kernelimplementierung: TinyOS \item hardwarespezifischer $\mu$Kernel: L4-Abkömmlinge \item Mischung aus beidem: RIOT \item Kommerziell bedeutender $\mu$Kernel: QNX Neutrino \end{itemize*} - \item - weitere Vertreter: + \item weitere Vertreter: \begin{itemize*} \item hardwarespezifische Makrokernel: VRTX, VxWorks \item $\mu$Kernel: DRYOS, DROPS @@ -3826,28 +3133,24 @@ VRTX (Versatile Real-Time Executive) \begin{itemize*} - \item - Entwickler: + \item Entwickler: \begin{itemize*} \item Hunter \& Ready \end{itemize*} - \item - Eckdaten: + \item Eckdaten: \begin{itemize*} \item Makrokernel \item war erstes kommerzielles Echtzeitbetriebssystem für eingebettete Systeme \item heutige Bedeutung eher historisch \item Nachfolger (1993 bis heute): Nucleus RTOS (Siemens) \end{itemize*} - \item - Anwendung: + \item Anwendung: \begin{itemize*} \item Eingebettete Systeme in Automobilen(Brems-und ABS-Controller) \item Mobiltelefone \item Geldautomaten \end{itemize*} - \item - Einsatzgebiete + \item Einsatzgebiete \begin{itemize*} \item spektakulär: im Hubble-Weltraumteleskop \end{itemize*} @@ -3856,29 +3159,25 @@ VxWorks \begin{itemize*} - \item - Entwickler: + \item Entwickler: \begin{itemize*} \item Wind River Systems (USA) \end{itemize*} - \item - Eckdaten: + \item Eckdaten: \begin{itemize*} \item modularer Makrokernel \item Konkurrenzprodukt zu VRTX \item Erfolgsfaktor: POSIX-konforme API \item ähnlich QNX: ,,skalierbarer'' Kernel,zuschneidbarauf Anwendungsdomäne ( $\rightarrow$ Adaptivitätsansatz) \end{itemize*} - \item - Anwendung: + \item Anwendung: \begin{itemize*} \item eingebettete Systeme: \item industrielle Robotersteuerung \item Luft-und Raumfahrt \item Unterhaltungselektronik \end{itemize*} - \item - Einsatzgebiete + \item Einsatzgebiete \begin{itemize*} \item Deep-Impact-Mission zur Untersuchung des Kometen Temple 1 \item NASA Mars Rover @@ -3889,10 +3188,8 @@ DRYOS® \begin{itemize*} - \item - Entwickler: Canon Inc. - \item - Eckdaten: + \item Entwickler: Canon Inc. + \item Eckdaten: \begin{itemize*} \item Mikrokernel(Größe: 16 kB) \item Echtzeit-Middleware (Gerätetreiber $\rightarrow$ Objektive) @@ -3905,10 +3202,8 @@ DROPS (Dresden Real-Time Operating System) \begin{itemize*} - \item - Entwickler: TU Dresden, Lehrstuhl Betriebssysteme - \item - Eckdaten: Multi-Server-Architektur auf Basis eines L4-Mikrokerns + \item Entwickler: TU Dresden, Lehrstuhl Betriebssysteme + \item Eckdaten: Multi-Server-Architektur auf Basis eines L4-Mikrokerns %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-drops.png} \end{itemize*} @@ -3919,19 +3214,16 @@ \subsection{Motivation} \begin{itemize*} - \item - als unmittelbar geforderte NFE: + \item als unmittelbar geforderte NFE: \begin{itemize*} \item eingebettete Systeme \item Systeme in garstiger Umwelt (Meeresgrund, Arktis, Weltraum, ...) \item Unterstützung von Cloud-Computing-Anwendungen \item Unterstützung von Legacy-Anwendungen \end{itemize*} - \item - Beobachtung: genau diese Anwendungsdomänen fordern typischerweise auch + \item Beobachtung: genau diese Anwendungsdomänen fordern typischerweise auch andere wesentliche NFE (s.bisherige Vorlesung ...) - \item - $\rightarrow$ Adaptivität als komplementäre NFE zur + \item $\rightarrow$ Adaptivität als komplementäre NFE zur Förderung von \begin{itemize*} \item Robustheit: funktionale Adaptivitätdes BS reduziert Kernelkomplexität ( $\rightarrow$ kleiner, nicht adaptiver $\mu$Kernel) @@ -3948,16 +3240,13 @@ \subsection{Adaptivitätsbegriff} \begin{itemize*} - \item - Adaptability: ,,see Flexibility. '' [Marciniak94] - \item - Flexibility: + \item Adaptability: ,,see Flexibility. '' [Marciniak94] + \item Flexibility: \begin{itemize*} \item ,,The ease with which a system or a component can be modified for use in applications or environments other than those for which it was specifically designed.'' (IEEE) \item für uns: entspricht Erweiterbarkeit \end{itemize*} - \item - Adaptivität: (unsere Arbeitsdefinition) + \item Adaptivität: (unsere Arbeitsdefinition) \begin{itemize*} \item Die Fähigkeit eines Systems, sich an ein breites Spektrum verschiedener Anforderungen anpassen zu lassen. \item = ... so gebaut zu sein, dass ein breites Spektrum verschiedener nicht funktionaler Eigenschaften unterstützt wird. @@ -3969,17 +3258,14 @@ \subsection{Roadmap} \begin{itemize*} - \item - in diesem Kapitel: gleichzeitig Mechanismen und Architekturkonzepte - \item - Adaptivität jeweils anhand komplementärer Eigenschaften dargestellt: + \item in diesem Kapitel: gleichzeitig Mechanismen und Architekturkonzepte + \item Adaptivität jeweils anhand komplementärer Eigenschaften dargestellt: \begin{itemize*} \item Exokernel: \{ Adaptivität \} $\cup$ \{ Performanz, Echtzeitfähigkeit,Wartbarkeit, Sparsamkeit \} \item Virtualisierung: \{ Adaptivität \} $\cup$ \{ Wartbarkeit, Sicherheit, Robustheit \} \item Container: \{ Adaptivität \} $\cup$ \{ Wartbarkeit, Portabilität, Sparsamkeit \} \end{itemize*} - \item - Beispielsysteme: + \item Beispielsysteme: \begin{itemize*} \item Exokernel-Betriebssysteme: Aegis/ExOS, Nemesis, MirageOS \item Virtualisierung: Vmware, VirtualBox, Xen @@ -3991,16 +3277,13 @@ \subsection{Exokernelarchitektur} \begin{itemize*} - \item - Grundfunktion von Betriebssystemen + \item Grundfunktion von Betriebssystemen \begin{itemize*} \item physische Hardware darstellen als abstrahierte Hardware mit komfortableren Schnittstellen - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-exokernelarchitekturen.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-exokernelarchitekturen.png} \item Schnittstelle zu Anwendungen (API) : bietet dabei exakt die gleichen Abstraktionen der Hardware für alle Anwendungen an, z.B. \begin{itemize*} \item \textbf{Prozesse:} gleiches Zustandsmodell, gleiches Threadmodell \item \textbf{Dateien:} gleiche Namensraumabstraktion \item \textbf{Adressräume:} gleiche Speicherverwaltung (VMM, Seitengröße, Paging) \item \textbf{Interprozesskommunikation:} gleiche Mechanismen für alle Anwendungsprozesse \end{itemize*} \end{itemize*} - \item - Problem: + \item Problem: \begin{itemize*} \item Implementierungsspielraumfür Anwendungen wird begrenzt: \end{itemize*} @@ -4010,8 +3293,7 @@ \item die Implementierung existierender Abstraktionen kann bei veränderten Anforderungen nicht an Anwendungen angepasst werden $\rightarrow$ \textbf{Wartbarkeit} \item Hardwarespezifikationen, insbesondere des Zeitverhaltens (E/A, Netzwerk etc.), werden von Effekten des BS-Management überlagert $\rightarrow$ \textbf{Echtzeitfähigkeit} \end{enumerate*} - \item - Idee von Exokernel-Architekturen: + \item Idee von Exokernel-Architekturen: %\begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-exokernel-architektur.png} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-exokernel-beispiel.png} @@ -4022,29 +3304,25 @@ \subsubsection{Exokernelmechanismen} \begin{itemize*} - \item - Designprinzip von Exokernelmechanismen: + \item Designprinzip von Exokernelmechanismen: \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 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 - Funktion des Exokernels: + \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 ( $\rightarrow$ Gerätetreiber $\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*} - \item - prinzipielle Exokernelmechanismen am Beispiel Aegis/ExOS + \item prinzipielle Exokernelmechanismen am Beispiel Aegis/ExOS [Engler+95] \begin{itemize*} \item Der Exokernel... \begin{itemize*} \item \emph{implementiert:} Multiplexing der Hardware-Ressourcen \item \emph{exportiert:} geschützte Hardware-Ressourcen \end{itemize*} \end{itemize*} - \item - minimal: drei Arten von Mechanismen + \item minimal: drei Arten von Mechanismen \begin{enumerate*} \item Secure Binding: erlaubt geschützte Verwendung von Hardware-Ressourcen durch Anwendungen, Behandlung von Ereignissen @@ -4057,26 +3335,21 @@ \subsubsection{Secure Binding} \begin{itemize*} - \item - Schutzmechanismus, der Autorisierung ( $\rightarrow$ + \item Schutzmechanismus, der Autorisierung ( $\rightarrow$ Library-BS)zur Benutzung einer Ressource von tatsächlicher Benutzung ( $\rightarrow$ Exokernel) trennt - \item - implementiert für den Exokernelerforderliches Zuordnungswissenvon + \item implementiert für den Exokernelerforderliches Zuordnungswissenvon (HW-)Ressource zu Mangement-Code (der im Library-BS implementiert ist) - \item - $\rightarrow$ ''Binding'' in Aegis implementiert als + \item $\rightarrow$ ''Binding'' in Aegis implementiert als Unix-Hardlinkauf Metadatenstruktur zu einem Gerät im Kernelspeicher ( ,,remember: everythingisa file...'' ) - \item - Zur Implementierung benötigt: + \item Zur Implementierung benötigt: \begin{itemize*} \item Hardware-Unterstützung zur effizienten Rechteprüfung (insbes. HW-Caching) \item Software-Caching von Autorisierungsentscheidungen im Kernel (bei Nutzung durch verschiedene Library-BS) \item Downloadingvon Applikationscode in Kernel zur effizienten Durchsetzung (quasi: User-Space-Implementierung von Systemaufrufcode) \end{itemize*} - \item - einfach ausgedrückt: ,,Secure Binding'' erlaubt einem ExokernelSchutz + \item einfach ausgedrückt: ,,Secure Binding'' erlaubt einem ExokernelSchutz von Ressourcen, ohne deren Semantik verstehen zu müssen. \end{itemize*} @@ -4085,16 +3358,14 @@ Revocation} \begin{itemize*} - \item - monolithische Betriebssysteme: entziehen Ressourcen ,,unsichtbar'' + \item monolithische Betriebssysteme: entziehen Ressourcen ,,unsichtbar'' (invisible), d.h. transparent für Anwendungen \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! \end{itemize*} - \item - Exokernel-Betriebssysteme: entziehen(überwiegend) Ressourcen + \item Exokernel-Betriebssysteme: entziehen(überwiegend) Ressourcen ,,sichtbar'' $\rightarrow$ Dialog zwischen Exokernel und Library-BS \begin{itemize*} @@ -4108,14 +3379,11 @@ \subsubsection{Abort - Protokoll} \begin{itemize*} - \item - Ressourcenentzug bei unkooperativen Library-Betriebssystemen ( + \item Ressourcenentzug bei unkooperativen Library-Betriebssystemen ( Konflikt mit Anforderung durch andere Anwendung/deren Library-BS: Verweigerung der Rückgabe, zu späte Rückgabe, ...) - \item - notwendig aufgrund von Visible Ressource Revocation - \item - Dialog: + \item notwendig aufgrund von Visible Ressource Revocation + \item Dialog: \begin{itemize*} \item Exokernel: ,,Bitte Seitenrahmen x freigeben.'' \item Library-BS: ,,...'' @@ -4124,8 +3392,7 @@ \item Exokernel: (führt Abort-Protokoll aus) \item Library-BS: X (,,Abort'' in diesem Bsp. = Anwendungsprozess terminieren) \end{itemize*} - \item - In der Praxis: + \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 ermöglicht sinnvolle Reaktion des Library-BS (in Library-BS wird ,,Repossession''-Exceptionausgelöst, so dass auf Entzug geeignet reagiert werden kann) @@ -4137,8 +3404,7 @@ \subsubsection{Exokernelperformanz} \begin{itemize*} - \item - Was macht Exokern-Architekturen adaptiv(er)? + \item Was macht Exokern-Architekturen adaptiv(er)? \begin{itemize*} \item Abstraktionen und Mechanismen des Betriebssystems können den Erfordernissen der Anwendungen angepasst werden \item (erwünschtes) Ergebnis: beträchtliche Performanzsteigerungen (vgl. komplementäre Ziel-NFE: Performanz, Echtzeitfähigkeit, Wartbarkeit, Sparsamkeit ) @@ -4148,80 +3414,61 @@ Performanzstudien \begin{enumerate*} - \item - Aegis mit Library-BS ExOS (MIT: Dawson Engler, Frans Kaashoek) - \item - Xok mit Library-BS ExOS (MIT) - \item - Nemesis (Pegasus-Projekt, EU) - \item - XOmB (U Pittsburgh) - \item - ... + \item Aegis mit Library-BS ExOS (MIT: Dawson Engler, Frans Kaashoek) + \item Xok mit Library-BS ExOS (MIT) + \item Nemesis (Pegasus-Projekt, EU) + \item XOmB (U Pittsburgh) + \item ... \end{enumerate*} Aegis/ExOSals erweiterte Machbarkeitsstudie [Engler+95] \begin{enumerate*} - \item - machbar: sehr effiziente Exokerne + \item machbar: sehr effiziente Exokerne \begin{itemize*} \item Grundlage: begrenzte Anzahl einfacher Systemaufrufe (Größenordnung ~10) und Kernel-interne Primitiven (,,Pseudo-Maschinenanweisungen''), die enthalten sein müssen \end{itemize*} - \item - machbar: sicheres Hardware-Multiplexing auf niedriger + \item machbar: sicheres Hardware-Multiplexing auf niedriger Abstraktionsebene (,,low-level'') mit geringem Overhead - \item - traditionelle Abstraktionen (VMM, IPC) auf Anwendungsebene effizient + \item traditionelle Abstraktionen (VMM, IPC) auf Anwendungsebene effizient implementierbar $\rightarrow$ einfache Erweiterbarkeit, Spezialisierbarkeitbzw. Ersetzbarkeit dieser Abstraktionen - \item - für Anwendungen: hochspezialisierte Implementierungen von + \item für Anwendungen: hochspezialisierte Implementierungen von Abstraktionen generierbar, die genau auf Funktionalität und Performanz-Anforderungen dieser Anwendung zugeschnitten - \item - geschützte Kontrollflussübergabe: als IPC-Primitive im Aegis-Kernel, + \item geschützte Kontrollflussübergabe: als IPC-Primitive im Aegis-Kernel, 7-mal schnellerals damals beste Implementierung (vgl. [Liedtke95], Kap. 3) - \item - Ausnahmebehandlung bei Aegis: 5-mal schneller als bei damals bester + \item Ausnahmebehandlung bei Aegis: 5-mal schneller als bei damals bester Implementierung - \item - durch Aegis möglich: Flexibilität von ExOS, die mit + \item durch Aegis möglich: Flexibilität von ExOS, die mit Mikrokernel-Systemen nicht erreichbar ist: \begin{itemize*} \item Bsp. VMM: auf Anwendungsebene implementiert, wo diese sehr einfach mit DSM-Systemen u. Garbage-Kollektoren verknüpfbar \end{itemize*} - \item - Aegis erlaubt Anwendungen Konstruktion effizienter IPC-Primitiven ($\Delta \mu$Kernel: nicht vertrauenswürdige Anwendungen können keinerlei spezialisierte IPC-Primitiven nutzen, geschweige denn selbst implementieren) + \item Aegis erlaubt Anwendungen Konstruktion effizienter IPC-Primitiven ($\Delta \mu$Kernel: nicht vertrauenswürdige Anwendungen können keinerlei spezialisierte IPC-Primitiven nutzen, geschweige denn selbst implementieren) \end{enumerate*} Xok/ExOS \begin{itemize*} - \item - praktische Weiterentwicklung von Aegis: Xok - \item - für x86-Hardware implementiert - \item - Kernel-Aufgaben (wie gehabt): Multiplexing von Festplatte, Speicher, + \item praktische Weiterentwicklung von Aegis: Xok + \item für x86-Hardware implementiert + \item Kernel-Aufgaben (wie gehabt): Multiplexing von Festplatte, Speicher, Netzwerkschnittstellen, ... - \item - Standard Library-BS (wie bei Aegis): ExOS + \item Standard Library-BS (wie bei Aegis): ExOS \begin{itemize*} \item ,,Unix as a Library'' \item Plattform für unmodifizierte Unix-Anwendungen (csh, perl, gcc, telnet, ftp, ...) \end{itemize*} - \item - z.B. Library-BS zum Dateisystem-Management: C-FFS + \item 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( $\rightarrow$ zusammenhängendes Lesen) \item Secure Bindings für Metadaten-Modifikation \end{itemize*} - \item - Forschungsziele: + \item Forschungsziele: \begin{itemize*} \item Aegis: Proof-of-Concept \item XOK: Proof-of-Feasibility (Performanz) @@ -4232,22 +3479,19 @@ Zwischenfazit: Exokernelarchitektur \begin{itemize*} - \item - Ziele: + \item Ziele: \begin{itemize*} \item Performanz, Sparsamkeit: bei genauer Kenntnis der Hardware ermöglicht deren direkte BenutzungAnwendungsentwicklern Effizienzoptimierung \item Wartbarkeit: Hardwareabstraktionen sollen flexibel an Anwendungsdomänen anpassbar sein, ohne das BS modifizieren/wechseln zu müssen \item Echtzeitfähigkeit: Zeitverhaltendes Gesamtsystems durch direkte Steuerung der Hardware weitestgehend durch (Echtzeit-) Anwendungen kontrollierbar \end{itemize*} - \item - Idee: + \item Idee: \begin{itemize*} \item User-Space:anwendungsspezifische Hardwareabstraktionen im User-Space implementiert \item Kernel-Space:nur Multiplexing und Schutz der HW-Schnittstellen \item in der Praxis: kooperativer Ressourcenentzug zwischen Kernel, Lib. OS \end{itemize*} - \item - Ergebnisse: + \item Ergebnisse: \begin{itemize*} \item hochperformanteHardwarebenutzung durch spezialisierte Anwendungen \item funktional kleiner Exokernel( $\rightarrow$ Sparsamkeit, Korrektheit des Kernelcodes ) @@ -4260,41 +3504,35 @@ \subsection{Virtualisierung} \begin{itemize*} - \item - Ziele (zur Erinnerung): + \item Ziele (zur Erinnerung): \begin{itemize*} \item Adaptivität \item Wartbarkeit, Sicherheit, Robustheit \item[$\rightarrow$] auf gleicher Hardware mehrere unterschiedliche Betriebssysteme ausführbar machen \end{itemize*} - \item - Idee: + \item Idee: %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-virtualisierung-idee.png} \end{itemize*} Ziele von Virtualisierung \begin{itemize*} - \item - Adaptivität: ( ähnlich wie bei Exokernen) + \item Adaptivität: ( ähnlich wie bei Exokernen) \begin{itemize*} \item können viele unterschiedliche Betriebssysteme - mit jeweils unterschiedlichen Eigenschaften ausgeführt werden damit können: Gruppen von Anwendungen auf ähnliche Weise jeweils unterschiedliche Abstraktionen etc. zur Verfügung gestellt werden \end{itemize*} - \item - Wartbarkeit: + \item Wartbarkeit: \begin{itemize*} \item Anwendungen - die sonst nicht gemeinsam auf gleicher Maschine lauffähig - auf einer phyischenMaschine ausführbar \item ökonomische Vorteile: Cloud-Computing, Wartbarkeit von Legacy-Anwendungen \end{itemize*} - \item - Sicherheit: + \item Sicherheit: \begin{itemize*} \item Isolation von Anwendungs-und Kernelcode durch getrennte Adressräume (wie z.B. bei Mikrokern-Architekturen) \item somit möglich: \begin{enumerate*} \item Einschränkung der Fehlerausbreitung $\rightarrow$ angreifbare Schwachstellen \item Überwachung der Kommunikation zwischen Teilsystemen \end{enumerate*} \item darüber hinaus: Sandboxing (vollständig von logischer Ablaufumgebung isolierte Software, typischerweise Anwendungen $\rightarrow$ siehe z.B. Cloud-Computing) \end{itemize*} - \item - Robustheit: + \item Robustheit: \begin{itemize*} \item siehe Sicherheit! \end{itemize*} @@ -4303,12 +3541,9 @@ Architekturvarianten - drei unterschiedliche Prinzipien: \begin{enumerate*} - \item - Typ-1 - Hypervisor ( früher: VMM - ,,Virtual MachineMonitor'' ) - \item - Typ-2 - Hypervisor - \item - Paravirtualisierung + \item Typ-1 - Hypervisor ( früher: VMM - ,,Virtual MachineMonitor'' ) + \item Typ-2 - Hypervisor + \item Paravirtualisierung \end{enumerate*} @@ -4316,80 +3551,68 @@ \begin{itemize*} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-virtualisierung-hypervisor-1.png} - \item - Idee des Typ- 1 - Hypervisors: + \item Idee des Typ- 1 - Hypervisors: \begin{itemize*} \item Kategorien traditioneller funktionaler Eigenschaften von BS: \begin{enumerate*} \item Multiplexing \& Schutz der Hardware (ermöglicht Multiprozess-Betrieb) \item abstrahierte Maschine** mit ,,angenehmerer'' Schnittstelle als die reine Hardware (z.B. Dateien, Sockets, Prozesse, ...) \end{enumerate*} \end{itemize*} - \item - Typ- 1 - Hypervisor trennt beide Kategorien: + \item Typ- 1 - Hypervisor trennt beide Kategorien: \begin{itemize*} \item läuft wie ein Betriebssystem unmittelbar über der Hardware \item bewirkt Multiplexing der Hardware, liefert aber keine erweiterte Maschine** an Anwendungsschicht $\rightarrow$ ,,Multi-Betriebssystem-Betrieb'' \end{itemize*} - \item - Bietet mehrmals die unmittelbare Hardware-Schnittstelle an, wobei jede + \item Bietet mehrmals die unmittelbare Hardware-Schnittstelle an, wobei jede Instanz eine virtuelle Maschine jeweils mit den unveränderten Hardware-Eigenschaften darstellt (Kernel u. User Mode, Ein-/Ausgaben usw.). - \item - Ursprünge: Time-Sharing an Großrechnern + \item Ursprünge: Time-Sharing an Großrechnern \begin{itemize*} \item Standard-BS auf IBM-Großrechner System/360: OS/360 \item reines Stapelverarbeitungs-Betriebssystem (1960er Jahre) \item Nutzer (insbes. Entwickler) strebten interaktive Arbeitsweise an eigenem Terminal an $\rightarrow$ timesharing (MIT, 1962: CTSS) \begin{itemize*} \item IBM zog nach: CP/CMS, später VM/370 $\rightarrow$ z/VM \item CP: Control Program $\rightarrow$ Typ- 1 - Hypervisor \item CMS: ConversationalMonitor System $\rightarrow$ Gast-BS \end{itemize*} \item CP lief auf ,,blanker'' Hardware (Begriff geprägt: ,,bare metal hypervisor'' ) \begin{itemize*} \item lieferte Menge virtueller Kopiender System/360-Hardware an eigentliches Timesharing-System \item je eines solche Kopie pro Nutzer $\rightarrow$ unterschiedliche BS lauffähig (da jede virtuelle Maschine exakte Kopie der Hardware) \item in der Praxis: sehr leichtgewichtiges, schnelles Einzelnutzer-BS als Gast $\rightarrow$ CMS (heute wäre das wenig mehr als ein Terminal-Emulator...) \end{itemize*} \end{itemize*} - \item - heute: Forderungen nach Virtualisierung von Betriebssystemen + \item heute: Forderungen nach Virtualisierung von Betriebssystemen \begin{itemize*} \item seit 1980er: universeller Einsatz des PC für Einzelplatz- und Serveranwendungen $\rightarrow$ veränderte Anforderungen an Virtualisierung \item Wartbarkeit: vor allem ökonomische Gründe: \begin{enumerate*} \item Anwendungsentwicklung und -bereitstellung: verschiedene Anwendungen in Unternehmen, bisher auf verschiedenen Rechnern mit mehreren (oft verschiedenen) BS, auf einem Rechner entwickeln und betreiben (Lizenzkosten!) \item Administration: einfache Sicherung, Migration virtueller Maschinen \item Legacy-Software \end{enumerate*} \item später: Sicherheit, Robustheit $\rightarrow$ Cloud-Computing-Anwendungen \end{itemize*} - \item - ideal hierfür: Typ- 1 - Hypervisor + \item ideal hierfür: Typ- 1 - Hypervisor \begin{itemize*} - \item \cmark Gast-BS angenehm wartbar - \item \cmark Softwarekosten beherrschbar - \item \cmark Anwendungen isolierbar + \item[\cmark] Gast-BS angenehm wartbar + \item[\cmark] Softwarekosten beherrschbar + \item[\cmark] Anwendungen isolierbar \end{itemize*} \end{itemize*} Hardware-Voraussetzungen \begin{itemize*} - \item - Voraussetzungen zum Einsatz von Typ-1-HV + \item Voraussetzungen zum Einsatz von Typ-1-HV \begin{itemize*} \item Ziel: Nutzung von Virtualisierung auf PC-Hardware \item systematische Untersuchung der Virtualisierbarkeit von Prozessoren bereits 1974 durch Popek \& Goldberg [Popek\&Goldberg74] \item Ergebnis: \begin{itemize*} \item Gast-BS (welches aus Sicht der CPU im User Mode - also unprivilegiert läuft) muss sicher sein können, dass privilegierte Instruktionen (Maschinencode im Kernel) ausgeführt werden \item dies geht nur, wenn tatsächlich der HV diese Instruktionen ausführt! \item dies geht nur, wenn CPU bei jeder solchen Instruktion im Nutzermodus Kontextwechsel zum HV ausführen, welcher Instruktion emuliert! \end{itemize*} \end{itemize*} - \item - virtualisierbare Prozessoren bis ca. 2006: + \item virtualisierbare Prozessoren bis ca. 2006: \begin{itemize*} - \item \cmark IBM-Architekturen(bekannt: PowerPC, bis 2006 Apple-Standard) - \item \xmark Intel x86-Architekturen (386, Pentium, teilweise Core i) + \item[\cmark] IBM-Architekturen(bekannt: PowerPC, bis 2006 Apple-Standard) + \item[\xmark] Intel x86-Architekturen (386, Pentium, teilweise Core i) \end{itemize*} \end{itemize*} Privilegierte Instruktionen \textbf{ohne} Hypervisor \begin{itemize*} - \item - kennen wir schon: Instruktion für Systemaufrufe + \item kennen wir schon: Instruktion für Systemaufrufe \end{itemize*} \begin{enumerate*} - \item - User Mode: Anwendung bereitet Befehl und Parameter vor - \item - User Mode: Privilegierte Instruktion (syscall/Trap - Interrupt) + \item User Mode: Anwendung bereitet Befehl und Parameter vor + \item User Mode: Privilegierte Instruktion (syscall/Trap - Interrupt) $\rightarrow$ CPU veranlasst Kontext-und Privilegierungswechsel, Ziel: BS-Kernel - \item - Kernel Mode: BS-Dispatcher (Einsprungpunkt für Kernel-Kontrollfluss) + \item Kernel Mode: BS-Dispatcher (Einsprungpunkt für Kernel-Kontrollfluss) behandelt Befehl und Parameter, ruft weitere privilegierte Instruktionen auf (z.B. EA-Code) \end{enumerate*} @@ -4399,25 +3622,19 @@ Privilegierte Instruktionen mit Typ- 1 - Hypervisor(1) \begin{itemize*} - \item - zum Vergleich: Instruktion für Systemaufrufe des Gast-BS + \item zum Vergleich: Instruktion für Systemaufrufe des Gast-BS \end{itemize*} \begin{enumerate*} - \item - User Mode: Anwendung bereitet Befehl und Parameter vor - \item - User Mode: Trap $\rightarrow$ Kontext-und + \item User Mode: Anwendung bereitet Befehl und Parameter vor + \item User Mode: Trap $\rightarrow$ Kontext-und Privilegierungswechsel, Ziel: Typ-1-HV - \item - Kernel Mode: HV-Dispatcher ruft Dispatcher im Gast-BS auf - \item - User Mode: BS-Dispatcher behandelt Befehl und Parameter, ruft weitere + \item Kernel Mode: HV-Dispatcher ruft Dispatcher im Gast-BS auf + \item User Mode: BS-Dispatcher behandelt Befehl und Parameter, ruft weitere privilegierte Instruktionenauf (z.B. EA-Code) $\rightarrow$ Kontext-und Privilegierungswechsel, Ziel: Typ-1-HV - \item - Kernel Mode: HV führt privilegierte Instruktionen anstelle des Gast-BS + \item Kernel Mode: HV führt privilegierte Instruktionen anstelle des Gast-BS aus \end{enumerate*} @@ -4428,34 +3645,28 @@ Maschinenbefehlssätzen: [Popek\&Goldberg74] \begin{itemize*} - \item - $\exists$ Menge an Maschinenbefehlen, die nur im + \item $\exists$ Menge an Maschinenbefehlen, die nur im Kernel Mode ausgeführt werden dürfen (Befehle zur Realisierung von E/A, Manipulation der MMU, ...) \begin{itemize*} \item[$\rightarrow$] sensible Instruktionen \end{itemize*} - \item - $\exists$ Menge an Maschinenbefehlen, die Wechsel des + \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 \end{itemize*} - \item - Prozessor ist virtualisierbarfalls (notw. Bed.): sensible + \item Prozessor ist virtualisierbarfalls (notw. Bed.): sensible Instruktionen $\subseteq$ privilegierte Instruktionen - \item - Folge: jeder Maschinenbefehl, der im Nutzermodus nicht erlaubt ist, + \item Folge: jeder Maschinenbefehl, der im Nutzermodus nicht erlaubt ist, muss einen Privilegierungswechsel auslösen (z.B. Trap generieren) - \item - kritische Instruktionen = sensible Instruktionen \textbackslash{} + \item kritische Instruktionen = sensible Instruktionen \textbackslash{} privilegierte Instruktionen \begin{itemize*} \item Befehle, welche diese Bedingung verletzen $\rightarrow$ Existenz im Befehlssatz führt zu nicht-virtualisierbarem Prozessor \end{itemize*} - \item - Beispiele für sensible Instruktionen bei Intel x86: + \item Beispiele für sensible Instruktionen bei Intel x86: \begin{itemize*} \item hlt: Befehlsabarbeitung bis zum nächsten Interrupt stoppen \item invlpg: TLB-Eintrag für Seite invalidieren @@ -4463,8 +3674,7 @@ \item mov auf Steuerregistern \item ... \end{itemize*} - \item - Beispiel: Privilegierte Prozessorinstruktionen + \item Beispiel: Privilegierte Prozessorinstruktionen \begin{itemize*} \item Bsp.: write - Systemaufruf \item Anwendungsprogramm schreibt String in Puffer eines Ausgabegeräts ohne Nutzung der libc Standard-Bibliothek: \texttt{asm\ (\ "int\ \$0x80"\ );\ /*\ interrupt\ 80\ (trap)\ */} @@ -4480,28 +3690,23 @@ Folgen für Virtualisierung \begin{itemize*} - \item - privilegierte Instruktionen bei virtualisierbaren Prozessoren - \item - bei Ausführung einer privilegierten Instruktion in virtueller + \item privilegierte Instruktionen bei virtualisierbaren Prozessoren + \item bei Ausführung einer privilegierten Instruktion in virtueller Maschine: immer Kontrollflussübergabe an im Kernel-Modus laufende Systemsoftware - hier Typ-1-HV - \item - HV kann (anhand des virtuellen Privilegierungsmodus) feststellen: + \item HV kann (anhand des virtuellen Privilegierungsmodus) feststellen: \begin{enumerate*} \item ob sensible Anweisung durch Gast-BS \item oder durch Nutzerprogramm (Systemaufruf!) ausgelöst \end{enumerate*} - \item - Folgen: + \item Folgen: \begin{enumerate*} \item privilegierte Instruktionen des Gast-Betriebssystems werden ausgeführt $\rightarrow$ ,,trap-and-emulate'' \item Einsprung in Betriebssystem, hier also Einsprung in Gast-Betriebssystem $\rightarrow$ Upcall durch HV \end{enumerate*} - \item - privilegierte Instruktionen bei nicht virtualisierbaren Prozessoren + \item privilegierte Instruktionen bei nicht virtualisierbaren Prozessoren \begin{itemize*} \item solche Instruktionen typischerweise ignoriert! \end{itemize*} @@ -4510,19 +3715,14 @@ Intel-Architektur ab 386 \begin{itemize*} - \item - dominant im PC-und Universalrechnersegment ab 1980er - \item - keine Unterstützung für Virtualisierung ... - \item - kritische Instruktionen im User Mode werden von CPU ignoriert - \item - außerdem: in Pentium-Familie konnte Kernel-Code explizit feststellen, + \item dominant im PC-und Universalrechnersegment ab 1980er + \item keine Unterstützung für Virtualisierung ... + \item kritische Instruktionen im User Mode werden von CPU ignoriert + \item außerdem: in Pentium-Familie konnte Kernel-Code explizit feststellen, ob er im Kernel- oder Nutzermodus läuft $\rightarrow$ Gast-BS trifft (implementierungsabhängig) evtl. fatal fehlerhafte Entscheidungen - \item - Diese Architekturprobleme (bekannt seit 1974) wurden 20 Jahre lang im + \item Diese Architekturprobleme (bekannt seit 1974) wurden 20 Jahre lang im Sinne von Rückwärtskompatibilität auf Nachfolgeprozessoren übertragen ... \begin{itemize*} @@ -4534,14 +3734,11 @@ Forschungsarbeit 1990er Jahre \begin{itemize*} - \item - verschiedene akademische Projekte zur Virtualisierung bisher nicht + \item verschiedene akademische Projekte zur Virtualisierung bisher nicht virtualisierbarer Prozessoren - \item - erstes und vermutlich bekanntestes: DISCO- Projekt der University of + \item erstes und vermutlich bekanntestes: DISCO- Projekt der University of Stanford - \item - Resultat: letztlich VMware (heute kommerziell) und + \item Resultat: letztlich VMware (heute kommerziell) und Typ-2-Hypervisors... \end{itemize*} @@ -4553,10 +3750,8 @@ Virtualisierung ohne Hardwareunterstützung: \begin{itemize*} - \item - keine Möglichkeit, trap-and-emulate zu nutzen - \item - keine Möglichkeit, um + \item keine Möglichkeit, trap-and-emulate zu nutzen + \item keine Möglichkeit, um \begin{enumerate*} \item korrekt (bei sensiblen Instruktionen im Gast-Kernel) den Privilegierungsmodus zu wechseln @@ -4567,15 +3762,12 @@ Übersetzungsstrategie in Software: \begin{itemize*} - \item - vollständige Übersetzung des Maschinencodes, der in VM ausgeführt + \item vollständige Übersetzung des Maschinencodes, der in VM ausgeführt wird, in Maschinencode, der im HV ausgeführt wird - \item - praktische Forderung: HV sollte selbst abstrahierte HW-Schnittstelle + \item praktische Forderung: HV sollte selbst abstrahierte HW-Schnittstelle zur Ausführung des (komplexen!) Übersetzungscodes zur Verfügung haben (z.B. Nutzung von Gerätetreibern) - \item - $\rightarrow$ Typ-2-HV als Kompromiss: + \item $\rightarrow$ Typ-2-HV als Kompromiss: \begin{itemize*} \item korrekte Ausführung von virtualisierter Software auf virtualisierter HW \item beherrschbare Komplexität der Implementierung @@ -4585,48 +3777,38 @@ aus Nutzersicht \begin{itemize*} - \item - läuft als gewöhnlicher Nutzer-Prozess auf Host-Betriebssystem (z.B. + \item läuft als gewöhnlicher Nutzer-Prozess auf Host-Betriebssystem (z.B. Windows oder Linux) - \item - VMware bedienbarwie physischer Rechner (bspw. erwartet Bootmedium in + \item VMware bedienbarwie physischer Rechner (bspw. erwartet Bootmedium in virtueller Repräsentation eines physischen Laufwerks) - \item - persistente Daten des Gast-BS auf virtuellem Speichermedium ( + \item persistente Daten des Gast-BS auf virtuellem Speichermedium ( tatsächlich: Image-Datei aus Sicht des Host-Betriebssystems) \end{itemize*} Mechanismus: Code-Inspektion \begin{itemize*} - \item - Bei Ausführung eines Binärprogramms in der virtuellen Maschine (egal + \item Bei Ausführung eines Binärprogramms in der virtuellen Maschine (egal ob Bootloader, Gast-BS-Kernel, Anwendungsprogramm): zunächst inspiziert Typ-2-HV den Code nach Basisblöcken \begin{itemize*} \item Basisblock: Befehlsfolge, die mit privilegierten Befehlen oder solchen Befehlen abgeschlossen ist, die den Kontrollfluss ändern (sichtbar an Manipulation des Programm-Zählers eip), z.B. jmp, call, ret. \end{itemize*} - \item - Basisblöcke werden nach sensiblen Instruktionen abgesucht - \item - diese werden jeweils durchAufruf einer HV-Prozedur ersetzt, die + \item Basisblöcke werden nach sensiblen Instruktionen abgesucht + \item diese werden jeweils durchAufruf einer HV-Prozedur ersetzt, die jeweilige Instruktion behandelt - \item - gleiche Verfahrensweise mit letzter Instruktion eines Basis-Blocks + \item gleiche Verfahrensweise mit letzter Instruktion eines Basis-Blocks \end{itemize*} Mechanismus: Binary Translation (Binärcodeübersetzung) \begin{itemize*} - \item - modifizierter Basisblock: wird innerhalbdes HVin Cachegespeichert und + \item modifizierter Basisblock: wird innerhalbdes HVin Cachegespeichert und ausgeführt - \item - Basisblock ohne sensible Instruktionen: läuft unter Typ-2-HV exakt so + \item Basisblock ohne sensible Instruktionen: läuft unter Typ-2-HV exakt so schnell wie unmittelbar auf Hardware (weil er auch tatsächlich unmittelbar auf der Hardware läuft, nur eben im HV-Kontext) - \item - sensible Instruktionen: nach dargestellter Methode abgefangen und + \item sensible Instruktionen: nach dargestellter Methode abgefangen und emuliert $\rightarrow$ dabei hilft jetzt das Host-BS (z.B. durch eigene Systemaufrufe, Gerätetreiberschnittstellen) \end{itemize*} @@ -4634,43 +3816,33 @@ Mechanismus: Caching von Basisblöcken \begin{itemize*} - \item - HV nutzt zwei parallel arbeitende Module (Host-BS-Threads!): + \item HV nutzt zwei parallel arbeitende Module (Host-BS-Threads!): \begin{itemize*} \item Translator: Code-Inspektion, Binary Translation \item Dispatcher: Basisblock-Ausführung \end{itemize*} - \item - zusätzliche Datenstruktur: Basisblock-Cache - \item - Dispatcher: sucht Basisblock mit jeweils nächster auszuführender + \item zusätzliche Datenstruktur: Basisblock-Cache + \item Dispatcher: sucht Basisblock mit jeweils nächster auszuführender Befehlsadresse im Cache; falls miss $\rightarrow$ suspendieren (zugunsten Translator) - \item - Translator: schreibt Basisblöcke in Basisblock-Cache - \item - Annahme: irgendwann ist Großteil des Programms im Cache, dieses läuft + \item Translator: schreibt Basisblöcke in Basisblock-Cache + \item Annahme: irgendwann ist Großteil des Programms im Cache, dieses läuft dann mit nahezu Original-Geschwindigkeit (theoretisch) \end{itemize*} Performanzmessungen \begin{itemize*} - \item - zeigen gemischtes Bild: Typ2-HV keinesfalls so schlecht, wie einst + \item zeigen gemischtes Bild: Typ2-HV keinesfalls so schlecht, wie einst erwartet wurde - \item - qualitativer Vergleich mit virtualisierbarer Hardware + \item qualitativer Vergleich mit virtualisierbarer Hardware (Typ1-Hypervisor): - \item - ,,trap-and-emulate,,: erzeugt Vielzahl von Traps + \item ,,trap-and-emulate,,: erzeugt Vielzahl von Traps $\rightarrow$ Kontextwechsel zwischen jeweiliger VM und HV - \item - insbesondere bei Vielzahl an VMs sehr teuer: CPU-Caches, TLBs, + \item insbesondere bei Vielzahl an VMs sehr teuer: CPU-Caches, TLBs, Heuristiken zur spekulativen Ausführung werden verschmutzt - \item - wenn andererseits sensible Instruktionen durch Aufruf von + \item wenn andererseits sensible Instruktionen durch Aufruf von VMware-Prozeduren innerhalb des ausführenden Programms ersetzt: keine Kontextwechsel-Overheads \end{itemize*} @@ -4678,11 +3850,9 @@ Studie: (von Vmware) [Adams\&Agesen06] \begin{itemize*} - \item - last-und anwendungsabhängig kann Softwarelösung sogar Hardwarelösung + \item last-und anwendungsabhängig kann Softwarelösung sogar Hardwarelösung übertreffen - \item - Folge: viele moderne Typ1-HV benutzen aus Performanzgründen ebenfalls + \item Folge: viele moderne Typ1-HV benutzen aus Performanzgründen ebenfalls Binary Translation \end{itemize*} @@ -4692,39 +3862,31 @@ Funktionsprinzip \begin{itemize*} - \item - ... unterscheidet sich prinzipiell von Typ-1/2-Hypervisor - \item - wesentlich: Quellcode des Gast-Betriebssystems modifiziert - \item - sensible Instruktionen: durch Hypervisor-Calls ersetzt - \item - Folge: Gast-Betriebssystem arbeitet jetzt vollständig wie + \item ... unterscheidet sich prinzipiell von Typ-1/2-Hypervisor + \item wesentlich: Quellcode des Gast-Betriebssystems modifiziert + \item sensible Instruktionen: durch Hypervisor-Calls ersetzt + \item Folge: Gast-Betriebssystem arbeitet jetzt vollständig wie Nutzerprogramm, welches Systemaufrufe zum Betriebssystem (hier dem Hypervisor) ausführt - \item - dazu: + \item dazu: \begin{itemize*} \item Hypervisor: muss geeignetes Interface definieren (HV-Calls) \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 - mehr dazu: Xen + \item mehr dazu: Xen \end{itemize*} Verwandtschaft mit Mikrokernel-Architekturen \begin{itemize*} - \item - Geht man vom Typ-1-HV noch einen Schritt weiter ... + \item Geht man vom Typ-1-HV noch einen Schritt weiter ... \begin{itemize*} \item und entfernt alle sensiblen Instruktionen aus Gast-Betriebssystem ... \item und ersetzt diese durch Hypervisor-Aufrufe, um Systemdienste wie E/A zu benutzen, ... \item hat man praktisch den Hypervisor in Mikrokernel transformiert. \end{itemize*} - \item - ... und genau das wird auch schon gemacht: $L^4$Linux (TU + \item ... und genau das wird auch schon gemacht: $L^4$Linux (TU Dresden) \begin{itemize*} \item Basis: stringente $L^4\mu$ Kernel-Implementierung (Typ-1-HV-artiger Funktionsumfang) @@ -4736,27 +3898,24 @@ Zwischenfazit Virtualisierung \begin{itemize*} - \item - Ziele: Adaptivität komplementär zu... + \item Ziele: Adaptivität komplementär zu... \begin{itemize*} \item Wartbarkeit : ökonomischer Betrieb von Cloud-und Legacy-Anwendungen ohne dedizierte Hardware \item Sicherheit : sicherheitskritische Anwendungen können vollständig von nichtvertrauenswürdigen Anwendungen (und untereinander) isoliert werden \item Robustheit : Fehler in VMs (= Anwendungsdomänen) können nicht andere VMs beeinträchtigen \end{itemize*} - \item - Idee: drei gängige Prinzipien: + \item Idee: drei gängige Prinzipien: \begin{itemize*} \item Typ-1-HV: unmittelbares HW-Multiplexing, trap-and-emulate \item Typ-2-HV: HW-Multiplexing auf Basis eines Host-OS, binarytranslation \item Paravirtualisierung: Typ-1-HV für angepasstes Gast-OS, kein trap-and-emulate nötig $\rightarrow$ HV ähnelt $\mu$Kern \end{itemize*} - \item - Ergebnisse: + \item Ergebnisse: \begin{itemize*} - \item \cmark VMs mit individuell anpassbarer Laufzeitumgebung - \item \cmark isolierteVMs - \item \cmark kontrollierbare VM-Interaktion (untereinander und mit HW) - \item \xmark keine hardwarespezifischen Optimierungen aus VM heraus möglich $\rightarrow$ Performanz, Echtzeitfähigkeit, Sparsamkeit! + \item[\cmark] VMs mit individuell anpassbarer Laufzeitumgebung + \item[\cmark] isolierteVMs + \item[\cmark] kontrollierbare VM-Interaktion (untereinander und mit HW) + \item[\xmark] keine hardwarespezifischen Optimierungen aus VM heraus möglich $\rightarrow$ Performanz, Echtzeitfähigkeit, Sparsamkeit! \end{itemize*} \end{itemize*} @@ -4766,18 +3925,15 @@ Ziele: \begin{itemize*} - \item - Adaptivität , im Dienste von ... - \item - ... Wartbarkeit: einfachen Entwicklung, Installation, Rekonfiguration + \item Adaptivität , im Dienste von ... + \item ... Wartbarkeit: einfachen Entwicklung, Installation, Rekonfiguration durch Kapselung von \begin{itemize*} \item Anwendungsprogrammen \item \begin{itemize*} \item durch sie benutzte Bibliotheken \end{itemize*} \item \begin{itemize*} \item Instanzen bestimmter BS-Ressourcen \end{itemize*} \end{itemize*} - \item - ... Portabilität: Betrieb von Anwendungen, die lediglich von einem + \item ... Portabilität: Betrieb von Anwendungen, die lediglich von einem bestimmten BS-Kernel abhängig sind (nämlich ein solcher, der Container unterstützt); insbesondere hinsichtlich: \begin{itemize*} @@ -4785,8 +3941,7 @@ \item fehlenden Abhängigkeiten (Anwendungen und Bibliotheken) \item Versions-und Namenskonflikten \end{itemize*} - \item - ... Sparsamkeit: problemgerechtes ,,Packen,, von Anwendungen in + \item ... Sparsamkeit: problemgerechtes ,,Packen,, von Anwendungen in Container $\rightarrow$ Reduktion an Overhead: selten (oder gar nicht) genutzter Code, Speicherbedarf, Hardware, ... \end{itemize*} @@ -4794,14 +3949,11 @@ Idee: \begin{itemize*} - \item - private Sichten (Container) bilden = private User-Space-Instanzen für + \item private Sichten (Container) bilden = private User-Space-Instanzen für verschiedene Anwendungsprogramme - \item - Kontrolle dieser Container i.S.v. Multiplexing, Unabhängigkeit und + \item Kontrolle dieser Container i.S.v. Multiplexing, Unabhängigkeit und API: BS-Kernel - \item - somit keine Form der BS-Virtualisierung, eher: + \item somit keine Form der BS-Virtualisierung, eher: ,,User-Space-Virtualisierung,, \end{itemize*} @@ -4810,60 +3962,50 @@ Anwendungsfälle für Container \begin{itemize*} - \item - Anwendungsentwicklung: + \item Anwendungsentwicklung: \begin{itemize*} \item konfliktfreies Entwickeln und Testen unterschiedlicher Software, für unterschiedliche Zielkonfigurationen BS-User-Space \end{itemize*} - \item - Anwendungsbetrieb und -administration: + \item Anwendungsbetrieb und -administration: \begin{itemize*} \item Entschärfung von ,,dependency hell,, \item einfache Migration, einfaches Backup von Anwendungen ohne den (bei Virtualisierungsimages als Ballast auftretenden) BS-Kernel \item einfache Verteilung generischer Container für bestimmte Aufgaben \item = Kombinationen von Anwendungen \end{itemize*} - \item - Anwendungsisolation? $\rightarrow$ Docker + \item Anwendungsisolation? $\rightarrow$ Docker \end{itemize*} Zwischenfazit: Container \begin{itemize*} - \item - Ziele: Adaptivität komplementär zu... + \item Ziele: Adaptivität komplementär zu... \begin{itemize*} \item Wartbarkeit : Vermeidung von Administrationskosten für Laufzeitumgebung von Anwendungen \item Portabilität : Vereinfachung von Abhängigkeitsverwaltung \item Sparsamkeit : Optimierung der Speicher-und Verwaltungskosten für Laufzeitumgebung von Anwendungen \end{itemize*} - \item - Idee: + \item Idee: \begin{itemize*} \item unabhängige User-Space-Instanz für jeden einzelnen Container \item Aufgaben des Kernels: Unterstützung der Containersoftware bei Multiplexing und Herstellung der Unabhängigkeitdieser Instanzen \end{itemize*} - \item - Ergebnisse: + \item Ergebnisse: \begin{itemize*} - \item \cmark vereinfachte Anwendungsentwicklung - \item \cmark vereinfachter Anwendungsbetrieb - \item \xmark Infrastruktur nötig über (lokale) Containersoftware hinaus, um Containern zweckgerecht bereitzustellen und zu warten - \item \xmark keine vollständige Isolationmöglich + \item[\cmark] vereinfachte Anwendungsentwicklung + \item[\cmark] vereinfachter Anwendungsbetrieb + \item[\xmark] Infrastruktur nötig über (lokale) Containersoftware hinaus, um Containern zweckgerecht bereitzustellen und zu warten + \item[\xmark] keine vollständige Isolationmöglich \end{itemize*} \end{itemize*} Beispielsysteme (Auswahl) \begin{itemize*} - \item - Virtualisierung: VMware, VirtualBox - \item - Paravirtualisierung: Xen - \item - Exokernel: Nemesis, MirageOS, RustyHermit - \item - Container: Docker, LupineLinux + \item Virtualisierung: VMware, VirtualBox + \item Paravirtualisierung: Xen + \item Exokernel: Nemesis, MirageOS, RustyHermit + \item Container: Docker, LupineLinux \end{itemize*} @@ -4873,12 +4015,9 @@ \paragraph{VMware} \begin{itemize*} - \item - " ... ist Unternehmenin PaloAlto, Kalifornien (USA) - \item - gegründet 1998 von 5 Informatikern - \item - stellt verschiedene Virtualisierungs-Softwareprodukte her: + \item " ... ist Unternehmenin PaloAlto, Kalifornien (USA) + \item gegründet 1998 von 5 Informatikern + \item stellt verschiedene Virtualisierungs-Softwareprodukte her: \begin{enumerate*} \item VMware Workstation \begin{itemize*} \item war erstes Produkt von VMware (1999) \item mehrere unabhängige Instanzen von x86- bzw. x86-64-Betriebssystemen auf einer Hardware betreibbar \end{itemize*} @@ -4887,13 +4026,10 @@ \item VMware Server (eingestellte Freeware, ehem. GSX Server) \item VMware vSphere (ESXi) \begin{itemize*} \item Produkte 1 ... 3: für Desktop-Systeme \item Produkte 4 ... 5: für Server-Systeme \item Produkte 1 ... 4: Typ-2-Hypervisor \end{itemize*} \end{enumerate*} - \item - bei VMware-Installation: spezielle vm- Treiber in Host-Betriebssystem + \item bei VMware-Installation: spezielle vm- Treiber in Host-Betriebssystem eingefügt - \item - diese ermöglichen: direkten Hardware-Zugriff - \item - durch Laden der Treiber: entsteht ,,Virtualisierungsschicht'' + \item diese ermöglichen: direkten Hardware-Zugriff + \item durch Laden der Treiber: entsteht ,,Virtualisierungsschicht'' (VMware-Sprechweise) %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-vmware-host-guest-architecture.png} %\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-vmware-bare-metal.png} @@ -4911,96 +4047,73 @@ \paragraph{VirtualBox} \begin{itemize*} - \item - Virtualisierungs-Software für x86- bzw. x86-64-Betriebssysteme für + \item Virtualisierungs-Software für x86- bzw. x86-64-Betriebssysteme für Industrie und ,,Hausgebrauch'' (ursprünglich: Innotek , dann Sun , jetzt Oracle ) - \item - frei verfügbare professionelle Lösung, als Open Source Software unter + \item frei verfügbare professionelle Lösung, als Open Source Software unter GNU General Public License(GPL) version 2. ... - \item - (gegenwärtig) lauffähig auf Windows, Linux, Macintosh und Solaris + \item (gegenwärtig) lauffähig auf Windows, Linux, Macintosh und Solaris Hosts - \item - unterstützt große Anzahl von Gast-Betriebssystemen: Windows (NT 4.0, + \item unterstützt große Anzahl von Gast-Betriebssystemen: Windows (NT 4.0, 2000, XP, Server 2003, Vista, Windows 7), DOS/Windows 3.x, Linux (2.4 and 2.6), Solaris and OpenSolaris , OS/2 , and OpenBSD u.a. - \item - reiner Typ-2-Hypervisor + \item reiner Typ-2-Hypervisor \end{itemize*} \subsubsection{Paravirutalisierung: Xen} \begin{itemize*} - \item - entstanden als Forschungsprojekt der University of Cambridge (UK), + \item entstanden als Forschungsprojekt der University of Cambridge (UK), dann XenSource Inc., danach Citrix, jetzt: Linux Foundation (,,self-governing'') - \item - frei verfügbar als Open Source Software unter GNU General Public + \item frei verfügbar als Open Source Software unter GNU General Public License (GPL) - \item - lauffähig auf Prozessoren der Typen x86, x86-64, PowerPC, ARM, MIPS - \item - unterstützt große Anzahl von Gast-Betriebssystemen: FreeBSD, + \item lauffähig auf Prozessoren der Typen x86, x86-64, PowerPC, ARM, MIPS + \item unterstützt große Anzahl von Gast-Betriebssystemen: FreeBSD, GNU/Hurd/Mach, Linux, MINIX, NetBSD, Netware, OpenSolaris, OZONE, Plan 9 - \item - ,,Built for the cloud before it was called cloud.'' (Russel Pavlicek, + \item ,,Built for the cloud before it was called cloud.'' (Russel Pavlicek, Citrix) - \item - bekannt für Paravirtualisierung - \item - unterstützt heute auch andere Virtualisierungs-Prinzipien + \item bekannt für Paravirtualisierung + \item unterstützt heute auch andere Virtualisierungs-Prinzipien \end{itemize*} Xen : Architektur \begin{itemize*} - \item - Gast-BSe laufen in Xen Domänen (,,$dom_i$'', analog $VM_i$) - \item - es existiert genau eine, obligatorische, vertrauenswürdige Domäne: + \item Gast-BSe laufen in Xen Domänen (,,$dom_i$'', analog $VM_i$) + \item es existiert genau eine, obligatorische, vertrauenswürdige Domäne: $dom_0$ - \item - Aufgaben (Details umseitig): + \item Aufgaben (Details umseitig): \begin{itemize*} \item Bereitstellen und Verwalten der virtualisierten Hardware für andere Domänen (Hypervisor-API, Scheduling-Politiken für Hardware-Multiplexing) \item Hardwareverwaltung/-kommunikation für paravirtualisierte Gast-BSe (Gerätetreiber) \item Interaktionskontrolle (Sicherheitspolitiken) \end{itemize*} - \item - $dom_0$ im Detail: ein separates, hochkritisch administriertes, + \item $dom_0$ im Detail: ein separates, hochkritisch administriertes, vertrauenswürdiges BS mit eben solchen Anwendungen (bzw. Kernelmodulen) zur Verwaltung des gesamten virtualisierten Systems \begin{itemize*} \item es existieren hierfür spezialisierte Variantenvon Linux, BSD, GNU Hurd - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-Xen-architektur.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-Xen-architektur.png} \end{itemize*} \end{itemize*} Xen : Sicherheit \begin{itemize*} - \item - Sicherheitsmechanismusin Xen: Xen Security Modules (XSM) - \item - illustriert, wie (Para-) Typ-1-Virtualisierung von BS die NFE + \item Sicherheitsmechanismusin Xen: Xen Security Modules (XSM) + \item illustriert, wie (Para-) Typ-1-Virtualisierung von BS die NFE Sicherheit unterstützt - \item - PDP: Teil des vertrauenswürdigen BS in $dom_0$, PEPs: XSMs im + \item PDP: Teil des vertrauenswürdigen BS in $dom_0$, PEPs: XSMs im Hypervisor - \item - Beispiel: Zugriff auf Hardware + \item Beispiel: Zugriff auf Hardware \begin{itemize*} \item Sicherheitspolitik-Integration, Administration, Auswertung: $dom_0$ - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-Xen-sicherheit.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-Xen-sicherheit.png} \end{itemize*} - \item - Beispiel: Inter-Domänen-Kommunikation + \item Beispiel: Inter-Domänen-Kommunikation \begin{itemize*} \item Interaktionskontrolle (Aufgaben wie oben): $dom_0$ \item Beispiel: \href{https://www.flyn.org/projects/VisorFlow/}{VisorFlow} @@ -5014,11 +4127,9 @@ Nemesis \begin{itemize*} - \item - Betriebssystemaus EU-Verbundprojekt ,,Pegasus,, zur Realisierung eines + \item Betriebssystemaus EU-Verbundprojekt ,,Pegasus,, zur Realisierung eines verteilten multimediafähigen Systems (1. Version: 1994/95) - \item - Entwurfsprinzipien: + \item Entwurfsprinzipien: \begin{enumerate*} \item Anwendungen: sollen Freiheit haben, Betriebsmittel in für sie geeignetster Weise zu nutzen (= Exokernel-Prinzip) @@ -5030,30 +4141,24 @@ MirageOS + Xen \begin{itemize*} - \item - Spezialfall: Exokernel als paravirtualisiertes BS auf Xen - \item - Ziele : Wartbarkeit (Herkunft: Virtualisierungsarchitekturen ...) + \item Spezialfall: Exokernel als paravirtualisiertes BS auf Xen + \item Ziele : Wartbarkeit (Herkunft: Virtualisierungsarchitekturen ...) \begin{itemize*} \item ökonomischer HW-Einsatz \item Unterstützung einfacher Anwendungsentwicklung \item nicht explizit: Unterstützung von Legacy-Anwendungen! \end{itemize*} - \item - Idee: ,,Unikernel'' $\rightarrow$ eine Anwendung, eine + \item Idee: ,,Unikernel'' $\rightarrow$ eine Anwendung, eine API, ein Kernel - \item - umfangreiche Dokumentation, Tutorials, ... + \item umfangreiche Dokumentation, Tutorials, ... $\rightarrow$ \href{https://mirage.io/wiki/learning}{ausprobieren} - \item - Unikernel - Idee + \item Unikernel - Idee \begin{itemize*} \item Architekturprinzip: %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-unikernel-architektur.png} \item in MirageOS: %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-mirageOs-architektur.png} \end{itemize*} - \item - Ergebnis: Kombination von Vorteilen zweier Welten + \item Ergebnis: Kombination von Vorteilen zweier Welten \begin{itemize*} \item Virtualisierungs vorteile: Sicherheit, Robustheit ( $\rightarrow$ Xen - Prinzip genau einer vertrauenswürdigen, isolierten Domäne $dom_0$) \item Exokernelvorteile: Wartbarkeit, Sparsamkeit @@ -5065,8 +4170,7 @@ \subsubsection{Container: Docker} \begin{itemize*} - \item - Idee: Container für einfache Wartbarkeit von + \item Idee: Container für einfache Wartbarkeit von Linux-Anwendungsprogrammen ... \begin{itemize*} \item ... entwickeln @@ -5074,21 +4178,17 @@ \item ... konfigurieren \item ... portieren $\rightarrow$ Portabilität \end{itemize*} - \item - Besonderheit: Container können - unabhängig von ihrem Einsatzzweck - + \item Besonderheit: Container können - unabhängig von ihrem Einsatzzweck - wie Software-Repositories benutzt, verwaltet, aktualisiert, verteilt ... werden - \item - Management von Containers: Docker Client $\rightarrow$ + \item Management von Containers: Docker Client $\rightarrow$ leichtgewichtiger Ansatz zur Nutzung der Wartbarkeitsvorteile von Virtualisierung - \item - Forsetzung unter der OCI (Open Container Initiative) + \item Forsetzung unter der OCI (Open Container Initiative) \begin{itemize*} \item ,,Docker does a nice job [...] for a focused purpose, namely the lightweight packaging and deployment of applications.'' (Dirk Merkel, Linux Journal) \end{itemize*} - \item - Implementierung der Containertechnik basierend auf + \item Implementierung der Containertechnik basierend auf Linux-Kernelfunktionen: \begin{itemize*} \item Linux Containers (LXC): BS-Unterstützung für Containermanagement @@ -5106,10 +4206,8 @@ \subsection{Motivation} \begin{itemize*} - \item - Performanz: Wer hätte gern einen schnell(er)en Rechner...? - \item - Wer braucht schnelle Rechner: + \item Performanz: Wer hätte gern einen schnell(er)en Rechner...? + \item Wer braucht schnelle Rechner: \begin{itemize*} \item Hochleistungsrechnen, HPC (,,high performancecomputing'') \begin{itemize*} \item wissenschaftliches Rechnen(z.B. Modellsimulation natürlicher Prozesse, Radioteleskop-Datenverarbeitung) \item Datenvisualisierung(z.B. Analysen großer Netzwerke) \item Datenorganisation-und speicherung(z.B. Kundendatenverarbeitung zur Personalisierung von Werbeaktivitäten, Bürgerdatenverarbeitung zur Personalisierung von Geheimdienstaktivitäten) \end{itemize*} \item nicht disjunkt dazu: kommerzielle Anwendungen \begin{itemize*} \item ,,Big Data'': Dienstleistungen für Kunden, die o. g. Probleme auf gigantischen Eingabedatenmengen zu lösen haben (Software wie Apache Hadoop ) \item Wettervorhersage \end{itemize*} @@ -5121,16 +4219,13 @@ \subsection{Performanzbegriff} \begin{itemize*} - \item - Performance: The degree to which a system or component accomplishes + \item Performance: The degree to which a system or component accomplishes its designated functions within given constraints, such as speed, accuracy, or memory usage. (IEEE) - \item - Performanz im engeren Sinne dieses Kapitels: Minimierung der für + \item Performanz im engeren Sinne dieses Kapitels: Minimierung der für korrekte Funktion (= Lösung eines Berechnungsproblems) zur Verfügung stehenden Zeit. - \item - oder technischer: Maximierung der Anzahl pro Zeiteinheit + \item oder technischer: Maximierung der Anzahl pro Zeiteinheit abgeschlossener Berechnungen. \end{itemize*} @@ -5138,19 +4233,16 @@ \subsection{Roadmap} \begin{itemize*} - \item - Grundlegende Erkenntnis: Performanz geht nicht (mehr) ohne + \item Grundlegende Erkenntnis: Performanz geht nicht (mehr) ohne Parallelität $\rightarrow$ Hochleistungsrechnen = hochparalleles Rechnen - \item - daher in diesem Kapitel: Anforderungen hochparallelen Rechnens an ... + \item daher in diesem Kapitel: Anforderungen hochparallelen Rechnens an ... \begin{itemize*} \item Hardware: Prozessorarchitekturen \item Systemsoftware: Betriebssystemmechanismen \item Anwendungssoftware: Parallelisierbarkeitvon Problemen \end{itemize*} - \item - BS-Architekturen anhand von Beispielsystemen: + \item BS-Architekturen anhand von Beispielsystemen: \begin{itemize*} \item Multikernel: Barrelfish \item verteilte Betriebssysteme @@ -5161,8 +4253,7 @@ \subsection{Hardware-Voraussetzungen} \begin{itemize*} - \item - Entwicklungstendenzen der Rechnerhardware: + \item Entwicklungstendenzen der Rechnerhardware: \begin{itemize*} \item Multicore-Prozessoren: seit ca. 2006 (in größerem Umfang) \item Warum neues Paradigma für Prozessoren? bei CPU-Taktfrequenz $>>$ 4 GHz: z.Zt. physikalische Grenze, u.a. nicht mehr sinnvoll handhabbare Abwärme @@ -5177,14 +4268,11 @@ Folgerungen \begin{enumerate*} - \item - weitere Performanz-Steigerung von Anwendungen: primär durch + \item weitere Performanz-Steigerung von Anwendungen: primär durch Parallelität (aggressiverer) Multi-Threaded-Anwendungen - \item - erforderlich: Betriebssystem-Unterstützung + \item erforderlich: Betriebssystem-Unterstützung $\rightarrow$ Scheduling, Sychronisation - \item - weiterhin erforderlich: Formulierungsmöglichkeiten (Sprachen), + \item weiterhin erforderlich: Formulierungsmöglichkeiten (Sprachen), Compiler, verteilte Algorithmen ... $\rightarrow$ hier nicht im Fokus \end{enumerate*} @@ -5195,38 +4283,30 @@ Vorteile von Multicore-Prozessoren \begin{enumerate*} - \item - möglich wird: \textbf{Parallelarbeit auf Chip-Ebene} + \item möglich wird: \textbf{Parallelarbeit auf Chip-Ebene} $\rightarrow$ Vermeidung der Plagen paralleler verteilter Systeme - \item - bei geeigneter Architektur: Erkenntnisse und Software aus Gebiet + \item bei geeigneter Architektur: Erkenntnisse und Software aus Gebiet verteilter Systeme als Grundlage verwendbar - \item - durch gemeinsame Caches (architekturabhängig): schnellere + \item durch gemeinsame Caches (architekturabhängig): schnellere Kommunikation (speicherbasiert), billigere Migration von Aktivitäten kann möglich sein - \item - höhere Energieeffizienz: mehr Rechenleistung pro Chipfläche, geringere + \item höhere Energieeffizienz: mehr Rechenleistung pro Chipfläche, geringere elektrische Leistungsaufnahme $\rightarrow$ weniger Gesamtabwärme, z.T. einzelne Kerne abschaltbar (vgl. Sparsamkeit , mobile Geräte) - \item - Baugröße: geringeres physisches Volumen + \item Baugröße: geringeres physisches Volumen \end{enumerate*} Nachteile von Multicore-Prozessoren \begin{enumerate*} - \item - durch gemeinsam genutzte Caches und Busstrukturen: Engpässe + \item durch gemeinsam genutzte Caches und Busstrukturen: Engpässe (Bottlenecks) möglich - \item - zur Vermeidung thermischer Zerstörungen: Lastausgleich zwingend + \item zur Vermeidung thermischer Zerstörungen: Lastausgleich zwingend erforderlich! (Ziel: ausgeglichene Lastverteilung auf einzelnen Kernen) - \item - zum optimalen Einsatz zwingend erforderlich: + \item zum optimalen Einsatz zwingend erforderlich: \begin{enumerate*} \item Entwicklung Hardwarearchitektur \item zusätzlich: Entwicklung geeigneter Systemsoftware @@ -5238,10 +4318,8 @@ \subsubsection{Multicore-Prozessoren} \begin{itemize*} - \item - Sprechweise in der Literatur gelegentlich unübersichtlich... - \item - daher: Terminologie und Abkürzungen: + \item Sprechweise in der Literatur gelegentlich unübersichtlich... + \item daher: Terminologie und Abkürzungen: \begin{itemize*} \item MC ...multicore(processor) \item CMP ...chip-level multiprocessing, hochintegrierte Bauweise für ,,MC'' @@ -5254,54 +4332,44 @@ Architekturen von Multicore-Prozessoren \begin{itemize*} - \item - A. Netzwerkbasiertes Design + \item A. Netzwerkbasiertes Design \begin{itemize*} \item Prozessorkerne des Chips u. ihre lokalen Speicher (oder Caches): durch Netzwerkstruktur verbunden \item damit: größte Ähnlichkeit zu traditionellen verteilten Systemen \item Verwendung: bei Vielzahl von Prozessorkernen (Skalierbarkeit!) \item Beispiel: Intel Teraflop-Forschungsprozessor Polaris (80 Kerne als 8x10-Gitter) - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-multicore-prozessoren.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-multicore-prozessoren.png} \end{itemize*} - \item - B. Hierarchisches Design + \item B. Hierarchisches Design \begin{itemize*} \item mehrere Prozessor-Kerne teilen sich mehrere baumartig angeordnete Caches \item meistens: \begin{itemize*} \item jeder Prozessorkern hat eigenen L1-Cache \item L2-Cache, Zugriff auf (externen) Hauptspeicher u. Großteil der Busse aber geteilt \end{itemize*} \item Verwendung: typischerweise Serverkonfigurationen \item Beispiele: \begin{itemize*} \item IBM Power \item Intel Core 2, Core i \item Sun UltraSPARCT1 (Niagara) \end{itemize*} - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-multicore-prozessoren-2.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-multicore-prozessoren-2.png} \end{itemize*} - \item - C. Pipeline-Design + \item C. Pipeline-Design \begin{itemize*} \item Daten durch mehrere Prozessor-Kerne schrittweise verarbeitet \item durch letzten Prozessor: Ablage im Speichersystem \item Verwendung: \begin{itemize*} \item Graphikchips \item (hochspezialisierte) Netzwerkprozessoren \end{itemize*} \item Beispiele: Prozessoren X10 u. X11 von Xelerator zur Verarbeitung von Netzwerkpaketen in Hochleistungsroutern (X11: bis zu 800 Pipeline-Prozessorkerne) - %\item - % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-multicore-prozessoren-3.png} + %\item % %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-multicore-prozessoren-3.png} \end{itemize*} \end{itemize*} Symmetrische u. asymmetrische Multicore-Prozessoren \begin{itemize*} - \item - symmetrische Multicore-Prozessoren (SMC) + \item symmetrische Multicore-Prozessoren (SMC) \begin{itemize*} \item alle Kerne identisch, d.h. gleiche Architektur und gleiche Fähigkeiten \item Beispiele: \begin{itemize*} \item Intel Core 2 Duo \item Intel Core 2 Quad \item ParallaxPropeller \end{itemize*} \end{itemize*} - \item - asymmetrische MC-Prozessoren (AMC) - \item - Multicore-Architektur, jedoch mit Kernen unterschiedlicher Architektur + \item asymmetrische MC-Prozessoren (AMC) + \item Multicore-Architektur, jedoch mit Kernen unterschiedlicher Architektur und/oder unterschiedlichen Fähigkeiten - \item - Beispiel: Kilocore: + \item Beispiel: Kilocore: \begin{itemize*} \item 1 Allzweck-Prozessor (PowerPC) \item \begin{itemize*} \item 256 od. 1024 Datenverarbeitungsprozessoren \end{itemize*} @@ -5313,24 +4381,20 @@ Prozessoren} \begin{itemize*} - \item - Bekannt aus Rechnerarchitektur: Pipelining + \item Bekannt aus Rechnerarchitektur: Pipelining \begin{itemize*} \item parallele Abarbeitung von Teilen eines Maschinenbefehls in Pipeline-Stufen \item ermöglicht durch verschiedene Funktionseinheiten eines Prozessors für verschiedene Stufen: \begin{itemize*} \item Control Unit (CU) \item ArithmeticLogicUnit (ALU) \item Float Point Unit (FPU) \item Memory Management Unit (MMU) \item Cache \end{itemize*} \item sowie mehrere Pipeline-Register \end{itemize*} - \item - superskalare Prozessoren: solche, bei denen zur Bearbeitung einer + \item superskalare Prozessoren: solche, bei denen zur Bearbeitung einer Pipeling-Stufe erforderlichen Funktionseinheiten n-fach vorliegen - \item - Ziel: + \item Ziel: \begin{itemize*} \item Skalarprozessor (mit Pipelining): 1 Befehl pro Takt (vollständig) bearbeitet \item Superskalarprozessor: bis zu n Befehle pro Taktbearbeitet \end{itemize*} - \item - Verbereitung heute: universell (bis hin zu allen + \item Verbereitung heute: universell (bis hin zu allen Desktop-Prozessorfamilien) \end{itemize*} @@ -5339,16 +4403,13 @@ Betriebssystemen} \begin{itemize*} - \item - Basis für alle Parallelarbeit aus BS-Sicht: Multithreading - \item - wir erinnern uns ...: + \item Basis für alle Parallelarbeit aus BS-Sicht: Multithreading + \item wir erinnern uns ...: \begin{itemize*} \item Kernel-Level-Threads (KLTs): BS implementiert Threads $\rightarrow$ Scheduler kann mehrere Threads nebenläufig planen $\rightarrow$ Parallelität möglich \item User-Level-Threads (ULTs): Anwendung implementiert Threads $\rightarrow$ keine Parallelität möglich! \end{itemize*} - \item - grundlegend für echt paralleles Multithreading: + \item grundlegend für echt paralleles Multithreading: \begin{itemize*} \item parallelisierungsfähige Hardware \item kausal unabhängige Threads @@ -5360,11 +4421,9 @@ Vorläufiges Fazit: \begin{itemize*} - \item - BS-Abstraktionen müssen Parallelität unterstützen (Abstraktion + \item BS-Abstraktionen müssen Parallelität unterstützen (Abstraktion nebenläufiger Aktivitäten: KLTs) - \item - BS muss Synchronisationsmechanismen implementieren + \item BS muss Synchronisationsmechanismen implementieren \end{itemize*} @@ -5372,34 +4431,29 @@ Sperrmechanismen} \begin{itemize*} - \item - Synchronisationsmechanismen zur Nutzung + \item Synchronisationsmechanismen zur Nutzung \begin{itemize*} \item ... durch Anwendungen $\rightarrow$ Teil der API \item ... durch den Kernel (z.B. Implementierung Prozessmanagement, E/A, ...) \end{itemize*} - \item - Aufgabe: Verhinderung konkurrierender Zugriffe auf logische oder + \item Aufgabe: Verhinderung konkurrierender Zugriffe auf logische oder physische Ressourcen \begin{itemize*} \item Vermeidung von raceconditions \item Herstellung einer korrekten Ordnung entsprechend Kommunikationssemantik (z.B. ,,Schreiben vor Lesen'') \end{itemize*} - \item - (alt-) bekanntes Bsp.: Reader-Writer-Problem + \item (alt-) bekanntes Bsp.: Reader-Writer-Problem \end{itemize*} Erinnerung: Reader-Writer-Problem \begin{itemize*} - \item - Begriffe: (bekannt) + \item Begriffe: (bekannt) \begin{itemize*} \item wechselseitiger Ausschluss ( mutual exclusion) \item kritischer Abschnitt (critical section) \end{itemize*} - \item - Synchronisationsprobleme: + \item Synchronisationsprobleme: \begin{itemize*} \item Wie verhindern wir ein write in vollen Puffer? \item Wie verhindern wir ein read aus leerem Puffer? @@ -5410,17 +4464,14 @@ Sperrmechanismen ( Locks ) \begin{itemize*} - \item - Wechselseitiger Ausschluss ... + \item Wechselseitiger Ausschluss ... \begin{itemize*} \item ... ist in nebenläufigen Systemen zwingend erforderlich \item ... ist in echt parallelen Systemen allgegenwärtig \item ... skaliert äußerst unfreundlich mit Code-Komplexität $\rightarrow$ (monolithischer) Kernel-Code! \end{itemize*} - \item - Mechanismen in Betriebssystemen: Locks - \item - Arten von Locks am Beispiel Linux: + \item Mechanismen in Betriebssystemen: Locks + \item Arten von Locks am Beispiel Linux: \begin{itemize*} \item Big Kernel Lock (BKL) \begin{itemize*} \item historisch (1996-2011): lockkernel(); ... unlockkernel(); \item ineffizient durch massiv gestiegene Komplexität des Kernels \end{itemize*} \item atomic-Operationen @@ -5432,14 +4483,12 @@ atomic* \begin{itemize*} - \item - Bausteine der komplexeren Sperrmechanismen: + \item Bausteine der komplexeren Sperrmechanismen: \begin{itemize*} \item Granularität: einzelne Integer- (oder sogar Bit-) Operation \item Performanz: mittels Assembler implementiert, nutzt Atomaritäts garantiender CPU ( TSL - Anweisungen: ,,test-set-lock'' ) \end{itemize*} - \item - Benutzung: + \item Benutzung: %\begin{Shaded} %\begin{Highlighting}[] @@ -5463,11 +4512,9 @@ Eigenschaften} \begin{itemize*} - \item - Funktionale Eigenschaften: beschreiben, was ein (Software)-Produkt tun + \item Funktionale Eigenschaften: beschreiben, was ein (Software)-Produkt tun soll - \item - Nichtfunktionale Eigenschaften: beschreiben, wie funktionale + \item Nichtfunktionale Eigenschaften: beschreiben, wie funktionale Eigenschaften realisiert werden, also welche sonstigen Eigenschaftendas Produkt haben soll ... unterteilbar in: \begin{enumerate*} @@ -5480,18 +4527,12 @@ Roadmap (... von Betriebssystemen) \begin{itemize*} - \item - Sparsamkeit und Effizienz - \item - Robustheit und Verfügbarkeit - \item - Sicherheit - \item - Echtzeitfähigkeit - \item - Adaptivität - \item - Performanzund Parallelität + \item Sparsamkeit und Effizienz + \item Robustheit und Verfügbarkeit + \item Sicherheit + \item Echtzeitfähigkeit + \item Adaptivität + \item Performanzund Parallelität \end{itemize*} @@ -5499,18 +4540,14 @@ Effizienz} \begin{itemize*} - \item - Sparsamkeit: Die Eigenschaft eines Systems, seine Funktion mit + \item Sparsamkeit: Die Eigenschaft eines Systems, seine Funktion mit minimalem Ressourcenverbrauch auszuüben. - \item - Effizienz: Der Grad, zu welchem ein System oder eine seiner + \item Effizienz: Der Grad, zu welchem ein System oder eine seiner Komponenten seine Funktion mit minimalem Ressourcenverbrauch ausübt. $\rightarrow$ Ausnutzungsgrad begrenzter Ressourcen - \item - Die jeweils betrachtete(n) Ressource(n) muss /(müssen) dabei + \item Die jeweils betrachtete(n) Ressource(n) muss /(müssen) dabei spezifiziert sein! - \item - sinnvolle Möglichkeiten bei Betriebssystemen: + \item sinnvolle Möglichkeiten bei Betriebssystemen: \begin{enumerate*} \item Sparsamer Umgang mit Energie , z.B. energieeffizientes Scheduling @@ -5523,21 +4560,18 @@ Sparsamkeit mit Energie \begin{itemize*} - \item - Sparsamkeit mit Energie als heute extrem wichtigen Ressource, mit + \item Sparsamkeit mit Energie als heute extrem wichtigen Ressource, mit nochmals gesteigerter Bedeutung bei mobilen bzw. vollständig autonomen Geräten Maßnahmen: \end{itemize*} \begin{enumerate*} - \item - Hardware-Ebene: momentan nicht oder nicht mit maximaler Leistung + \item Hardware-Ebene: momentan nicht oder nicht mit maximaler Leistung benötigte Ressourcen in energiesparenden Modus bringen: abschalten, Standby, Betrieb mit verringertem Energieverbrauch ( abwägen gegen verminderte Leistung). (Geeignete Hardware wurde/wird ggf. erst entwickelt) - \item - Software-Ebene: neue Komponenten entwickeln, die in der Lage sein + \item Software-Ebene: neue Komponenten entwickeln, die in der Lage sein müssen: \begin{itemize*} \item Bedingungenzu erkennen, unter denen ein energiesparender Modus möglich ist; @@ -5550,18 +4584,15 @@ Sparsamkeit mit Speicherplatz \begin{itemize*} - \item - Betrachtet: Sparsamkeit mit Speicherplatz mit besonderer Wichtigkeit + \item Betrachtet: Sparsamkeit mit Speicherplatz mit besonderer Wichtigkeit für physisch beschränkte, eingebettete und autonome Geräte - \item - Maßnahmen Hauptspeicherauslastung: + \item Maßnahmen Hauptspeicherauslastung: \begin{enumerate*} \item Algorithmus und Strategie z.B.: \begin{itemize*} \item Speicherplatz sparende Algorithmen zur Realisierung gleicher Strategien \end{itemize*} \item Speicherverwaltung von Betriebssystemen: \begin{itemize*} \item physische vs. virtuelle Speicherverwaltung \item speichereffiziente Ressourcenverwaltung \item Speicherbedarfdes Kernels \item direkte Speicherverwaltungskosten \end{itemize*} \end{enumerate*} - \item - Maßnahmen Hintergrundspeicherauslastung: + \item Maßnahmen Hintergrundspeicherauslastung: \begin{enumerate*} \item Speicherbedarf des Betriebssystem-Images @@ -5569,8 +4600,7 @@ \item VMM-Auslagerungsbereich \item Modularität und Adaptivität des Betriebssystem-Images \end{enumerate*} - \item - Nicht betrachtet: Sparsamkeit mit Prozessorzeit + \item Nicht betrachtet: Sparsamkeit mit Prozessorzeit $\rightarrow$ 99\% Überschneidung mit NFE Performanz \end{itemize*} @@ -5579,18 +4609,15 @@ Verfügbarkeit} \begin{itemize*} - \item - Robustheit: Zuverlässigkeit unter Anwesenheit externer Ausfälle - \item - fault, aktiviert $\rightarrow$ error, breitet sich aus + \item Robustheit: Zuverlässigkeit unter Anwesenheit externer Ausfälle + \item fault, aktiviert $\rightarrow$ error, breitet sich aus $\rightarrow$ failure \end{itemize*} Robustheit \begin{itemize*} - \item - Erhöhung der Robustheit durch Isolation: + \item Erhöhung der Robustheit durch Isolation: \begin{itemize*} \item Maßnahmen zur Verhinderung der Fehlerausbreitung: \end{itemize*} @@ -5600,29 +4627,24 @@ \item kryptografische HW-Unterstützung: Intel SGX und \item Virtualisierungsarchitekturen \end{enumerate*} - \item - Erhöhung der Robustheit durch Behandlung von Ausfällen: Micro-Reboots + \item Erhöhung der Robustheit durch Behandlung von Ausfällen: Micro-Reboots \end{itemize*} Vorbedingung für Robustheit: Korrektheit \begin{itemize*} - \item - Korrektheit: Eigenschaft eines Systems sich gemäß seiner Spezifikation + \item Korrektheit: Eigenschaft eines Systems sich gemäß seiner Spezifikation zu verhalten (unter der Annahme, dass bei dieser keine Fehler gemacht wurden). - \item - Maßnahmen (nur angesprochen): + \item Maßnahmen (nur angesprochen): \end{itemize*} \begin{enumerate*} - \item - diverse Software-Tests: + \item diverse Software-Tests: \begin{itemize*} \item können nur Fehler aufspüren, aber keine Fehlerfreiheit garantieren! \end{itemize*} - \item - Verifizierung: + \item Verifizierung: \begin{itemize*} \item Durch umfangreichen mathematischen Apparat wird Korrektheit der Software bewiesen. \item Aufgrund der Komplexität ist Größe verifizierbarer Systeme (bisher?) begrenzt. @@ -5633,13 +4655,10 @@ Verfügbarkeit \begin{itemize*} - \item - Verfügbarkeit: Der Anteil an Laufzeit eines Systems, in dem dieses + \item Verfügbarkeit: Der Anteil an Laufzeit eines Systems, in dem dieses seine spezifizierte Leistung erbringt. - \item - angesprochen: Hochverfügbare Systeme - \item - Maßnahmen zur Erhöhung der Verfügbarkeit: + \item angesprochen: Hochverfügbare Systeme + \item Maßnahmen zur Erhöhung der Verfügbarkeit: \begin{enumerate*} \item Robustheitsmaßnahmen @@ -5654,12 +4673,10 @@ \subsection{Sicherheit} \begin{itemize*} - \item - Sicherheit (IT-Security): Schutz eines Systems gegen Schäden durch + \item Sicherheit (IT-Security): Schutz eines Systems gegen Schäden durch zielgerichtete Angriffe, insbesondere in Bezug auf die Informationen, die es speichert, verarbeitet und kommuniziert. - \item - Sicherheitsziele: + \item Sicherheitsziele: \begin{enumerate*} \item Vertraulichkeit (Confidentiality) @@ -5673,26 +4690,22 @@ Security Engineering \begin{itemize*} - \item - Sicherheitsziele $\rightarrow$ Sicherheitspolitik + \item Sicherheitsziele $\rightarrow$ Sicherheitspolitik $\rightarrow$ Sicherheitsarchitektur $\rightarrow$ Sicherheitsmechanismen - \item - Sicherheitspolitik: Regeln zum Erreichen eines Sicherheitsziels. + \item Sicherheitspolitik: Regeln zum Erreichen eines Sicherheitsziels. \begin{itemize*} \item hierzu formale Sicherheitsmodelle: \item IBAC, TE, MLS \item DAC, MAC \end{itemize*} - \item - Sicherheitsmechanismen: Implementierung der Durchsetzung einer + \item Sicherheitsmechanismen: Implementierung der Durchsetzung einer Sicherheitspolitik. \begin{itemize*} \item Zugriffssteuerungslisten(ACLs) \item SELinux \end{itemize*} - \item - Sicherheitsarchitektur: Platzierung, Struktur und Interaktion von + \item Sicherheitsarchitektur: Platzierung, Struktur und Interaktion von Sicherheitsmechanismen. \begin{itemize*} \item wesentlich: Referenzmonitorprinzipien @@ -5706,28 +4719,23 @@ \subsection{Echtzeitfähigkeit} \begin{itemize*} - \item - Echtzeitfähigkeit: Fähigkeit eines Systems auf eine Eingabe innerhalb + \item Echtzeitfähigkeit: Fähigkeit eines Systems auf eine Eingabe innerhalb eines spezifizierten Zeitintervalls eine korrekte Reaktion hervorzubringen. - \item - Maximum dieses relativen Zeitintervalls: Frist d + \item Maximum dieses relativen Zeitintervalls: Frist d \end{itemize*} \begin{enumerate*} - \item - echtzeitfähige Scheduling-Algorithmen für Prozessoren + \item echtzeitfähige Scheduling-Algorithmen für Prozessoren \begin{itemize*} \item zentral: garantierte Einhaltung von Fristen \item wichtige Probleme: Prioritätsumkehr, Überlast, kausale Abhängigkeit \end{itemize*} - \item - echtzeitfähige Interrupt-Behandlung + \item echtzeitfähige Interrupt-Behandlung \begin{itemize*} \item zweiteilig:asynchron registrieren, geplant bearbeiten \end{itemize*} - \item - echtzeitfähige Speicherverwaltung + \item echtzeitfähige Speicherverwaltung \begin{itemize*} \item Primärspeicherverwaltung, VMM (Pinning) \item Sekundärspeicherverwaltung, Festplattenscheduling @@ -5738,12 +4746,10 @@ \subsection{Adaptivität} \begin{itemize*} - \item - Adaptivität: Eigenschaft eines Systems, so gebaut zu sein, dass es ein + \item Adaptivität: Eigenschaft eines Systems, so gebaut zu sein, dass es ein gegebenes (breites) Spektrum nichtfunktionaler Eigenschaften unterstützt. - \item - Beobachtung: Adaptivität i.d.R. als komplementär und synergetisch zu + \item Beobachtung: Adaptivität i.d.R. als komplementär und synergetisch zu anderen NFE: \begin{itemize*} \item Sparsamkeit @@ -5758,8 +4764,7 @@ Adaptive Systemarchitekturen \begin{itemize*} - \item - Zielstellungen: + \item Zielstellungen: \begin{itemize*} \item Exokernel: \{ Adaptivität \} $\cup$ \{ Performanz, Echtzeitfähigkeit, Wartbarkeit, Sparsamkeit \} \item Virtualisierung: \{ Adaptivität \} $\cup$ \{ Wartbarkeit, Sicherheit, Robustheit \} @@ -5772,11 +4777,9 @@ Parallelität} \begin{itemize*} - \item - Performanz (wie hier besprochen): Eigenschaft eines Systems, die für + \item Performanz (wie hier besprochen): Eigenschaft eines Systems, die für korrekte Funktion (= Berechnung) benötigte Zeit zu minimieren. - \item - hier betrachtet: Kurze Antwort-und Reaktionszeiten + \item hier betrachtet: Kurze Antwort-und Reaktionszeiten \begin{enumerate*} \item vor allen Dingen: Parallelisierung auf Betriebssystemebene zur weiteren Steigerung der Performanz/Ausnutzung von Multicore-Prozessoren(da Steigerung der Prozessortaktfrequenz kaum noch möglich) @@ -5787,21 +4790,18 @@ Mechanismen, Architekturen, Grenzen der Parallelisierung \begin{itemize*} - \item - Hardware: + \item Hardware: \begin{itemize*} \item Multicore-Prozessoren \item Superskalarität \end{itemize*} - \item - Betriebssystem: + \item Betriebssystem: \begin{itemize*} \item Multithreading(KLTs) und Scheduling \item Synchronisation und Kommunikation \item Lastangleichung \end{itemize*} - \item - Anwendung(sprogrammierer): + \item Anwendung(sprogrammierer): \begin{itemize*} \item Parallelisierbarkeiteines Problems \item optimaler Prozessoreneinsatz, Effizienz @@ -5813,14 +4813,12 @@ Eigenschaften} \begin{itemize*} - \item - Normalerweise: + \item Normalerweise: \begin{itemize*} \item Eine nichtfunktionale Eigenschaft bei IT-Systemen meist nicht ausreichend \item Beispiel: Was nützt ein Echtzeit-Betriebssystem - z.B. innerhalb einer Flugzeugsteuerung - wenn es nicht auch verlässlich arbeitet? \end{itemize*} - \item - In diesem Zusammenhang interessant: + \item In diesem Zusammenhang interessant: \begin{itemize*} \item Welche nichtfunktionalen Eigenschaften mit Maßnahmen erreichbar, die in gleiche Richtung zielen, bei welchen wirken Maßnahmen eher gegenläufig? \item Erstere sollen synergetische, die zweiten konträre (also in Widerspruch zueinander stehende) nichtfunktionale Eigenschaften genannt werden. @@ -5832,13 +4830,11 @@ \subsection{Notwendige NFE-Paarungen} \begin{itemize*} - \item - Motivation: Anwendungen (damit auch Betriebssysteme) für bestimmte + \item Motivation: Anwendungen (damit auch Betriebssysteme) für bestimmte Einsatzgebiete brauchen oft mehrere nichtfunktionale Eigenschaften gleichzeitig - unabhängig davon, ob sich diese synergetisch oder nichtsynergetisch zueinander verhalten. - \item - Beispiele: + \item Beispiele: \begin{itemize*} \item Echtzeit und Verlässlichkeit: ,,SRÜ''-Systeme an potentiell gefährlichen Einsatzgebieten (Atomkraftwerk, Flugzeugsteuerung, Hinderniserkennung an Fahrzeugen, ...) \item Echtzeit und Sparsamkeit: Teil der eingebetteten Systeme @@ -5868,14 +4864,10 @@ %\end{longtable} \begin{itemize*} - \item - \cmark ... Zieleigenschaft - \item - ( \cmark ) ... synergetische Eigenschaft - \item - \xmark ... konträre Eigenschaft - \item - Leere Zellen: keine pauschale Aussage möglich. + \item[\cmark] ... Zieleigenschaft + \item ( \cmark ) ... synergetische Eigenschaft + \item[\xmark] ... konträre Eigenschaft + \item Leere Zellen: keine pauschale Aussage möglich. \end{itemize*} Fazit: Breites und offenes Forschungsfeld $\rightarrow$