Suchen

Separation-Kernel-Hypervisoren im Embedded-Umfeld

| Autor / Redakteur: Mark Pitchford * / Franz Graser

Virtualisierungstechniken, wie sie in vielen Prozessoren zu finden sind, werden im Embedded-Umfeld kaum voll angewendet. Sogenannte Least-Privilege-Separation-Kernel-Hypervisoren versprechen Abhilfe.

Firma zum Thema

Bild 1: Die feinere Granularität infolge von Least-Privilege-Prinzipien für die Separation-Kernel-Blöcke beschränkt die Anzahl der Abläufe äußerst effektiv.
Bild 1: Die feinere Granularität infolge von Least-Privilege-Prinzipien für die Separation-Kernel-Blöcke beschränkt die Anzahl der Abläufe äußerst effektiv.
(Bilder: Lynx Software Technologies)

Bereits vor 30 Jahren forderten Saltzer und Schroeder, dass „jedes Programm und jeder Benutzer nur die Rechte erhält, die zur Erfüllung der jeweiligen Aufgaben absolut erforderlich sind.“ Dieser Ansatz der geringsten möglichen Rechte wird notwendig, wenn Anwendungen unterschiedlicher Kritikalität in unmittelbarer Nähe zueinander ausgeführt werden.

Das Konzept eines Separation-Kernels bildet die Grundlage der Initiative „Multiple Independent Levels of Security“ (MILS). MILS forciert den Zusammenschluss von Komponenten und Subsystemen zu Einheiten, die klein genug sind, um einer exakten Prüfung unterzogen werden zu können.

Bildergalerie

Sowohl bei MILS als auch bei Least Privilege liegt der Schwerpunkt auf den Vorzügen der Modularisierung. Traditionell fokussierten Separation-Kernels auf die Isolierung von Ressourcen, was bedeutet, dass sie nicht der Granularität die Geltung verschafften, die die Least Privilege-Prinzipien verlangen.

Bild 1 zeigt die „Subjects“ (aktive, ausführbare Einheiten) mit den wenigsten oder geringsten Rechten und Ressourcen, die über die Separation-Kernel-Blocks gelegt sind. Wo der Separation-Kernel die Granularität der Flusskontrolle je Subject und je Ressource unterstützt, werden weit weniger unerwünschte Kontrollflüsse zugelassen, als wenn die Flusskontrolle jeweils per Block verwaltet werden würde.

Entwickler hosten heute oftmals mehrere Betriebssysteme (OS) auf demselben Computer. Die Umgebung dafür nennt man Virtual Machine Monitor (VMM) oder Hypervisor.

In diesen Domänen läuft das Gastbetriebssystem auf einer niedrigeren Berechtigungsstufe als der zugrundeliegende VMM (welcher die Ressourcen zu verwalten hat), während das Betriebssystem von der darunterliegenden Hardware durch Binär-Translation abgekoppelt wird.

Hardwareunterstützte Virtualisierungstechniken wie VT-x von Intel vermeiden Privilegierungsprobleme, wie sie bei der Nutzung herkömmlicher Software-Virtualisierungstechnologien auftauchen. Mit ihnen wird es einfacher, von den Vorteilen der Virtualisierung speziell für eingebettete Systeme zu profitieren.

Den Least-Privilege-Separation-Kernel wirksam einsetzen

Bild 2 zeigt einen Separation-Kernel und Hypervisor (SKH). In dieser Konfiguration gibt es als Subjects ein Echtzeitbetriebssystem (RTOS), ein Allzweckbetriebssystem (GPOS), und eine vertrauenswürdige (Trusted) Bare Metal-Anwendung zur Implementierung einer hochkritischen Funktion. Die Mechanismen des SKH sorgen dafür, dass die Subjekte so wenig wie möglich miteinander kommunizieren. Die Leistung der Anwendungen wird nicht beeinträchtigt, wenn jedem Subjekt ein eigener Kern zugeordnet ist. Drei typische Konfigurationen zeigen auf, was möglich ist:

Bildergalerie

Sichere Separierung zwischen Bedientechnik und Informationstechnik im IoT:

Ein SKH funktioniert als ideale Plattform für ein IoT-Gateway. Nehmen wir mit Verweis auf Bild 2 an, ein RTOS diene zur Steuerung der Prozessanlage einer Neugeborenen-Intensivstation. Ordnet man dem RTOS-Subject einen CPU-Kern zu, steht seine deterministische Performance voll zur Verfügung.

Gleichzeitig stellt ein Allzweckbetriebssystem (GPOS) eine über das Internet erreichbare Schnittstelle zur Verfügung, um dem Wartungspersonal den Fernzugriff auf aktuelle Daten des Werks zu gewähren.

Sollte das GPOS einem Angriff zum Opfer fallen, kann der SHK aufgrund seiner Struktur und der sorgfältig geregelten Kommunikationspfade das RTOS bestens verteidigen. Der Datenfernzugriff wird beeinträchtigt, doch die Anlage kann sicher weiterbetrieben werden.

Virtualisierung von Zielobjekten als preiswerte Methode, Hardware aufzufrischen:

Stellen Sie sich vor, ein Echtzeit-, also RTOS-basiertes Strahlentherapiesystem zu entwickeln mit der Anforderung eines kontinuierlichen Supports über einen Zeitraum von 15 Jahren. Durch die Installation des RTOS als SKH-Subjekt kann jedes eingesetzte Objekt virtualisiert – das heißt, vom Secure Virtual Device Driver (siehe Bild 2) verwaltet – werden. Das RTOS benötigt für die virtualisierten Objekte lediglich Treiber. Auch wenn die zugrundeliegende Hardware erneuert wird, erfolgen alle Treiber-Updates extern auf das RTOS-Image, das nicht geändert werden muss.

Plattformkonsolidierung durch Virtualisierung verschiedener Umgebungen mit diversen Safety- und Security-Integritätsstufen:

Angenommen, ein Medizintechnik-Gerät nutzt einen PC für die grafische Benutzerschnittstelle (GUI) und die Netzwerkanbindung; dedizierte Prozessoren steuern jeweils eine der drei Koordinatenachsen.

Diese vier Objekte lassen sich per SKH auf einer Mehrkernplattform konsolidieren.

Hier bietet ein SKH zuverlässig die benötigte Trennung, die sicherstellt, dass die kritischeren Subjekte nicht durch die weniger kritischen beeinträchtigt werden und dass jegliche Sicherheitsgefährdung des Allzweckbetriebssystems der GUI keinerlei Auswirkungen auf die Maschinenachsensteuerungen haben kann und haben wird.

* Mark Pitchford ist als technischer Leiter EMEA (Europa, Mittlerer Osten, Afrika) bei Lynx Software Technologies tätig.

Artikelfiles und Artikellinks

(ID:43962704)