16.3 Grundsätzlicher Aufbau
Den Segmenten des Hauptspeichers kann jeweils ein Privilegien-Level zugeordnet werden. Um sich diese Segmentierung und Aufteilung in vier Level besser vorstellen zu können, entwickelte man die Vorstellung von Ringen. Jeder Prozess kann immer nur in einem einzelnen Ring ausgeführt werden. Dabei ist ihm nicht erlaubt, aus diesem Ring auszubrechen. Die Ringe werden dadurch unterschieden, dass jeder Ring dem in ihm laufenden Prozess nur einen Teil des CPU-Befehlssatzes zur Verfügung stellt.
Prozessoren der x86-Architektur stellen vier solcher Ringe zur Verfügung. Diese werden von 0 bis 3 nummeriert. Hierbei stellt Ring 0 den uneingeschränkten Zugriff auf die CPU dar (Supervisor-Mode) und Ring 3 den Level mit der größten Einschränkung (siehe Abbildung 16.3).
- Ring 0 ist üblicherweise die Heimat des Kernels und bildet daher auch den sogenannten Kernel-Space. Man nennt diesen Ring auch Supervisor-Mode.
- In Ring 3 hingegen laufen die Anwendungen, deshalb bildet Ring 3 den sogenannten User-Space.
Nun stellt sich die Frage, welche Prozesse in den Ringen 1 und 2 ihr virtuelles Zuhause finden. Die Antwort ist einfach: keine. Der Grund ist, dass andere aktuelle Prozessorarchitekturen nur zwei Ringe unterscheiden. Damit Anwendungen leichter portiert werden können, entschied man sich dafür, zwei der ursprünglich vier Ringe nicht zu nutzen. Eine Ausnahme stellt hier OS/2 dar.
Abbildung 16.3 Ringmodell – Ring 0 ist der Supervisor-Mode und stellt den uneingeschränkten Zugriff auf den Befehlssatz der CPU dar. Je höher die Ringnummer ist, desto eingeschränkter ist der Zugriff.
16.3.1 Generelles Problem bei der x86-Virtualisierung
Soll ein Hypervisor ein Betriebssystem kontrollieren, das standardmäßig in Ring 0 läuft, ergibt sich ein generelles Problem: Um das Betriebssystem kontrollieren zu können, muss der Hypervisor selbstverständlich in einem Ring laufen, der mehr Rechte besitzt als das Betriebssystem. Das Betriebssystem wiederum ist so konzipiert, dass es auf Ring 0 laufen muss (manche Instruktionen des Betriebssystems erfordern dies).
Und genau in diesem Zwiespalt liegt das Problem, weshalb ein x86-Prozessor ohne spezielle Virtualisierungsunterstützung nicht effektiv virtualisiert werden kann: Das Betriebssystem läuft bei der Virtualisierung in der Regel auf Ebene 3, und deshalb gibt es Befehle, bei denen es zu Problemen kommt.
Probleme heißt in diesem Fall, dass sich ein Befehl je nach Ring, in dem er ausgeführt wird, unterschiedlich verhält. Ich komme auf diese Probleme in Abschnitt 16.3.3, »Machtmissbrauch«, noch einmal zurück.
16.3.2 Möglichkeiten der x86-Virtualisierung
Auch wenn die x86-Architektur alles andere als optimal für Virtualisierungszwecke ist, wurde aufgrund ihrer hohen Verbreitung sehr viel Arbeit in die Entwicklung von x86-Virtualisierung investiert. Diese Arbeit trug im Laufe der Zeit ihre Früchte. Dabei werden folgende Techniken und Vorgehensweisen verwendet:
- Emulation
Jedes Stück Hardware wird von der Software simuliert. Dies ermöglicht zwar eine saubere Virtualisierung und eine große Zahl von unterstützten Hardwarekomponenten, erfordert allerdings viel Rechenleistung bei der Ausführung und einen hohen Implementierungsaufwand, da für jedes Stück Hardware ein Simulator und die Abbildung auf die reale Hardware geschrieben werden muss (von Fehlern im Simulator und davon ausgehenden Sicherheitsrisiken ganz zu schweigen). - Paravirtualisierung
Hierbei wird Betriebssystemen durch den Hypervisor eine Softwareschnittstelle bereitgestellt, die ähnlich wie die, aber nicht identisch mit der Hardwareschnittstelle ist. Konkret heißt das, dass der Hypervisor auf Ebene 0 läuft und das Betriebssystem so angepasst wird, dass es ohne Probleme auf Ebene 1 oder 3 laufen kann.Dadurch kann der Hypervisor schlanker sein, und es ergibt sich eine höhere Performance (es muss beispielsweise bei einem portierten Betriebssystem nicht für jede Instruktion geprüft werden, ob sie eine Aktion durchführen möchte, die nur auf Ring 0 erfolgreich sein kann). Allerdings ist das Anpassen des Betriebssystems aufwendig und bei proprietären Betriebssystemen ohne offenen Quellcode schlicht unmöglich.
- Binary Translation
Die aufwendigste Art der Virtualisierung ist die Binary Translation. Hierbei überprüft der Hypervisor für jede Instruktion des Betriebssystems, ob sie die Virtualisierung beeinflusst oder ob Probleme bezüglich der Rechte auftreten. Ist dies der Fall, so ersetzt der Hypervisor diese Instruktion durch eine Folge anderer Instruktionen. Dass dies einen sehr hohen Verwaltungsaufwand mit sich bringt, ist offensichtlich.
16.3.3 Machtmissbrauch
Wenn ein Prozess in einem wenig privilegierten Ring eine Operation ausführt, zu der ihm die nötigen Privilegien fehlen, wird von der CPU eine sogenannte Exception erzeugt. Diese Exception wird im Normalfall an einen privilegierteren Ring weitergegeben. Routinen zur Behandlung dieser Exceptions können den privilegierten Befehl emulieren. Um dies aber effizient zu bewerkstelligen, sind jetzt erheblich mehr Instruktionen erforderlich.
Dieser Umgang mit Exceptions verlangsamt zwangsläufig das System. Misslingt er, kommt es zu einem General Protection Fault. Als Folge davon stürzt der initiierende Prozess ab. Wenn der Initiator der Kernel selbst ist, stürzt das gesamte System ab.
Exceptions
Die wichtigste Voraussetzung für das Funktionieren dieses Ansatzes ist also, dass der Prozessor bei jeder unberechtigt durchgeführten privilegierten Anweisung eine Exception auslöst. Allerdings sind die x86-Prozessoren nicht ganz so gründlich bei den Exceptions. Beispielsweise werden Speicherzugriffe beim x86 über eine GDT (Global Descriptor Table) abgewickelt. Diese GDT ist eine globale Ressource und wird vom Betriebssystem verwaltet. Eigentlich müsste jeder direkte Zugriff auf diese Ressource als privilegierte Handlung angesehen werden und dürfte dementsprechend im User Mode nicht erlaubt sein. Der x86 behandelt die LGDT+SGDT-Anweisung (Load Global Descriptor Table) auch als privilegiert. Allerdings führt SGDT (Store Global Descriptor Table) nicht zu einer Schutzverletzung.
Allein diese Inkonsistenz verhindert es, die GDT zu virtualisieren. Intels Virtualization Technology greift hier ein und erleichtert unter anderem auch das Exception-Handling. VM-Software mit Virtualization-Technology-Support lässt sich somit einfacher programmieren und bietet gleichzeitig eine höhere Betriebssicherheit und Stabilität.
16.3.4 Ungenutzte Ringe
In nicht virtualisierten Systemen laufen sowohl der Kernel als auch sämtliche Hardwaretreiber in Ring 0, während die Anwendungen in Ring 3 arbeiten. Ring 1 und 2 bleiben ungenutzt, und genau dies machen sich manche Voll-Virtualisierungslösungen wie beispielsweise VMware zunutze: Die Gäste werden in einem nicht genutzten Ring ausgeführt.
Kommt es hierbei zu Exceptions, werden diese vom VMM (Virtual Machine Manager) in Ring 0 und nicht vom Gast ausgeführt. Xen, um ein weiteres Beispiel zu nennen, arbeitet nach dem gleichen Prinzip und setzt den Hypervisor in Ring 0. Abbildung 16.4 soll diese Wirkungsweise veranschaulichen.
Hypercalls
Hypercalls sind die Befehle, um die Xen den Befehlssatz der x86-Architektur erweitert hat. Sie entsprechen in ihrer Funktionsweise den UNIX-System-Calls:
- Wenn ein Prozess im User-Space eine privilegierte Operation ausführen möchte, ruft er einen UNIX-System-Call auf.
- Ebenso wird ein Hypercall aufgerufen, wenn ein Gastsystem eine privilegierte Operation ausführen möchte.
Der Kernel wandert gleichzeitig von Ring 0 in einen weniger privilegierten Ring. Je nach Architektur des zugrundeliegenden Systems kann dies Ring 1 oder 3 sein.
Abbildung 16.4 Nutzung der Ringe durch »Xen«, hier dargestellt an einer 32-Bit-CPU
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
