Betriebssysteme stecken nicht nur in Einzelplatzrechnern, sondern z.B. auch in:
- Informationssystemen
- Gesundheitswesen
- Finanzdienstleister
- Verkehrsmanagement-Systemen
- Eisenbahn
- Flugwesen
- Kommunikationssystemen
- Mobilfunk
- Raumfahrt
- eingebettetenSystemen
- Multimedia
- Fahrzeugsysteme
- Sensornetze
- ... $\rightarrow$ verschiedenste Anforderungen!
Konsequenz: Spezialbetriebssysteme für Anforderungen wie ...
- Robustheit
- Echtzeitfähigkeit
- Energieeffizienz
- Sicherheit
- Adaptivität
- ...
Gegenstand dieser Vorlesung: Konstruktionsrichtlinien für solche ,,High-End Betriebssysteme''
## Funktionale und nichtfunktionale Eigenschaften
- Beispiel: Autokauf ,,Mit unserem Fahrzeug können Sie einkaufen fahren!''
- Beispiel: Handykauf ,,Mit unserem Telefon können Sie Ihre Freunde und Familie anrufen!''
- Anforderungen (Requirements)
- Funktionale und nichtfunktionale Eigenschaften (eines Produkts, z.B. Softwaresystems) entstehen durch Erfüllung von funktionalen und nichtfunktionalen Anforderungen
- funktionale Eigenschaft
- legt fest, was ein Produkt tun soll.
- Bsp Handykauf: Das Produkt soll Telefongespräche ermöglichen.
- eine nichtfunktionale Eigenschaft (NFE)
- legt fest, wie es dies tun soll, also welche sonstigen Eigenschaften das Produkt haben soll.
- Bsp Handykauf: Das Produkt soll klein, leicht, energiesparend, strahlungsarm, umweltfreundlich,... sein.
- andere Bezeichnungen nichtfunktionaler Eigenschaften
- Qualitäten bzw. Qualitätsattribute (eines Software-Produkts):
- Nichtfunktionale Anforderungen bzw. Eigenschaften eines Software-Systems bzw. -Produkts oft auch als seine Qualitäten bezeichnet.
- einzelne realisierte Eigenschaft ist demzufolge ein Qualitätsattribut (quality property) dieses Systems bzw. Produkts.
- Weitere in der Literatur zu findende Begriffe in diesem Zusammenhang:
5. Verteiltes Rechnen auf Multicore-Prozessoren: temperaturabhängige Lastverteilung
6. ...
### Energieeffiziente Dateizugriffe
Hardwarebedingungen: Magnetplatten (HDD), Netzwerkgeräte, DRAM-ICs,... sparen nur bei relativ langen Inaktivitätsintervallen Energie.
- Aufgabe: Erzeugen kurzer, intensiver Zugriffsmuster $\rightarrow$ lange Inaktivitätsintervalle (für alle Geräte mit geringem Energieverbrauch im Ruhezustand)
- Beobachtung bei HDD-Geräten: i.A. vier Zustände mit absteigendem Energieverbrauch:
1. Aktiv: einziger Arbeitszustand
2. Idle (Leerlauf): Platte rotiert, aber Plattenelektronik teilweise abgeschaltet
3. Standby: Rotation abgeschaltet
4. Sleep: gesamte restliche Elektronik abgeschaltet
- ähnliche, noch stärker differenzierte Zustände bei DRAM (vgl. [DGMB07] )
- Voraussetzung: Vorwissen über benötigte Folge von zukünftigen Datenblockreferenzen (z.B. Blockadressen für bestimmte Dateien, gewonnen durch Aufzeichnung früherer Zugriffsmuster beim Start von Anwendungen -Linux: readahead syscall)
- Ziel: Performanzverbesserungdurch Durchsatzerhöhung u. Latenzzeit-Verringerung
- Idee: Vorziehen möglichst vieler E/A-Anforderungen an Festplatte + zeitlich gleichmäßige Verteilung der verbleibenden
- Umsetzung: Caching (Zwischenspeichern) dieser vorausschauend gelesenen Blöcke in ungenutzten Hauptspeicherseitenrahmen ( pagecache )
- Folge: Inaktivitätsintervalle überwiegend sehr kurz $\rightarrow$ Energieeffizienz ...?
- Zugriffsoperation: (durch Anwendung)
- access(x) ... greife (lesend/schreibend) auf den Inhalt von Festplattenblock x im Page Cache zu
- Festplattenoperationen:
- fetch(x) ... hole Block x nach einem access(x) von Festplatte
- prefetch(x) ... hole Block x ohne access(x) von Festplatte
- beide Operationen schreiben x in einen freien Platz des Festplattencaches; falls dieser voll ist ersetzen sie einen der Einträge gemäß fester Regeln $\rightarrow$ Teil der (Pre-) Fetching-Strategie
- Beispiel für solche Strategien: Anwendung ...
- mit Datenblock-Referenzstrom A, B, C, D, E, F, G, ...
- mit konstanter Zugriffsdauer: 10 Zeiteinheiten je Blockzugriff
- Cache-Kapazität: 3 Datenblöcke
- Zeit zum Holen eines Blocks bei Cache-Miss: 1 Zeiteinheit
4. Maximiere Zugriffsfolgen: Führe immer dann nach einem _fetch_ oder _prefetch_ ein weiteres _prefetch_ aus, wenn Blöcke für eine Ersetzung geeignet sind. (i.S.v. Regel 3)
5. Beachte Idle-Zeiten: Unterbrich nur dann eine Inaktivitätsperiode durch ein _prefetch_ , falls dieses sofort ausgeführt werden muss, um einen Cache-Miss zu vermeiden.
Allgemeine Schlussfolgerungen
1. Hardware-Spezifikation nutzen: Modi, in denen wenig Energie verbraucht wird
2. Entwicklung von Strategien, die langen Aufenthalt in energiesparenden Modi ermöglichen , und dabei Leistungsparameter in vertretbarem Umfang reduzieren
3. Implementieren dieser Strategien in Betriebssystemmechanismen zur Ressourcenverwaltung
### Energieeffizientes Prozessormanagement
Hardware-Gegebenheiten
- z.Zt. meistgenutzte Halbleitertechnologie für Prozessor-Hardware: CMOS ( Complementary Metal Oxide Semiconductor)
- Konsequenz: Leckströme kritisch für energiesparenden Hardwareentwurf
#### Regelspielraum: Nutzererfahrung
- Nutzererwartung: wichtigstes Kriterium zur (subjektiven) Bewertung von auf einem Rechner aktiven Anwendungen durch Nutzer $\rightarrow$ Nutzerwartung bestimmt Nutzererfahrung
- Typ einer Anwendung
- entscheidet über jeweilige Nutzererwartung
1. Hintergrundanwendung (z.B. Compiler); von Interesse: Gesamt-Bearbeitungsdauer, Durchsatz
3. Interaktive Anwendung (z.B. Webbrowser); von Interesse: Reaktivität, d.h. keine (wahrnehmbare) Verzögerung zwischen Nutzer-Aktion und Rechner-Reaktion
- Insbesondere kritisch: Echtzeitanwendungen, interaktive Anwendungen
Reaktivität
- Reaktion von Anwendungen
- abhängig von sog. Reaktivität des Rechnersystems ≈ durchschnittliche Zeitdauer, mit der Reaktion eines Rechners auf eine (Benutzerinter-) Aktion erfolgt
- Reaktivität: von Reihe von Faktoren abhängig, z.B.:
1. von **Hardware** an sich
2. von **Energieversorgung** der Hardware (wichtig z.B. Spannungspegel an verschiedenen Stellen)
3. von **Software-Gegebenheiten** (z.B. Prozess-Scheduling, Speichermanagement, Magnetplatten-E/A-Scheduling, Vorgänge im Fenstersystem, Arten des Ressourcen-Sharing usw.)
- dies erfordert ebenfalls Verteilungsstrategien: ,,Energy-aware Scheduling'' (Linux-Strategie zur Prozessorallokation -nicht zeitlichem Multiplexing!)
- Traditionelle Betriebssysteme: Entwurf so, dass zu jedem Zeitpunkt Spitzen-Performanzangestrebt
- Beobachtungen:
- viele Anwendungen benötigen keine Spitzen-Performanz
- viele Hardware-Komponenten verbringen Zeit in Leerlaufsituationen bzw. in Situationen, wo keine Spitzen-Performanz erforderlich
- Konsequenz (besonders für mobile Systeme) :
- Hardware mit Niedrigenergiezuständen(Prozessoren und Magnetplattenlaufwerke, aber auch DRAM, Netzwerkschnittstellen, Displays, ...)
- somit kann Betriebssystem **Energie-Management** realisieren
#### Hardwaretechnologien
- DPM: Dynamic Power Management
- versetzt leerlaufende/unbenutzte Hardware-Komponenten selektiv in Zustände mit niedrigem Energieverbrauch
- Zustandsübergänge durch Power-Manager (in Hardware) gesteuert, dem bestimmte _DPM-_ Strategie (Firmware) zugrunde liegt, um gutes Verhältnis zwischen Performanz/Reaktivität und Energieeinsparung zu erzielen
- DVS: Dynamic Voltage Scaling
- effizientes Verfahren zur dynamischen Regulierungvon Taktfrequenz gemeinsammit Versorgungsspannung
- Nutzung quadratischer Abhängigkeitder dynamischen Leistung von Versorgungsspannung
Dynamisches Energiemanagement (DPM)- Strategien (Klassen) bestimmt, wann und wie lange eine Hardware-Komponente sich in Energiesparmodusbefinden sollte
- ebenfalls sparsames BS,optimiert für anspruchsvollere Anwendungen (breiteres Spektrum)
- ,,RIOT ist ein Open-Source-Mikrokernel-basiertes Betriebssystem, das speziell für die Anforderungen von Internet-of-Things-Geräten (IoT) und anderen eingebetteten Geräten entwickelt wurde.''
- Smartdevices,
- intelligentes Zuhause, intelligente Zähler,
- eingebettete Unterhaltungssysteme
- persönliche Gesundheitsgeräte,
- intelligentes Fahren,
- Geräte zur Verfolgung und Überwachung der Logistik.
- Architektur:
- halbwegs: Mikrokernel
- energiesparendeKernelfunktionalität:
- minimale Algorithmenkomplexität
- vereinfachtes Threadkonzept $\rightarrow$ keine Kontextsicherung erforderlich
- keine dynamische Speicherallokation
- energiesparende Hardwarezustände vom Scheduler ausgelöst (inaktive CPU)
- Ausfälle zur Laufzeit erkennen und Folgen beheben, abschwächen...
- $\rightarrow$ Micro-Reboots
## Fehlerhafter Zustand
- interner und externer Zustand (internal & external state)
- externer Zustand (einer Systems oder Subsystems): der Teil des Gesamtzustands, der an externer Schnittstelle (also für das umgebende (Sub-) System) sichtbar wird
- interner Zustand: restlicher Teilzustand
- (tatsächlich) erbrachte Leistung: zeitliche Folge externer Zustände
- Beispiele für das System ( Betriebssystem-) Kernel :
#### Private virtuelle Adressräume und Fehlerausbreitung
- korrekte private vAR ~ kollisionsfreie Seitenabbildung!
- Magie in Hardware: MMU (BS steuert und verwaltet...)
- Robustheit: Was haben wir von privaten vAR?
- ✓ nichtvertrauenswürdiger (i.S.v. potenziell nicht korrekter) Code kann keine beliebigen physischen Adressen schreiben (er erreicht sie ja nicht mal...)
- ✓ Kommunikation zwischen nvw. Code (z.B. Anwendungstasks) muss durch IPC-Mechanismen explizit hergestellt werden (u.U. auch shared memory)
- $\rightarrow$ Überwachung und Validierung zur Laufzeit möglich
- ✓ Kontrollfluss begrenzen: Funktionsaufrufe können i.A. (Ausnahme: RPC) keine AR-Grenzen überschreiten
- $\rightarrow$ BS-Zugriffssteuerungkann nicht durch Taskfehler ausgehebelt werden
- Rest (insbes. Treiber): ,,gewöhnliche'' Anwendungsprozesse mit Adressraumisolation
- Kommunikation: botschaftenbasierteIPC (auch client-server operating system )
- Nomenklatur: Mikrokernelund Serverprozesse
### Modularer Makrokernel vs. Mikrokernel
- ![Abb. nach [Heis19]](Assets/AdvancedOperatingSystems-modularer-makrokernel.png)
- minimale Kernelfunktionalität:
- keine Dienste, nur allgemeine Schnittstellenfür diese
- keine Strategien, nur grundlegende Mechanismenzur Ressourcenverwaltung
- neues Problem: minimales Mikrokerneldesign
- ,,Wir haben 100 Leute gefragt...'': Wie entscheide ich das?
- ![Abb. nach [Heis19]](Assets/AdvancedOperatingSystems-modularer-makrokernel-2.png)
- Ablauf eines Systemaufrufs
- schwarz: unprivilegierteInstruktionen
- blau:privilegierte Instruktionen
- rot:Übergang zwischen beidem (μKern $\rightarrow$ Kontextwechsel!)
#### Robustheit von Mikrokernen
- = Gewinn durch Adressraumisolation innerhalb des Kernels
- ✓ kein nichtvertrauenswürdiger Code im kernelspace , der dort beliebige physische Adressen manipulieren kann
- ✓ Kommunikation zwischen nvw. Code (nicht zur zwischen Anwendungstasks)muss durch IPC explizit hergestellt werden $\rightarrow$ Überwachung und Validierung zur Laufzeit
- ✓ Kontrollfluss begrenzen: Zugriffssteuerung auch zwischen Serverprozessen, zur Laufzeit unabhängiges Teilmanagement von Code (Kernelcode) möglich (z.B.: Nichtterminierung erkennen)
- Neu:
- ✓ nvw. BS-Code muss nicht mehr im kernelspace (höchste Prozessorprivilegierung) laufen
- ✓ verbleibender Kernel (dessen Korrektheit wir annehmen): klein, funktional weniger komplex, leichter zu entwickeln, zu testen, evtl. formal zu verifizieren
- ✓ daneben: Adaptivitätdurch konsequentere Modularisierung des Kernels gesteigert
### Mach
- Mikrokernel-Design: Erster Versuch
- Carnegie Mellon University (CMU), School of Computer Science 1985 - 1994
- ein wenig Historie
- UNIX (Bell Labs) - K. Thompson, D. Ritchie
- BSD (U Berkeley) - W. Joy
- System V - W. Joy
- Mach (CMU) - R. Rashid
- MINIX - A. Tanenbaum
- NeXTSTEP (NeXT) - S. Jobs
- Linux - L. Torvalds
- GNU Hurd (FSF) - R. Stallman
- Mac OS X (Apple) - S. Jobs
#### Mach: Ziele
Entstehung
- Grundlage:
- 1975: Aleph(BS des ,,Rochester Intelligent Gateway''), U Rochester
- 1979/81: Accent (verteiltes BS), CMU
- gefördert durch militärische Geldgeber:
- DARPA: Defense AdvancedResearch Projects Agency
- SCI: Strategic Computing Initiative
Ziele
- Mach 3.0 (Richard Rashid, 1989): einer der ersten praktisch nutzbaren μKerne
- Ziel: API-Emulation(≠ Virtualisierung!)von UNIX und -Derivaten auf unterschiedlichen Prozessorarchitekturen
- mehrere unterschiedliche Emulatoren gleichzeitig lauffähig
- Emulation außerhalb des Kernels
- jeder Emulator:
- Komponente im Adressraum des Applikationsprogramms
- 1...n Server, die unabhängig von Applikationsprogramm laufen
- Liedtke: Unterscheidung zwischen Konzepten und deren Implementierung
- bestimmende Anforderungen an beide:
- Konzeptsicht $\rightarrow$ Funktionalität,
- Implementierungssicht $\rightarrow$ Performanz
- $\rightarrow$ 1. μKernel-Generation: Konzept durch Performanzentscheidungen aufgeweicht
- $\rightarrow$ Effekt in der Praxis genau gegenteilig: schlechte (IPC-) Performanz!
> ,,The determining criterion used is functionality, not performance. More precisely, a concept is tolerated inside the μ-kernel only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the systems‘s required functionality .'' [Jochen Liedtke]
Designprinzipien für Mikrokernel-Konzept:
- $\rightarrow$ Annahmen hinsichtlich der funktionalen Anforderungen:
1. System interaktive und nicht vollständig vertrauenswürdige Applikationen unterstützen ($\rightarrow$ HW-Schutz, -Multiplexing),
2. Hardware mit virtueller Speicherverwaltung und Paging
Designprinzipien:
1. Autonomie: ,,Ein Subsystem (Server)muss so implementiert werden können, dass es von keinem anderen Subsystem gestört oder korrumpiert werden kann.''
2. Integrität: ,,Subsystem (Server) $S_1$ muss sich auf Garantien von $S_2$ verlassen können. D.h. beide Subsysteme müssen miteinander kommunizieren können, ohne dass ein drittes Subsystem diese Kommunikation stören, fälschen oder abhören kann.''
L4: Speicherabstraktion
- Adressraum: Abbildung, die jede virtuelle Seite auf einen physischen Seitenrahmen abbildet oder als ,,nicht zugreifbar'' markiert
- Implementierung über Seitentabellen, unterstützt durch MMU-Hardware
- Aufgabe des Mikrokernels (als gemeinsame obligatorische Schicht aller Subsysteme): muss Hardware-Konzept des Adressraums verbergen und durch eigenes Adressraum-Konzept überlagern (sonst Implementierung von VMM-Mechanismen durch Server unmöglich)
- Mikrokernel-Konzept des Adressraums:
- muss Implementierung von beliebigen virtuellen Speicherverwaltungs-und -schutzkonzepten oberhalb des Mikrokernels (d.h. in den Subsystemen) erlauben
- sollte einfach und dem Hardware-Konzept ähnlich sein
- Idee: abstrakte Speicherverwaltung
- rekursive Konstruktion und Verwaltung der Adressräume auf Benutzer-(Server-)Ebene
- Mikrokernel stellt dafür genau drei Operationen bereit:
1. grant(x) - Server $S$ überträgt Seite $x$ seines AR in AR von Empfänger $S‘$
2. map(x) - Server $S$ bildet Seite $x$ seines AR in AR von Empfänger $S‘$ ab
3. flush(x) - Server $S$ entfernt (flusht) Seite x seines AR aus allen fremden AR
Hierarchische Adressräume
- Rekursive Konstruktion der Adressraumhierarchie
- Server und Anwendungenkönnen damit ihren Klienten Seiten des eigenen Adressraumes zur Verfügung stellen
- Realspeicher: Ur-Adressraum, vom μKernel verwaltet
- Speicherverwaltung(en), Paging usw.: vollständig außerhalb des μ-Kernels realisiert
- TU Dresden (Hermann Härtig): Neuimplementierung in C++ (L4/Fiasco), Basis des Echtzeit-Betriebssystems DROPS, der VirtualisierungsplattformNOVA (genauer: Hypervisor) und des adaptiven BS-Kernels Fiasco.OC
- University ofNew South Wales (UNSW), Australien (Gernot Heiser):
- Implementierung von L4 auf verschiedenen 64 - Bit-Plattformen, bekannt als L4/MIPS, L4/Alpha
- Implementierung in C (Wartbarkeit, Performanz)
- Mit L4Ka::Pistachio bisher schnellste Implementierung von botschaftenbasierterIPC (2005: 36 Zyklen auf Itanium-Architektur)
- seit 2009: seL4, erster formal verifizierter BS-Kernel (d.h. mathematisch bewiesen, dass Implementierung funktional korrekt ist und nachweislich keinen Entwurfsfehler enthält)
Zwischenfazit
- Begrenzung von Fehlerausbreitung ( $\rightarrow$ Folgen von errors ):
- konsequent modularisierte Architektur aus Subsystemen
- Isolationsmechanismen zwischen Subsystemen
- Konsequenzen für BS-Kernel:
- statische Isolation auf Quellcodeebene $\rightarrow$ strukturierte Programmierung
- dynamische Isolation zur Laufzeit $\rightarrow$ private virtuelle Adressräume
- Architektur, welche diese Mechanismen komponiert: Mikrokernel
- Was haben wir gewonnen?
- ✓ Adressraumisolation für sämtlichen nichtvertrauenswürdigen Code
- ✓ keine privilegierten Instruktionen in nvw. Code (Serverprozesse)
- ✓ geringe Größe (potenziell: Verifizierbarkeit) des Kernels
- ✓ neben Robustheit: Modularitätund Adaptivitätdes Kernels
- Und was noch nicht?
- ✗ Behandlung von Ausfällen ( $\rightarrow$ abstürzende Gerätetreiber ...)
## 3.5 Micro-Reboots
- Beobachtungen am Ausfallverhalten von BS:
- Kernelfehler sind (potenziell) fatal für gesamtes System
- Anwendungsfehler sind es nicht
- $\rightarrow$ kleiner Kernel = geringeres Risiko von Systemausfällen
- $\rightarrow$ durch BS-Code in Serverprozessen: verbleibendes Risiko unabhängiger Teilausfälle von BS-Funktionalität (z.B. FS, Treiberprozesse, GUI, ...)
- Ergänzung zu Isolationsmechanismen:
- Mechanismen zur Behandlung von Subsystem-Ausfällen
- = Mechanismen zur Behandlung Anwendungs-, Server- und Gerätetreiberfehlen
- $\rightarrow$ Micro-Reboots
Ansatz
- wir haben:
- kleinen, ergo vertrauenswürdigen (als fehlerfrei angenommenen)μKernel
- BS-Funktionalität in bedingt vertrauenswürdigen Serverprozessen (kontrollierbare, aber wesentlich größere Codebasis)
- Gerätetreiber und Anwendungen in nicht vertrauenswürdigen Prozessen (nicht kontrollierbare Codebasis)
- wir wollen:
- Systemausfälle verhindern durch Vermeidung von errors im Kernel $\rightarrow$ höchste Priorität
- Treiber-und Serverausfälle minimieren durch Verbergen ihrer Auswirkungen $\rightarrow$ nachgeordnete Priorität (Best-Effort-Prinzip)
- Idee:
- Systemausfälle $\rightarrow$ μKernel
- Treiber-und Serverausfälle $\rightarrow$ Neustart durch spezialisierten Serverprozess
- [vorkompiliertes Kernel-Image zum Installieren (VirtualBox, VMWare, ...)](https://wiki.minix3.org/doku.php?id=www:download:start)
## Verfügbarkeit
- komplementäre NFE zu Robustheit: Verfügbarkeit ( availability )
- Zur Erinnerung: Untereigenschaften von Verlässlichkeit
1. Verfügbarkeit (availability)
2. Robustheit (robustness, reliability)
- Beziehung:
- Verbesserung von Robustheit $\Rightarrow$ Verbesserung von Verfügbarkeit
- Robustheitsmaßnahmen hinreichend , nicht notwendig (hochverfügbare Systeme können sehr wohl von Ausfällen betroffen sein...)
- eine weitere komplementäre NFE:
- Robustheit $\Rightarrow$ Sicherheit (security)
Allgemeine Definition: Der Grad, zu welchem ein System oder eine Komponente funktionsfähig und zugänglich (erreichbar) ist,wann immer seine Nutzung erforderlichist. (IEEE)
genauer quantifiziert:
- Der Anteil an Laufzeit eines Systems, in dem dieses seine spezifizierte Leistung erbringt.
- 27.-28.11.2016: Ausfälle von über 900.000 Kundenanschlüssen der Deutschen Telekom
- Bundesamt für Sicherheit in der Informationstechnik (BSI): weltweiter Angriff auf ausgewählte Fernverwaltungsports von DSL-Routern, um angegriffene Geräte mit Schadsoftware zu infizieren
- Angreiferziel: Missbrauch der Hardware für eigentliche Angriffe (Botnet)
- 15.05.-06.06.2019: Ransomware-Angriff zur Erpressung der Heise Verlagsgruppe
- Infektion eines Rechners im lokalen Netz durch Malware in eMail-Anhang (Trojaner)
- Täuschung des Nutzers: Schadcode mit Administratorrechten ausgeführt (Spezialfall von Malware: _Root Kit_)
- Malwareziel: Verschlüsselungvon Nutzerdaten
- Angreiferziel: Erspressungvon Lösegeld für Entschlüsselung
Was sichere Betriebssysteme erreichen können ... und was nicht: [youtube](https://www.youtube.com/watch?v=opRMrEfAIiI&t=)
Allgemeines Ziel von IT-Sicherheit i.S.v. Security ...
ein Rechnersystem sicher zu machen gegen Schäden durch zielgerichtete Angriffe, insbesondere in Bezug auf die Informationen, die in solchen Systemen gespeichert, verarbeitet und übertragen werden. (Programme sind somit ebenfalls als Informationen zu verstehen.)
Cave! Insbesondere für Sicherheitsziele gilt: Daten $\not=$ Informationen
Sicherheitsziele: sukzessive Konkretisierungen dieser Allgemeinformel hinsichtlich anwendungsspezifischer Anforderungen
Abstrakte Ziele dienen zur Ableitung konkreter Sicherheitsziele. Wir definieren sie als Eigenschaften von gespeicherten oder übertragenen Informationen ...
- Vertraulichkeit: ... nur für einen autorisierten Nutzerkreis zugänglich (i.S.v. interpretierbar) zu sein.
- Integrität: ... vor nicht autorisierter Veränderung geschützt zu sein.
- Verfügbarkeit: ... autorisierten Nutzern in angemessener Frist zugänglich zu sein.
- Authentizität: ... ihren Urheber eindeutig erkennen zu können.
- Verbindlichkeit: ... sowohl integer als auch authentisch zu sein.
##### Schadenspotenzial
1. Vandalismus, Terrorismus
- reine Zerstörungswut
2. Systemmissbrauch
- illegitime Ressourcennutzung, Ziel i.d.R.: hocheffektive Folgeangriffe
- Außerkraftsetzen lebenswichtiger Infrastruktur (z.B. schon Registrierkassen)
- Erpressung von ausgewählten (oder schlicht großen ) Zielgruppen durch vollendete, reversible Sabotage ($\rightarrow$ Verschlüsselung von Endanwenderinformationen)
##### Bedrohungen
1. Eindringlinge (intruders)
- im engeren Sinne menschliche Angreifer ( ,,Hacker'' ), deren Angriff eine technische Schwachstelleausnutzt ( exploit )
2. Schadsoftware (malicious software, malware)
- durch Ausnutzung einer (auch menschlichen) Schwachstelle zur Ausführung gebrachte Programme, die (teil-) automatisierte Angriffe durchführen
Kritischfür korrekten Entwurf, Spezifikation, Implementierung der Betriebssystem-Sicherheitseigenschaften!
Begriffsdefinitionen:
- Sicherheitspolitik (Security Policy): Eine Menge von Regeln, die zum Erreichen eines Sicherheitsziels dienen.
- Sicherheitsmodell (Security Model): Die formale Darstellung einer Sicherheitspolitik zum Zweck
- der Verifikation ihrer Korrektheit
- der Spezifikation ihrer Implementierung.
##### 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
##### Beispiele für BS-Zugriffssteuerungspolitiken
klassifiziert nach Semantik der Politikregeln:
- IBAC (Identity-basedAccess Control): Politik spezifiziert, welcher Nutzer an welchen Ressourcen bestimmte Rechte hat.
- Bsp.: ,,Nutzer Anna darf Brief.docx lesen, aber nicht schreiben.''
- TE (Type-Enforcement): Politik spezifiziert Rechte durch zusätzliche Abstraktion (Typen): welcher Nutzertyp an welchem Ressourcentyp bestimmte Rechte hat.
- Bsp.: ,,Nutzer vom Typ Administrator dürfen Dateien vom Typ Log lesen und schreiben.''
- 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.
- Bsp.: ,,Nutzer der Klasse nicht vertrauenswürdig dürfen Dateien der Klasse vertraulich nicht lesen.''
- 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.
- Bsp.: ,,Der Eigentümer einer Datei bestimmt (bzw. ändert), welcher Nutzer welche Rechte daran hat.''
- MAC (MandatoryAccess Control, auch: obligatorische Zugriffssteuerung ): Keine Beteiligung der Nutzer an der Durchsetzungeiner (zentral administrierten) Sicherheitspolitik.
- Bsp.: ,,Anhand ihres Dateisystempfads bestimmt das Betriebssystem, welcher Nutzer welche Rechte an einer Datei hat.''
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)
- es gibt Subjekte (Nutzer, Prozesse) und Objekte (Dateien, Sockets ...)
- jedes Objekt hat einen Eigentümer
- Eigentümer legen Zugriffsrechte an Objekten fest ($\rightarrow$ DAC)
- es gibt drei Zugriffsrechte: read, write, execute
- 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'')
- Korrektheitskriterium: Garantiert die Politik, dass acm mit $\leq$ jederzeit konsistent ist? ( BLP Security ) [BeLa76]
- elevation-Mechanismus: verändert nach Nutzeranfrage ($\rightarrow$ DAC) sowohl acm als auch $\leq\rightarrow$ konsistenzerhaltend?
- andere BS-Operationen: verändern unmittelbar nur acm (z.B. mittels Dateisystemmanagement) $\rightarrow$ konsistenzerhaltend?
## Autorisierungsmechanismen
Begriffsdefinitionen:
- Sicherheitsmechanismen: Datenstrukturen und Algorithmen, welche die Sicherheitseigenschaften eines Betriebssystems implementieren.
- $\rightarrow$ Sicherheitsmechanismen benötigt man zur Herstellung jeglicher Sicherheitseigenschaften (auch jener, die in unseren Modellen implizit angenommen werden!)
- Auswahl im Folgenden: Autorisierungsmechanismen und -informationen
### Traditionell: ACLs, SUID
Autorisierungsinformationen:
- müssen Subjekte (Nutzer) bzw. Objekte (Dateien, Sockets ...) mit Rechten assoziieren $\rightarrow$ Implementierung der Zugriffsmatrix ( acm ), diese ist:
- groß ($\rightarrow$ Dateianzahl auf Fileserver)
- dünn besetzt
- in Größe und Inhalt dynamisch veränderlich
- $\rightarrow$ effiziente Datenstruktur?
- Lösung: verteilte Implementierung der acm als Spaltenvektoren, deren Inhalt in den Objekt-Metadaten repräsentiert wird: Zugriffssteuerungslisten ( Access Control Lists , ACLs)
bisher: Linux-Sicherheitspolitik formuliert Nutzerrechte an Dateien (verteilt gespeichert in ACLs)
Durchsetzung: basiert auf Prozessrechten
- Annahme: Prozesse laufen mit UID des Nutzers, welcher sie gestartet hat und repräsentieren Nutzerintention und Nutzerberechtigungen i.S.d. Sicherheitspolitik
- technisch bedeutet dies: ein Nutzer beauftragt einen anderen Prozess, sich zu dublizieren( fork() ) und das gewünschte Programm auszuführen ( exec*() )
- Nutzer können im Rahmen der DAC-Politik ACLs manipulieren
- Nutzer können (i.A.) jedoch keine Prozess-UIDs manipulieren
- $\rightarrow$ und genau so sollte es gem. Unix-Sicherheitspolitik auch sein!
Hintergrund:
- 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
- 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)
- dazu muss
- _root_ bzw. zweckgebundener Nutzer Eigentümer des Druckers sein
- ACL als `rw- --- ---` gesetzt sein
Folge:
- Nutzerprozesse könnten z.B. nicht drucken ...
Lösung: Mechanismus zur Rechtedelegation
- implementiert durch ein weiteres ,,Recht'' in ACL: SUID-Bit (,, setUID'' )
- Programmausführung modifiziert Kindprozess, so dass UID des Programmeigentümers (im Bsp.: root ) seine Rechte bestimmt
- Technik: eine von UID abweichende Prozess-Metainformation ($\rightarrow$ PCB) effektive UID (eUID) wird tatsächlich zur Autorisierung genutzt
- Anfang 2000er Jahre: sicherheitsfokussiertes Betriebssystemprojekt für US-amerikanische NSA [LoSm01]
- Implementierung des (eigentlich)μKernel-Architekturkonzepts Flask
- heute: Open Source, Teil des mainline Linux Kernels
- Klassische UNIXoide: Sicherheitspolitik fest im Kernel implementiert
- I-Nodes, PCBs, ACLs, UID, GID, SUID, ...
- Idee SELinux: Sicherheitspolitikals eigene BS-Abstraktion
- zentrale Datenstruktur für Regeln, die erlaubte Zugriffe auf ein SELinux-System definiert
- erlaubt Modifikation und Anpassung an verschiedene Sicherheitsanforderungen $\rightarrow$ NFE Adaptivität ...
##### SELinux-Sicherheitsmechanismen
BS-Komponenten
- Auswertung der Sicherheitspolitik: Security- Server , implementiert als Linux-Kernelmodul(Technik: LSM, Linux Security Module ); $\rightarrow$ entscheidet über alle Zugriffe auf alle Objekte
- Durchsetzung der Sicherheitspolitik : LSM Hooks (generische Anfrage-Schnittstellen in allen BS-Funktionen)
- Administration der Sicherheitspolitik: geschrieben in Textform, muss zur Laufzeit in Security Server installiert werden
##### SELinux-Sicherheitspolitik
Repräsentation der Sicherheitspolitik:
- physisch: in spezieller Datei, die alle Regeln enthält (in maschinenlesbarer Binärdarstellung), die der Kernel durchsetzen muss
- diese Datei wird aus Menge von Quelldateien in einer Spezifikationssprache für SELinux-Sicherheitspolitiken kompiliert
- diese ermöglicht anforderungsspezifische SELinux-Politiken: können (und müssen) sich von einem SELinux-System zum anderen wesentlich unterscheiden
- Politik wird während des Boot-Vorgangs in Kernel geladen
##### Politiksemantik
Regeln einer SELinux-Sicherheitspolitiken, Semantische Konzepte(Auswahl):
- Type Enforcement (TE)
- Typisierung von
- Subjekten: Prozesse
- Objekten der Klassen: Dateien, Sockets, EA-Geräteschnittstellen, ...
- Rechte delegation durch Retypisierung(vgl. Unix-SUID!)
- Ziel: Schutz von sicherheitskritischen Anwendungen durch vollständige, hardwarebasierte Isolation
- $\rightarrow$ strenggenommen kein BS-Mechanismus: Anwendungen müssen dem BS nicht mehr vertrauen! (AR-Schutz, Wechsel von Privilegierungsebenen, ...)
- Annahmen/Voraussetzungen:
1. sämtliche Software nicht vertrauenswürdig (potenziell durch Angreifer kontrolliert)
2. Kommunikation mit dem angegriffenen System nicht vertrauenswürdig (weder vertraulich noch verbindlich)
3. kryptografische Algorithmen (Verschlüsselung und Signierung) sind vertrauenswürdig, also nicht für den Angreifer zu brechen
4. Ziel der Isolation: Vertraulichkeit, Integrität und Authentizität(nicht Verfügbarkeit) von Anwendungen (Code) und den durch sie verarbeiteten Informationen
##### Enclaves
- Idee: geschützter Speicherbereich für Teilmenge der Seiten (Code und Daten) einer Task: Enclave Page Cache (EPC)
- Prozessor (und nur dieser) ver-und entschlüsselt EPC-Seiten
> Any system in which the time at which output is produced is significant. This is usually because the input corresponds to some movement in the physical world, and the output has to relate to that same movement. The lag from input time to output time must be sufficiently small for acceptable timeliness. (The Oxford DictionaryofComputing)
> A real-time system is any information processing activity or system which has to respond to externally generated input stimuli within a finite and specified period. [Young 1982]
> A real-time system is a system that is required to react to stimuli from the environment (including the passage of physical time) within time intervals dictated by the environment. [Randall et.al. 1995]
6. Aerodynamik und Flug Mechanik führt zu Flugzeugbewegung (1.)
Beispiel Überwachungssysteme
- Luftraumüberwachung:
- Ortsfeste Radarstation
- Mobile Radarstation
- Tiefflieger-Erfassungsradar
- Flugplatzradar Netzfunkstellen
- Zentrale
- Umweltüberwachung: Stickstoffdioxidkonzentration über Europa
- Vorgeburtliche Gesundheitsüberwachung: Herzschlagsüberwachungssystem für Mutter und Kind
Beispiel Multimediasystem
- zeitabhängige Datenwiedergabe
- Bildwiedergabe bei Mediendatenströmen
- Durchführung der Schritte durch Multimedia-Task binnen $t_{i+1} - t_i$
- Frist für Rendering in Multimedia-Tasks: festgelegt durch periodische Bildrate (24~48 fps $\rightarrow$ 1/24 ... 1/48 s)
- $\rightarrow$ Berücksichtigung bei Scheduling, Interruptbehandlung, Speicherverwaltung, ... erforderlich!
Zwischenfazit [Buttazzo97]
- Murphy‘s General Law: If something can go wrong, it will got wrong.
- Murphy‘s Constant: Damage to an object is proportional to its value.
- Johnson‘s First Law: If a system stops working, it will do it at the worst possible time.
- Sodd‘sSecond Law: Sooner or later, the worst possible combination of circumstances will happen.
Realisierung von Echtzeiteigenschaften: komplex und fragil!
## Terminologie
bevor wir uns über Echtzeit-Betriebssystemen unterhalten:
1. Wie ist die Eigenschaft Echtzeit definiert?
2. Was sind (rechnerbasierte) Echtzeitsysteme?
3. Wie können Echtzeitanwendungen beschrieben werden?
4. Welche grundsätzlichen Typen von Echtzeitprozessen gibt es/wodurch werden diese charakterisiert?
Antwortzeit:
- 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.
Frist
- Bei Echtzeitsystemen ist genau dieses $\Delta t$ kritisch, d.h. je nach Art des Systems darf dieses auf keinen Fall zu groß werden.
- 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.
Echtzeitfähigkeit und Korrektheit
- 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.
- Die Frist trennt also korrektes von inkorrektem Verhalten des Systems.
- WennalleSpezifikationeneingehaltenwerden-muss Betriebssystem garantieren, dass
1. zeitgesteuerte periodische Prozesse: mit ihrer spezifizierten Rate aktiviert werden und ihre Frist einhalten können
2. ereignisgesteuerte periodische Prozesse: ihre Frist einhalten können
### Aperiodische Prozesse
- typisch für
- unregelmäßig auftretende Ereignisse, z.B.:
- Überfahren der Spurgrenzen, Unterschreiten des Sicherheitsabstands $\rightarrow$ Reaktion des Fahrassistenzsystems
- Nutzereingaben in Multimediasystemen ($\rightarrow$ Spielkonsole)
- Prozessaktivierung
- ereignisgesteuert
- Fristen
- oft weich(aber anwendungsabhängig)
- Aufgabendes Betriebssystems
- bei Einhaltung der Prozessspezifikationen muss Betriebssystem auch hier für Einhaltung der Fristen sorgen
- Modellierung
- bestehen ebenfalls aus (maximal unendlicher) Folge identischer Aktivierungen (Instanzen); aber: Aktivierungszeitpunkte nicht regelmäßig (möglich: nur genau eine Aktivierung)
- 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$)
- außerdem:
- criticality: Parameter zur Beschreibung der Konsequenzen einer Fristüberschreitung (typischerweise ,,hart'' oder ,,weich'')
- $V_i$ ...Wert (value): Parameter zum Ausdruck der relativen Wichtigkeit eines Prozesses bezogen auf andere Prozesse der gleichen Anwendung
## Echtzeitfähige Betriebssysteme
- Hauptfragestellungen
1. Was muss BS zu tun, um Echtzeitprozesse zu ermöglichen? Welche Teilprobleme müssen beachtet werden?
2. Welche Mechanismen müssen hierfür anders als bei nicht-echtzeitfähigen Betriebssystemen implementiert werden, und wie?
- Grundlegender Gedanke
- Abgeleitet aus den Aufgaben eines Betriebssystems sind folgende Fragestellungenvon Interesse:
1. Wie müssen die Ressourcen verwaltet werden? ($\rightarrow$ CPU, Speicher, E/A, ...)
2. Sind neue Abstraktionen, Paradigmen (Herangehensweisen) und entsprechende Komponenten erforderlich (oder günstig)?
4. im Zusammenhang damit: Prioritätsumkehr, Überlast
- Ressourcen-Management
- Wie müssen Ressourcen verwaltet werden, damit Fristen eingehalten werden können?
Wir betrachten i.F.
1. Algorithmen, die Rechnersysteme echtzeitfähig machen -einschließlich des Betriebssystems:
- grundlegende Algorithmen zum Echtzeitscheduling
- Besonderheiten der Interruptbehandlung
- Besonderheiten der Speicherverwaltung
2. Probleme, die behandelt werden müssen, um Echtzeitfähigkeit nicht zu be- oder verhindern:
- Prioritätsumkehr
- Überlast
- Kommunikation-und Synchronisationsprobleme
### Echtzeitscheduling
- Scheduling:
- Schedulingvon Prozessen/Threads als wichtigster Einflussfaktor auf Zeitverhalten des Gesamtsystems
- Echtzeit-Scheduling:
- benötigt: Scheduling-Algorithmen, die Scheduling unter Berücksichtigung der ( unterschiedlichen ) Fristen der Prozesse durchführen können
- Fundamentale Algorithmen:
- wichtigste Strategien:
1. Ratenmonotones Scheduling (RM)
2. Earliest Deadline First (EDF)
- beide schon 1973 von Liu & Layland ausführlich diskutiert [Liu&Layland73]
Annahmen der Scheduling-Strategien
- 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.
- A2: Alle Instanzen eines periodischen Prozesses $t_i$ haben den gleichen Worst-Case-Rechenzeitbedarf $C_i$.
- A3: Alle Instanzen eines periodischen Prozesses $t_i$ haben die gleiche relative Frist $D_i$, welche gleich der Periodendauer $T_i$ ist.
- A4: Alle Prozessesind kausal unabhängig voneinander (d.h. keine Vorrang- und Betriebsmittel-Restriktionen)
- A5: Kein Prozess kann sich selbst suspendieren, z.B. bei E/A-Operationen.
- A6: Alle Prozesse werden mit ihrer Aktivierung sofort rechenbereit ( release time = arrival time ).
- A7: Jeglicher Betriebssystem-Overhead (Kontextwechsel, Scheduler-Rechenzeit) wird vernachlässigt.
A5-7 sind weitere Annahmen des Scheduling Modells
Ratenmonotones Scheduling (RM)
- Voraussetzung:
- periodisches Bereitwerden der Prozesse/Threads, d.h. periodische Prozesse bzw. Threads
- Strategie RM:
- Prozess (Thread) mit höchster Ankunftsrate bekommt höchste statische Priorität (Kriterium: Wie oft pro Zeiteinheit wird Prozess bereit?)
- Scheduling-Zeitpunkt: nur einmal zu Beginn (bzw. wenn neuer periodischer Prozess auftritt)
- präemptiver Algorithmus
- 
- Zuteilung eines Prozessors nach RM
- $t_1, t_2$: Anforderungen von Prozessorzeit durch zwei periodische Prozesse
- darunter: Prozessorzuteilung nach RM
- Optimalität von RM
- 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]
- Prozessor-Auslastungsfaktor
- Bei gegebener Menge von n periodischen Prozessen gilt: $U=\sum_{i=1}^n \frac{C_i}{T_i}$
- mit $\frac{C_i}{T_i}$ Anteil an Prozessorzeit für jeden periodischen Prozess $t_i$
- und $U$ Summe der Prozessorzeit zur Ausführung der gesamten Prozessmenge (,,utilization factor'')
- Prozessorlast
- $U$ ist folglich Maß für die durch Prozessmenge verursachte Last am Prozessor $\rightarrow$ Auslastungsfaktor
- Planbarkeitsanalyse einer Prozessmenge
- im allgemeinen Fall kann RM einen Prozessor nicht zu 100% auslasten
- von besonderem Interesse: kleinste obere Grenze des Auslastungsfaktors $U_{lub}$ (lub: ,,least upper bound'')
- Obere Grenze des Prozessor-Auslastungsfaktors für zwei periodische Prozesse als Funktion des Verhältnisses ihrer Perioden.
- (Abb. nach [Buttazzo97] Bild 4.7, S. 90)
- Obere Auslastungsgrenze bei RM
- nach [Buttazzo97] (S. 89-91) erhält man bei n Prozessen für RM: $U_{lub}=n(2^{\frac{1}{n}}-1)$
- für $n\rightarrow\infty$ konvergiert $U_{lub}$ zu $ln\ 2 \approx 0,6931...$
- Wird genannter Wert nicht überschritten, sind beliebige Prozessmengen planbar.
- (Herleitung siehe [Buttazzo97] , Kap. 4.3.3)
### Earliest Deadline First (EDF)
- Voraussetzung:
- kann sowohl periodische als auch aperiodische Prozesse planen
- Optimalität:
- EDF in Klasse der Schedulingverfahren mit dynamischen Prioritäten: optimaler Algorithmus [Liu&Layland73]
- Strategie EDF:
- Zu jedem Zeitpunkt erhält Prozess mit frühester Frist höchste dynamische Priorität
- Scheduling-Zeitpunkt: Bereitwerden eines (beliebigen) Prozesses
- präemptiver Algorithmus (keine Verdrängung bei gleichen Prioritäten)
- Beispiel
- 
- Zuteilung eines Prozessors nach EDF
- $t_1, t_2$: Anforderungen nach Prozessorzeit durch zwei periodische Prozesse
- darunter: Prozessorzuteilung nach EDF
- Planbarkeitsanalyse:
- Mit den Regeln $A1 ... A7$ ergibt sich für die obere Schranke des Prozessorauslastungsfaktors: $U_{lub}= 1\rightarrow$ Auslastung bis 100% möglich!
- Eine Menge periodischer Prozesse ist demnach mit EDF planbar genau dann wenn: $U=\sum_{i=1}^n \frac{C_i}{T_i}\leq 1$ (Prozessor natürlich nicht mehr als 100% auslastbar)
- Beweis: Obere Auslastungsgrenze bei EDF
- Behauptung: Jede Menge von n periodischen Tasks ist mit EDF planbar $\Leftrightarrow$: $U=\sum_{i=1}^n \frac{C_i}{T_i}\leq 1$
- $\Leftarrow$: $U>1$ übersteigt die verfügbare Prozessorzeit; folglich kann niemals eine Prozessmenge mit dieser (oder höherer) Gesamtauslastung planbar sein.
- $\Rightarrow$: Beweis durch Widerspruch. Annahme: $U\leq 1$ und die Prozessmenge ist nicht planbar. Dies führt zu einem Schedule mit Fristverletzung zu einem Zeitpunkt $t_2$, z.B.:
- $exists$ ein längstes, kontinuierliches Rechenintervall $[t_1,t_2]$, in welchem nur Prozessinstanzen mit Fristen $\leq t_2$ rechnen
- die Gesamtrechenzeit $C_{bad}$ aller Prozesse in $[t_1,t_2]$ muss die verfügbare Prozessorzeit übersteigen: $C_{bad} > t_2-t_1$ (sonst: keine Fristverletzung an $t_2$)
- Anwesenheit in $[t_1,t_2]$ leitet sich davon ab, ob (genauer: wie oft) die Periode eines Prozesses in $t_2-t_1$ passt: $t_i$ in $[t_1,t_2]\Leftrightarrow\lfloor\frac{t_2-t_1}{T_i}\rfloor >0$
- Damit ist $C_{bad}$ die Summe der Rechenzeiten aller Prozessinstanzen, die garantiert in $[t_1,t_2]$ sind, mithin: $C_{bad}=\sum_{i=1}^n \lfloor\frac{t_2-t_1}{T_i}\rfloor C_i$
- Im Beispiel: $t_1... t_3$ in $[t_1,t_2]$, folglich: $C_{bad}= 2 C_1 + 1 C_2 + 1 C_3$
- Zu zeigen: Beobachtung $C_{bad}> t_2-t_1$ widerspricht Annahme $U\leq 1$.
- Es gilt $\sum_{i=1}^n \lfloor\frac{t_2-t_1}{T_i}\rfloor C_i\leq\sum_{i=1}^n\frac{t_2-t_1}{T_i}C_i$ wegen Abrundung.
- Mit $U=\sum_{i=1}^n\frac{C_i}{T_i}$ folgt daraus $C_{bad}\leq(t_2-t_1)U$
- $C_{bad}>t_2-t_1$ entspricht also $(t_2-t_1)U>t_2-t_1$ und somit $U>1$. Widerspruch zur Annahme!
### Vergleich: EDF vs. RM
Zuteilung eines Prozessors nach EDF (dynamisch) bzw. RM (statisch) $t_1,t_2$: Anforderungen nach Prozessorzeit durch zwei periodische Prozesse darunter: Prozessorzuteilung nach EDF bzw. RM
- gut erkennbar: deutliche Unterschiede bei Scheduling mit statischem (RM) vs. dynamischem Algorithmus (EDF).
Vergleich: Anzahl Prozesswechsel
- Häufigkeit von Prozesswechseln im Beispiel:
- RM: 16
- EDF: 12
- 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
Vergleich: 100% Prozessorauslastung
- EDF: erzeugt auch bei Prozessorauslastung bis 100% (immer) korrekte Schedules
- RM: kann das im allgemeinen Fall nicht
- 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.
Vergleich: Implementierung
- RM
- statisch: jeweils eine Warteschlange pro Priorität:
- interaktive Prozesse : keine Fristen , aber: keine zu langen Antwortzeiten Ansatz (z.B.): maximal tolerierbare Verzögerung
- Hintergrund-Prozesse : zeitunkritisch, keine Fristen, aber : dürfen nicht verhungern
Multimediaanwendungen sind ein typisches Beispiel für mögliche Abweichungen der Lastpezifikation $(T_i,C_i)$ eines Echtzeitprozesses!
Problem: Abweichungen von Lastspezifikation
- gibt Prozessor nicht frei
- verspätete periodische Prozesse
### RC Algorithmus
- Ziel
- spezifikationstreue Prozesse nicht bestrafen durch Fristüberschreitung aufgrund abweichender Prozesse
- Idee
- grundsätzlich: Schedulingnach frühester Fristaufsteigend (= EDF) $\rightarrow$ für eine vollständig spezifikationstreue Prozessmenge verhält sich RC wie reines EDF
- 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}$
- Bsp.: $U_i =\frac{20}{40}=\frac{1}{2}$ ($t_B$ hat spezifizierte Aktivitätsrate von $0,5$ pro Periode)
#### RC Algorithmus: Strategie
- Variablen
- $a_i$: Ankunftszeit der zuletzt bereitgewordenen Instanz von $t_i$
- $t_i^{virt}$: virtuelle Zeit in aktueller Periode, die $t_i$ bereits verbraucht hat
- $c_i^{virt}$: Netto-Rechenzeit, die $t_i$ in aktueller Periode bereits verbraucht hat
- $d_i$: dynamische Frist von $t_i$, nach der sich dessen Priorität berechnet (EDF)
- Strategie
- für eine bereite (lauffähige) Instanz von $t_i$: adaptiere dynamisch $d_i$ basierend auf $t_i^{virt}$
- 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
preempt(rnd_member( SCHED )); // sonst: irgendein Prozess mit nächster Frist verdrängt den laufenden
```
#### Umgang mit abweichenden Prozessen unter RC
#### Resultat
> Garantie: Prozesse, die sich entsprechend ihrer Spezifikation verhalten, erhalten bis zum Ende jeder spezifizierten Periode ihren spezifizierten Anteil an Prozessorzeit.
Auswirkung auf verschiedene Prozesstypen:
- ,,pünktliche'' Prozesse: Einhaltung der Frist in jeder Periode garantiert (unabhängig von Verhalten anderer Prozesse)
- ,,verspätete'' Prozesse: nur aktuelle Periode betrachtet, Nachholen ,,ausgelassener Perioden'' nicht möglich
- nicht-periodische Hintergrundprozesse: pro ,,Periode'' wird spezifizierte Prozessorrate garantiert (z.B. kleine Raten bei großen ,,Periodendauern'' wählen.)
### Umgang mit gemischten Prozessmengen
- Hintergrund-Scheduling:
- Prinzip: 
- rechenbereite Prozesse auf 2 Warteschlangen aufgeteilt (einfache Variante eines Mehr-Ebenen-Scheduling )
- Warteschlange 1:
- alle periodischen Prozesse
- mit höchster Priorität mittels RM oder EDF bedient
- Warteschlange 2:
- alle aperiodischen Prozesse
- nur bedient, wenn keine wartenden Prozesse in Warteschlange 1
#### Hintergrund-Scheduling: Vor- und Nachteile
- Hauptvorteil:
- einfache Implementierung
- Nachteile:
- Antwortzeit **aperiodischer Prozesse** kann zu lang werden (insbesondere bei hoher aperiodischer Last) $\rightarrow$ Verhungern möglich!
- geeignet nur für relativ zeitunkritische aperiodische Prozesse
- Beispiel: Hintergrund-Scheduling mit RM
- 
#### Optimierung: Server-Prozess
- Scheduling mit Server-Prozessen:
- Prinzip: periodisch aktivierter Prozess benutzt zur Ausführung aperiodischer Prozessoranforderungen
- Beschreibung Server-Prozess: durch Parameter äquivalent zu wirklichem periodischen Prozess:
- geplant mit gleichem Scheduling-Algorithmus wie periodische Prozesse
- zum Aktivierungszeitpunkt vorliegende aperiodische Anforderungen bedient bis zur Kapazität des Servers
- keine aperiodischen Anforderungen: Server suspendiert sich bis Beginn der nächsten Periode (Schedule wird ohne ihn weitergeführt $\rightarrow$ Prozessorzeit für periodische Prozesse)
- Kapazitätin jeder Server-Periode neu ''aufgeladen''
#### Beispiel: Server-Prozess mit RM
> Mechanismen zur Synchronisation und Koordination sind häufige Ursachen für kausale Abhängigkeiten zwischen Prozessen!
#### Problem
- Prinzip _kritischer Abschnitt_ (Grundlagen BS):
- Sperrmechanismen stellen wechselseitigen Ausschluss bei der Benutzung exklusiver Betriebsmittel durch nebenläufige Prozesse sicher
- Benutzung von exklusiven sowie nichtentziehbaren Betriebsmitteln: kritischer Abschnitt
- 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)
- Konflikt: kritische Abschnitte vs. Echtzeit-Prioritäten
- 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
- (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
#### Ursache der Prioritätsumkehr
- 
- Prioritätsumkehr bei Blockierung an nichtentziehbarem, exklusivem Betriebsmittel
- $\rightarrow$ unvermeidlich
#### Folgen der Prioritätsumkehr
- Kritisch bei zusätzlichen Prozessen mittlerer Priorität
- 
- Lösung: Priority Inheritance Protocol (PIP)
#### Lösung: Prioritätsvererbung
- ![Abb. nach [Buttazzo97] , Bild 7.6, S.188]
- ePrio ... effektive Priorität
### Überlast
- Definition: kritische Situation - bei der die benötigte Menge an Prozessorzeit die Kapazität des vorhandenen Prozessors übersteigt $(U>1)$
- Folge: nicht alle Prozesse können Fristen einhalten
- Hauptrisiko: kritische Prozesse können Fristen nicht einhalten $\rightarrow$ Gefährdung funktionaler und anderer nichtfkt. Eigenschaften ($\rightarrow$ harte Fristen!)
- Minimallösung: (lebenswichtig für Echtzeit-System)
- Unterscheidung zwischen Zeitbeschränkungen (Fristen) und tatsächlicher Wichtigkeit eines Prozesses für System
- Allgemein gilt:
- Wichtigkeit eines Prozesses ist unabhängig von seiner Periodendauer und irgendwelchen Fristen
- z.B. kann ein Prozess trotz späterer Frist viel wichtiger als anderer mit früherer Frist sein.
- Beispiel: Bei chemischem Prozess könnte Temperaturauswertung jede 10s wichtiger sein als Aktualisierung graphischer Darstellung an Nutzerkonsole jeweils nach 5s
#### Umgang mit Überlast: alltägliche Analogien
1. Weglassen weniger wichtiger Aktionen
- ohne Frühstück aus dem Haus...
- kein Zähneputzen ...
- Wichtung vom Problem bzw. Aktivitätsträgern (hier: Personen) abhängig!
2. Verkürzen von Aktivitäten
- Katzenwäsche...
3. Kombinieren
- kein Frühstück + Katzenwäsche + ungekämmt
#### Wichtung von Prozessen
Behandlung:
- zusätzlicher Parameter V (Wert) für jeden Prozess/Thread einer Anwendung
- spezifiziert relative Wichtigkeit eines Prozesses (od. Thread) im Verhältnis zu anderen Prozessen (Threads) der gleichen Anwendung
- bei Scheduling: V stellt zusätzliche Randbedingung (primär: Priorität aufgrund von Frist, sekundär: Wichtigkeit)
#### Obligatorischer und optionaler Prozessanteil
- Aufteilung der Gesamtberechnung $(C_{ges})$ eines Prozesses in zwei Phasen
- einfache Möglichkeit der Nutzung des Konzepts des anpassbaren Prozessorzeitbedarfs
- Prinzip:
- Bearbeitungszeitbedarf eines Prozesses zerlegt in
1. obligatorischer Teil (Pflichtteil, $C_{ob}$): muss unbedingt u. immer ausgeführt werden $\rightarrow$ liefert bedingt akzeptables Ergebnis
2. optionaler Teil $(C_{opt})$: nur bei ausreichender Prozessorkapazität ausgeführt $\rightarrow$ verbessert durch obligatorischen Teil erzieltes Ergebnis
- wie bei Interrupt-Bearbeitung und Prioritätsumkehr: unkontrollierbare Verzögerungen der Prozessbearbeitung (= zeitlicher Nichtdeterminismus) vermeiden!
- Ressourcenzuordnung, deswegen:
1. keine Ressourcen-Zuordnung ,,on-demand'' (d.h. in dem Moment, wo sie benötigt werden) sondern ,,Pre-Allokation'' (= Vorab-Zuordnung)
2. keine dynamische Ressourcenzuordnung (z.B. Hauptspeicher), sondern Zuordnung maximal benötigter Menge bei Pre-Allokation ($\rightarrow$ BS mit ausschließlich statischer Hauptspeicherallokation: TinyOS)
#### Hauptspeicherverwaltung
- bei Anwendung existierender Paging-Systeme
- durch unkontrolliertes Ein-/Auslagern ,,zeitkritischer'' Seiten (-inhalte): unkontrollierbare Zeitverzögerungen möglich!
- Technik hier: ,,Festnageln'' von Seiten im Speicher (Pinning, Memory Locking)
- für Zugriffsreihenfolge auf Datenblöcke: lediglich deren Fristen maßgebend (weitere Regeln existieren nicht!)
- Resultat bei HDDs:
- ineffiziente Bewegungen der Lese-/Schreibköpfe -ähnlich FCFS
- nichtdeterministische Positionierzeiten
- geringer Durchsatz
- Fazit:
- Echtzeit-Festplattenscheduling $\rightarrow$ Kompromiss zwischen Zeitbeschränkungen und Effizienz
- bekannte Lösungen:
1. Modifikation von EDF
2. Kombination von EDF mit anderen Zugriffsstrategien
$\rightarrow$ realisierte Strategien:
1. SCAN-EDF (SCAN: Kopfbewegung nur in eine Richtung bis Mitte-/Randzylinder; EDF über alle angefragten Blöcke _in dieser Richtung_ )
2. Group Sweeping_ (SCAN mit nach Fristen gruppenweiser Bedienung)
3. Mischstrategien
- Vereinfachung:
- o.g. Algorithmen i.d.R. zylinderorientiert $\rightarrow$ berücksichtigen bei Optimierung nur Positionierzeiten (Grund: Positionierzeit meist ≫Latenzzeit)
- 
- MRW: Most-Recently-Written; Zeiger auf jüngstes, durch Sender vollständig geschriebenes Element
- LRW: Least-Recently-Written; Zeiger auf ältestes durch Sender geschriebenes Element
- Garantien:
- sowohl _MRW_ als auch _LRW_ können ausschließlich durch Sender manipuliert werden $\rightarrow$ keine inkonsistenten Zeiger durch konkurrierende Schreibzugriffe!
- sowohl _MRW_ als auch _LRW_ zeigen niemals auf ein Element, das gerade geschrieben wird $\rightarrow$ keine inkonsistenten Inhalte durch konkurrierende Schreib-/Lesezugriffe!
- Regeln für Sender:
- muss **nach** jedem Schreiben _MRW_ auf geschriebenes Element setzen
- muss **bevor**_LRW_ geschrieben wird _LRW_ inkrementieren
- Regel für Empfänger: muss immer nach Lesen von _MRW_ als nächstes _LRW_ anstelle des Listennachbarn lesen
- Schreiben in Puffer grundsätzlich in Reihenfolge der Elemente $\rightarrow$ keine blockierenden Puffergrenzen $\rightarrow$ niemals Blockierung des Senders
- keine Vollständigkeitsgarantien:Empfänger kann nicht sicher sein, eine temporal stetige Sequenz zu lesen
- $\rightarrow$ Szenarien, in denen Empfänger sowieso nur an aktuellsten Daten interessiert (z.B. Sensorwerte)
- ,,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)
- für uns: entspricht Erweiterbarkeit
- Adaptivität: (unsere Arbeitsdefinition)
- Die Fähigkeit eines Systems, sich an ein breites Spektrum verschiedener Anforderungen anpassen zu lassen.
- = ... so gebaut zu sein, dass ein breites Spektrum verschiedener nicht funktionaler Eigenschaften unterstützt wird.
- letztere: komplementär zur allgemeinen NFE Adaptivität
## Roadmap
- in diesem Kapitel: gleichzeitig Mechanismen und Architekturkonzepte
- Adaptivität jeweils anhand komplementärer Eigenschaften dargestellt:
- **Interprozesskommunikation:** gleiche Mechanismen für alle Anwendungsprozesse
- Problem:
- Implementierungsspielraumfür Anwendungen wird begrenzt:
1. Vorteile domänenspezifischer Optimierungender Hardwarebenutzung können nicht ausgeschöpft werden $\rightarrow$ **Performanz, Sparsamkeit**
2. die Implementierung existierender Abstraktionen kann bei veränderten Anforderungen nicht an Anwendungen angepasst werden $\rightarrow$ **Wartbarkeit**
3. Hardwarespezifikationen, insbesondere des Zeitverhaltens (E/A, Netzwerk etc.), werden von Effekten des BS-Management überlagert $\rightarrow$ **Echtzeitfähigkeit**
- ,,low-level'' = so hardwarenah wie möglich, bspw. die logische Schnittstelle eines elektronischen Schaltkreises/ICs ($\rightarrow$ Gerätetreiber $\subseteq$ Library-BS!)
- 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, ...
- Library-Betriebssysteme: implementieren darauf jeweils geeignete anwendungsnahe Abstraktionen
- Bsp.: Adressraumsemantik, Seitentabellenlayout und -verwaltung, Paging-und Locking-Verfahren, ...
- Anwendungsprogrammierer: wählen geeignete Library-Betriebssysteme bzw. schreiben ihre eigenen Exokernelmechanismen
- prinzipielle Exokernelmechanismen am Beispiel Aegis/ExOS [Engler+95]
- Der Exokernel...
- _implementiert:_ Multiplexing der Hardware-Ressourcen
- _exportiert:_ geschützte Hardware-Ressourcen
- minimal: drei Arten von Mechanismen
1. Secure Binding: erlaubt geschützte Verwendung von Hardware-Ressourcen durch Anwendungen, Behandlung von Ereignissen
2. Visible ResourceRevocation: beteiligt Anwendungen am Entzug von Ressourcen mittels (kooperativen) Ressourcen-Entzugsprotokolls
3. Abort-Protokoll: erlaubt ExokernelBeendigung von Ressourcenzuordnungen bei unkooperativen Applikationen
### Secure Binding
- Schutzmechanismus, der Autorisierung ($\rightarrow$ Library-BS)zur Benutzung einer Ressource von tatsächlicher Benutzung ($\rightarrow$ Exokernel) trennt
- implementiert für den Exokernelerforderliches Zuordnungswissenvon (HW-)Ressource zu Mangement-Code (der im Library-BS implementiert ist)
- $\rightarrow$ ''Binding'' in Aegis implementiert als Unix-Hardlinkauf Metadatenstruktur zu einem Gerät im Kernelspeicher ( ,,remember: everythingisa file...'' )
- Zur Implementierung benötigt:
- Hardware-Unterstützung zur effizienten Rechteprüfung (insbes. HW-Caching)
- Software-Caching von Autorisierungsentscheidungen im Kernel (bei Nutzung durch verschiedene Library-BS)
- Downloadingvon Applikationscode in Kernel zur effizienten Durchsetzung (quasi: User-Space-Implementierung von Systemaufrufcode)
- einfach ausgedrückt: ,,Secure Binding'' erlaubt einem ExokernelSchutz von Ressourcen, ohne deren Semantik verstehen zu müssen.
- Vorteil: im allgemeinen geringere Latenzzeiten, einfacheres und komfortableres Programmiermodell
- Nachteil: Anwendungen(hier: die eingebetteten Library-BS) erhalten keine Kenntnis über Entzug,bspw. aufgrund von Ressourcenknappheit etc.
- $\rightarrow$ erforderliches Wissen für Management-Strategien!
- Exokernel-Betriebssysteme: entziehen(überwiegend) Ressourcen ,,sichtbar''$\rightarrow$ Dialog zwischen Exokernel und Library-BS
- Vorteil: effizientes Management durch Library-BS möglich (z.B. Prozessor: nur tatsächlich benötigte Register werden bei Entzug gespeichert)
- Nachteil : Performanz bei sehr häufigem Entzug, Verwaltungs-und Fehlerbehandlungsstrategien zwischen verschiedenen Library-BS müssen korrekt und untereinander kompatibelsein...
- $\rightarrow$ Abort - Protokoll notwendig, falls dies nicht gegeben ist
### Abort - Protokoll
- Ressourcenentzug bei unkooperativen Library-Betriebssystemen ( Konflikt mit Anforderung durch andere Anwendung/deren Library-BS: Verweigerung der Rückgabe, zu späte Rückgabe, ...)
- notwendig aufgrund von Visible Ressource Revocation
- Dialog:
- Exokernel: ,,Bitte Seitenrahmen x freigeben.''
- Library-BS: ,,...''
- Exokernel: ,,Seitenrahmen x innerhalb von 50 μs freigeben!''
- Library-BS: ,,...''
- Exokernel: (führt Abort-Protokoll aus)
- Library-BS: X (,,Abort'' in diesem Bsp. = Anwendungsprozess terminieren)
- In der Praxis:
- harte Echtzeit-Fristen (,, innerhalb von 50 μs'' ) in den wenigsten Anwendungen berücksichtigt
- $\rightarrow$ Abort = lediglich Widerruf aller Secure Bindings der jeweiligen Ressource für die unkooperativeAnwendung, nicht deren Terminierung (= unsichtbarerRessourcenentzug)
- $\rightarrow$ anschließend: Informieren des entsprechenden Library-BS
- ermöglicht sinnvolle Reaktion des Library-BS (in Library-BS wird ,,Repossession''-Exceptionausgelöst, so dass auf Entzug geeignet reagiert werden kann)
- bei zustandsbehafteten Ressourcen ($\rightarrow$ CPU): Exokernelkann diesen Zustand auf Hintergrundspeicher sichern $\rightarrow$ Management-Informationen zum Aufräumen durch Library-BS
### Exokernelperformanz
- Was macht Exokern-Architekturen adaptiv(er)?
- Abstraktionen und Mechanismen des Betriebssystems können den Erfordernissen der Anwendungen angepasst werden
- Grundlage: begrenzte Anzahl einfacher Systemaufrufe (Größenordnung ~10) und Kernel-interne Primitiven (,,Pseudo-Maschinenanweisungen''), die enthalten sein müssen
2. machbar: sicheres Hardware-Multiplexing auf niedriger Abstraktionsebene (,,low-level'') mit geringem Overhead
3. traditionelle Abstraktionen (VMM, IPC) auf Anwendungsebene effizient implementierbar $\rightarrow$ einfache Erweiterbarkeit, Spezialisierbarkeitbzw. Ersetzbarkeit dieser Abstraktionen
4. für Anwendungen: hochspezialisierte Implementierungen von Abstraktionen generierbar, die genau auf Funktionalität und Performanz-Anforderungen dieser Anwendung zugeschnitten
5. geschützte Kontrollflussübergabe: als IPC-Primitive im Aegis-Kernel, 7-mal schnellerals damals beste Implementierung (vgl. [Liedtke95], Kap. 3)
6. Ausnahmebehandlung bei Aegis: 5-mal schneller als bei damals bester Implementierung
7. durch Aegis möglich: Flexibilität von ExOS, die mit Mikrokernel-Systemen nicht erreichbar ist:
- Bsp. VMM: auf Anwendungsebene implementiert, wo diese sehr einfach mit DSM-Systemen u. Garbage-Kollektoren verknüpfbar
8. Aegis erlaubt Anwendungen Konstruktion effizienter IPC-Primitiven (∆ μKernel: nicht vertrauenswürdige Anwendungen könnenkeinerlei spezialisierte IPC-Primitiven nutzen, geschweige denn selbst implementieren)
Xok/ExOS
- praktische Weiterentwicklung von Aegis: Xok
- für x86-Hardware implementiert
- Kernel-Aufgaben (wie gehabt): Multiplexing von Festplatte, Speicher, Netzwerkschnittstellen, ...
- keine Isolation von Anwendungen ($\rightarrow$ Parallelisierbarkeit: teuer und mit schwachen Garantien; $\rightarrow$ Robustheit und Sicherheit der Anwendungen: nicht umsetzbar)
## Virtualisierung
- Ziele (zur Erinnerung):
- Adaptivität
- Wartbarkeit, Sicherheit, Robustheit
- $\rightarrow$ auf gleicher Hardware mehrere unterschiedliche Betriebssysteme ausführbar machen
- 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
- Wartbarkeit:
- Anwendungen - die sonst nicht gemeinsam auf gleicher Maschine lauffähig - auf einer phyischenMaschine ausführbar
- ökonomische Vorteile: Cloud-Computing, Wartbarkeit von Legacy-Anwendungen
- Sicherheit:
- Isolation von Anwendungs-und Kernelcode durch getrennte Adressräume (wie z.B. bei Mikrokern-Architekturen)
- somit möglich:
1. Einschränkung der Fehlerausbreitung $\rightarrow$ angreifbare Schwachstellen
2. Überwachung der Kommunikation zwischen Teilsystemen
- darüber hinaus: Sandboxing (vollständig von logischer Ablaufumgebung isolierte Software, typischerweise Anwendungen $\rightarrow$ siehe z.B. Cloud-Computing)
- Robustheit:
- siehe Sicherheit!
Architekturvarianten - drei unterschiedliche Prinzipien:
- Kategorien traditioneller funktionaler Eigenschaften von BS:
1. Multiplexing & Schutz der Hardware (ermöglicht Multiprozess-Betrieb)
2. abstrahierte Maschine** mit ,,angenehmerer'' Schnittstelle als die reine Hardware (z.B. Dateien, Sockets, Prozesse, ...)
- Typ- 1 - Hypervisor trennt beide Kategorien:
- läuft wie ein Betriebssystem unmittelbar über der Hardware
- bewirkt Multiplexing der Hardware, liefert aber keine erweiterte Maschine** an Anwendungsschicht $\rightarrow$ ,,Multi-Betriebssystem-Betrieb''
- 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.).
- Ursprünge: Time-Sharing an Großrechnern
- Standard-BS auf IBM-Großrechner System/360: OS/360
- Nutzer (insbes. Entwickler) strebten interaktive Arbeitsweise an eigenem Terminal an $\rightarrow$ timesharing (MIT, 1962: CTSS)
- IBM zog nach: CP/CMS, später VM/370 $\rightarrow$ z/VM
- CP: Control Program $\rightarrow$ Typ- 1 - Hypervisor
- CMS: ConversationalMonitor System $\rightarrow$ Gast-BS
- CP lief auf ,,blanker'' Hardware (Begriff geprägt: ,,bare metal hypervisor'' )
- lieferte Menge virtueller Kopiender System/360-Hardware an eigentliches Timesharing-System
- je eines solche Kopie pro Nutzer $\rightarrow$ unterschiedliche BS lauffähig (da jede virtuelle Maschine exakte Kopie der Hardware)
- in der Praxis: sehr leichtgewichtiges, schnelles Einzelnutzer-BS als Gast $\rightarrow$ CMS (heute wäre das wenig mehr als ein Terminal-Emulator...)
- heute: Forderungen nach Virtualisierung von Betriebssystemen
- seit 1980er: universeller Einsatz des PC für Einzelplatz- und Serveranwendungen $\rightarrow$ veränderte Anforderungen an Virtualisierung
- Wartbarkeit: vor allem ökonomische Gründe:
1. Anwendungsentwicklung und -bereitstellung: verschiedene Anwendungen in Unternehmen, bisher auf verschiedenen Rechnern mit mehreren (oft verschiedenen) BS, auf einem Rechner entwickeln und betreiben (Lizenzkosten!)
- Ziel: Nutzung von Virtualisierung auf PC-Hardware
- systematische Untersuchung der Virtualisierbarkeit von Prozessoren bereits 1974 durch Popek & Goldberg [Popek&Goldberg74]
- Ergebnis:
- 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
- dies geht nur, wenn tatsächlich der HV diese Instruktionen ausführt!
- dies geht nur, wenn CPU bei jeder solchen Instruktion im Nutzermodus Kontextwechsel zum HV ausführen, welcher Instruktion emuliert!
- virtualisierbare Prozessoren bis ca. 2006:
- ✓ IBM-Architekturen(bekannt: PowerPC, bis 2006 Apple-Standard)
- ✗ Intel x86-Architekturen (386, Pentium, teilweise Core i)
Privilegierte Instruktionen **ohne** Hypervisor
- kennen wir schon: Instruktion für Systemaufrufe
1. User Mode: Anwendung bereitet Befehl und Parameter vor
2. User Mode: Privilegierte Instruktion (syscall/Trap - Interrupt) $\rightarrow$ CPU veranlasst Kontext-und Privilegierungswechsel, Ziel: BS-Kernel
3. Kernel Mode: BS-Dispatcher (Einsprungpunkt für Kernel-Kontrollfluss) behandelt Befehl und Parameter, ruft weitere privilegierte Instruktionen auf (z.B. EA-Code)
- privilegierte Instruktionen bei virtualisierbaren Prozessoren
- bei Ausführung einer privilegierten Instruktion in virtueller Maschine: immer Kontrollflussübergabe an im Kernel-Modus laufende Systemsoftware - hier Typ-1-HV
- HV kann (anhand des virtuellen Privilegierungsmodus) feststellen:
1. ob sensible Anweisung durch Gast-BS
2. oder durch Nutzerprogramm (Systemaufruf!) ausgelöst
- Folgen:
1. privilegierte Instruktionen des Gast-Betriebssystems werden ausgeführt $\rightarrow$ ,,trap-and-emulate''
2. Einsprung in Betriebssystem, hier also Einsprung in Gast-Betriebssystem $\rightarrow$ Upcall durch HV
- privilegierte Instruktionen bei nicht virtualisierbaren Prozessoren
- solche Instruktionen typischerweise ignoriert!
Intel-Architektur ab 386
- dominant im PC-und Universalrechnersegment ab 1980er
- keine Unterstützung für Virtualisierung ...
- kritische Instruktionen im User Mode werden von CPU ignoriert
- 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
- Diese Architekturprobleme (bekannt seit 1974) wurden 20 Jahre lang im Sinne von Rückwärtskompatibilität auf Nachfolgeprozessoren übertragen ...
- erste virtualisierungsfähige Intel-Prozessorenfamilie (s. [Adams2006] ): VT, VT-x® (2005)
1. korrekt (bei sensiblen Instruktionen im Gast-Kernel) den Privilegierungsmodus zu wechseln
2. den korrekten Code im HV auszuführen
Übersetzungsstrategie in Software:
- vollständige Übersetzung des Maschinencodes, der in VM ausgeführt wird, in Maschinencode, der im HV ausgeführt wird
- praktische Forderung: HV sollte selbst abstrahierte HW-Schnittstelle zur Ausführung des (komplexen!) Übersetzungscodes zur Verfügung haben (z.B. Nutzung von Gerätetreibern)
- $\rightarrow$ Typ-2-HV als Kompromiss:
- korrekte Ausführung von virtualisierter Software auf virtualisierter HW
- beherrschbare Komplexität der Implementierung
aus Nutzersicht
- läuft als gewöhnlicher Nutzer-Prozess auf Host-Betriebssystem (z.B. Windows oder Linux)
- VMware bedienbarwie physischer Rechner (bspw. erwartet Bootmedium in virtueller Repräsentation eines physischen Laufwerks)
- persistente Daten des Gast-BS auf virtuellem Speichermedium ( tatsächlich: Image-Datei aus Sicht des Host-Betriebssystems)
Mechanismus: Code-Inspektion
- 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
- 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.
- Basisblöcke werden nach sensiblen Instruktionen abgesucht
- diese werden jeweils durchAufruf einer HV-Prozedur ersetzt, die jeweilige Instruktion behandelt
- gleiche Verfahrensweise mit letzter Instruktion eines Basis-Blocks
- modifizierter Basisblock: wird innerhalbdes HVin Cachegespeichert und ausgeführt
- 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)
- sensible Instruktionen: nach dargestellter Methode abgefangen und emuliert $\rightarrow$ dabei hilft jetzt das Host-BS (z.B. durch eigene Systemaufrufe, Gerätetreiberschnittstellen)
Mechanismus: Caching von Basisblöcken
- HV nutzt zwei parallel arbeitende Module (Host-BS-Threads!):
- Translator: Code-Inspektion, Binary Translation
- Dispatcher: Basisblock-Ausführung
- zusätzliche Datenstruktur: Basisblock-Cache
- Dispatcher: sucht Basisblock mit jeweils nächster auszuführender Befehlsadresse im Cache; falls miss $\rightarrow$ suspendieren (zugunsten Translator)
- Translator: schreibt Basisblöcke in Basisblock-Cache
- Annahme: irgendwann ist Großteil des Programms im Cache, dieses läuft dann mit nahezu Original-Geschwindigkeit (theoretisch)
Performanzmessungen
- zeigen gemischtes Bild: Typ2-HV keinesfalls so schlecht, wie einst erwartet wurde
- qualitativer Vergleich mit virtualisierbarer Hardware (Typ1-Hypervisor):
- insbesondere bei Vielzahl an VMs sehr teuer: CPU-Caches, TLBs, Heuristiken zur spekulativen Ausführung werden verschmutzt
- wenn andererseits sensible Instruktionen durch Aufruf von VMware-Prozeduren innerhalb des ausführenden Programms ersetzt: keine Kontextwechsel-Overheads
Studie: (von Vmware) [Adams&Agesen06]
- last-und anwendungsabhängig kann Softwarelösung sogar Hardwarelösung übertreffen
- Folge: viele moderne Typ1-HV benutzen aus Performanzgründen ebenfalls Binary Translation
### Paravirtualisierung
Funktionsprinzip
- ... unterscheidet sich prinzipiell von Typ-1/2-Hypervisor
- wesentlich: Quellcode des Gast-Betriebssystems modifiziert
- sensible Instruktionen: durch Hypervisor-Calls ersetzt
- Folge: Gast-Betriebssystem arbeitet jetzt vollständig wie Nutzerprogramm, welches Systemaufrufe zum Betriebssystem (hier dem Hypervisor) ausführt
- dazu:
- Hypervisor: muss geeignetes Interface definieren (HV-Calls)
- $\rightarrow$ Menge von Prozedur-Aufrufen zur Benutzung durch Gast-Betriebssystem
- bilden eine HV-API als Schnittstelle für Gast-Betriebssysteme (nicht für Nutzerprogramme!)
- mehr dazu: Xen
Verwandtschaft mit Mikrokernel-Architekturen
- Geht man vom Typ-1-HV noch einen Schritt weiter ...
- und entfernt alle sensiblen Instruktionen aus Gast-Betriebssystem ...
- und ersetzt diese durch Hypervisor-Aufrufe, um Systemdienste wie E/A zu benutzen, ...
- hat man praktisch den Hypervisor in Mikrokernel transformiert.
- ... und genau das wird auch schon gemacht: $L^4$Linux (TU Dresden)
- Typ-2-HV: HW-Multiplexing auf Basis eines Host-OS, binarytranslation
- Paravirtualisierung: Typ-1-HV für angepasstes Gast-OS, kein trap-and-emulate nötig $\rightarrow$ HV ähnelt $\mu$Kern
- Ergebnisse:
- ✓ VMs mit individuell anpassbarer Laufzeitumgebung
- ✓ isolierteVMs
- ✓ kontrollierbare VM-Interaktion (untereinander und mit HW)
- ✗ keine hardwarespezifischen Optimierungen aus VM heraus möglich $\rightarrow$ Performanz, Echtzeitfähigkeit, Sparsamkeit!
## Container
Ziele:
- Adaptivität , im Dienste von ...
- ... Wartbarkeit: einfachen Entwicklung, Installation, Rekonfiguration durch Kapselung von
- Anwendungsprogrammen
- + durch sie benutzte Bibliotheken
- + Instanzen bestimmter BS-Ressourcen
- ... 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:
- Abhängigkeitskonflikten (Anwendungen und Bibliotheken)
- fehlenden Abhängigkeiten (Anwendungen und Bibliotheken)
- Virtualisierungs-Software für x86- bzw. x86-64-Betriebssysteme für Industrie und ,,Hausgebrauch'' (ursprünglich: Innotek , dann Sun , jetzt Oracle )
- frei verfügbare professionelle Lösung, als Open Source Software unter GNU General Public License(GPL) version 2. ...
- (gegenwärtig) lauffähig auf Windows, Linux, Macintosh und Solaris Hosts
- 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.
- reiner Typ-2-Hypervisor
### Paravirutalisierung: Xen
- entstanden als Forschungsprojekt der University of Cambridge (UK), dann XenSource Inc., danach Citrix, jetzt: Linux Foundation (,,self-governing'')
- frei verfügbar als Open Source Software unter GNU General Public License (GPL)
- lauffähig auf Prozessoren der Typen x86, x86-64, PowerPC, ARM, MIPS
- unterstützt große Anzahl von Gast-Betriebssystemen: FreeBSD, GNU/Hurd/Mach, Linux, MINIX, NetBSD, Netware, OpenSolaris, OZONE, Plan 9
- ,,Built for the cloud before it was called cloud.'' (Russel Pavlicek, Citrix)
- bekannt für Paravirtualisierung
- unterstützt heute auch andere Virtualisierungs-Prinzipien
Xen : Architektur
- Gast-BSe laufen in Xen Domänen (,,$dom_i$'', analog $VM_i$)
- es existiert genau eine, obligatorische, vertrauenswürdige Domäne: $dom_0$
- Aufgaben (Details umseitig):
- Bereitstellen und Verwalten der virtualisierten Hardware für andere Domänen (Hypervisor-API, Scheduling-Politiken für Hardware-Multiplexing)
- Hardwareverwaltung/-kommunikation für paravirtualisierte Gast-BSe (Gerätetreiber)
- Interaktionskontrolle (Sicherheitspolitiken)
- $dom_0$ im Detail: ein separates, hochkritisch administriertes, vertrauenswürdiges BS mit eben solchen Anwendungen (bzw. Kernelmodulen) zur Verwaltung des gesamten virtualisierten Systems
- es existieren hierfür spezialisierte Variantenvon Linux, BSD, GNU Hurd
1. Anwendungen: sollen Freiheit haben, Betriebsmittel in für sie geeignetster Weise zu nutzen (= Exokernel-Prinzip)
2. Realisierung als sog. vertikal strukturiertes Betriebssystem:
- weitaus meiste Betriebssystem-Funktionalität innerhalb der Anwendungen ausgeführt (= Exokernel-Prinzip)
- Echtzeitanforderungen durch Multimedia $\rightarrow$ Vermeidung von Client-Server-Kommunikationsmodell wegen schlecht beherrschbarer zeitlicher Verzögerungen (neu)
- nicht: Exokernelvorteil der hardwarenahen Anwendungsentwicklung... ($\rightarrow$ Performanz und Echzeitfähigkeit )
### Container: Docker
- Idee: Container für einfache Wartbarkeit von Linux-Anwendungsprogrammen ...
- ... entwickeln
- ... testen
- ... konfigurieren
- ... portieren $\rightarrow$ Portabilität
- Besonderheit: Container können - unabhängig von ihrem Einsatzzweck - wie Software-Repositories benutzt, verwaltet, aktualisiert, verteilt ... werden
- Management von Containers: Docker Client $\rightarrow$ leichtgewichtiger Ansatz zur Nutzung der Wartbarkeitsvorteile von Virtualisierung
- Forsetzung unter der OCI (Open Container Initiative)
- ,,Docker does a nice job [...] for a focused purpose, namely the lightweight packaging and deployment of applications.'' (Dirk Merkel, Linux Journal)
- Implementierung der Containertechnik basierend auf Linux-Kernelfunktionen:
- Linux Containers (LXC): BS-Unterstützung für Containermanagement
- cgroups: Accounting/Beschränkung der Ressourcenzuordnung
- union mounting: Funktion zur logischen Reorganisation hierarchischer Dateisysteme
- Datenorganisation-und speicherung(z.B. Kundendatenverarbeitung zur Personalisierung von Werbeaktivitäten, Bürgerdatenverarbeitung zur Personalisierung von Geheimdienstaktivitäten)
- nicht disjunkt dazu: kommerzielle Anwendungen
- ,,Big Data'': Dienstleistungen für Kunden, die o. g. Probleme auf gigantischen Eingabedatenmengen zu lösen haben (Software wie Apache Hadoop )
- Wettervorhersage
- anspruchsvolle Multimedia- Anwendungen
- Animationsfilme
- VR-Rendering
## Performanzbegriff
- Performance: The degree to which a system or component accomplishes its designated functions within given constraints, such as speed, accuracy, or memory usage. (IEEE)
- Performanz im engeren Sinne dieses Kapitels: Minimierung der für korrekte Funktion (= Lösung eines Berechnungsproblems) zur Verfügung stehenden Zeit.
- oder technischer: Maximierung der Anzahl pro Zeiteinheit abgeschlossener Berechnungen.
## Roadmap
- Grundlegende Erkenntnis: Performanz geht nicht (mehr) ohne Parallelität $\rightarrow$ Hochleistungsrechnen = hochparalleles Rechnen
- daher in diesem Kapitel: Anforderungen hochparallelen Rechnens an ...
- Daten durch mehrere Prozessor-Kerne schrittweise verarbeitet
- durch letzten Prozessor: Ablage im Speichersystem
- Verwendung:
- Graphikchips
- (hochspezialisierte) Netzwerkprozessoren
- Beispiele: Prozessoren X10 u. X11 von Xelerator zur Verarbeitung von Netzwerkpaketen in Hochleistungsroutern (X11: bis zu 800 Pipeline-Prozessorkerne)
- Funktionale Eigenschaften: beschreiben, was ein (Software)-Produkt tun soll
- Nichtfunktionale Eigenschaften: beschreiben, wie funktionale Eigenschaften realisiert werden, also welche sonstigen Eigenschaftendas Produkt haben soll ... unterteilbar in:
1. Laufzeiteigenschaften (zur Laufzeit sichtbar)
2. Evolutionseigenschaften (beim Betrieb sichtbar: Erweiterung, Wartung, Test usw.)
Roadmap (... von Betriebssystemen)
- Sparsamkeit und Effizienz
- Robustheit und Verfügbarkeit
- Sicherheit
- Echtzeitfähigkeit
- Adaptivität
- Performanzund Parallelität
## Sparsamkeit und Effizienz
- Sparsamkeit: Die Eigenschaft eines Systems, seine Funktion mit minimalem Ressourcenverbrauch auszuüben.
- Effizienz: Der Grad, zu welchem ein System oder eine seiner Komponenten seine Funktion mit minimalem Ressourcenverbrauch ausübt. $\rightarrow$ Ausnutzungsgrad begrenzter Ressourcen
- Die jeweils betrachtete(n) Ressource(n) muss /(müssen) dabei spezifiziert sein!
- sinnvolle Möglichkeiten bei Betriebssystemen:
1. Sparsamer Umgang mit Energie , z.B. energieeffizientes Scheduling
2. Sparsamer Umgang mit Speicherplatz (Speichereffizienz)
3. Sparsamer Umgang mit Prozessorzeit
4. ...
Sparsamkeit mit Energie
- Sparsamkeit mit Energie als heute extrem wichtigen Ressource, mit nochmals gesteigerter Bedeutung bei mobilen bzw. vollständig autonomen Geräten Maßnahmen:
1. 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)
2. Software-Ebene: neue Komponenten entwickeln, die in der Lage sein müssen:
- Bedingungenzu erkennen, unter denen ein energiesparender Modus möglich ist;
- Steuerungs-Algorithmen für Hardwarebetrieb so zu gestalten, dass Hardware-Ressourcen möglichst lange in einem energiesparenden Modus betrieben werden.
- Energie-Verwaltungsstrategien: energieeffizientes Scheduling zur Vermeidung von Unfairness und Prioritätsumkehr
- Betrachtet: Sparsamkeit mit Speicherplatz mit besonderer Wichtigkeit für physisch beschränkte, eingebettete und autonome Geräte
- Maßnahmen Hauptspeicherauslastung:
1. Algorithmus und Strategie z.B.:
- Speicherplatz sparende Algorithmen zur Realisierung gleicher Strategien
2. Speicherverwaltung von Betriebssystemen:
- physische vs. virtuelle Speicherverwaltung
- speichereffiziente Ressourcenverwaltung
- Speicherbedarfdes Kernels
- direkte Speicherverwaltungskosten
- Maßnahmen Hintergrundspeicherauslastung:
1. Speicherbedarf des Betriebssystem-Images
2. dynamische SharedLibraries
3. VMM-Auslagerungsbereich
4. Modularität und Adaptivität des Betriebssystem-Images
- Nicht betrachtet: Sparsamkeit mit Prozessorzeit $\rightarrow$ 99% Überschneidung mit NFE Performanz
## Robustheit und Verfügbarkeit
- Robustheit: Zuverlässigkeit unter Anwesenheit externer Ausfälle
- fault, aktiviert $\rightarrow$ error, breitet sich aus $\rightarrow$ failure
Robustheit
- Erhöhung der Robustheit durch Isolation:
- Maßnahmen zur Verhinderung der Fehlerausbreitung:
1. Adressraumisolation: Mikrokernarchitekturen,
2. kryptografische HW-Unterstützung: Intel SGX und
3. Virtualisierungsarchitekturen
- Erhöhung der Robustheit durch Behandlung von Ausfällen: Micro-Reboots
Vorbedingung für Robustheit: Korrektheit
- Korrektheit: Eigenschaft eines Systems sich gemäß seiner Spezifikation zu verhalten (unter der Annahme, dass bei dieser keine Fehler gemacht wurden).
- Maßnahmen (nur angesprochen):
1. diverse Software-Tests:
- können nur Fehler aufspüren, aber keine Fehlerfreiheit garantieren!
2. Verifizierung:
- Durch umfangreichen mathematischen Apparat wird Korrektheit der Software bewiesen.
- Aufgrund der Komplexität ist Größe verifizierbarer Systeme (bisher?) begrenzt.
- Betriebssystem-Beispiel: verifizierter Mikrokern seL
Verfügbarkeit
- Verfügbarkeit: Der Anteil an Laufzeit eines Systems, in dem dieses seine spezifizierte Leistung erbringt.
- angesprochen: Hochverfügbare Systeme
- Maßnahmen zur Erhöhung der Verfügbarkeit:
1. Robustheitsmaßnahmen
2. Redundanz
3. Redundanz
4. Redundanz
5. Ausfallmanagement
## Sicherheit
- Sicherheit (IT-Security): Schutz eines Systems gegen Schäden durch zielgerichtete Angriffe, insbesondere in Bezug auf die Informationen, die es speichert, verarbeitet und kommuniziert.
- Performanz (wie hier besprochen): Eigenschaft eines Systems, die für korrekte Funktion (= Berechnung) benötigte Zeit zu minimieren.
- hier betrachtet: Kurze Antwort-und Reaktionszeiten
1. vor allen Dingen: Parallelisierung auf Betriebssystemebene zur weiteren Steigerung der Performanz/Ausnutzung von Multicore-Prozessoren(da Steigerung der Prozessortaktfrequenz kaum noch möglich)
2. weiterhin: Parallelisierung auf Anwendungsebene zur Verringerung der Antwortzeiten von Anwendungen und Grenzen der Parallelisierbarkeit(für Anwendungen auf einem Multicore-Betriebssystem).
Mechanismen, Architekturen, Grenzen der Parallelisierung
- Hardware:
- Multicore-Prozessoren
- Superskalarität
- Betriebssystem:
- Multithreading(KLTs) und Scheduling
- Synchronisation und Kommunikation
- Lastangleichung
- Anwendung(sprogrammierer):
- Parallelisierbarkeiteines Problems
- optimaler Prozessoreneinsatz, Effizienz
## Synergetische und konträre Eigenschaften
- Normalerweise:
- Eine nichtfunktionale Eigenschaft bei IT-Systemen meist nicht ausreichend
- Beispiel: Was nützt ein Echtzeit-Betriebssystem - z.B. innerhalb einer Flugzeugsteuerung - wenn es nicht auch verlässlich arbeitet?
- In diesem Zusammenhang interessant:
- Welche nichtfunktionalen Eigenschaften mit Maßnahmen erreichbar, die in gleiche Richtung zielen, bei welchen wirken Maßnahmen eher gegenläufig?
- Erstere sollen synergetische, die zweiten konträre (also in Widerspruch zueinander stehende) nichtfunktionale Eigenschaften genannt werden.
- Zusammenhang nicht immer eindeutig und offensichtlich, wie z.B. bei: ,,Sicherheit kostet Zeit.'' (d.h. Performanz und Sicherheit sind nichtsynergetische Eigenschaften)
## Notwendige NFE-Paarungen
- 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.
- Beispiele:
- Echtzeit und Verlässlichkeit: ,,SRÜ''-Systeme an potentiell gefährlichen Einsatzgebieten (Atomkraftwerk, Flugzeugsteuerung, Hinderniserkennung an Fahrzeugen, ...)
- Echtzeit und Sparsamkeit: Teil der eingebetteten Systeme
- Robustheit und Sparsamkeit: unter entsprechenden Umweltbedingungen eingesetzte autonome Systeme, z.B. smart-dust-Systeme
Fazit: Breites und offenes Forschungsfeld $\rightarrow$ werden Sie aktiv!
# Prüfungsschwerpunkte
- Basiswissen: Allgemeines zu NFEn, NFE-Ziele (Anwendungsbsp.), Probleme und deren Lösungskonzepte (Strategien, Mechanismen, Architekturen)!
- zu jeder NFE: Konzepte und Strategien der Mechanismen (Idee), relevante System-Architekturen (Idee, Vor-und Nachteile)
- z.B.: Warum Sicherheit? Wo? Welche BS-Probleme sind zur Herstellung von Sicherheitseigenschaften zu lösen? Durch welche Konzepte (z.B. Zugriffssteuerungsmechanismen, Referenzmonitor-Arch.) ist dies möglich?
- Basiswissen plus (= für gute Noten):
- Mechanismen: prinzipieller Ablauf von Algorithmen, praktische Eigenheiten/Implementierungsprobleme
- Beispiel-BSe(Idee, ggf. deren Aufbau)
- Vergleichende Bewertung synergetischer und konträrer NFE anhand ihrer jeweils relevanten Mechanismen und Architekturen (Stoffquerschnitt)
- Tipp: Übungsstoff zu 90% aus diesen beiden Schwerpunktklassen
- KELLNER, SIMON: Flexible Online Energy Accounting in TinyOS
- Verlässlichkeitsbegriff, Fehlermodell:
- [ALRL04] AVIŽIENIS, ALGIRDAS; LAPRIE, JEAN-CLAUDE; RANDELL, BRIAN; LANDWEHR, CARL: Basic Concepts and Taxonomy of Dependable and Secure Computing. In: IEEE Trans. Dependable Secur. Comput. https://doi.org/10.1109/TDSC.2004.2
- [AvLR04] AVIŽIENIS, ALGIRDAS; LAPRIE, JEAN-CLAUDE; RANDELL, BRIAN: Dependability and Its Threats: A Taxonomy. In: JACQUART, R.(Hrsg.): Building theInformation Society , IFIP International Federation for Information Processing : Springer US, 2004, https://doi.org/10.1007/978
- [TaBo15] TANENBAUM, ANDREWS; WOODHULL, ALBERTS: Operating Systems Design and Implementation. 3. Aufl. UpperSaddleRiver, NJ, USA: Prentice-Hall, Inc., 2005
- Mikrokerneldesign, L4:
- [Lied95] LIEDTKE, JOCHEN: On μ-Kernel Construction. In: Operating Systems Review. Special issue for the Fifteenth ACM Symposium on Operating System Principles Bd. 29 (1995), https://doi.org/10.1145/224056.224075
- [Amth16] AMTHOR, PETER: The Entity LabelingPattern for Modeling Operating Systems Access Control. In: OBAIDAT, S. M.; LORENZ, P.(Hrsg.): E-Business and Telecommunications: 12th International Joint Conference, ICETE 2015, Colmar, France, http://dx.doi.org/10.1007/978-3-319-30222-5_13
- [BeLa76] BELL, D. ELLIOTT; LAPADULA, LEONARDJ.: Secure Computer System: Unified Exposition and MulticsInterpretation (Technical Report Nr. AD-A023 588): MITRE, 1976
- [Biba77] BIBA, KENNETHJ.: IntegrityConsiderationsforSecure Computer Systems (Technical Report Nr. ESD-TR-76-372). Bedford, Massachusetts: MITRE, 1977 http://seclab.cs.ucdavis.edu/projects/history/papers/biba75.pdf (digitalisierte Fassung von 1975)
- [LoSm01] LOSCOCCO, PETERA.; SMALLEY, STEPHEND.: Integrating Flexible Support for Security Policies into the Linux Operating System. In: COLE, C.(Hrsg.): Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference. Berkeley, CA, USA: USENIX Association
- [MaMC06] MAYER, FRANK; MACMILLAN, KARL; CAPLAN, DAVID: SELinux by Example: Using Security Enhanced Linux (Prentice Hall Open Source Software Development Series). UpperSaddle River, NJ, USA: PrenticeHall PTR, 2006
- [Spen07] SPENNEBERG, RALF: SELinux & AppArmor: Mandatory Access Control für Linux einsetzen und verwalten. 1. Aufl. München: Addison-Wesley Verlag, 2007
- Microsoft Singularity:
- [HLAA05] HUNT, GALEN; LARUS, JAMES; ABADI, MARTIN; AIKEN, MARK; BARHAM, PAUL; FÄHNDRICH, MANUEL; HAWBLITZEL, CHRIS; HODSON, ORION; U.A.: An Overview of the Singularity Project (Nr. MSR-TR-2005-135): Microsoft Research, Redmond, 2005 http://research.microsoft.com/pubs/52716/tr-2005-135.pdf
- [Jaeg11] JAEGER, TRENT: Reference Monitor. In: VANTILBORG, H. C. A.; JAJODIA, S.(Hrsg.): Encyclopedia of Cryptography and Security. Boston, MA: Springer US, 2011, S. 1038 - 1040 http://www.cse.psu.edu/~trj1/cse543-s15/docs/refmon.pdf
- [Buttazzo97], [Buttazzo2000] Giorgio C. Buttazzo: Hard Real-Time Computing Systems - Predictable Scheduling Algorithms and Applications, Kluwer Academic Publishers Boston / Dordrecht / London, 1997
- [Burns+89] Alan Burns, Andy Wellings: Real-Time Systems andProgrammingLanguages, Addison-Wesley, 3rd edition 2001
- [Liu&Layland73] C. L. Liu, James W. Layland: Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment, Journal of the ACM, Vol. 20, Nr. 1 (Januar 1973)
- [Quade+2012] Jürgen Quade, Michael Mächtel: Moderne Realzeitsysteme kompakt -Eine Einführung mit Embedded Linux, dpunkt.verlag, 2012
- [Liu2000] Jane W. S. Liu: Real-Time Systems, PrenticeHall 2000
- [Clark89] Dayton Clark: HIC: An Operating System for Hierarchies of Servo Loops, Proceedings of the 1989 International Conference on Robotics and Automation
- [Deitel90] Harvey M. Deitel: Operating Systems, Addison-Wesley, 1990
- [Goyal+96] PawanGoyal, XingangGuo, HarrickM. Vin: A HierarchicalCPU Scheduler forMultimedia Operating Systems, OSDI (ACM-Konferenz ,,Operating System Design andImplementation'') 1996
- [Sha+90] L. Sha, R. Rajkumar, J. P. Lehoczky: Priority Inheritance Protocols: An Approach to Real-Time Synchronization, IEEE Transactions on Computers, September 1990
- [Inf-Handbuch97] Peter Rechenberg, Gustav Pomberger (Hrsg.): Informatik-Handbuch, Carl-Hanser-Verlag München Wien, 1997
- [Schiebe+92] Michael Schiebe (Hrsg.): Real-time Systems -Engineering andApplications, Kluwer Academic Publishers 1992
- [Silberschatz+91] Abraham Silberschatz, James L. Peterson, Peter B. Galvin: Operating Systems Concepts(3rd edition), Addison-Wesley Publishing Company, 1991
- [Steinmetz95] Ralf Steinmetz: Analyzing the Multimedia Operating System, IEEE Multimedia, Vol. 2, Nr. 1 (Spring 1995)
- [Yau+96] David K. Y. Yau, Simon S. Lam: Adaptive Rate-Controlled Scheduling for Multimedia Applications, Proceedings of the 4th ACM International Multimedia Conference 1996
- Container:
- [Merkel14] Dirk Merkel: Docker: Lightweight Linux Containers for Consistent Development and Deployment, Linux Journal, No. 239 (Mar 2014).
- Adaptivitätsbegriff:
- [Marciniak94] John J. Marciniak (Hrsg.): Encyclopedia of Software Engineering, Vol. 1, John Wiley& Sons, 1994
- Exokernel:
- [Engler+95] Dawson R. Engler, M. Frans Kaashoek, James O‘TooleJr.: Exokernel: An Operating System Architecture for Application-Level Resource Management, 15th ACM Symposium on Operating System Principles(SOSP), 1995
- [Engler98] Dawson R. Engler: The Exokernel Operating System Architecture, Ph.D. Thesis, Massachusetts Institute ofTechnology, 1998
- [Engler+97] M. Frans Kaashoek, Dawson R. Engler, Gregory R. Ganger, Héctor M. Briceño, Russell Hunt, David Mazieres, Thomas Pinckney, Robert Grimm, John Jannotti, Kenneth Mackenzie: Application Performance and Flexibility of Exokernel Systems, 16th ACM Symposium on Operating System Principles(SOSP), 1997
- [Engler+96] Dawson R. Engler, M. Frans Kaashoek, Gregory R. Ganger, Héctor M. Briceño, Russell Hunt, David Mazieres, Thomas Pinckney, John Jannotti: Exokernels (Präsentation, online verfügbar unter: https://pdos.csail.mit.edu/exo/exo-slides/sld001.htm)
- Nemesis:
- [Reed+97] Dickon Reed, Robin Fairbairns (Hrsg.): Nemesis, The Kernel - Overview, Technischer Bericht, 1997, (verfügbar unter: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.512)
- MirageOS:
- [Scott+13] Anil Madhavapeddy, David J. Scott: Unikernels: Rise of the Virtual Library Operating System, ACM Queue -Distributed Computing, Vol. 11, No. 11 (Nov 2013), https://dl.acm.org/citation.cfm?id=2566628
- Virtualisierung:
- [Popek&Goldberg74] Gerald J. Popek, Robert P. Goldberg: Formal Requirements for Virtualizable Third Generation Architectures, Communications of the ACM, Vol. 17, No.7, 1974
- [Adams&Agesen06] Keith Adams, Ole Agesen: A Comparison of Software and Hardware Techniques for x86 Virtualization, 12th Int. Conf. on Architectural Support for Programming Languages and Operating, Systems(ASPLOS XII), 2006
- [Keckler+2009] Stephen W. Keckler: Multicore Processors and Systems, Springer Science+BusinessMedia, LLC 2009, ISBN 978-1-4419-0263-4
- Barrelfish:
- [Baumann+2009b] Andrew Baumann et al.: The Multikernel: A newOS architecture for scalable multicoresystems, Proceedings ACM SOSP (Symposium on Operating System Principles) 2009
- Amoeba:
- [Tanenbaum+91] AndrewS. Tanenbaum, M. Frans Kaashoek, Robbertvan Renesse, Henri E. Bal: The Amoeba Distributed Operating System - A Status Report Elsevier Computer Communications, Vol. 14, No.6, 1991, S. 324 – 335
