Vorteile eines Hypervisors in kritischen Embedded-Systemen

Gängige Betriebssysteme (OS) wie Linux und Android mit ihrem Kernel und ihren Softwarepaketen, die aus Millionen von Codezeilen bestehen, sind in Embedded-Systemen heute weit verbreitet. Da es praktisch unmöglich ist, Millionen von Codezeilen zu testen, ist es unvermeidlich, dass Linux und Android weiterhin Sicherheitslücken und Softwarefehler enthalten. Einmal beeinträchtigt, kann ein Hacker die verletzen und die Kontrolle über das gesamte System übernehmen.

Embedded-Linux- und Android-Sicherheit

Eine Möglichkeit, die Sicherheit dieser Systeme zum Schutz vor ausgefeilten Angriffen zu erhöhen, besteht darin, einen auf einem sicheren Microkernel basierenden Hypervisor zu verwenden, um eine Trennung zwischen den Softwarekomponenten des Systems zu gewährleisten. Der Microkernel ist die sichere Software-Ebene unterhalb des Betriebssystems. Er läuft auf einer höheren privilegierten Ebene als das und virtualisiert die Hardware-Ressourcen. Der Hypervisor ermöglicht dem Gastbetriebssystem sich so zu verhalten, als würde es direkt auf der Hardware ablaufen.

Aufgrund der höher privilegierten Ebene bleibt die Integrität des Hypervisors intakt, auch wenn das Betriebssystem kompromittiert wird. Ein Hypervisor, der von Grund auf sicher und zuverlässig ausgelegt ist, bietet erhebliche Vorteile gegenüber Hardware, die für die Umsetzung von Sicherheit auf niedriger Ebene verwendet wird. Außerdem kann er mehrere privilegierte Ebenen bereitstellen, so dass ein Dienst mit sensiblen Daten in einem isolierten Bereich oder einer Partition neben einem Dienst mit weniger sensiblen Informationen ausgeführt werden kann. Diese verschiedenen Sicherheitsstufen können gleichzeitig laufen, sind aber niemals in der Lage, sich gegenseitig zu beeinflussen oder zu modifizieren.

Mit einem Schutz auf mehreren Ebenen, wie etwa MILS (Multiple Independent Levels of Security), lässt sich gewährleisten, dass Systeme, die auf anfälligen Betriebssystemen basieren, sicher bleiben. Hier kommt die Virtualisierung ins Spiel: Sie bietet die Möglichkeit, ein Gastbetriebssystem auf einem (anderen) Host-Betriebssystem zu betreiben. Der Hypervisor stellt dem Gast die Virtualisierungsumgebung zur Verfügung. Da ein Hypervisor die Ausführung der verschiedenen Gastbetriebssysteme auf dem System umsetzt, bleibt die Isolation vollständig erhalten, was effektive Sicherheit garantiert und mit einer physikalischen Trennung vergleichbar ist.

Der Hypervisor-Kernel

Der Separationskernel wird unbestritten als das beste Betriebssystem-Design für Betriebs- und angesehen: ein System, auf dem nur die minimale Menge an Code auf der höchsten privilegierten Ebene läuft. Der Separationskernel besteht aus Bereichen, die als Partitionen bezeichnet werden. In jeder dieser Partitionen läuft ein Softwareprozess. Innerhalb der Partition ist die Trennung nicht gewährleistet – wenn Fehler im Code auftreten oder dieser kompromittiert wird, verbleibt das Geschehen innerhalb der Partition, wobei der Betrieb oder das Verhalten anderer Partitionen oder des Separationskernels unverändert bleiben.

Virtualisierung, kombiniert mit einem Separationskernel, bietet fortschrittliche Funktionen für Entwickler von Embedded-Software, die:

• sicherstellen, dass die heterogenen Softwarekomponenten frei von Störungen sind;
• den Informationsfluss schützen;
• die Daten- und Betriebssicherheit des Kommunikationssystems erhöhen (gegebenenfalls durch zusätzliche Filterung oder Verschlüsselung);
• die Zuordnung von Geräten eindeutig verwalten und sicherstellen, sodass nicht beschriebene Ressourcen unzugänglich sind.

Der Separationskernel bringt all die Sicherheitsfunktionen mit, die ein Gastbetriebssystem nicht garantieren kann. Der für den Gast verantwortliche Teil des Hypervisors läuft im gleichen Adressbereich wie der Gast selbst und muss nicht notwendigerweise privilegierten Status haben. Er läuft als eigenständige Applikation auf dem Separationskernel. Dabei läuft ein nicht vertrauenswürdiges Gastbetriebssystem wie Linux oder Android in einer Partition. Damit wird Speicherressourcenschutz und die sichere Zugriffskontrolle für I/Os und andere Systemobjekte sichergestellt. Workloads lassen sich somit sicher und effizient über Cores verteilen.

Durch die Trennung von Systemkomponenten in verschiedene Partitionen müsste ein Hacker mehrere Partitionen kompromittieren, um sensible Daten modifizieren oder darauf zugreifen zu können – im Gegensatz zu einem einzigen Dienst, der kompromittiert wird, um Zugriff auf das gesamte System zu erhalten.

Lesen Sie auf der nächsten Seite: „Sensible Daten schützen“ und „I/O Device Handling“.

Sensible Daten schützen

Da Hacker zunehmend IoT-basierte Embedded-Systeme angreifen, ist eine robuste Softwarearchitektur zur Sicherung von Geräten und zum Schutz sensibler Daten erforderlich. Alle sensiblen Daten sollten in separaten Partitionen isoliert werden, während andere Anwendungen auf dem Gast verbleiben können, beispielsweise Linux oder Android. Auf diese Weise werden die sicherheitskritischen Anwendungen von den weniger sicheren und vernetzten Anwendungen isoliert, während der Nutzen flexibler Frameworks auf Linux weiter zur Verfügung steht.

Allerdings könnte eine schädliche Anwendung, die auf dem Gastbetriebssystem läuft, Bugs in der Virtualisierungs-Software einiger Virtualisierungssysteme ausnutzen, um andere Gäste oder Partitionen zu behindern oder auf diese zuzugreifen und somit die Vertraulichkeit, Integrität und Verfügbarkeit ihres Codes oder ihrer Daten zu verletzen. Aus diesem Grund muss das Virtualisierungssystem in der Lage sein, die Trennung zwischen Gästen und Partitionen zu gewährleisten. Die Mikrokernel-Architektur einiger Separationskernel, wie das Integrity RTOS von Green Hills Software, sorgt dafür, dass die Kernelgröße klein bleibt und daher leichter getestet und überprüft werden kann, um sicherzustellen, dass sie frei von Bugs und Sicherheitslücken ist. In Mikrokernel-Architekturen sind nur grundlegende Dienste Teil des Kernels: Unterstützung für die Kommunikation zwischen Partitionen (IPC), virtuelle Speicherverwaltung und Scheduling.

Bild 1: Beispiel für eine sicherheitskritische Anwendung auf dem Betriebssystem Embedded-Linux. GHS

In Bild 1 ist ein Szenario dargestellt, bei dem eine generische, sicherheitskritische Anwendung vertrauliche Nachrichten über das austauscht, vertrauliche Daten speichert und dem Endnutzer schließlich über eine HMI anzeigen muss. Durch die Ausnutzung von Linux-Schwachstellen und/oder die Installation von Malware kann ein Hacker möglicherweise die Kontrolle über das gesamte System übernehmen.

Bild 2: Durch den Einsatz eines Separationskernel erhöht sich die Sicherheit für das Linux-basierte System. GHS

Im Gegensatz dazu ist es mit einem sicheren Separationskernel, der auch eine Virtualisierung bietet, möglich, die Sicherheit des in Bild 1 dargestellten Systems zu verbessern. Bild 2 zeigt ein System, in dem die sicherheitskritischen Komponenten der Linux-Anwendung als Separationskernel-native Anwendungen und isoliert in verschiedenen Partitionen portiert wurden. Die Softwarekomponenten können über sichere IPC-Systeme (Inter Partition Communication) interagieren, sodass sichere Anfragen von der Linux-Applikation mit der Secure-Services-Partition ausgeführt werden können. Auf diese Weise kann die Secure-Services-Partition für die sicherheitskritische Funktion verantwortlich sein, während die Network-Stack-/Gateway-Partition die aus dem Netzwerk kommenden Anfragen verarbeitet und filtert.

Dabei schafft der Separationskernel Sicherheit in einer Weise, die mit ARM TrustZone oder anderen ergänzenden Isolationsmechanismen vergleichbar ist. Denn es kommen modernere und flexible hardwaregestützte Virtualisierungstechniken wie ARM VE oder Intel VT zum Einsatz.

I/O Device Handling

Ein weiterer wichtiger Aspekt bezüglich der Sicherheit eines virtualisierten Systems ist die Geräteverwaltung. Darunter fallen insbesondere Geräte, die einem Gastbetriebssystem zur Verfügung stehen. Bild 1 zeigt ein System mit Hochgeschwindigkeits-Erweiterungs-Ports, die einen direkten Speicherzugriff (DMA) ermöglichen. Wenn der Separationskernel dem Linux-Gast die vollständige Kontrolle über DMA-Systeme geben würde, kann die Sicherheit des gesamten Systems kompromittiert werden. Mit DMA könnte das Gastbetriebssystem das System anweisen, jeden Bereich des Hauptspeichers direkt zu lesen oder in jeden Bereich zu schreiben, einschließlich des Kernels. Sofern kein bestimmter Schutz vorhanden ist, kann ein Hacker eine solche Möglichkeit nutzen, um direkten Zugriff auf einen Teil oder den gesamten physikalischen Speicheradressraum des Systems zu erhalten, wobei alle Sicherheitsmechanismen umgangen werden.

Aus diesem Grund bieten viele moderne Mechanismen an, um die Zugriffsbereiche der DMA-Geräte zu beschränken: die sogenannten „I/O Memory Management Units“ (IOMMU). Mehrere Implementierungen finden sich am Markt, zum Beispiel ARM SMMU, Intel VT-d oder Renesas IPMMU. Die IOMMU, ähnlich wie eine CPU MMU, bietet eine programmatische Schnittstelle, um festzulegen, auf welche Adressenbereiche das System zugreifen kann. Dadurch können Gerätetreiber vollständig in einer Separationskernel-Partition oder einem Gastbetriebssystem laufen. Wenn ein IOMMU nicht in der Lage ist, das System zu schützen, wird allerdings der direkte Gerätezugriff vom Gast stark eingeschränkt. Dies ist leider eine gängige Praxis und dient als Kompromiss für die Wartbarkeit eines Systems oder für eine schnelle Markteinführung.

Wenn ein Hardware-Schutz nicht vorhanden ist, sollten DMA-Systeme stattdessen vom Separationskernel (einer virtuellen Treiberpartition für jedes DMA-System) verwaltet werden, um sicherzustellen, dass ein Fehler in einem Gast-OS-Gerätetreiber die DMA-Hardware nicht falsch programmieren und eine folgenschwere Speicherkorrumpierung verursachen kann. Genauer gesagt müssen die DMA-Anfragen vom Separationskernel gehandhabt werden, während der komplexere Teil des Treibers weiterhin im Gast laufen kann. Dies verschiebt die Treiberimplementierung in Richtung eines paravirtualisierten, spezifischen Modells, um das gewünschte Verhalten weiterhin zu gewährleisten. Die zusätzliche Komplexität ist der Preis, den man zahlen muss, um das System robust, betriebs- und datensicher zu halten. Die Erfahrung zeigt, dass der Overhead tatsächlich kleiner ist als erwartet, sofern die Schnittstelle korrekt ausgelegt ist.

(ku)