Software-Partitionierung Der Separation-Kernel als Alternative zum Hypervisor

Software-Partitionierung, d.h. die Ausführung von Anwendungen in voneinander getrennten Umgebungen, sorgt für Funktions- und Datensicherheit. Der Einsatz eines Hypervisors ist hier ein probates Mittel, aber nicht immer die beste und nie die einzige Lösung. Denn: Auch ein Hypervisor selbst kann Risiken bergen.

Ein Hypervisor ermöglicht die Ausführung mehrerer Betriebssysteme auf ein und derselben Hardwareplattform, wodurch die Hardwareleistung maximiert und gleichzeitig die Unabhängigkeit gewährleistet wird. Speziell wenn die Einhaltung spezifischer Sicherheitsstandards gefordert wird, beispielsweise gemäß ISO 26262 oder ISO 21434, kann der Einsatz eines Hypervisors auch Einschränkungen mit sich bringen.

Als Alternative hierzu bietet sich die Implementierung eines Separation-Kernels in einem Echtzeitbetriebssystem an. Dadurch wird die Trennung von Interessen innerhalb eines einzigen Betriebssystems ermöglicht und gleichzeitig die Trennung auf Anwendungsebene anstelle der Trennung auf Betriebssystemebene garantiert.

Kurz rekapituliert: Ein eingebetteter Hypervisor ist eine Software, die es mehreren Betriebssystemen ermöglicht, auf einem ressourcenbeschränkten Einzelprozessor eines Geräts zu laufen und die Ressourcen gemeinsam zu nutzen. Je nach Ausprägung kann ein Hypervisor dynamisch agieren, d.h. mit flexibler Anzahl von Rechenkernen und Speichernutzung, oder statisch, mit einer fixen Zahl von Rechenkernen und fester Speicherzuweisung. Peripheriegerätetreiber können dediziert sein oder von verschiedenen Betriebssystemen gemeinsam genutzt werden. Bild 1 zeigt eine Partitionierung mittels klassischer Hypervisor-Architektur.

Gleichzeitig ist aber die Einführung eines Hypervisors in eine Softwarearchitektur für die Partitionierung nicht unproblematisch, da sie die Komplexität erhöht. Der Hypervisor muss die Speichertrennung und den Speicherschutz sowie die Verteilung der verschiedenen Workloads planen und kontrollieren. Außerdem muss er die Berechtigungsstufen der virtualisierten Gastbetriebssysteme zusammen mit sich selbst verwalten und gleichzeitig den Zugriff auf die Hardwareressourcen ausbalancieren.

So wird dem System Code hinzugefügt, der auf der höchsten Privilegierungsstufe der Hardware läuft. Die Implementierung eines Hypervisors muss deshalb v.a. Dingen sicher sein, da sonst der zugrunde liegende Gedanke, mittels eines Hypervisors die Systemsicherheit zu erhöhen, ad absurdum geführt werden würde. Das Hinzufügen eines komplexen Hypervisors (sprich: eines auf einer großen Codebasis basierenden Hypervisors) in den empfindlichsten Teil des Systems birgt daher ein hohes Risiko, gleichzeitig neue Sicherheitslücken zu integrieren. Als Beispiel sei hier der weit verbreitete Open-Source-Hypervisor Xen aufgeführt, der laut National Vulnerability Database aufgelisteten mehrere hundert bekannte Schwachstellen besitzt.

Saubere Trennung – ohne Hypervisor

Eine Alternative stellt der sogenannte Software-Separation-Kernel dar. Er sorgt dafür, dass jede Anwendungsdomäne wie ein separater, isolierter Rechner erscheint, der den Informationsfluss nur über bekannte externe Kommunikationsleitungen zulässt. Dieser Kernel bietet ein hohes Maß an Sicherheit, indem er isolierte Domänen oder Partitionen auf einem einzigen physischen System schafft. Partitionen werden strikt voneinander getrennt und so wird verhindert, dass Software in einer Partition die Software in einer anderen beeinträchtigt. So wird das Gesamtsystem vor bösartiger Software und unbefugtem Zugriff geschützt.

Auf der Grundlage einer Mikrokernel-Architektur bietet der Separationskernel nur minimale Dienste und stützt sich für zusätzliche Funktionen auf separate Dienste. Dieser Ansatz reduziert die Angriffsfläche des Kernels und erhöht seine Widerstandsfähigkeit gegen Kompromittierung. Einige Separation-Kernel, wie etwa der L4-Mikrokernel, wurden bereits einer formalen Überprüfung unterzogen, um den korrekten Betrieb zu garantieren. Es gibt auch kommerziell erhältliche Separation-Kernels, wie z.B. das INTEGRITY Echtzeitbetriebssystem von Green Hills Software. Bild 2 zeigt die Partitionierung auf Anwendungsebene in einer Echtzeit-Betriebssystemumgebung mit Separation-Kernel.

Anzahl der Kontextwechsel beachten

Greifen mehrere Betriebssysteme auf dieselben Ressourcen zu, kann es bei einigen Implementierungen zu Leistungsproblemen kommen. Ein Typ-1-Hypervisor benötigt beispielsweise zwei Kontextwechsel, um eine kritische Aufgabe nach Auftreten eines Interrupts auszuführen. Der erste Interrupt wird an den Hypervisor weitergeleitet, verarbeitet und zur Task-Planung an das Gastbetriebssystem weitergeleitet. Eine Lösung auf Basis eines Separation-Kernels würde hingegen lediglich einen Interrupt für die Planung eines kritischen Tasks benötigen. Obwohl dies implementierungsspezifisch ist, ist die Virtualisierung in Bezug auf die Leistung nicht immer kostenlos, insbesondere bei kritischen Aufgaben oder beim Zugriff auf gemeinsam genutzte Ressourcen. Deshalb muss in die Designüberlegungen für spezifische Anwendungsfälle in eingebetteten Systemen auch die jeweilige Performanz von Separation-Kernel und/oder Hypervisor mit einfließen.

In der Praxis zeigen sich mehrere Gründe, weshalb eine Software-Partitionierung bzw. eine saubere und sichere Trennung von Softwarebereichen angeraten ist. Der häufigste Grund ist die Sicherheit bzw. der geschützte Zugriff auf Hardwareressourcen. So ermöglicht die Isolierung bestimmter Funktionen innerhalb mehrerer Instanzen desselben Betriebssystems einen sicheren Zugriff auf bestimmte Ressourcen.

Zudem kann es in vielen Systemen ratsam sein, bereits bestehenden Code („Legacy code“) wiederzuverwenden. Mehrere – auch verschiedene – Betriebssysteme können so Funktionen nutzen, ohne dass eine Neuarchitektur oder Neuimplementierung erforderlich ist. Darüber hinaus wird so der Einsatz mehrerer Betriebssysteme ermöglicht, um Sicherheitsstandards zu erfüllen, die eine Trennung der Anwendungen erfordern, da diese unterschiedliche Kritikalitätsstufen erreichen müssen.

Um diese Anforderungen zu erfüllen, wird häufig eine Hypervisor-Lösung in Betracht gezogen. Allerdings: Auch ein Separation-Kernel kann diese Anforderungen erfüllen, ohne auf Virtualisierung zurückgreifen zu müssen.

Einsatz eines Separation-Kernel

Wenn die Zugriffskontrollmethoden des zugrundeliegenden Betriebssystems sicher genug sind, kann ein geschützter Ressourcenzugriff auf der Anwendungsebene erreicht werden. Die Untersuchung alternativer Separation-Kernel-Betriebssysteme anstelle der Virtualisierung kann helfen, potenzielle Fallstricke zu vermeiden. Solche Implementierungen verwenden in der Regel obligatorische Zugriffskontrollrichtlinien, um dies zu erreichen, und können Betriebssystemmechanismen für die sichere gemeinsame Nutzung solcher Ressourcen nutzen, z.B. dedizierte Peripheriezugriffe.

Bestimmte Software, z.B. Bibliotheken von Drittanbietern, kann nicht ohne Weiteres sicher gemacht werden. In solchen Fällen muss die Software partitioniert werden, um Interferenzen mit den Sicherheitsanforderungen des restlichen Systems zu vermeiden. Anstatt mittels Virtualisierung unnötige Komplexität einzubauen, kann es effizienter sein, den Code selektiv zu ändern und mit Drittanbietern zusammenzuarbeiten, v.a. wenn ein Separation-Kernel spezifische Portabilitätsebenen bietet. Zugegebenermaßen erfordert die Anwendung eines Separation-Kernel hier mehr Aufwand, was aber hinsichtlich des Bemühens, ein sicheres System zu schaffen, vertretbar ist.

Wird man angehalten, spezifische Sicherheitsstandards einzuhalten, ist oft eine Separierung erforderlich, um Interferenzen zu vermeiden. Anstatt eine vollständige Virtualisierungsschicht einzuführen, kann eine weitere Trennungsschicht ausreichen, welche allerdings die Ziele des Sicherheitsstandards erfüllen muss. Die Verwendung einer kleineren, vertrauenswürdigen Basis für Funktions- und Datensicherheit steht im Einklang mit den Anforderungen der funktionalen Sicherheit. Der INTEGRITY RTOS-Separation-Kernel von Green Hills Software wird beispielsweise in verschiedenen Bereichen wie der Automobil-, Industrie- und Avionikbranche eingesetzt und bietet mehrere Sicherheitsschichten.

Kein Virtualisierungszwang

Die obigen Anwendungsfälle zeigen, dass Separierung auch ohne Virtualisierung möglich ist, wenn die Softwarearchitektur neu gedacht wird. Ein Separation-Kernel ist in der Lage, Anwendungen mit gemischten Kritikalitätsanforderungen zu hosten, ohne dass ein Hypervisor erforderlich ist. Anwendungskompatibilitätsschichten wie POSIX, TCP/IP-Sockets und Standard-Dateisystem-Interaktionen werden durch offene Schnittstellen erreicht. Der Separation-Kernel folgt einer Mikrokernel-Architektur und erweitert diese durch die Isolierung von Funktionen, die Implementierung einer obligatorischen Gerätezugriffskontrolle und die Bereitstellung einer Grundlage für eine alternative Softwarearchitektur. Dieser Ansatz führt zu einem weniger komplexen Design mit einer kleineren Codebasis, was es einfacher macht, die Sicherheit des Gesamtsystems zu gewährleisten. Der Einsatz eines Separation-Kernels erzwingt eine statische Architekturentwurfsphase, was wiederum ein elementarer Bestandteil der „Best Practices“ für die Entwicklung von Sicherheitssystemen darstellt.

Um sichere Systeme zu erreichen, müssen Software-Ingenieure eine Denkweise annehmen, die sich auf die Architektur von Funktionen mit Blick auf die Separierung konzentriert. Klare und geschützte Schnittstellen zwischen Anwendungen und Diensten sind von elementarer Bedeutung, und es ist wichtig zu erkennen, dass ein Dienst, im Kontext eines Separation-Kernel, eine separate Anwendung sein kann.

Fazit

In eingebetteten Systemen kann sowohl ein Hypervisor als auch ein Separation-Kernel helfen, die Anforderungen an die Sicherheit zu erfüllen. Der Ansatz, einen Hypervisor als Default-Technologie zu nutzen, sollte jedoch infrage gestellt werden. Ein Separation-Kernel, mit einer kleineren vertrauenswürdigen Datenverarbeitungsbasis und der gleichen bereitgestellten Funktionalität, ist aus der Sicherheitsperspektive oft die bessere Wahl. Ist erhöhte Sicherheit wichtiger als die Wiederverwendung von Software, empfiehlt es sich, Legacy- oder De-facto-Betriebssysteme durch sicherere Separation-Kernels und entsprechende Anpassungsschichten zu ersetzen.

Der Autor

Marcus Nissemark ist Field Applications Engineer bei Green Hills Software und leitet das EMEA FAE-Team. Bevor er 2014 zu Green Hills in Schweden kam, arbeitete Marcus Nissemark seit 1999 als Softwarearchitekt und Entwickler von Embedded-Produkten. Zu diesen Produkten gehörten Steuerungen und Anzeigecomputer für Nutzfahrzeuge, medizinische und militärische Geräte. Seine Erfahrung umfasst mehrere Betriebssysteme, die Entwicklung von Gerätetreibern sowie die Herausforderungen des Prozess- und Produktmanagements in der Softwareentwicklung.  

Dieser Beitrag stammt ursprünglich von unserem Partnerportal Embedded-Software-Engineering.de. (Chefredakteurin: mbf)

(ID:49976608)