QNX
Zukunftssicher mit Hypervisor
Hypervisoren trennen sicherheitskritische und nichtsicherheitskritische Bereiche eines Systems. Sie sorgen aber auch dafür, dass Funktionserweiterungen für die nächste Gerätegeneration so implementiert werden, dass sich Test- und Zertifizierungsaufwand in Grenzen halten.
Hypervisoren haben sich aus mehreren Gründen zur ersten Wahl entwickelt, wenn es um das Design von Embedded-Systemen geht. Ohne die Verzögerungen oder Laufzeitunstimmigkeiten, die bei Bare-Metal-Designs unter Linux oder Android üblich sind, unterstützt ein sorgfältig entwickelter Hypervisor das Starten kritischer Dienste unmittelbar nach dem Einschalten und bietet Echtzeit- und Performance-Garantien. Ein Hypervisor kann Safety-Anwendungen von Nicht-Safety-Anwendungen isolieren, und security-sensible Schnittstellen lassen sich in virtuellen Maschinen (VMs) schützen.
Dies ist jedoch erst der Anfang, denn die System-on-Chip-Anbieter statten ihre Produkte mit immer mehr Kernen mit größerer Verarbeitungsleistung aus, sodass Entwickler mit dem hier beschriebenen erweiterten Hypervisor-Design langfristige Vorteile erzielen können.
Produkt A ist die erste Version eines virtualisierten, linux-basierten Produkts mit safety-kritischen Elementen. Die gestrichelte Linie umschließt eine unter Linux laufende virtuelle Maschine, einen safety-zertifizierten Hypervisor-Host, der die virtuelle Maschine steuert, und die Geräte-Hardware. Es sind drei verschiedene Methoden der Treiberintegration dargestellt: ein emulierter Gerätetreiber (hochpräziser Timer) innerhalb der virtuellen Maschine, ein Pass-through-Treiber, bei dem der Linux-Bluetooth-Treiber durchgeleitet wird und direkt mit der Geräte-Hardware interagiert, sowie ein paravirtualisierter Dateisystemtreiber, der ein auf der virtuellen Maschine laufendes Frontend und ein auf dem Hypervisor-Host laufendes Backend verwendet.
Im ursprünglichen Design gibt es nur eine virtuelle Maschine. Ein auf dem Hypervisor-Host laufender PCI-Manager präsentiert dem Gast eine Teilmenge des PCI-Device-Space, der auf die an Linux durchgeleiteten Devices begrenzt ist. Eine System-Memory-Manager-Unit (SMMU) konfiguriert die Speichergrenzen der durchgeleiteten Geräte, sodass ein als Busmaster fungierendes Hardware-Gerät nicht das System-RAM verfälschen kann. Das erfolgreiche Starten von Produkt A wird durch die Verwendung eines Hypervisors sichergestellt, der gemäß IEC 61508 SIL 3 zertifiziert ist, um die Safety-, Echtzeit- und Performance-Anforderungen zu erfüllen.
Zukunftssicher durch Funktionserweiterungen
Die Erweiterung von Produkt A durch Features der nächsten Generation erfordert fünf Ergänzungen (in der Grafik mit Zahlen markiert).
- 1: DriverX wird zum Hypervisor-Host hinzugefügt und startet binnen Millisekunden nach dem Einschalten, bevor eine virtuelle Maschine hochfährt.
- 2: Auf einer zusätzlichen virtuellen Maschine läuft der RTOS-Gast, der das Robot-Operating-System (ROS) unterstützt. Ein virtuelles Netzwerk übernimmt die schnelle Anbindung des RTOS-Gasts an den Linux-Gast. Der RTOS-Gast teilt das zugrundeliegende Block-Device mit dem Linux-Gast für seinen Diskspeicher, sieht aber nur eine Teilmenge des PCI-Space. Dazu gehört das Hardware-Gerät, das anfangs von dem auf dem Hypervisor-Host laufenden DriverX kontrolliert wurde.
- 3: Sobald der RTOS-Gast startet, nimmt DriverX auf dem Host eine Übergabe an den DriverX auf dem RTOS-Gast vor. Die ROS-Umgebung kann DriverX deshalb ohne jede Virtualisierung nutzen. DriverX auf dem Hypervisor-Host wird nach der Übergabe beendet.
- 4: Die virtuelle Umgebung wird um einen Linux-Spezialtreiber, ein individuelles virtuelles Gerät und ein individuelles Backend (z. B. eine Verschlüsselungs-Einheit zum Schutz der Daten) erweitert.
- 5: Neue Systemdienste (Watchdog und Zustandsüberwachung) werden ebenfalls dem Hypervisor-Host hinzugefügt.
Ein erweiterbarer Hypervisor unterstützt diese neuen Features mit Standards, nämlich POSIX C (und C++) für Hypervisor-Host-Dienste und VirtIO für individuelle virtuelle Geräte. Darüber hinaus unterstützt der Hypervisor Echtzeit-Reaktionen und das prioritätsgesteuerte Scheduling virtueller Maschinen, auch wenn mehrere virtuelle Maschinen dieselben CPU-Kerne nutzen.
Die neuen Features reduzieren die Auswirkungen auf die Entwicklungs- und Test-Teams, die die Verifikation von Produkt A als Ausgangspunkt für eine erweiterte Produktfamilie nutzen. Der erweiterungsfähige Hypervisor ist eine safety-zertifizierte Grundlage des Systems und sorgt für Zukunftssicherheit.
Randy Martin, Blackberry QNX
QNX
Halle 4, Stand 278
Jobangebote+ passend zum Thema
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Android
Samsung und Blacknet entwickeln Betriebssystem für die Bundeswehr
Echtzeitbetriebssystem / Medical
Kritische Schwachstellen bei VxWorks
Microsoft und Windows IoT
Gleiche Bits, anderes Verhalten
