ECU: Hypervisor verwalten virtuelle Maschinen

Die meisten Autohersteller arbeiten bereits an der nächsten Generation elektronischer Architekturen, die unterschiedliche Anwendungen in nur einem Elektronikmodul kombinieren. Manchmal ist es jedoch nötig, einem Steuergerät neue Funktionen hinzuzufügen, da ansonsten ein neuer Domänencontroller erforderlich sein könnte. Die Herausforderung für den Hersteller des Elektroniksystems besteht nun darin Hard- und Software bereitzustellen, die eine sichere, geschützte und optimierte Lösung unterstützen.

Früher eins, künftig viele

Wer verstehen will, wie die neuen Anforderungen an die Elektronik realisierbar sind, muss sich zunächst darüber im Klaren sein, dass die Entwickler früherer Generationen von Embedded-Prozessoren, wie sie heute in Steuergeräten im Einsatz sind, diese ursprünglich für den Gebrauch mit nur einer einzigen Softwareanwendung konzipiert haben. Manche dieser Prozessoren unterstützten Embedded-Betriebssysteme (OS), mit deren Hilfe Anwender die Applikationssoftware entwickeln konnten. Sie teilten hierfür Aktionen in verschiedene einzelne Aufgaben (Tasks) auf, um dann mit dem OS einen Zeitplan für deren Abarbeitung festzulegen. Dieser Ansatz erweckt den Eindruck, dass Softwareaktivitäten unabhängig voneinander ablaufen. Sie sind jedoch in der Regel lediglich Einzelaspekte derselben Anwendung. Der Prozessor weist der Betriebssystemsoftware typischerweise spezielle Berechtigungen zu, die es ihm ermöglichen, die Tasks nach Bedarf zu starten und zu stoppen. Dieses etablierte Modell eignet sich gut für Hardware, die auf einem einzigen Betriebssystem basiert. Das gilt auch dann, wenn mehrere CPU-Kerne zur Verfügung stehen.

Bild 1: Eine mögliche Integrationslösung für Fahrzeuge mit Plug-in-Hybrid (PHEV) NXP

In künftigen Fahrzeugarchitekturen laufen aber mehrere Applikationen zur gleichen Zeit und es gibt die Möglichkeit, auch mehr als ein Betriebssystem gleichzeitig laufen zu lassen. Die Idee spezieller Berechtigungen erweist sich nun plötzlich als sehr restriktiv, da sich die beiden Betriebssysteme möglicherweise nicht auf einen auszuführenden Task einigen können. Darüber hinaus stellen in der Regel von verschiedenen Entwicklern unabhängige Unternehmen (Automobilhersteller und Zulieferer) die Applikationen bereit, die in verschiedenen Niederlassungen und Ländern unterschiedliche Tools einsetzen. Zudem müssen die nebeneinander vorhandenen Applikationen auch sicherstellen, dass ihre eigenen privaten Ressourcen (wie Speicher und Peripheriegeräte) sich nicht gegenseitig stören (Bild 1).

Virtuelle Maschinen

Bild 2: Beispiel eines SoC mit vier Kernen, auf dem zwei VMs unter einem Hypervisor laufen. NXP

Die Lösung dieses Problems ist in der Informatik seit langem bekannt. Die Applikationen sind so aufzuteilen, dass sie sich jeweils in einer eigenen dezidierten virtuellen Maschine (Virtual Machine, VM) ausführen lassen. Eine VM basiert auf der Fähigkeit eines Computers sich so zu verhalten, als wäre er eine andere Art von Computer, zum Beispiel bei der Ausführung von Linux auf einem PC oder einem Videospiele-Emulator auf einem Mac. Obwohl in Desktop- und anderen IT-Szenarien allgemein bekannt und verbreitet sind VMs in den in Fahrzeugen verwendeten Embedded-Mikroprozessoren bisher nicht in großem Umfang implementiert.

Ein Betriebssystem, das seine Berechtigungen zur Koordination von Tasks heranzieht, bezeichnen Entwickler auch als Supervisor, während sie die nicht privilegierten Aufgaben als Anwendersoftware bezeichnen. Das neue Softwaresystem, das die Super-Berechtigungsebene verwendet, wird daher auch als Hypervisor bezeichnet, da seine Privilegien eine höhere Ebene als die des Supervisors aufweisen. Daher lässt es sich auch für die Bestimmung der Aufgaben des Supervisors und seiner Anwendertasks innerhalb der ECU verwenden.

Hypervisor koordiniert und verwaltet

Die Hauptaufgabe des Hypervisors besteht darin, die für jede VM verfügbaren Funktionen zu definieren, indem er den Zugriff auf Onchip-Ressourcen wie CPUs, Speicher und Peripheriemodule einschränkt oder zulässt. Der Hypervisor kann mehrere VMs erstellen, indem er jeder einen unterschiedlichen Ressourcenanteil zuweist. Beispielsweise kann er die Verarbeitungszeit auf einer CPU in Zeitabschnitte unterteilen und nach Bedarf verschiedenen VMs zuteilen. Und eine VM kann sowohl auf eine gemeinsam genutzte CPU oder gleich mehrere CPUs zugreifen. In gleicher Weise lassen sich Speicher und Peripheriemodule gemeinsam nutzen oder einer einzelnen VM zuweisen. Die VMs wiederum müssen nur wenig oder gar nichts voneinander wissen und haben keinen Zugriff auf Ressourcen, die ihnen der Hypervisor nicht zur Verfügung stellt. Aus diesem Grund trägt der Hypervisor auch die Bezeichnung Virtual Machine Monitor (VMM).

Ein Hypervisor koordiniert den Zugriff auf Speicher und chipinterne Peripheriemodule mithilfe einer Kombination von Schutzmechanismen und einem Ressourcencontroller, der bausteinübergreifend funktioniert. Darüber hinaus stellt er auf bestimmten Peripheriemodulen Teilfunktionen zur Verfügung. Die gemeinsame Nutzung der CPU-Zeit verwaltet der Hypervisor normalerweise mithilfe eines Timers, der mitteilt, wann es nötig ist die CPU auf eine andere VM umzuschalten.

In einem Echtzeit-Applikationsprozessor stellt eine Memory Protection Unit (MPU) die Schutzmechanismen innerhalb der CPU bereit. In der Regel verwendet ein Betriebssystem eine MPU, um Speicher für die laufenden Benutzertasks freizugeben beziehungsweise zuzuweisen. Eine Software mit Supervisor-Berechtigungen kann einen eigenen privaten oder gemeinsam genutzten Bereich haben und auch die MPU auf die jeweilige Applikation konfigurieren. Der Hypervisor verfügt über eine zusätzliche unabhängige MPU mit höherer Priorität und auf dieser höheren Berechtigungsebene ist der für jede VM verfügbare Gesamtspeicher zugewiesen. Aktuelle Echtzeitprozessoren wie der ARM-Cortex-R52 bieten die dafür erforderlichen Funktionen.

Die Effizienz steigern

Da die auf den einzelnen virtuellen Maschinen laufenden Applikationen und nicht der Hypervisor die gesamten Nutzaktivitäten des Steuergeräts bereitstellen, ist es wichtig, die für die Ausführung des Hypervisors selbst herangezogenen Prozessorressourcen zu minimieren. Dies lässt sich durch einen Ressourcencontroller erreichen, der einen sich über den gesamten Baustein erstreckenden Schutzmechanismus implementiert und bestimmte wichtige Peripheriemodule für die weitere Zuordnung unterteilt. Wichtig ist, dass diese Unterteilung vollständig in die Hardware implementiert ist und auch die Funktion der CPUs abdeckt. Das ist insbesondere dann der Fall, wenn die zu kombinierenden Applikationen solche beinhalten, die ein hohes Maß an Sicherheit voraussetzen, und auch solche, bei denen Sicherheit keine große Rolle spielt.

Der Ressourcencontroller erweitert die Speicherschutzmechanismen auf andere Busmaster im System, wie zum Beispiel DMA oder Ethernet, und verbessert die verfügbaren Speicher- und Peripherieschutzfunktionen für die Kerne. Da er sich so konfigurieren lässt, dass er die auf einer CPU laufende VM erkennt, kann er diesen Schutz ohne weitere Hypervisor-Aktivitäten oder zusätzlichen Aufwand bereitstellen. Auf diese Weise ist es möglich, eine VM beispielsweise auf mehreren Kernen auszuführen, während ein Teil der Prozessorkapazitäten dann für eine andere VM zur Verfügung steht. Ein solches Schema kann einer VM beispielsweise die äquivalente Prozessorleistung von 1,5 Kernen und einer anderen die von 2,5 Kernen zuweisen, wobei die Hardware diese Zuweisung vollständig unterstützt (Bild 2).

Bild 3: Sichere Verarbeitung als ein Element innerhalb eines systematischen Sicherheitskonzepts für ein Fahrzeug NXP

In vielen Fällen ist es wünschenswert oder erforderlich, Ressourcen wie Speicher und Peripheriefunktionen einer bestimmten VM zuzuweisen. In einigen Fällen kann es jedoch besser oder notwendig sein, diese Ressourcen auf mehrere VMs zu verteilen. Eine ideale Lösung würde auch Funktionen einschließen, die dabei helfen Peripheriemodule (zum Beispiel I/O) unter Verwendung von angepasster Hardware und nicht von Hypervisor-Software zu unterteilen, sodass mehrere VMs diese gemeinsam nutzen können. Das vermeidet den Aufwand für zusätzliche Software, der normalerweise in solchen Fällen erforderlich ist.

Komplexität birgt Sicherheits-Herausforderungen

Durch die Integration mehrerer Applikationen in Multi-Core-Systemen durch hardwarespezifische Maßnahmen erhöht sich jedoch auch das Potenzial für Hackerangriffe auf die Systemsicherheit. Die Vergrößerung der Angriffsfläche ist darauf zurückzuführen, dass das System für Applikationen aus mehreren Quellen geöffnet und der neue Hypervisor mit extrem hohen Rechten ausgestattet ist.

Eine Sicherheitslücke in einer der Applikationen und insbesondere im Hypervisor könnte es einem Angreifer ermöglichen, nicht nur die Zielapplikation, sondern auch das gesamte System zu stören oder sogar zu übernehmen. Dies ist insbesondere dann von Belang, wenn das Steuergerät eine Applikation enthält, die die funktionelle Sicherheit eines Fahrzeugs gefährden könnte.

Bild 4: Der S32S24-Prozessor mit Hardware-Hypervisor und Security Engine Support NXP

Das Thema Sicherheit lässt sich am besten mit einem mehrschichtigen Ansatz unter Kontrolle bringen. Für das Steuergerät kann dies mit einer Kombination aus Hard- und Software erfolgen. Beim Booten ist es wichtig, dass der Code für das Steuergerät vertrauenswürdig ist, aber dennoch schnell lädt. In diesem Fall ist eine Hardwareunterstützung für komplexe Kryptografieverfahren erforderlich. Um diesem Anspruch Rechnung zu tragen, lassen sich der Programmcode und die Daten des Benutzers verschlüsseln und die Hardwarebeschleunigung zum zeitnahen Entschlüsseln verwenden. Darüber hinaus ist es entscheidend, dass die Sicherheitshardware und ihre Kryptografieschlüssel vor einer Gefährdung durch die ausgeführten Applikationen beziehungsweise durch Hardwareverfahren wie Seitenkanalangriffe geschützt sind (Bild 3).

Hochleistungsplattform für Hypervisor-Anwender

Der S32S-Prozessor von NXP bietet eine sichere und leistungsstarke Plattform mit umfassender Hardwareunterstützung für Hypervisor-Anwender und flexiblen Sicherheitsfunktionen. Damit Anwender robuste Lösungen schneller auf den Markt bringen können, hat NXP eine Partnerschaft mit dem Softwareanbieter Open Synergy geschlossen, um dessen Knowhow in die Entwicklung von Hypervisor-Software für die S32S-Prozessorfamilie einzubringen. Der COQOS-Micro-Hypervisor nutzt die Funktionen des S32S247-Prozessors, um unabhängige virtuelle Maschinen zu realisieren, die bis zur Sicherheitsstufe ASIL-D arbeiten (Bild 4).

(aok)