Vortrag zum Seminar Konzepte und Techniken virtueller Maschinen und Emulatoren. Bruno Kleinert 20. Juni 2007

Transkript

1 User Mode Linux (UML) Vortrag zum Seminar Konzepte und Techniken virtueller Maschinen und Emulatoren Friedrich-Alexander-Universität Erlangen-Nürnberg Bruno Kleinert 20. Juni 2007

2 Überblick Was ist UML? Architektur Probleme und Lösungen UML Verbesserung User Mode Linux 2

3 Was ist UML? Linux Kernel Patch Portierung von Linux auf Linux Idee ist nicht neu IBM hat Linux vorher schon auf S/390 portiert User Mode Linux 3

4 Was tut UML? aus technischer Sicht wird nicht die Hardware virtualisiert... sondern eher das Betriebssystem Kernel wird als normaler Prozess ausgeführt Mehrere UML Prozesse können auf einer Maschine laufen User Mode Linux 4

5 Einordnung in Virtualisierungstechniken Mischung Paravirtualisierung und Virtualisierung auf BS-Ebene Paravirtualisierung Zwingend notwendige Modifikation des Gastsystems native Code-Ausführung Wirtkernel entspricht einem VMM BS-Ebene Gerätetreiber API für Gast = Systemaufrufe Partitionierung der Wirtmaschine User Mode Linux 5

6 Aufbau von UML Gastsystem telnetd ftpd ircd Wirtsystem Architekturunabhängige Schicht UML Architektur allg. Treiber Architekturunabhängige Schicht Architekturabhängige Treiber allg. Treiber Reale Hardware User Mode Linux 6

7 UML Architektur hauptsächlich hardwarespezifische Treiber mussten portiert/ersetzt werden Hardware E/A des Linux Kernels wird auf Systemaufrufe am Wirtkernel abgebildet bis auf Gerätetreiber bleibt ein (fast) vollwertiger Linux Kernel erhalten Ungelöst: E/A (z.b. inb/outb in Anwendungsprogrammen ist nicht möglich) User Mode Linux 7

8 Zu lösende Probleme Bei einer Unterbrechung, die von einem Prozess eines Gastsystems ausgelöst wird, übergibt die CPU die Kontrolle an den Kernel des Wirtsystems. Diese Unterbrechung muss aber von UML behandelt werden. User Mode Linux 8

9 Zu lösende Probleme Betrifft Systemaufrufe Traps, Interrupts ( Signale) User Mode Linux 9

10 Tracing Thread zu jedem Prozess im Gastsystem existiert ein Prozess im Wirtsystem dient als Ausführungskontext für Prozesse des Gastsystem zusätzlich läuft im Wirtsystem der sog. Tracing Thread verfolgt Systemaufrufe der Prozesse in UMLs und denen zugestellte Signale User Mode Linux 10

11 Tracing Thread UML init PID: 1 UID: root bash PID: 7 UID: foouser linux PID: 42 UID: baruser linux PID: 23 UID: baruser Tracing Thread Wirtsystem verfolgt Systemaufrufe User Mode Linux 11

12 Normaler Systemaufruf Prozess löst Systemaufruf aus (int 0x80 auf IA32) Prozessorstatuswort wird auf aktuellem Stack gespeichert CPU übergibt Kontrolle an den Kernel Kernel behandelt Systemaufruf, setzt Rückgabewert Kernel stellt Prozessorstatuswort wieder her Kernel übergibt Kontrolle zurück an den Aufrufer User Mode Linux 12

13 Problem bei UML CPU übergibt bei einem Systemaufruf die Kontrolle an den falschen Kernel (Wirtskernel) Behandlung soll aber in UML stattfinden! User Mode Linux 13

14 Virtualisierung von Systemaufrufen Behandlung eines Systemaufrufs eines Prozesses in der UML Umgebung 1.Prozessorstatuswort speichern 2.Systemaufruf annullieren 3.Behandlung muss auf UML Stack stattfinden 4.Kontrolle an UML übergeben 5.Systemaufruf Rückgabewert setzen 6.Prozessorstatuswort wiederherstellen User Mode Linux 14

15 Tracing Thread - ptrace() Behandlung mit Hilfe des Tracing Threads benutzt ptrace() Systemaufruf zur Überwachung gewöhnlich von Debuggern verwendet Schema: Vaterprozess überwacht Kindprozess Ausführung des Kindprozesses wird bei jeder Signalzustellung angehalten (außer SIGKILL) Vaterprozess (Tracing Thread) wird per wait() informiert und kann Kindprozess analysieren und modifizieren User Mode Linux 15

16 Virtualisierung von Systemaufrufen Gastsystem Prozess Stack UML Stack Tracing Thread int 0x80 Bearbeitet Systemaufruf stellt sich selbst Signal zu Weiter gehts annulliert Systemaufruf Speichert Prozessorstatuswort Prozessorstatuswort wiederherstellen Rückgabewert setzen User Mode Linux 16

17 Behandlung von Traps, Interrupts und Signalen wird von Tracing Thread analog der Behandlung von Systemaufrufen übernommen und in UML geleitet FPU Exception ( SIGFPE) Illigal Instruction ( SIGILL) usw. User Mode Linux 17

18 Virtueller Speicher Physischer Speicher wird durch eine temporäre Datei im Wirtsystem emuliert Datei wird vollständig in den UML Adressraum eingeblendet (mmap()) wird von UML in Prozessadressräume und in den eigenen virtuellen Adressraum eingeblendet User Mode Linux 18

19 Adressraumorganisation Identisch zu realem System Code Segment Text Segment Dynamische Bibliotheken (Wirt-)Kernel Adressraum Nicht identisch zu realem System Prozess Stack liegt ½ GB tiefer um Platz darüber für UML selbst zu schaffen User Mode Linux 19

20 Hardware E/A in UML Austauschen von Assembler Instruktionen zum Zeitpunkt des Kompilierens Ermöglicht den Einsatz unmodifizierter Gerätetreiber im Gast Einsetzen: ja, Funktionieren:??? x86 BIOS Funktionen größtenteils durch UML emuliert User Mode Linux 20

21 Scheduling in UML Zur Erinnerung: Prozesse in UML sind Prozesse im Wirtsystem! Problem: UML kann Prozesse nicht selbst ein- und auslagern ircd ftpd?!? ircd ftpd UML Scheduler Wirtkernel Scheduler User Mode Linux 21

22 Indirektes Scheduling Wirtsystem zum Prozesswechsel bringen jeder Prozess öffnet eine Pipe und lauscht an ihr auszulagernder Prozess schreibt ein Byte in die Pipe des einzulagernden Prozesse... und startet selbst ein read() auf die eigene Pipe einzulagernde Prozess wird zum Lesen des Bytes aus seiner Pipe aufgeweckt Prozess der von Pipe lesen will, muss (vom Wirtkernel) aufgeweckt werden User Mode Linux 22

23 Bisher inperformante Implementierung Inperformante Bearbeitung von Systemaufrufen Viele Kontextwechsel Ressourcenverschwendung bei der Speicherverwaltung Prozesse im Wirtsystem werden nur deswegen benötigt um einen Adressraum zu bereitzustellen Inperformantes Scheduling schon wieder viele Kontextwechsel in Prozesse eingeblendeter UML Adressraum war (standardmäßig) schreib (!) und lesbar sicherheitskritisch User Mode Linux 23

24 Erweiterung von UML: SKAS Modus SKAS: Separate Kernel Adress Space User Mode Linux 24

25 SKAS Modus Erfordert Modifikation des Wirtkernels UML bekommt dedizierten Adressraum im Wirtsystem im Gegensatz zu normalen Prozessen automatischer Wechsel in Kerneladressraum bei Zustellung eines Signals Tracing Thread ist hierfür nicht mehr notwendig Adressraum von UML Prozessen gleicht normalem Adressraum über den Adressraum ist es nicht mehr möglich zu erkennen, ob ein Prozess virtualisiert ist User Mode Linux 25

26 Nachteile von UML Virtualisierung ist erkennbar (trotz SKAS Modus) Inperformante Behandlung von Systemaufrufen ohne SKAS Modus können Kernelstrukturen von Prozessen einfach gelesen (und standardmäßig sogar geschrieben!) werden frickelige Installation des Gastsystems (Installationsroutinen fallen häufig auf die Nase) User Mode Linux 26

27 Vorteile von UML trotz vieler Verschwendung dennoch geringer Speicherverbrauch erleichtert Fehlersuche bei plattformunabhängigen Kernelroutinen flexibel für Hosting Einsatz Netzwerkanbindung Dateisysteme User Mode Linux 27

28 Fragen? User Mode Linux 28

29 Quellen J. Dike (2002) User-mode Linux slides/wvu2002/wvu2002.htm J. Dike (2002) Blurring boudnaries with User-mode Linux slides/lca2002/lca2002.htm J. Dike (2002) Making Linux safe for virtual machines slides/ols2002/ols2002.html User Mode Linux 29