Funktionale Sicherheit
Hardware oder Software? - Was ist sicherer?
Fortsetzung des Artikels von Teil 1
Hardware-Konsolidierung mit heterogenen Core-Architekturen
Die andere Seite der Hardware-Trennung ist die Hardware-Konsolidierung. Ein höher integriertes System-on-Chip ist mit einem kleinen Core mit dediziertem Speicher-, Takt- und Energiemanagement auf demselben Chip wie bei größeren Systemen ausgestattet, um eine leistungsfähigere Kommunikation zu ermöglichen. Ein Beispiel ist in Bild 3 dargestellt.
Dabei ist zu berücksichtigen, dass die Trennung zwischen den verschiedenen Cores frei von Störungen ist, da die Trennung der Performance-Domäne und der Sicherheitsdomäne weiterhin vorhanden sein müssen. Das heißt, dass keine dynamischen Änderungen auf einer Seite der anderen Seite erlauben dürfen, sich anders zu verhalten. Wenn sich die Cores Konfigurationsregister, Speicherbusse oder Cache-Speicher teilen, sind dies offensichtliche Störquellen, die zusätzlichen Schutz benötigen. In diesen Fällen muss der SoC-Anbieter versichern, dass die Trennung für einen Betrieb gemäß dem Sicherheitsstandard nachgewiesen wurde.
Jobangebote+ passend zum Thema
Diese Art von SoC beseitigt also einige der Engpässe bei der Kommunikation und beim Datenaustausch – zumindest wenn der interne SoC-Speicher oder ähnliche Pfade sicher verwendet werden können. Es gibt aber immer noch das Problem der Skalierbarkeit von Algorithmen zwischen der Sicherheits- und Performance-Domäne. Der Grund: die Sicherheitsseite ist meist auf die kleinere MCU beschränkt, die nun in den großen SoC mit integriert ist.
Erforderlich ist, dass sowohl Sicherheits- als auch Performance-Algorithmen auf denselben Cores in jedem SoC ausgeführt werden. Es besteht also Bedarf an Software auf höherer Ebene, die eine Isolation und Trennung ermöglicht. Ein gängiges Konzept für die Softwaretrennung ist die Annahme, die Virtualisierung mithilfe eines Hypervisors sei der einzige Weg. Es muss jedoch auch die Separationskernel-Architektur mit in Betracht gezogen werden.
Trennnung durch Software-Separationskernel
Ein geeigneter Separationskernel bietet eine Isolation, die der Hardware-Isolierung entspricht. Er ermöglicht eine Aufteilung der Anwendungen auf mehrere Kritikalitätsebenen, was in der Gesamtsystemarchitektur erheblich weiterhilft, d. h. beim Erstellen einer Performance- und einer Sicherheitsdomäne innerhalb des gleichen RTOS. Das Integrity RTOS von Green Hills Software ist ein Beispiel für eine RTOS-Separationskernel-Architektur.
Auf einem solchen System muss nur einer Teilmenge der Anwendungen eine Sicherheitsintegritätsstufe zugewiesen werden, und der Rest kann als normaler Standardcode beibehalten werden. Dies wirkt sich positiv auf skalierbare Sicherheitsalgorithmen aus, da diese als Performance-Algorithmen innerhalb der Sicherheitsdomäne ausgeführt werden können – wobei nicht alle Algorithmen dort ausgeführt werden müssen. Da Code in Anwendungen von Code in anderen Anwendungen isoliert ist, ist es nicht mehr nötig, den gesamten Code auf höchster Ebene zu testen und zu zertifizieren. Dies hilft bei prozessbezogenen Elementen, wenn die ISO 26262 oder andere Standards eingehalten werden müssen, da sich der Zertifizierungsaufwand dadurch erheblich verringert. Daher werden die Sicherheitsdomäne und die Performance-Domäne auf demselben SoC ausgeführt, solange der Separationskernel die tatsächlichen Cores des SoC unterstützt (Bild 4).
Zieht man die Leistungsfähigkeit dieser Systeme in Betracht, ist zu beachten, dass selbst bei einem Zugriff auf den Betriebssystemcode sich auf der Hardware-Ebene Cache-Speicher und Pipelines und andere Optimierungen befinden, die nicht sichtbar sind, außer dass sie unterschiedliche Performance-Ergebnisse liefern. Die Endanwendung muss noch Optimierungen in ihrem Kontext durchlaufen, in dem sie ausgeführt wird, wobei nur dann die tatsächliche Leistungsfähigkeit gemessen werden kann.
Ein weiterer Vorteil von Separationskerneln ist, dass sie auch die Software-Konsolidierung mehrerer Software-Funktionen auf demselben SoC ermöglichen, während sie dennoch logisch getrennt sind. Solange die Plattform über ausreichende Performance verfügt, ist es sinnvoll, immer mehr unabhängige Funktionen auf der Plattform zu integrieren, ohne dass ein Hardware-Redesign erforderlich ist.
Trennung durch Virtualisierung
Das andere Verfahren für die Softwaretrennung wird als Hardware-Virtualisierung bezeichnet. Dabei werden spezielle Ausführungspfade verwendet, damit mehrere Betriebssysteme die CPU und den Speicher des SoC gemeinsam nutzen können. Das Framework, das dies ermöglicht, wird als Hypervisor oder Virtual-Machine-Monitor bezeichnet. Es erstellt die Virtual-Machine-Instanzen, die verschiedene Betriebssysteme auf einer einzigen physikalischen Hardwareplattform ausführen können. Die Virtualisierung lässt sich durch moderne CPU-Funktionen wie ARM-VE und Intel VT-x mittels Hardware beschleunigen, die als hardwarebeschleunigte Virtualisierung bezeichnet wird. Diese Art der Virtualisierung unterscheidet sich von der Betriebssystem-Virtualisierung, bei der sich Instanzen (Container) einen einzigen Betriebssystem-Kernel teilen.
Die Einführung von Hypervisor in die Software-Architektur – für mehr Sicherheit – bringt Herausforderungen mit sich, da sich die Komplexität erhöht. Der Hypervisor muss Speichertrennung und -schutz sowie die Planung verschiedener Workloads und die Verwaltung der Berechtigungsstufen der virtualisierten Gastbetriebssysteme vornehmen. Der Hypervisor selbst wird zur höchstprivilegierten Software im System, d. h. dass im Zusammenhang mit Sicherheitsanwendungen auch der Hypervisor selbst als sicherheitsrelevant betrachtet werden muss. Im Wesentlichen plant ein Hypervisor mehrere Betriebssysteme, so wie ein Separationskernel Anwendungen plant.
Hypervisors können auch kategorisiert werden: in native oder Bare-Metal (Typ 1) und in gehostete Hypervisors (Typ 2). Hypervisors vom Typ 1 laufen direkt auf der Hardware (Bild 5), während gehostete Hypervisors ähnlich wie normale Anwendungen auf dem tatsächlichen Betriebssystem laufen. Die Unterscheidung zwischen den Typen ist nicht ganz klar, da einige Konfigurationen mehrdeutig sein können. In einigen Typ-1-Implementierungen gibt es auch eine anfängliche Gastdomäne mit höheren Berechtigungsstufen und dediziertem Peripheriezugriff, die als Domäne 0 bezeichnet wird. Letztere findet sich in der Hypervisor-Lösung Xen. Solche Lösungen erfordern natürlich auch, dass der gesamte Domäne-0-Gast in einer Sicherheitsimplementierung entsprechend sicherheitsrelevant ist.
Neben der notwendigen Trennung (um Sicherheit zu erzielen) besteht der wesentliche Vorteil der Virtualisierung in der Möglichkeit, Hochleistungsalgorithmen für ein Betriebssystem wie Linux wiederzuverwenden. Gleichzeitig wird ein effizienter Pfad zur Isolierung solcher Anwendungen von Sicherheitsanwendungen bereitgestellt, die in einem virtualisierten Sicherheits-RTOS auf demselben System ausgeführt werden. Darüber hinaus sollte der Hypervisor IPC-Mechanismen (Inter Process Communication) ermöglichen, um Datenübergänge zwischen einer Sicherheitsdomäne und einer Performance-Domäne zu unterstützen, da diese Art des Datenaustauschs wichtig ist.
Der Nachteil ist, dass die Typ-1-Virtualisierung von Betriebssystemen unerwünschte Latenz zur Event-Behandlung hinzufügen kann, was Probleme in Echtzeit-Anwendungen verursacht. Darüber hinaus wird die Planung von Workloads über die Cores auf dem SoC erschwert und kann die Leistungsfähigkeit negativ beeinflussen.
Typ-2-Hypervisoren werden meist als leistungsschwach angesehen und sind auf die Sicherheitslösungen des Host-Betriebssystems beschränkt. Dies liegt daran, dass der Hypervisor entweder die Hardware-Beschleunigung nicht ausnutzt, keine direkte Gerätezuweisung (Pass-Through) zulässt und/oder auf einem Nicht-Echtzeit-Betriebssystem ausgeführt wird. Die Verwendung eines Trennungsarchitektur-Mikro¬kernels vermeidet diese Nachteile und schafft eine interessante Hypervisor-Lösung. Darüber hinaus können native Anwendungen in einem solchen Szenario sowohl die Sicherheitsanforderungen als auch die Echtzeit-Anforderungen für niedrige Latenz erfüllen. Ein Beispiel für eine solche Hypervisor-Architektur ist Green Hills’ Integrity Multivisor (Bild 6).
Komplexität reduzieren
Funktionale Sicherheit in leistungsstarken Systemen abzuwägen erfordert eine Trennung durch Hardware oder Software. Die Hardware-Trennung ist in Sachen Skalierbarkeit und Datentransport eingeschränkt, sorgt jedoch für eine einfache Trennung der Sicherheits- und Performance-Domäne. Andererseits bietet die Software-Trennung skalierbare Lösungen für Performance contra Sicherheit, erfordert jedoch manchmal eine komplexe Software-Lösung durch Virtualisierung. Der Mittelweg mit einer Separationskernel-Architektur stellt den am wenigsten komplexen Pfad für die Software-Trennung bereit. Damit sind skalierbare Sicherheitsanwendungen möglich, die auf Hochleistungs-CPU-Cores ausgeführt werden können.
Der Autor
Marcus Nissemark
arbeitet als Field Applications Engineer bei Green Hills Software in Schweden. Zuvor war er über 15 Jahre als Software-Architekt und Entwickler tätig. Dabei entwickelte er Steuerungen und Display-Computer für schwere Fahrzeuge, medizinische Geräte und militärisches Equipment. Er kennt sich mit mehreren Betriebssystemen und deren Treiber-Entwicklung aus, ebenso mit Entwicklungsprozessen und Produktmanagement.
- Hardware oder Software? - Was ist sicherer?
- Hardware-Konsolidierung mit heterogenen Core-Architekturen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Cadence/Green Hills
Geld-gepolsterte Partnerschaft für Safety und Security
IoT
Cloud-Anbindung mit Security-Zertifikat
Software-Projektmanagement
Multicore-Software mit APP4MC entwickeln
RIOT Summit 2018
Agiles IoT mit Open Source
Sicherheitsstandard für autonome Autos
Volvo Cars stellt autonom fahrende Konzeptstudie 360c vor
CodeSonar5
Statische Code-Analyse für C# und Visual Studio
Entwicklungstools
Automatisch Testen mit ARMs DS-5
Effizienter Test von Software-Varianten
Auf Nummer sicher
Sicherheitskritische Systemsoftware
Green Hills bringt Linux ins Auto-Cockpit
Safety-Steuerungen
HIMA eröffnet Embedded-Entwicklungsstandort in Kassel
