Systeme auf Multicore-Prozessoren
Multicore, Modularität, Konnektivität – und Sicherheit
Fortsetzung des Artikels von Teil 1
Jetzt kommt die Z-Anwendung
Eine »Z-App« – Kurzform für Z-Applikation – ist eine Sammlung virtueller Maschinen mit Separationskernel. Das Z-App-Konzept richtet sich an Anwendungsentwickler, die ein ausgefeiltes, hartes Echtzeitverhalten mit Funktionsschutz und Domänentrennung erreichen und gleichzeitig den mit der Verwendung von RTOS verbundenen Verwaltungsaufwand (Overhead) vermeiden möchten.
Z-App wurde ursprünglich von Lynx Software Technologies entwickelt, um ein Problem in der Automobilbranche zu lösen. Die klassische AUTOSAR-Stack-Implementierung, die in dieser Branche verwendet wird, führt alle Funktionen in einem flachen Adressraum aus und verwendet ein Mikrocontroller-RTOS, typischerweise das ETAS RTA-OS, um sie zu planen. Ein solcher Ansatz bietet keine Bereichstrennung oder Funktionsschutz.
Dieses Problem wurde durch die Einführung eines flexiblen Schedulers (Z-scheduler) gelöst, der von einer speziellen VM ausgeführt wird. Der Z-Scheduler ersetzt die Scheduling-Funktion von RTA-OS und ist ein Funktionsaufrufer, der mit Hilfe von Hypervisor-Kontextwechsel-»Hypercalls« in eine separate Speicherdimension springt. AUTOSAR-Funktionen sind als »Z-Funktionen« in separaten VMs implementiert und bieten so die erforderliche Scheduling-Fähigkeit in Verbindung mit Domänen- und Funktionsschutz.
Die Z-Anwendungsarchitektur
Die heutige Z-Anwendung ist eine Sammlung von virtuellen Maschinen mit einem separaten Kernel-Hypervisor, die zu einer gemeinsamen Ausführungsgruppe gehören. Jede Z-App-Instanz bildet einen konventionellen Rahmen für Bare-Metal-Anwendungen und modelliert einen Programmstapel, so dass eine Programmausführung ein Standard-Speicherlayout erstellt, um die Ausführung von Funktionen innerhalb eines Hauptprogramms zu organisieren (Bild 3).
In der Praxis ahmt Z-App zur Laufzeit ein herkömmliches Computerprogramm nach, wobei der Z-Scheduler die Rolle des »Haupt«-Einstiegspunkts übernimmt. Jeder Z-Funktion wird eine eigene VM (in der Lynx-Terminologie ein »Raum«) zugewiesen, so dass sie das Äquivalent einer Methode oder Funktion in einem herkömmlichen Programm ist, jedoch mit dem Vorteil des Schutzes durch Trennung. Global-/Heap-Speicher und Stack-Speicher werden genau wie in einem herkömmlichen Programm zugewiesen und verwendet.
Scheduling
Im Gegensatz zu einem RTOS, das in der Regel die Thread-Prioritätsplanung in einem unzugänglichen »Blackbox«-Scheduler verwaltet, liegt die Planung in einer Z-App in der Verantwortung der Anwendung, die im Gastbereich in Form ihres Z-Schedulers läuft. Die Eigenschaften der Z-Apps stellen nicht nur sicher, dass die Adressraumtrennung beibehalten wird, sondern erleichtern auch die Implementierung von benutzerdefinierten Zeitplänen.
Der Z-Scheduler ruft die Z-Funktionen (zFns) nach einem Zeitplanungsalgorithmus auf, der an die jeweilige Anwendung angepasst werden kann. Bild 4 zeigt zum Beispiel eine Z-Scheduler-Implementierung eines periodischen Schedulers mit HW-Timer-erzwungenen Budgets.
Zeitspende
Wie in Bild 5 dargestellt, gibt es auch eine Zeitspendefunktion, die es einer Z-Funktion ermöglicht, den Rest eines Zeitabschnitts an eine andere Z-Funktion zu spenden. Der Implementierungsmechanismus ist so verpackt, dass er wie Funktionsaufrufe der Standardsprache C aussieht.
Entwicklern stehen Messbibliotheken und -konstrukte für die Analyse zur Verfügung, beispielsweise um die Zeit in einer Z-Funktion, die verbleibende Zeit nach der Rückkehr (Slack), Ausnahmen vom zeitlichen Ablauf und verschiedene PMU-Werte (Performance Monitoring Unit) zu bestimmen. Die Architektur und ihre Funktionen eignen sich für ein hierarchisches Scheduling, so dass VMs nach unabhängigen Scheduling-Schemata und Prioritätsgruppen ausgeführt werden können.
Überlegungen zur Zertifizierung
Die Kosten für die Zertifizierung sind ein Hauptanliegen in vielen Sektoren, in denen diese Technik zum Einsatz kommen könnte. Die Integrität, die durch den Funktionsschutz und die Domänentrennung gewährleistet wird, wurde bereits erörtert, aber vielleicht weniger offensichtlich ist die Modularität der diskreten Z-Funktionen, die die Wiederverwendung und die Verhaltensanalyse unterstützt.
Bild 6 zeigt einen Entwurf, bei dem FACE-Anwendungen (Future Airborne Capability Environment) auf tiefen Abstraktionsschichten beruhen, die über mehrere CPU-Kerne implementiert sind. Bei diesem Entwurf stellt allein die potenzielle Menge an Interferenzen, die die FACE-Anwendung als Gast in der Hardware erzeugen kann, eine anspruchsvolle Analyse dar, um sicherzustellen, dass kritische Anwendungen ihre Zeitvorgaben einhalten können.
Diese Illustration zeigt auch wie unpraktisch das Ausführen einer kritischen Anwendung auf tiefen Abstraktionsschichten ist, die die Integritäts- und Timing-Analyse einer komplexen Laufzeitumgebung gewährleisten müssen. Hier können Störungen sowohl von der Hardware als auch von den Abstraktionsschichten ausgehen, auf die gleichzeitig von gemeinsam ausgeführten Anwendungen zugegriffen wird.
Das in Bild 7 abgebildete System zeigt einen Entwurf, der die Abstraktionsebenen minimiert und die Abhängigkeiten auf grundlegende Softwarekomponenten für sicherheitskritische Anwendungen beschränkt. Der FACE-Teil des Entwurfs hat nur begrenzten Hardware-Zugriff und wird nur für den einfachen Transport von Paketen verwendet, um die Interoperabilität des Netzes aufrechtzuerhalten, wogegen die sicherheitskritischen Bare-Metal-Anwendungen eigenständig ablaufen.
Dieses Konzept ermöglicht einen präzisen Blick auf den Ort, an dem kritische Anwendungen ausgeführt werden, sowie auf deren Abhängigkeiten. Evaluatoren können den ungünstigsten Störungsfall messen, der von einer bestimmten virtuellen Maschine erzeugt wird. Sie erhalten auch die Sicherheit, dass es keine internen Software-Plattform-Abhängigkeiten von komplexen Abstraktionen wie »Syscalls« in SMP-Kerneln (Symmetric Multi-Processing), internen Thread-Warteschlangen, allgemeinen Datensperren und Kohärenz-Protokollen gibt, die die Interferenzanalyse erschweren könnten.
Literatur
[1] Rushby, J.: Design and Verification of Secure Systems. ACM Operating Systems Review, 1981, H. 5, S. 12–21, www.csl.sri.com/users/rushby/papers/sosp81.pdf.
[2] Rushby, J.: Proof of Separability – A Verification Technique for a Class of Security Kernels. 5th International Symposium on Programming, Turin 1982, Konferenzband, Springer Verlag, Lecture Notes in Computer Science, Folge 137, S. 352–367, www.csl.sri.com/users/rushby/abstracts/isp82.
Der Autor
Arun Subbarao
ist als Vice President of Engineering & Technology bei Lynx Software Technologies für die Entwicklung von Produkten für den Embedded- und Edge-Computing-Markt verantwortlich. Er verfügt über fundiertes Fachwissen in den Bereichen Sicherheit und Virtualisierung und hat mehrere branchenweit führende Techniken entwickelt, die zu innovativen Softwareprodukten geführt haben.
Subbarao war federführend an der Entwicklung des Separationskernels und Hypervisors LynxSecure sowie an Softwarepatenten in den Bereichen Sicherheit, Schutz und Virtualisierung beteiligt. Nach dem Bachelor-Abschluss in Informatik in Indien, hat er Informatik (M. Sc.) an der staatlichen Universität von New York in Albany, USA, und Betriebswirtschaft (MBA) an der Universität in Santa Clara, USA, studiert.
- Multicore, Modularität, Konnektivität – und Sicherheit
- Jetzt kommt die Z-Anwendung
