Systeme auf Multicore-Prozessoren
Multicore, Modularität, Konnektivität – und Sicherheit
Multicore-Prozessoren sind auch für sicherheitskritische Anwendungen interessant. Der herkömmliche Ansatz mit einem RTOS ist jedoch unflexibel und aufwendig. Mit Z-Apps dagegen lassen sich kritische Elemente mit minimalem Speicherbedarf handlich implementieren.
Funktionale Sicherheitsstandards sollten idealerweise den Entwicklungsaufwand minimieren, indem sie die Aufteilung eines Softwaresystems in Softwareelemente erlauben. Ziel ist, so wenig wie möglich des Systems in die kritischeren Klassen zu stecken.
Für viele Anwendungen gibt es heute aus Sicht der Sicherheit und der betrieblichen Effizienz optimalere Lösungen. Der erfolgreichste Ansatz, den ein Unternehmen verfolgen kann, ist die Verwendung eines alternativen Mechanismus, um die Art von anspruchsvollen Multitasking-Anforderungen zu erfüllen, die traditionell von einem RTOS umgesetzt werden. Der konkrete Weg nach vorn, der von vielen in der Branche eingeschlagen wird, ist die Nutzung von Systemen mit gemischter Kritikalität, um eine angemessene Trennung zwischen den Softwareelementen zu erreichen, was für die Einhaltung der Normen für funktionale Sicherheit unerlässlich ist.
Sichere Trennung per Separation Kernel Hypervisor
Ein Separationskernel ist ein spezieller Typ eines Bare-Metal-Hypervisors, der nur die Separation durchführt. Genauer gesagt handelt es sich um ein winziges Stück – 15 KB klein – sorgfältig ausgearbeiteten Codes, der moderne Hardware-Virtualisierungsfunktionen nutzt, um
- feste virtuelle Maschinen (VM) zu definieren und
- den Informationsfluss zu steuern.
Separationskernel enthalten keine Gerätetreiber, kein Benutzermodell, keinen Shell-Zugriff und keinen dynamischen Speicher. Diese zusätzlichen Aufgaben werden alle in die Gastsoftware der VM verlagert. Diese einfache, elegante Architektur führt zu einer minimalen Implementierung, die zwar für die Desktop-Nutzung weniger geeignet ist, sich aber hervorragend für eingebettete Echtzeit- und sicherheitskritische Systeme eignet.
Das Konzept des Separationskernels wurde erstmals 1981 von John Rushby beschrieben [1]: »...die Aufgabe eines Separationskernels ist es, eine Umgebung zu schaffen, die von der eines physisch verteilten Systems nicht zu unterscheiden ist: Es muss so aussehen, als ob jedes System eine separate, isolierte Maschine ist und dass Informationen von einer Maschine zur anderen nur über bekannte externe Kommunikationsleitungen fließen können.«
Rushby vertritt die Auffassung, dass die Trennung zu wichtig ist, um vom Betriebssystem verwaltet zu werden. Das Betriebssystem ist groß, komplex und für viele Dinge verantwortlich, so dass es extrem schwierig ist, es aus der Sicht der Sicherheit „wasserdicht“ zu machen. Er erkannte, dass der beste Weg, ein sicheres Computersystem zu bauen, darin besteht, die Verwaltung der Trennung vom Betriebssystem in eine neue Art von Kernel auszulagern, der sich ausschließlich auf die Trennung konzentriert. Er nannte diesen neuen Kernel einen Separation Kernel. Der Separationskernel sollte so klein und einfach sein, dass er eingehend untersucht und vollständig verstanden werden kann, so dass seine Korrektheit formell bewiesen werden kann.
Im Jahr 1982 beschrieb Rushby in [2] wie sich mit formalen Methoden die Korrektheit eines solchen Separationskernel mathematisch überprüfen lässt.
Ursprünglich wurden Separation Kernel in sicheren Workstations eingesetzt, die für Hochsicherheitsanwendungen der Regierung und des Verteidigungsministeriums zuständig sind und eine Trennung von streng geheimen, geheimen und vertraulichen Informationen erfordern. Es folgten eingebettete militärische Netzwerkkommunikationssysteme wie sichere Funk-Gateways.
In jüngster Zeit werden Separationskernel als Hypervisor in Embedded Systemen und in sicherheitskritischen Avioniksystemen angewendet, die eine stärkere Trennung zur Bewältigung von Multicore-Interferenzen benötigen. Trotzdem ist der Separation Kernel ein Nischenkonzept geblieben, das nur in der Sicherheitsbranche wirklich anerkannt ist.
Separation Kernel Hypervisor ermöglichen eine robuste Partitionierung
Bei der Partitionierung des Speichers muss verhindert werden, dass eine Partition auf die Software oder Daten anderer Partitionen zugreifen kann. In einem Betriebssystem wird dies durch einen Prozess erreicht. Ein Prozess ist ein von der MMU definierter Speicherbereich, der Aufgaben enthält. Ausgelöst durch den fork()-Aufruf werden Prozesse on-the-fly von einem Betriebssystem erstellt, indem die MMU so konfiguriert wird, dass sie einen neuen geschützten Speicherbereich erschafft und diesen mit einem Task bestückt. Das gleiche Konzept verwendet der Separationskernel-Hypervisor um geschützte Speicherbereiche zu definieren. Allerdings mit drei Unterschieden, denn der Hypervisor:
- konfiguriert die MMU einmalig – zum Zeitpunkt des Bootens. Die Partitionen sind bis zum Abschalten fest.
- führt keine Aufgabenplanung durch. Die Planung wird der Software überlassen, die auf der Partition läuft.
- verwendet eine spezielle MMU, die Second Level Address Translation (SLAT), die speziell zur Unterstützung der Virtualisierung entwickelt wurde.
Intel nennt seine SLAT EPT (Extended Page Tables), ARM bezeichnet seine Implementierung als Stage-2 MMU. SLAT bietet ein verschachteltes MMU-Paging, das es dem Hypervisor, der im privilegierten Modus läuft, ermöglicht, physischen Speicher zuzuordnen, um Partitionen zu erstellen. Der Trick besteht darin, dass Gastbetriebssysteme, die in diesen Partitionen laufen, ihre eigene MMU haben und diese wie üblich aus ihrem eigenen Kernelbereich verwenden, um ihre eigenen – wie üblich MMU-geschützten – Benutzerprozesse zu erstellen. Ein Gast-OS, das in dieser Art von virtualisierter Umgebung ausgeführt wird, merkt nichts von der Anwesenheit des Hypervisors.
Isolierung von Multicore-Störungen
Da das Problem der robusten Speicherpartitionierung durch den Hypervisor gelöst ist, bleibt das Problem der Zeitpartitionierung offen und kann untersucht werden. Die Speicheraufteilung ohne ein RTOS verbessert die Genauigkeit der Messung von Timing-Störungen (Bild 1). Es ist wie das Polieren der Linse eines Mikroskops. Multicore-Timing-Effekte können flüchtig und unvorhersehbar sein. Die Eliminierung des RTOS hilft in zweierlei Hinsicht.
Erstens wird dadurch der Speicherdruck im System verringert. Bei der Ausführung muss jeder Teil des RTOS-Codes und der Daten über die Speicherhierarchie in die CPU geladen werden, was eine hohe Speicher-Datenübertragungsrate erfordert und die Caches belastet. Die durch den Wettbewerb um genau diese Einheiten verursachten Interferenzen sind exakt das, was gemessen werden soll.
Zweitens ist der Speicherdruck des RTOS selbst unberechenbar. Der RTOS-Scheduler schaltet zwischen den Tasks um, wodurch ein komplexer Befehlsstrom erzeugt wird, der eine unvorhersehbare Belastung des Systems zur Folge hat. In beiden Fällen erzeugt das RTOS ein verstärktes Hintergrundrauschen, das die zu messende Störung verdeckt.
Ein neuer Trend zeichnete sich auf der HiPEAC-Forschungskonferenz (High Performance Embedded Architecture and Compilation) Anfang 2021 ab, auf der drei Forschungsprojekte ihre sicherheitskritischen Multicore-Softwareplattformen vorstellten:
- MASTECS (Multicore Analysis Service and Tools for Embedded Critical Systems)
- De-RISC (Dependable Real-time Infrastructure for Safety-critical Computer)
- SELENE (Self-Monitored Dependable Platform for High-Performance Safety-Critical Systems
Alle drei Projekte befassen sich mit demselben Problem – dem Multicore-Problem – und alle drei verwenden dazu einen Hypervisor.
Einsatz moderner Hardware zur Optimierung von VMs
Moderne Multi-Core-Prozessoren verfügen über eine Vielzahl von Ressourcen. Sie verfügen nicht nur über mehrere Kerne, sondern auch über Peripheriegeräte, Speicher und fortschrittliche Virtualisierungsfunktionen, die es ermöglichen, sie wie einen Lego-Baukasten für virtuelle Maschinen zu behandeln. Obwohl in Cloud-Rechenzentren stark genutzt, werden die modernen Hardware-Techniken oft nur unzureichend von RTOS und eingebetteten Hypervisoren unterstützt.
Separationskernel können verwendet werden, um Prozessor-Hardware-Ressourcen in hochsichere VMs zu partitionieren, die sowohl manipulationssicher als auch nicht umgehbar sind, und um einen streng kontrollierten Informationsfluss zwischen VMs und Peripheriegeräten einzurichten, so dass VMs isoliert sind, sofern dies nicht ausdrücklich erlaubt ist. Im Endeffekt ist ein Separationskernel ein „Prozessorpartitionierungssystem“, das es Entwicklern von eingebetteten Systemen ermöglicht, die Vorteile moderner Mehrkernprozessoren mit vollem Funktionsumfang zu nutzen.
Der Vorteil eines Separation Kernel Hypervisors liegt in der Einfachheit seiner Ableitung aus einem statischen Partitionierungssystem, das eine konfigurierte Hardware nutzt, um unabhängige, isolierte Hardwareinstanzen – oder Subsysteme – für VMs zu erstellen. Systeme werden so partitioniert, dass der Umfang des zu zertifizierenden Codes minimiert wird, da er von anderen Anwendungen isoliert ist.
Das VM-Plattformmodell gilt aufgrund dieser Einfachheit als die überlegene Architektur für die Sicherheit. Das macht die Entwicklung, die Anpassung des Timings und die Analyse zu einer unkomplizierten Übung mit minimalen Überraschungen und wenigen technischen Herausforderungen. Bemerkenswert ist auch, dass die Hardware-Virtualisierung erheblich verbessert wurde, sowohl bei Prozessoren als auch bei der Peripherie, so dass die negativen Eigenschaften des VM-Modells deutlich verringert werden konnten, wodurch die Gemeinsamkeit von RTOS und dem Hypervisor mit getrenntem Kernel trotz der Gegensätze gestärkt wird.
Ein separater Kernel-Hypervisor, der nachweislich deterministisch und in Echtzeit arbeitet, ist nach wie vor die einzige Möglichkeit, die Betriebskosten und -zeiten niedrig zu halten und gleichzeitig ein Höchstmaß an Sicherheit zu gewährleisten.
Eine weitere Überlegung, die von vielen angestellt wird, ist die Sicherstellung der Möglichkeit, sicherheitskritische Steuerungsalgorithmen als unabhängige Bare-Metal-Anwendungen einzusetzen, d.h. als eine Anwendung, die überhaupt kein Betriebssystem verwendet. Dies ermöglicht es Entwicklern und Evaluatoren, die Interferenz zwischen Softwarekomponenten zu messen und bedeutet, dass kritische Anwendungen ihre Zeitvorgaben einhalten werden. Mit einem separaten Kernel-Hypervisor ist jede VM in der Lage, gerade so viel RTOS auszuführen, wie für die Erledigung ihrer Aufgaben erforderlich ist. In einem Extremfall könnte eine VM ein komplettes Open-Source-RTOS wie FreeRTOS oder Micrium µC/OS ausführen. Eine andere, separate VM könnte eine Bare-Metal-Anwendung ausführen (Bild 2). Jede Kombination dieser VMs kann zu einem System zusammengefasst werden.
- Multicore, Modularität, Konnektivität – und Sicherheit
- Jetzt kommt die Z-Anwendung
