Advanced Operating Systems (Teil C: Betriebssystem-Architekturkonzepte)

Transkript

1 - Advanced Operating Systems (Teil C: Betriebssystem-Architekturkonzepte) Kapitel 9: Virtualisierungs-Architekturen Peter Amthor Wintersemester 2017/18 Peter Amthor Fak. IA / FG VSBS Technische Universität Ilmenau

2 9.1 Einführung q Architekturprinzip Ziel: auf gleicher Hardware mehrere unterschiedliche Betriebssysteme ausführbar machen: Anwendungen für BS 1 Anwendungen für BS n (Gast-) Betriebssystem 1 (Gast-) Betriebssystem 2 (Gast-) Betriebssystem 3 (Gast-) Betriebssystem n (System-Software-Schicht) Hardware Ø damit: Anwendungen die sonst nicht gemeinsam auf gleicher Maschine lauffähig auf einer Maschine ausführbar (u.a. ökonomische Vorteile) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 2

3 Realisierungsprinzip q 3 unterschiedliche Prinzipien 1. Type-1-Hypervisor (früher: VMM Virtual Machine Monitor ) 2. Type-2-Hypervisor 3. Paravirtualisierung AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 3

4 9.2 Typ-1-Hypervisor (auch: Virtual Machine Monitor) Anwendungen für BS 1 Anwendungen für BS n (Gast-) Betriebssystem 1 (Gast-) Betriebssystem 2 (Gast-) Betriebssystem 3 (Gast-) Betriebssystem n Typ-1-Hypervisor Hardware System-Software-Schicht Gast-Betriebssystem(e) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 4

5 Typ-1-Hypervisor q Funktionsweise Normalerweise bewirkt ein Betriebssystem über der Hardware: 1. Multiplexing der Hardware (ermöglicht Multiprozess-Betrieb) 2. erweiterte ( verbesserte ) Maschine mit angenehmerer Schnittstelle als die reine Hardware (mit z.b. Dateien usw.) Typ-1-Hypervisor trennt beide Funktionen: läuft wie ein Betriebssystem unmittelbar über der Hardware bewirkt Multiplexing der Hardware, liefert aber keine erweiterte Maschine nach oben Ø Damit bietet er mehrmals die unmittelbare Hardware-Schnittstelle nach oben an, von denen also jede eine virtuelle Maschine jeweils mit den unveränderten Hardware-Eigenschaften darstellt (Kern- u. Nutzer- Modus, Ein-/Ausgaben usw.). AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 5

6 Typ-1-Hypervisor q Entwicklung auf IBM-Großrechnern (ursprünglich IBM /360) Ø Original-Betriebssystem OS /360: war reines Stapelverarbeitungs-Betriebssystem (1960iger Jahre) Ø Viele Nutzer: strebten interaktive Arbeitsweise an eigenem Terminal an. verschiedene Arbeitsgruppen innerhalb und außerhalb von IBM entwickelten Time-Sharing-Systeme IBM-Originalsystem: TSS /360 Ø gewaltige Entwicklungskosten Ø sehr schlechte Performanz Endsieger : Entwicklung des IBM Scientific Center in Cambridge, Mass.: CP/CMS, später VM /370 à z/vm AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 6

7 Typ-1-Hypervisor q Entwicklung Herzstück des Hypervisors: Virtual Machine Monitor (VMM) lief auf blanker Hardware (Begriff geprägt: Bare Metal Hypervisor ) lieferte: Menge virtueller Maschinen an nächste Schicht Ø auf jeder virtuellen Maschine: unterschiedliches Betriebssystem lauffähig (da jede virtuelle Maschine exakte Kopie der Hardware) teilweise benutzt: Original-Betriebssystem OS /360 beliebt bei Programmierern aber: CMS (Conversational Monitor System), ein interaktives Single- User-Betriebssystem AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 7

8 9.3 Voraussetzungen der Virtualisierung (oder: warum spielte Virtualisierung im PC-Bereich lange keine Rolle?) q Systematische Untersuchungen erstmals: 1974 durch Popek & Goldberg Ergebnis: zur Realisierung virtueller Maschinen: Prozessor muss virtualisierbar sein Entscheidend: ein Gast-Betriebssystem (welches auf virtueller Maschine im Nutzer- Modus läuft): muss erreichen, dass seine privilegierten Instruktionen irgendwie ausgeführt werden. Prozessor: muss bei jeder im Nutzermodus versuchten Ausführung einer privilegierten Instruktion Trap zum VMM ausführen, damit Instruktion gegebenenfalls dort emuliert werden kann AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 8

9 Voraussetzungen der Virtualisierung q Systematische Untersuchungen IBM-Hardware: besaß diese Eigenschaft und war virtualisierbar Intel-Prozessoren: besaßen diese Eigenschaft lange nicht waren also nicht virtualisierbar! AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 9

10 Voraussetzungen der Virtualisierung (genauer...) q Untersuchungen von Popek & Goldberg bei jedem Prozessor mit Kernel- u. Nutzer-Modus: existiert: Menge an Maschinen-Befehlen, die nur im Kernel-Modus ausgeführt werden dürfen (z.b. Befehle zur Realisierung von E/A, solche zur Änderung der MMU u.a.) nach [Popek&Goldberg]: sensitive Instruktionen es existiert auch: Menge an Maschinenbefehlen, die Trap auslösen, wenn sie im Nutzer-Modus ausgeführt werden nach [Popek&Goldberg]: privilegierte Instruktionen Ø Ein Prozessor nur dann virtualisierbar: wenn Menge der sensitiven Instruktionen Untermenge der privilegierten Instruktionen einfacher: Damit Prozessor virtualisierbar, muss bei jedem Befehl der im Nutzer- Modus nicht erlaubt, Trap generiert werden. AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 10

11 Voraussetzungen der Virtualisierung (genauer...) q privilegierte Instruktionen bei virtualisierbaren Prozessoren Ø auf virtualisierbaren Prozessoren: bei Ausführung einer privilegierten Instruktion in virtueller Maschine: Ø immer Trap in im Kernel-Modus laufende Systemsoftware hier (Typ1-)Hypervisor (siehe umseitig) Hypervisor: kann (durch Inspektion) feststellen: ob sensitive Anweisung in virtueller Maschine durch Gastbetriebssystem oder durch Nutzerprogramm auf virtueller Maschine (Systemaufruf!) ausgelöst Ø Instruktionen des Gast-Betriebssystems: werden ausgeführt AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 11

12 Voraussetzungen der Virtualisierung (genauer...) q privilegierte Instruktionen bei virtualisierbaren Prozessoren Ø Systemaufrufe von Nutzerprogrammen auf virtueller Maschine (Trap- Befehl!): wird emuliert, was reale Hardware getan hätte: - normalerweise: Einsprung in Betriebssystem, hier also Einsprung in Gast-Betriebssystem bei nicht virtualisierbaren Prozessoren: solche Instruktionen typischerweise ignoriert! AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 12

13 Privilegierte Instruktionen bei Typ-1-Hypervisor virtuelle Maschine Anwendungen des Gast-BS ein Gast-Betriebssystem virtueller Nutzer- Modus Typ-1-Hypervisor virtueller Kern- Modus Trap bei jeder privilegierten Instruktion Nutzer- Modus Kern- Modus Hardware Darstellung nach [Tanenbaum2008] Bild 8-26 S. 572 AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 13

14 Voraussetzungen der Virtualisierung (genauer...) q IBM/370-Prozessor Ø Virtualisierung wurde unterstützt q Intel-Architektur (ab 386) keine Unterstützung für Virtualisierung bei versuchter Ausführung einiger sensitiver Instruktionen im Nutzer- Modus: diese einfach ignoriert außerdem schlimm : z.b. auf Pentium-Prozessor kann Programm feststellen, ob es im Kerneloder Nutzer-Modus läuft Ø Betriebssystem, das entdeckt, dass es im Nutzer-Modus läuft: trifft möglicherweise absolut fehlerhafte Entscheidungen Ø Diese Mängel der Intel-Architektur 20 Jahre lang im Sinne von Rückwärtskompatibilität auch auf Nachfolgeprozessoren übertragen AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 14

15 q Forderungen nach Virtualisierbarkeit Bedarf an Virtualisierungslösungen Ø Reihe von Gründen: führten im Laufe der Zeit zu hohem Bedarf an Virtualisierungslösungen: 1. Mehrere unterschiedliche Server, die in Unternehmen bisher auf mehreren unterschiedlichen Rechnern mit unterschiedlichen Betriebssystemen liefen, jetzt ökonomischer auf einem Rechner lauffähig 2. Checkpointing u. Migration virtueller Maschinen wesentlich einfacher als als auf Prozess-Ebene 3. Benutzung von Legacy -Software kostengünstig möglich 4. Software-Entwicklung für unterschiedliche Systeme: ökonomischer u. angenehmer möglich AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 15

16 Forschungsarbeiten q 1990iger Jahre Ø verschiedene akademische Projekte zur Virtualisierung bisher nicht virtualisierbarer Prozessoren: erstes und vermutlich bekanntestes: DISCO-Projekt der University of Stanford Ø Resultat: letztlich VMware (heute kommerziell) u. Typ-2-Hypervisoren AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 16

17 - Organisatorisches ( ) Prüfungstermine: regulär am (Mo) bedarfsweise am (Do) Übungsblatt 3: jetzt online, Besprechung nächsten Mittwoch (17.01.) à vorbereiten! Übungswikis Betriebssysteme: zeitlich beschränkter Zugang, Passwort folgt (nächsten Mittwoch) Vergangenheitsbewältigung: erste virtualisierungsfähige Intel-Prozessorenfamilie (s. [Adams2006]): VT, VT-x (2005) dito für AMD: SVM, AMD-V (auch 2005) Privilegierte Prozessorinstruktionen aus Programmierersicht: Exkurs folgt (Zusatzmaterial im Web)

18 Exkurs: Privilegierte Prozessorinstruktionen (Linux-Beispiel, Intel x86 Architektur) Ein Beispiel: Anwenderprogramm, das String in Puffer eines Ausgabegeräts schreibt ohne Nutzung der libc Standard-Bibliothek: my_print_text = text; /* manually determine string length: */ for (my_print_len = 0; my_print_text[my_print_len]; ++my_print_len); /* system call: * write is system call no. 4 * stdout is file descriptor no. 1 */ asm("movl $4, %eax"); /* arg 0 (eax): syscall number */ asm("movl $1, %ebx"); /* arg 1 (ebx): file descriptor */ asm("movl my_print_text, %ecx"); /* arg 2 (ecx): buffer */ asm("movl my_print_len, %edx"); /* arg 3 (edx): length */ asm("int $0x80"); /* interrupt 80 (syscall) */ asm("movl %eax, my_print_ret"); /* save return code (eax) */ AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 18

19 Exkurs: Privilegierte Prozessorinstruktionen /* system call: * write is system call no. 4 * stdout is file descriptor no. 1 */ asm("movl $4, %eax"); /* arg 0 (eax): syscall number */ asm("movl $1, %ebx"); /* arg 1 (ebx): file descriptor */ asm("movl my_print_text, %ecx"); /* arg 2 (ecx): buffer */ asm("movl my_print_len, %edx"); /* arg 3 (edx): length */ asm("int $0x80"); /* interrupt 80 (syscall) */ asm("movl %eax, my_print_ret"); /* save return code (eax) */ unprivilegierte Instruktion privilegierte Instruktion Interrupt-Instruktion veranlasst Prozessor zum Kontextwechsel: Kernelcode im privilegierten Modus ausführen (umseitig) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 19

20 Exkurs: Privilegierte Prozessorinstruktionen asm("movl $4, %eax"); asm("movl $1, %ebx"); asm("movl my_print_text, %ecx"); asm("movl my_print_len, %edx"); asm("int $0x80"); asm("movl %eax, my_print_ret"); asm("movl $317, %eax"); asm("movl $1, %ebx"); asm("movl vax, %ecx"); asm("int $0x80"); User Mode (Ring 3) Kernel Mode (Ring 0) asm volatile( "rep ; movsl\n\t "movl %4,%%ecx\n\t "andl $3,%%ecx\n\t "jz 1f\n\t "rep ; movsb\n\t... asm volatile( "invlpg (%0)" ::"r" (addr) : "memory");... unprivilegierte Instruktion privilegierte Instruktion sensitive Instruktion AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 20

21 9.4 Typ-2-Hypervisor Anwendungen für BS 1 Anwendungen für BS n (Gast-) Betriebssystem 1 (Gast-) Betriebssystem 2 (Gast-) Betriebssystem n Anwendungen des Host-Betriebssystems Typ-2-Hypervisor Host-Betriebssystem Hardware System-Software-Schicht Gast-Betriebssystem(e) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 21

22 Funktion des Typ-2-Hypervisors (am Beispiel Vmware) q VMware läuft: als gewöhnlicher Nutzer-Prozess auf Host-Betriebssystem (z.b. Windows oder Linux) Ø beim ersten Start: VMware reagiert wie neuer Rechner u. erwartet Betriebssystem-DVD im entsprechenden Laufwerk Ø VMware: installiert Betriebssystem auf virtuellem Speichermedium (in Realität: eine Datei des Host-Betriebssystems) kann danach wie ganz normales Betriebssystem gestartet werden AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 22

23 Funktion des Typ-2-Hypervisors q Interne Arbeitsweise Ø Bei Ausführung z.b. von Pentium-Binärprogramm (egal ob von Installations-CD oder virtueller Disk): wird zunächst nach Basis-Blöcken gesucht Das sind Befehlsfolgen, die mit privilegierten (Trap-) Befehlen oder solchen Befehlen abgeschlossen sind, die den Kontrollfluss ändern (sichtbar an Änderung des Programm-Zählers eip), z.b. jmp, call, ret. Ø Basisblöcke: werden nach sensitiven Instruktionen abgesucht Ø Diese: jeweils durch Aufruf einer Vmware-Prozedur ersetzt, die jeweilige Instruktion behandelt Ø gleiche Verfahrensweise: mit letzter Instruktion eines Basis-Blocks Ø... AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 23

24 Funktion des Typ-2-Hypervisors q Interne Arbeitsweise Ø... Ø so modifizierter Basis-Block: wird innerhalb von VMware in Cache gespeichert u. ausgeführt Ø Basis-Block ohne sensitive Instruktionen: läuft unter VMware absolut genauso schnell wie unmittelbar auf Hardware (weil er auch tatsächlich unmittelbar auf der Hardware läuft) Ø sensitive Instruktionen: nach dargestellter Methode abgefangen u. emuliert è diese Technik: bekannt als Binary Translation (Binär-Übersetzung) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 24

25 Funktion des Typ-2-Hypervisors q Interne Arbeitsweise Ø Nachdem Basis-Block vollständig ausgeführt: erhält VMware Kontrolle zurück und lokalisiert nachfolgenden Basis-Block falls dieser schon transformiert: kann er sofort ausgeführt werden. (Falls nicht, wird wie eben verfahren.) irgendwann: Großteil des Programms im Cache, läuft dann: mit nahezu Original-Geschwindigkeit, die Hardware ermöglicht AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 25

26 Funktion des Typ-2-Hypervisors q Optimierungstechniken zusätzlich: verschiedene Optimierungstechniken angewendet Beispiel: Wenn Basisblock durch Sprung zu oder Aufruf eines anderen Basisblocks endet, kann diese letzte Anweisung durch Sprung zu bzw. Aufruf des übersetzten Basis-Blocks ersetzt werden. Ø Hierdurch jeglicher Overhead bezüglich Auffindens des nächsten Basis-Blocks eliminiert. AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 26

27 Performanz des Typ-2-Hypervisors q Performanz Messungen: zeigen gemischtes Bild Ø Typ2-Hypervisoren: keinesfalls so schlecht, wie vielleicht zu erwarten Vergleich mit virtualisierbarer Hardware (u. Typ1-Hypervisor): Ø durch dort verwendete trap-and-emulate -Technik: wird Vielzahl von Traps erzeugt Ø diese: bei moderner Hardware sehr teuer (weil sie CPU-Caches, TLBs u. Branch-Prediction-Tabellen des Prozessors korrumpiert) Ø wenn andererseits sensitive Instruktionen durch Aufruf von VMware- Prozeduren innerhalb des ausführenden Programms ersetzt: keine dieser Kontext-Umschaltungs-Overheads AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 27

28 Performanz des Typ-2-Hypervisors q Performanz Ø Messungen (von Adams u. Agesen) zeigen: manchmal: übertrifft Softwarelösung sogar Hardwarelösung (abhängig von Art der Last). deshalb heute: sogar einige Typ1-Hypervisoren benutzen aus Performanzgründen binary Translation (auch wenn alles auch ohne diese korrekt funktionieren würde) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 28

29 q Funktionsprinzip unterscheidet sich von jedem der diskutierten Hypervisor Hierbei: Quellcode des Gast-Betriebssystems modifiziert sensitive Instruktionen: durch Hypervisor-Calls ersetzt 9.5 Paravirtualisierung Effekt: Gast-Betriebssystem arbeitet jetzt wie Nutzerprogramm, welches Systemaufrufe ( system calls ) zum Betriebssystem (hier dem Hypervisor) ausführt dazu: Hypervisor: muss spezielles Interface definieren dieses umfasst: Menge von Prozedur-Aufrufen zur Benutzung durch Gast-Betriebssystem Prozedur-Aufrufe: bilden Art API als Schnittstelle für Gast- Betriebssysteme (nicht für Nutzerprogramme!) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 29

30 q Verwandtschaft mit Mikrokernel-Prinzip Paravirtualisierung Ø Geht man noch einen Schritt weiter und entfernt alle sensitiven Instruktionen aus Gast-Betriebssystem und ersetzt diese durch Hypervisor-Aufrufe, um Systemdienste wie E/A zu benutzen, hat man praktisch den Hypervisor in Mikrokern transformiert. AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 30

31 9.6 Sicherheit q Was macht Virtualisierungsarchitekturen sicher(er)? Vergleiche bisher gemachte Ausführungen: es existieren: viele getrennte Adressräume (wie z.b. bei Mikrokern-Architekturen) dadurch möglich: 1. bedeutende Einschränkung der Fehlerausbreitung 2. Überwachung der Kommunikation zwischen Teilsystemen möglich sogar: Sandboxing (Verhinderung jeglicher Beeinflussung der Umgebung durch Abfangen entsprechender Versuche) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 31

32 9.7 Robustheit q Was macht Virtualisierungsarchitekturen robust(er)? Vergleiche ebenfalls bisher gemachte Ausführungen: es existieren: viele getrennte Adressräume möglich dadurch: 1. Einschränkung der Fehlerausbreitung 2. Überwachung der Kommunikation AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 32

33 9.8 Adaptivität q Was macht Virtualisierungsarchitekturen adaptiv? Ähnlich wie bei Exokernen: 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 AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 33

34 9.9 Fallbeispiele VM /370 Vmware VirtualBox Xen VMI Paravirt ops virtuelle Maschine für Linux auf Linux (User-Mode-Linux) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 34

35 VMware (Aktuelles Logo) q... ist Unternehmen in Palo Alto, Kalifornien (USA) gegründet 1998 von 5 Informatikern stellt verschiedene Virtualisierungs-Software-Produkte her: 1. VMware Workstation - war erstes Produkt von VMware (1999) - mehrere unabhängige Instanzen von x86- bzw. x Betriebssystemen auf einer Hardware betreibbar 2. VMware Fusion - ähnliches Produkt für Intel Mac-Plattformen 3. VMware Player - (war) Freeware für nichtkommerziellen Gebrauch AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 35

36 VMware 4. VMware Server (früher GSX Server) 5. VMware vsphere (ESXi) Ø Produkte : für Desktop-Systeme Ø Produkte : für Server-Systeme Ø Produkte : benutzen Host-Guest-Architektur (Typ2-Hypervisor) (Bild umseitig) bei VMware-Installation: spezielle vm-treiber in Host-Betriebssystem eingefügt diese ermöglichen: direkten Hardware-Zugriff durch Laden der Treiber: entsteht sog. Virtualisierungsschicht AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 36

37 AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 37 VMware: Host-Guest-Architektur

38 Ø Typ1-Hypervisor-Architektur - Anwendung nur bei Vmware ESX-Server VMware: Bare-Metal -Architektur AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 38

39 VMware: Paravirtualisierung Ø Entsprechende Produkte in Vorbereitung AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 39

40 VirtualBox Virtualisierungs-Software für x86- bzw. x86-64-betriebssysteme für Industrie und Hausgebrauch (ursprünglich: Innotek, dann Sun, jetzt Oracle) (Aktuelles Logo) 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 u. 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. Ø Typ2-Hypervisor-Lösung AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 40

41 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) version 2. 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 Ø bekannt für Paravirtualisierung (Logo) Built for the cloud before it was called cloud. Ø unterstützt heute auch andere Virtualisierungs-Prinzipien (Russel Pavlicek, Citrix) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 41

42 Xen: Architektur Gast-BSe laufen in Xen Domänen es existiert genau eine, obligatorische, vertrauenswürdige Domäne: dom0 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) dom0 Kontroll-Domäne dom1 Gast-BS 1 dom2 Gast-BS 2 dom n Gast-BS n Scheduler Xen Hypervisor MMU Hardware AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 42

43 Xen: Architektur dom0 im Detail: ein separates, hochkritisch administriertes, vertrauenswürdiges BS mit ebensolchen Anwendungen (bzw. Kernelmodulen) zur Verwaltung des gesamten virtualisierten Systems es existieren hierfür spezialisierte Varianten von Linux, BSD, GNU Hurd (!) dom0 Kontroll-Domäne HV-API Treiber dom1 Gast-BS 1 dom2 Gast-BS 2 dom n Gast-BS n Sec. Pol. Linux, BSD (z.b. paravirt.) (z.b. voll virt.) Scheduler Xen Hypervisor MMU Hardware AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 43

44 Xen: Security Security-Mechanismus in Xen: Xen Security Modules (XSM) illustriert, wie (Para-) Typ-1-Virtualisierung von BS die NFE Security unterstützt PDP: Teil des vertrauenswürdigen BS in dom0, PEPs: XSMs im Hypervisor dom0 Kontroll-Domäne dom1 Gast-BS 1 dom2 Gast-BS 2 dom n Gast-BS n Sec. Pol. XSM XSM XSM Scheduler Xen Hypervisor MMU Hardware AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 44

45 Xen: Security Beispiel: Zugriff auf Hardware Security Policy Integration, Administration, Auswertung: dom0 dom0 Kontroll-Domäne dom1 Gast-BS 1 dom2 Gast-BS 2 dom n Gast-BS n Sec. Pol. XSM XSM XSM Scheduler Xen Hypervisor MMU Hardware AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 45

46 Xen: Security Beispiel: Inter-Domänen-Kommunikation Interaktionskontrolle (Aufgaben wie oben): dom0 dom0 Kontroll-Domäne dom1 Gast-BS 1 dom2 Gast-BS 2 dom n Gast-BS n Sec. Pol. XSM XSM XSM Scheduler Xen Hypervisor MMU Hardware AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 46

47 q Unterstützte nichtfunktionale Eigenschaften A. Laufzeiteigenschaften 1. Zuverlässigkeit nichtfunktionierendes Gastbetriebssystem: kann keinen Absturz des Host-Betriebssystems verursachen einfacher: 1. Test der Gastsysteme (sind unabhängige Teilsysteme) 2. Wartung/Modifikation der Gastsysteme 2. Robustheit stark eingeschränkte Fehlerausbreitung, bis hin zu Sandboxing 3. Security (IT-Sicherheit) (vergleiche Bemerkungen zur Robustheit) 9.10 Zusammenfassung AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 47

48 Zusammenfassung q Unterstützte nichtfunktionale Eigenschaften B. Evolutionseigenschaften 1. Wartbarkeit Veränderungen (Beheben von Fehlern, Anpassungen) der Gastsysteme leicht möglich 2. Portierbarkeit Gastsysteme leicht umsetzbar 3. Offenheit u. Erweiterbarkeit neue Gastsysteme einfach hinzufügbar AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 48

49 Zusammenfassung q Unterstützte nichtfunktionale Eigenschaften 4. Sparsamkeit Hardware-Ressourcen: für mehrere bis viele unterschiedliche Aufgaben genutzt (die sonst jeweils eigene Hardware benötigen würden) 5. Effizienz durch Mehrfachnutzung der Hardware: diese auch effizienter genutzt 6. Migrierbarkeit vollständige Gastsysteme: leichter migrierbar als einzelne Prozesse AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 49

50 Zusammenfassung q Weitere Vorteile von Virtualisierungsarchitekturen 1. höhere Modularität 2. Nutzbarkeit von Legacy-Software AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 50

51 q Nachteile von Virtualisierungsarchitekturen Zusammenfassung gewisser Overhead (je nach Virtualisierungsprinzip u. Hardware) AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 51

52 Literatur 1. [Tanenbaum2008] Tanenbaum, Andrew S.: Modern Operating Systems, 3te Auflage Pearson Prentice Hall 2008 ISBN 13 : S und S [Adams2006] Adams, Keith / Agesen, Ole: A Comparison of Software and Hardware Techniques for x86 Virtualization Artikel (aus dem www) 2006 oder später AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 52

53 Literatur IEEE-Zeitschrift Computer (Mai 2005) mit einer Reihe von Beiträgen zur Thematik: S : Figueiredo, R. u.a.: Resource Virtualization Renaissance S.32 38: Smith, James A. / Nair, Ravi: The Architecture of Virtual Machines S Rosenblum, Mendel / Garfinkel, Tal: Virtual Machine Monitors: Current Technology and Future Trends S Uhlig, Rich u.a.: Intel Virtualization Technology AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 53

54 Computer Mai Fortsetzung: Literatur S : Whitaker, Andrew / Cox, Richard S. / Shaw, Marianne / Gribble, Steven D.: Rethinking the Design of Virtual Machine Monitors S.63 69: Ruth, Paul / Jiang, Xuxian / Xu, Dongyan / Goasguen, Sebastian: Virtual Distributed Environments in a Shared Infrastructure ENDE Kap. 9 AOS WS 2017/18 P. Amthor, H.-A. Schindler 9 54