Mobile-Menu

Hypervisor

Jailhouse: Ein Hypervisor für Multi-Core, Embedded und Echtzeit

Seite: 3/4

Anbieter zum Thema

Linutronix GmbH
MicroConsult Academy GmbH

Wenn Ihr bisheriges System eine Migration auf eine „Teil-CPU“ nicht zulässt und Sie auch keinen Zugriff auf den Code haben, so ist das kein Beinbruch. Sie können für diesen Fall entweder in einer VM einen Hypervisor wie kvm (Virtualisierungslösung unter Linux) und einen Emulator (Qemu) laufen lassen oder Sie partitionieren Ihr SoC bereits von Anfang an in einen Teil mit kvm und Qemu und einen Teil mit Jailhouse. In beiden Fällen können Sie Ihre bisherige Lösung, etwa für das HMI, wiederverwenden.

Der Ansatz von Jailhouse, die Hardware-Ressourcen für die Virtualisierung zu nutzen, erlaubt einen sehr schlanken Hypervisor. Seine Codegröße und damit die Trusted Code Base (TCB) liegt sowohl für x86- als auch für ARM-basierte Systeme unter 10k LoC. Der zweite Vorteil ist die komplette Abschottung der Cells untereinander. Im Falle eines Angriffs auf eine VM ist dies ein großer Vorteil, da alle anderen Zellen davon nicht betroffen sind und eine Ausbreitung auf andere Zellen nicht möglich ist.

Virtualisierung und Systemsicherheit

Zum Thema Sicherheit gehört aber auch, dass man eine vertrauenswürdige Kette von Software besitzt, vom First Stage Bootloader (FSBL) über den eigentlichen Bootloader bis hin zu den Systemen, die in einer VM laufen. Die Kette aus FSBL, Bootloader wie Uboot, Linux usw. kann signierte Module erzeugen und verwalten. Damit kann sichergestellt werden, dass nur vertrauenswürdige und authentifizierte Software ausgeführt wird.

Für den Fall, dass eine rein softwaremäßige Absicherung nicht ausreicht, können Hardware-basierte Methoden wie TPM oder Trust Zone zusätzlich genutzt werden. Sorgt man dafür, dass ein Update der System-Software auch nur mit signierter Software erfolgen kann, so bekommt man ein sicheres System. Weitere Möglichkeiten zur Erhöhung der Sicherheit wie ständige Selbstüberwachung der „root cell“ sind denkbar. Es liegt am Kunden und am Einsatzfall, um zu entscheiden, welches Sicherheitsniveau erreicht werden muss und damit auch, welcher Aufwand investiert werden soll.

Wichtig: Der Einsatz des Hypervisors schließt die Verwendung von Technologien wie Trustzone nicht aus!

Ergänzendes zum Thema
Eine Übersicht über Hypervisor-Typen

Begonnen hat es in den sechziger Jahren des letzten Jahrhunderts, als IBM mit den ersten Forschungsarbeiten über virtuelle Maschinen auf dem Mainframe-Rechner IBM 360 begann. Um die virtuellen Maschinen verwalten zu können, wurde der Virtual Machine Manager (VMM), auch Hypervisor genannt, eingeführt.

1974 veröffentlichten Popek und Goldberg eine Arbeit [1], die wesentliche Eigenschaften eines Hypervisors definiert und seitdem Gültigkeit besitzt. Danach muss ein Hypervisor in der Lage sein, eine virtuelle Umgebung mit folgenden Eigenschaften zur Verfügung zu stellen:

  • Wiedergabegenauigkeit: eine Software, die in einer virtuellen Maschine (VM) ausgeführt wird, muss sich genauso verhalten, als wenn sie auf der physikalischen Hardware ausgeführt werden würde
  • Das Ergebnis der Ausführung einer Software in einer virtuellen Maschine darf sich nicht von dem Ergebnis bei einer Ausführung auf der physikalischen Hardware unterscheiden
  • Leistungsfähigkeit: die Mehrheit der Instruktionen des Gastsystems werden ohne Eingriff des Hypervisors von der Hardware ausgeführt
  • Sicherheit: Der Hypervisor managt alle verfügbaren Hardware-Ressourcen.

Goldberg hat in seiner Doktorarbeit von 1972 (Principles for Virtual Computer Systems) die noch heute gültige Unterscheidung von Hypervisoren nach der Art und Weise, wie sie auf einer Hardware installiert werden, in Type I und Type II eingeführt.

  • Ein Typ-1-Hypervisor (native oder bare-metal) setzt direkt auf der Hardware auf und benötigt keine vorherige Betriebssystem-Installation. Das setzt allerdings voraus, dass die Hardware des Hostsystems vom Typ-1-Hypervisor durch entsprechende Treiber unterstützt wird. [2]
  • Ein Typ-2-Hypervisor (hosted) setzt auf einem vollwertigen Betriebssystem, auf dem Hostsystem, auf und nutzt die Gerätetreiber des Betriebssystems, um auf die Hardware des Hostsystems zuzugreifen. Typ-2-Hypervisoren sind daher auf allen Hostsystemen lauffähig, auf denen vom Hypervisor unterstützte Hostbetriebssysteme lauffähig sind. [2]

Typ-1- und Typ-2-Hypervisoren können noch weiter unterteilt werden in Voll-Virtualisierung, Para-Virtualisierung und Dynamic-Binary-Translation- (DBT) Techniken. Bei einer vollständigen Virtualisierung präsentiert der Hypervisor jedem Gastsystem, unabhängig von der realen Hardware des Host-Systems, eine emulierte Hardware. Bei einer Para-Virtualisierung wird das Gastsystem so geändert, dass es nunmehr nicht mehr mit der realen Hardware, sondern nur noch mit dem Hypervisor kommuniziert.

Das hat den Vorteil, dass nicht für jede VM eine HW emuliert werden muss, das System wird dadurch deutlich performanter. Ein idealer Ansatz für Serversysteme, bei denen mehrere VMs gleichzeitig laufen sollen.

Daneben gibt es noch Betriebssystem-Virtualisierungen, bei dem das Betriebssystem die Hardware in virtuelle Maschinen aufteilt, in denen diese nur ihre eigenen Daten mitzubringen haben, also ähnlich wie bei einer Container Lösung.

Quellen:

[1] G. J. Popek and R. P. Goldberd, “Formal requirements for Virtualizable Third-Generation Architectures,” Communications of the ACM, 1974.

[2] Quelle: https://de.wikipedia.org/wiki/Hypervisor

Echtzeit-Eigenschaften unter Jailhouse

Nicht nur das Design des Hypervisors kann die Echtzeiteigenschaften beeinflussen. Auch die Hardware muss bei modernen CPUs in Betracht gezogen werden. Um etwa die Energiebilanz eines SoCs zu verbessern, wie es bei einem batteriebetriebenen System notwendig sein mag, haben die CPU Hersteller viele intelligente Details in ihre Systeme integriert. Dazu gehören beispielsweise die Reduzierung der CPU Frequenz, die Reduzierung von CPU Spannungen oder das Schlafenlegen der CPUs. Oder das Übertakten eines Cores, während gleichzeitig ein anderer Core verlangsamt wird. Und das kann, wenn das Echtzeitsystem auf diesem zweiten Kern läuft, schlecht für die Latenz des Systems sein. Der Hypervisor muss also ein solches schädliches Verhalten verhindern und auch alle anderen Möglichkeiten eines modernen SoCs abschalten, die negativen Einfluss auf die Reaktionsfähigkeit haben könnten.

Wenn der Hypervisor nicht eingreifen muss, wie es bei Jailhouse der Fall ist, wenn das Echtzeitbetriebssystem in einer sauber konfigurierten VM läuft und damit auch auf einer oder mehreren nur dem RTOS zugeordneten CPUs, dann sollte das zu Ergebnissen führen, die optimal sind. Und in der Tat zeigen unsere Messungen, dass auf einem x86 System der Unterschied in der Latenz zwischen einem echtzeitfähigen Linux in der „root cell“ und in der VM nur gut 1 Mikrosekunde beträgt [siehe Bild 4]. Ein vernachlässigbarer Wert. Und das bei einem RTOS, das voll gekapselt ist und unter kompletter Kontrolle des Hypervisor bzw. der Hardware ausgeführt wird. Echtzeit ist also in einer virtuellen Maschine darstellbar bei gleichzeitiger maximaler Sicherheit des Systems.

Die Latenzmessung erfolgte mit dem Programm cyclictest, das im Linux-Umfeld inzwischen generell als Messverfahren zur Feststellung von Latenzen bei zyklischen Anwendungen zum Einsatz kommt und anerkannt ist. Um einen realistischen Messwert zu erhalten, wird das System mit dem Tool hackbench mit einer hohen Last beaufschlagt (rund 1600 Prozesse kommunizieren ständig untereinander, damit auch die CPU-Cachespeicher immer neu gefüllt werden müssen und dergleichen).

Cyclictest setzt zyklisch verschiedene Timer auf und misst kontinuierlich die Abweichung zum gewünschten Aufwachzeitpunkt. Hiermit wird der komplette Codepfad abgedeckt, der auch für jeden anderen Interrupt relevant ist (Timer-Interrupt schlägt zu und in der Folge muss eine Applikation aufgeweckt werden). Daher sind die gemessenen Latenzen mit denen anderer physikalischer Interrupts, wie zum Beispiel von einem GPIO, vergleichbar.

Artikelfiles und Artikellinks

(ID:44453370)

Weiterführende Inhalte