Fest verbaut: ein Hypervisor für Multi-Core, Embedded und Echtzeit

Was ist Jailhouse?

| Autor / Redakteur: Heinz Egger* / Franz Graser

Bild 1: Systemkonsolidierung mit dem Jailhouse-Hypervisor. Für jede „Cell“, in der ein Gastsystem residiert, ist mindestens ein Prozessorkern erforderlich.
Bild 1: Systemkonsolidierung mit dem Jailhouse-Hypervisor. Für jede „Cell“, in der ein Gastsystem residiert, ist mindestens ein Prozessorkern erforderlich. (Bild: Linutronix)

Auch im Embedded-Umfeld lassen sich viele Vorteile der Hypervisor-Technik anwenden. Die Open-Source-Software „Jailhouse“ hat hierfür zahlreiche Trümpfe im Ärmel.

In den vergangenen Jahren sind IT-Technologien immer schneller in der Industrie akzeptiert worden. Bei dem Thema Hypervisor (oft auch Virtual Machine Manager, kurz VMM, genannt) hat es dennoch etwas gedauert.

Hypervisor werden seit ihrem ersten Auftreten in den 70er Jahren des letzten Jahrhunderts in Type I (bare–metal) und Type II (host based hypervisor) Lösungen unterschieden. Beiden Ansätzen gemein ist, dass sie virtuelle Maschinen für die einzelnen Gastsysteme vorhalten. Dazu benötigen sie Emulationen der Hardware, um jedem Gastsystem ein vollständiges Hardware-System zur Verfügung stellen zu können.

Hypervisor-Lösungen in der IT erlauben es, Systeme einfach zu skalieren, zu migrieren und zu portieren. Damit können die IT-Systeme dynamisch an die aktuelle Lastsituation angepasst werden und bei Problemen an der HW oder dem Einsatz neuerer Hardware einfach „umziehen“, also auf die neue Hardware übertragen werden.

Nebenbei wird die Sicherheit verbessert, da alle virtuellen Systeme untereinander abgeschottet sind. Alte Software kann länger genützt werden, da sie nun in einer eigenen virtuellen Maschine weiterhin auf der neuen Hardware zum Einsatz kommen kann.

Warum Virtual Machine Manager einsetzen?

Im Embedded-Bereich können viele dieser Vorteile ebenfalls genutzt werden. Bisher auf unterschiedliche Hardware verteilte Lösungen können auf eine Maschine konsolidiert werden. Alte Systeme (bare metal oder alte Betriebssysteme) können weiterhin genutzt werden, HMI (GUI), Echtzeit und SPS oder zertifizierte Programme können nebeneinander auf einer Hardware zum Einsatz kommen. Der Einsatz von dynamischer Lastverteilung ist bei Echtzeitanforderungen allerdings kontraproduktiv.

Die vornehmlich das Thema Security betreffenden Anforderungen aus dem IoT-Umfeld an Embedded-Systeme können mit dem Virtualisierungsansatz gelöst werden, ohne dass die zugrundeliegende Embedded-Applikation neu erstellt werden müsste. Und durch die Aufteilung in mehrere virtuelle Maschinen hat man auch die Probleme, die bei einer Anwendung mit zertifizierter und daher nicht einfach änderbarer Software auf der einen Seite und den ständigen Update-Anforderungen auf der IoT-Seite aufkommen, elegant gelöst.

Welche Hypervisor-Typen gibt es?

Seit den ersten Hypervisor-Lösungen werden diese prinzipiell in zwei große Kategorien, Type I und II, unterteilt. Hier eine kurze Beschreibung der beiden Typen:

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

Type-I-Hypervisoren (bare-metal) laufen direkt auf der Hardware und benötigen daher eine komplette Unterstützung sämtlicher vorhandener physikalischer Schnittstellen auf dem SoC. Denn hier ist es der Hypervisor, der die Hardware initialisieren muss und in Betrieb nimmt.

Es wundert daher nicht, dass hier oft Mikrokernel-Lösungen wie beispielsweise L4 zum Einsatz kommen. Nur so lässt sich die komplexe Aufgabenstellung einigermaßen sinnvoll lösen. Type-I-Hypervisoren können zwar die Hardware-basierten Unterstützungen nutzen, die Intel-VT oder AMD-V bieten, aber spätestens bei der Nutzung von virtuellen CPUs oder anderen virtuellen Geräten muss der Hypervisor aktiv werden und die Ressourcen verwalten und zuteilen.

Und das verursacht eine zusätzliche, durch die Software bedingte Latenz im System. Bei Industriesystemen, die auf Echtzeitverhalten (sprich: eine verlässliche, deterministische Reaktion) angewiesen sind, ist das kontraproduktiv. Auch ist die Skalierbarkeit beziehungsweise Portierbarkeit bei derartigen Type-I-Hypervisoren aufgrund Ihrer Komplexität eingeschränkt oder mit hohem Aufwand verbunden.

Type-II-Hypervisoren setzen im Gegensatz dazu auf einem Host-Betriebssystem (BS) auf. Das vereinfacht den Hypervisor und verleiht ihm eine einfachere Portierbarkeit, sofern das Host-OS einfach zu portieren ist oder bereits auf vielen Systemen unterstützt wird. Allerdings müssen hier Zugriffe auf die Hardware, sofern nicht durch die Hardware direkt auf das Gast-OS routbar, durch das Host-OS behandelt werden.

Virtuelle CPUs und I/O-Devices benötigen auch hier ein Scheduling, um den Zugriff durch die diversen Gast-Betriebssysteme zu regeln. Auch hier gilt, was schon bei den Type-I-Hypervisor-Lösungen in Bezug auf die Echtzeit gesagt wurde: dieses Verhalten ist kontraproduktiv, da es zusätzliche Verzögerungen (Latenzen) einführt und so den Jitter des Systems vergrößert.

Anpassungen im Gastbetriebssystem

Ein Weg, um Echtzeit-Verhalten im Gast zu erreichen, wäre es, das Gast-OS so anzupassen, dass es nicht alle Hardware benötigt und ihm die benötige Hardware exklusiv zur Verfügung zu stellen. Das geht nur bei Betriebssystemen, auf deren Quellcode man Zugriff hat oder die per se so konfigurierbar wären. Das komplette Gast-OS wäre nun außerhalb des Zugriffes des Hypervisors. Bei diesem Ansatz würde man die Vergrößerung der Latenzzeiten durch weitere (Verwaltungs-)Software vermeiden.

Der Nachteil bei diesem Ansatz ist, dass ein Monitoring dieses Gastsystems nicht mehr gegeben ist. Im Kontext von Security und Safety ein nicht akzeptabler Zustand, da dieser Gast vollkommen unkontrolliert auf dem SoC laufen würde und ein nicht autorisierter Zugriff auf ein Gerät nicht erkannt werden würde.

Zusammengefasst: Betrachtet man die spezifischen Anforderungen eines Embedded- (Industrie-) Systems und die Erwartungen an einen Hypervisor, dann würde man sich ein System wünschen, bei dem es zu keinem Overhead aufgrund der VMM kommt (wie bei den oben genannten Systemen), damit die Echtzeitfähigkeit gegeben bleibt. Auf der anderen Seite muss das System in sich gegeneinander komplett abgeschottet bleiben, damit keine gegenseitige Beeinflussung möglich ist, da sonst die notwendige Sicherheit (Datenintegrität zum Beispiel) beziehungsweise funktionale Sicherheit nicht realisierbar ist.

Hier setzt Jailhouse auf. Der Hypervisor nutzt die Tatsache, dass moderne SoCs bereits eine vielfältige Hardware Unterstützung für Virtualisierungstechnologien (Intel-VT, AMD-V, ARM-V Technologie) mitbringen. Jailhouse nutzt zur erstmaligen Initialisierung beim Bootvorgang ein Linux-System, was die Größe des Hypervisors und damit die Größe der vertrauenswürdigen Codebasis (TCB = trusted code base) deutlich limitiert.

Jailhouse – ein etwas anderer Ansatz

Jailhouse ist ein Open-Source-Softwareprojekt. Der Code steht unter der Lizenz GPL v2. Ursprünglich wurde die Entwicklung von Siemens gestartet, heute wird Jailhouse von vielen Unternehmen unterstützt. So hat beispielsweise AMD die Portierung auf seine CPUs beigesteuert, ARM die auf die ARM Technologie ab ARM v7 aufwärts. Und von Huawei kam die Portierung auf ARM64.

Das Linux-System verbleibt nach dem Start von Jailhouse auf dem System und bildet die sogenannte root cell. Sie übernimmt die Verwaltung und erlaubt den Zugriff auf das System und die VMs. VMs können hierüber gestoppt oder neu gestartet werden. Dies alles ohne Nebenwirkungen auf die anderen VMs. Damit ist eine kritische Mindestfunktionalität für Security und Safety gegeben.

Jailhouse ist also von der Art und Weise, wie der SoC initialisiert wird, ein Type-II-Hypervisor. Auf der anderen Seite ist es aber auch ein Bare-Metal-Hypervisor, da er während der Nutzung des SoCs direkt auf der Hardware sitzt und diese verwaltet.

Jailhouse erzeugt maximal so viele VMs, in Jailhouse „cell“ genannt, wie physikalische CPUs vorhanden sind. Es können dabei mehrere CPUs zu einer VM kombiniert werden. Jede Zelle bekommt ihren eigenen Speicherbereich, ihre eigenen Interrupts, ihre eigene I/O und dergleichen zugeordnet. Prinzipiell kommt ein Jailhouse-System ohne virtuelle Geräte aus. Die Zuordnung und später dann auch die Kontrolle, dass die Konfiguration eingehaltenen wird, erfolgt mit den eingebauten Hardware-Features der SoCs (MMU, IOMMU, PCI pass through …).

Im günstigsten Falle muss der Hypervisor bei einem korrekt laufenden System nie eingreifen, denn alle Vorgänge wie IRQ-Behandlung und dergleichen laufen ohne einen Eingriff des Hypervisors ab. Dies hat zum Vorteil, dass echtzeitkritische Aufgaben ohne Verzögerung durch Software abgearbeitet werden können. Die Kontrolle über die einzelnen Cells wird auch in diesem Fall von der „root cell“ ausgeübt.

Änderung der Konfiguration

Die Konfiguration des Systems kann jederzeit geändert werden. Wenn etwa eine VM nicht mehr benötigt und gestoppt wird, dann können die Ressourcen dieser VM neu aufgeteilt werden. Dazu ist die Konfigurationsdatei entsprechend anzupassen und von der „root cell“ danach auszuführen. Auf diese Weise kann das Gesamtsystem dynamisch angepasst werden. In einer Zelle können unterschiedliche Systeme zur Ausführung kommen, vom „historischen“ OS bis hin zu einer bare-metal Applikation. Dadurch eignet sich ein Jailhouse-Ansatz sowohl zur Konsolidierung als auch zur Migration bestehender Systeme [siehe: Bild 1].

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

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.

Kommunikationseigenschaften unter Jailhouse

Ein sicheres System, das in einer virtuellen Umgebung Echtzeit erlaubt, ist ein riesiger Schritt für die Industrie. Aber die Kommunikation fehlt noch. Die Zellen müssen sich untereinander verständigen können, wenn die Konsolidierung erfolgreich sein soll.

Ein Blick auf die bisherige Landschaft in der Industrie zeigt, dass die unabhängigen Systeme sich meist über Ethernet basierte Mechanismen (TCP/IP) ausgetauscht haben. Daher liegt es nahe, dies auch als zuverlässige Kommunikation in Jailhouse zu integrieren. Dies erleichtert die Portierung existierender Lösungen um ein Vielfaches. Dafür müssen virtuelle IOs geschaffen werden, die ein virtuelles Netzwerk ermöglichen.

Daneben benötigt solch ein System eine Interrupt-basierte Kommunikation über Shared-Memory-Bereiche, die mittels Semaphoren verwaltet wird. Auch muss die Systemzeit und Ähnliches unter allen Cells ausgetauscht werden können.

Portierbarkeit und Skalierbarkeit von Systemen

Industrielle Anwendungen werden oft über einen Zeitraum von vielen Jahren genutzt. Die zugrundeliegende Hardware steht jedoch nur für einen begrenzten Zeitraum zur Verfügung. Es ist daher wichtig, dass die Anwendung einfach portiert werden kann. Und falls die Anwendung wächst, dann muss auch eine einfache Skalierbarkeit gegeben sein.

Jailhouse kann diese Anforderungen spielend erfüllen. Mit Linux steht ein (Host-) System zur Verfügung, das auf jeder neuen SoC-Lösung zum Einsatz kommt. Damit ist die Skalierbarkeit und Portierbarkeit gegeben. Und die Einfachheit dieser Portierbarkeit ist durch die Nutzung der offenen Schnittstelle libvirt (populäre Bibliothek zur Verwaltung von Virtualisierungslösungen) zum Management des Hypervisors gegeben.

Schaut man etwas weiter in die Zukunft, dann sieht man bereits heterogene Multi-Core-Lösungen am Horizont. Diese eierlegenden Wollmilchsäue benötigen definitiv einen Hypervisor wie Jailhouse, damit all ihre Fähigkeiten sinnvoll genutzt werden können. Hier dient der Hypervisor auf der einen Seite zur Verwaltung der „großen“ CPUs, auf der anderen zur Kommunikation mit den anderen CPU-Architekturen oder FPGA-Einheiten. Auch das sichere Update erfolgt über den Hypervisor.

Der Beitrag erschien im Original bei der Schwesterpublikation Elektronik Praxis, Sonderheft Embedded Software Engineering.

* Heinz Egger ist seit 2006 Geschäftsführer von Linutronix. Er hat mehr als 20 Jahre Erfahrung im Embedded- und Automatisierungsbereich.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 44531627 / Middleware)