Virtualisierung
Die gedachten Maschinen
Fortsetzung des Artikels von Teil 1
Mikrokernbasierte Virtualisierung
Mikrokerne sind das Resultat eines völlig anderen Ansatzes: Ziel ist die Reduktion der Komplexität von Betriebssystemen. Konzepte, die außerhalb des Kerns (also im nicht-privilegierten Prozessormodus) implementierbar sind, werden nicht als Kernbestandteile geduldet. Ein Mikrokern bietet nur einen kleinen Satz an Mechanismen, auf deren Basis sich Betriebssysteme außerhalb des Kerns realisieren lassen. Diese werden als Server (d.h. nicht-privilegierte Prozesse, die Dienste anbieten) realisiert. Solche Betriebssystem-Server werden im Umfeld von Mikrokernen auch als Personalities bezeichnet.
Die Anforderung ihrer Dienste geschieht über das Senden von Nachrichten, das somit logisch an die Stelle der Betriebssystemaufrufe tritt. Auch Rückgabewerte werden als (Antwort-)Nachrichten transferiert. Die Rolle des Mikrokerns beschränkt sich damit auf das Bereitstellen einer Infrastruktur zum Nachrichtenaustausch. Diese Interprozesskommunikation (IPC) ist der einzig verbleibende Dienst, den ein Mikrokern bietet, wobei neben reinen Nachrichten auch Ereignisse wie Traps und Interrupts oder auch Rechte an Betriebsmitteln übertragen werden können.
Bedenkt man die unterschiedlichen Wurzeln der beiden Ansätze, so ist es bemerkenswert, zu wie ähnlichen Ergebnissen die Mikrokern- und die Hypervisor-Entwicklung schlussendlich geführt haben. Mit Hilfe von Personalities können Laufzeitumgebungen erzeugt werden, die für Anwenderprogramme nicht von einer „nativen“ Betriebssystemumgebung zu unterscheiden sind. So entsteht eine zur Paravirtualisierung vollkommen analoge Konstellation, in der der Mikrokern die Rolle des Hypervisors übernimmt. Sowohl der bereits 1994 entwickelte Lites Server [3] als auch L4Linux [4] – beides Implementierungen einer Unix-Personality auf einem Mikrokern – sind letztlich nichts anderes als paravirtualisierte Betriebssysteme, die schon lange vor der Prägung des Paravirtualisierungsbegriffs entstanden sind.
Isolation trotz gemeinsamer Hardware
Die Möglichkeit, mehrere, voneinander isolierte Subsysteme in einem einzigen gemeinsamen Rechner betreiben zu können, war die ursprüngliche Motivation für die Virtualisierung eingebetteter Systeme. Alle beschriebenen Virtualisierungsformen ermöglichen das Erzeugen mehrerer virtueller Maschinen (VMs) auf einem physischen Rechner. Diese VMs sind vollständig voneinander isoliert: Jegliche Interaktion mit einer von ihnen kann nur über eine durch den Hypervisor bereitgestellte Schnittstelle erfolgen und unterliegt somit dessen Kontrolle (siehe Bild 2). Jede VM hat ausschließlich Zugriff auf eine ihr vom Hypervisor zugewiesene Teilmenge der Betriebsmittel. Eine unkontrollierte Fehlerausbreitung über die Grenzen einer VM hinaus ist damit ausgeschlossen.
Kommunikation
War im Bereich der Serverkonsolidierung allein diese Isolation schon ausreichend, so sind bei eingebetteten Systemen zusätzlich effiziente Mechanismen zur sicheren Kommunikation über die VM-Grenzen hinweg erforderlich, da hier die verschiedenen Teilsysteme gemeinschaftlich zur Funktion des eingebetteten Systems beitragen.
Hypervisor aus dem Serverumfeld besitzen in der Regel nur „nachgerüstete“ Kommunikationsmechanismen wie Pseudo-Netzwerkschnittstellen mit dem entsprechendem Protokoll- Overhead. Bei den Mikrokernen hingegen hat man aus früheren Erfahrungen (z.B. mit dem Mach-Mikrokern) gelernt, weshalb Kerne der zweiten Generation wie L4 oder PikeOS von Grund auf für einen sehr effizienten und sicheren Nachrichtenaustausch konzipiert wurden.
Mithilfe ihrer IPC-Mechanismen können neben einfachen Nachrichten auch Zugriffsrechte, z.B. auf Speicherbereiche, übertragen werden. So können auch gemeinsame Speicherbereiche zur Kommunikation eingerichtet werden. Wichtig ist hierbei, dass sowohl der Sender als auch der Empfänger des Zugriffsrechts einer solchen Transaktion ausdrücklich zustimmen müssen, so dass eine unkontrollierte Beeinflussung eines Subsystems durch ein anderes ausgeschlossen ist.
Jobangebote+ passend zum Thema
Architekturunabhängigkeit
Server- und Desktop-Maschinen werden heute weitgehend von der 32-bit-Intel-Rechnerarchitektur dominiert, weshalb Virtualisierungslösungen wie z.B. VMware großen Aufwand auf die Kompensation der Einschränkungen dieser Architektur in Bezug auf Virtualisierung verwenden. Bei eingebetteten Systemen gibt es hingegen keine derart dominante Architektur.
Der große Vorteil der „Just-in-time“-Paravirtualisierung von VMware, unmodifizierte Betriebssystemkerne weiterverwenden zu können, verliert so bei eingebetteten Systemen viel von seiner Attraktivität: Diese Technik ist ausschließlich auf die IA-32-Architektur anwendbar. Gleiches gilt auch für die Vollvirtualisierung, die durch die neueren Prozessorvarianten mit Virtualisierungs- Support machbar wird. Bei den meisten Embedded-Entwicklungen liegt der Betriebssystem-Quellcode ohnehin vor, so dass einer Paravirtualisierung nichts im Wege steht. Vor diesem Hintergrund bringen die Voll- wie die „Just-in-time“-Paravirtualisierung gegenüber der statischen Paravirtualisierung nur Portabilitäts- und Geschwindigkeitsnachteile, aber keinerlei Vorteile mit sich. Im Sinne der Architekturunabhängigkeit wäre demnach der Paravirtualisierungsansatz zu bevorzugen.
Trusted Code Base
Bei jeder sicherheitskritischen Anwendung muss sämtlicher Code, dessen korrekte Funktion die Anwendung voraussetzt, einer eingehenden Prüfung unterzogen werden. Zu dieser Trusted Code Base zählt stets auch der Code, der im privilegierten Modus arbeitet (d.h. in einem Virtualisierungssystem: der Hypervisor). Da der Prüfaufwand in etwa proportional zum Umfang des zu prüfenden Codes steht, sollte ein Hypervisor in einem sicherheitskritischen System stets so klein wie möglich sein.
Die meisten der für Serveroder Desktop-Anwendungen konzipierten Hypervisor berücksichtigen diesen Aspekt nicht. So umfasst beispielsweise der Xen Hypervisor allein bereits etwa 100.000 Zeilen Code, benötigt aber zum Arbeiten zusätzlich eine privilegierte virtuelle Maschine („Domain 0“), in der ein vollständiges Linux-System mit einem Quellcode- Umfang von mehreren Millionen Zeilen arbeitet. Die Trusted Code Base eines Xen-basierten Systems ist damit entschieden zu groß für eine umfassende Validierung, geschweige denn für einen formalen Korrektheitsbeweis. Mikrokerne der zweiten Generation wie PikeOS oder L4 liegen hier mit etwa 10.000 Zeilen Code in einer völlig anderen Größenordnung, so dass sogar eine formale Verifikation in greifbare Nähe rückt (Bild 3) [5, 6].
Unnötige Funktionen
Der deutlich geringere Code-Umfang von beispielsweise PikeOS im Vergleich zu Xen hat zum Teil konzeptionelle Gründe, wie den Verzicht auf eine privilegierte VM. Zum Teil liegt er aber auch in einem größeren Funktionsumfang des Hypervisors gegenüber dem Mikrokern begründet. So bietet Xen eine Reihe von Funktionen wie z.B. Live Migration, die bei eingebetteten Systemen in der Regel nicht benötigt werden. Es handelt sich hier um Strategien, die entsprechend dem Mikrokern-Paradigma der Trennung von Strategie und Mechanismus nicht in den Kern gehört hätten. Nun, da sie Teil des Hypervisors sind, tragen sie zur Trusted Code Base bei, auch wenn ihre Funktionen nicht genutzt werden.
- Die gedachten Maschinen
- Mikrokernbasierte Virtualisierung
- Virtualisierung und Echtzeit-Fähigkeit
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
