So lässt sich ein MPSoC in gemischten sicherheitskritischen Systemen zertifizieren

In jüngster Zeit hat die Produktion von MPSoC-Designs zugenommen. Dies wurde durch die Marktnachfrage nach höherer Leistung und Kapazität, geringerem Stromverbrauch und niedrigen Stücklistenkosten vorangetrieben. Darüber hinaus verbessern einige Halbleiterhersteller ihre Konstruktionen weiter mit Sicherheitszonen, die die Aktivierung und Verwendung von Multicores noch schwieriger machen.

Bild 1: Eine Beispielarchitektur für ein gemischtes sicherheitskritisches System mit sicherer und nicht sicherer Domain. Mentor, a Siemens Business

Ergebnis dieser technologischen Entwicklungen ist das Konzept gemischter sicherheitskritischer Systeme.  Ein gemischtes sicherheitskritisches System ist ein System, das die Ausführung mehrerer Anwendungen mit unterschiedlichen Sicherheitsintegritätsstufen (SIL) oder unterschiedlichen Kritikalitäten, wie zum Beispiel sicherheitskritisch und nicht sicherheitskritisch, auf einem einzigen MPSoC erfordert. Beispielsweise muss in einem fahrzeuginternen Gateway für ein autonomes Fahrzeug eine Seite des Gateways mit einem ASIL-System (Automotive Safety Integrity Level) interagieren, während die andere Seite des Gateways Daten an andere Systeme weiterleitet (möglicherweise auch in die Cloud), für die keine funktionale Sicherheitsanforderung besteht.

Embedded Multicore Framework

Das Mentor Embedded Multicore Framework ermöglicht die Entwicklung einer AMP-Softwarearchitektur (Asymmetric Multiprocessing) für eine breite Palette homogener und heterogener MPSoCs. Das Multicore Framework verwaltet dazu die Systemressourcen und die Kommunikation zwischen den beteiligten Softwarekontexten.

Bild 2: IPC-Komponenten bei Multicore Framework Cert. Die Basistechnologie bietet die Möglichkeit, betriebssystemübergreifend auf heterogener Hardware zu kommunizieren. Mentor, a Siemens Business

Das Multicore Framework richtet dazu mit einer Implementierung von RPMSG (Restricted Permission Message) einen Kommunikationskanal zwischen dem Master-Betriebssystem und Remote-Betriebssystemen ein, so dass die Daten über diesen Kanal übertragbar sind. Darüber hinaus wird die Remoteproc-Funktion für das Lebenszyklusmanagement verwendet. Beispielsweise lässt sich ein Betriebssystem oder ein Anwendungsstack auf Remote-Prozessoren starten und stoppen, wodurch der Stromverbrauch sinkt. Im Weiteren konzentriert sich dieser Artikel auf die Kommunikation zwischen Prozessoren mit RPMSG.

Implementierung nicht zertifizierter und zertifizierter Software

Embedded Multicore Framework Cert von Mentor verbessert die Entwicklung gemischter Kritikalität zusätzlich, indem es die Implementierung von nicht zertifizierter und zertifizierter Software auf homogenen oder heterogenen Multicoreprozessoren ermöglicht. Durch die Trennung wird die Anzahl der zu zertifizierenden Codezeilen reduziert, wodurch sich die Gesamtzeit und die Kosten für die Zertifizierung verringern.  Anwender können auch vorzertifizierte Komponenten verwenden, wodurch ihre Entwicklungs- und Zertifizierungszeiten kürzer ausfallen.  Dieses umfassende Framework ermöglicht es Entwicklern auch, die vielen Herausforderungen im Zusammenhang mit der Interprozessor-Kommunikation (IPC) in einem zertifizierten System zu bewältigen.  Die Verwendung von Multicore Framework Cert mit Nucleus Safety Cert und Mentor Embedded Linux Flex OS bietet dem Anwender einen vollständigen Software-Stack für jedes gemischte sicherheitskritische System.

Allgemeine Sicherheitsarchitektur

Bild 3: Klassifizierung in sichere und nicht sicher Domains. Mentor, a Siemens Business

Vor der Entwicklung eines gemischten sicherheitskritischen Systems sind eine Reihe von Entscheidungen über die Architektur zu treffen. Welche Komponenten müssen sicherheitszertifiziert sein und welche nicht? Wie wird das System eine ordnungsgemäße Trennung gewährleisten?  Wie ist der Bootprozess für das System? Wie soll das System zwischen den sicheren und nicht sicheren Domains kommunizieren? Diese Entscheidungen erläutern die nächsten Abschnitte.

Sichere und nicht sichere Domains

Um die Kostenersparnis bei der Zertifizierung der funktionalen Sicherheit voll ausschöpfen zu können, muss festgelegt sein, welche Komponenten sich in der sicheren Domain befinden müssen und welche Komponenten sich außerhalb dieser Domain befinden können.

Die allgemeinen Anforderungen für die sichere Domain sind:

• Einen Isolationsperimeter im System einrichten.
• Systemfehler in der Software erkennen und vermeiden.
• Betriebsparameter der Hardware, wie Temperatur, Spannung, Takt, Fehler und andere Systemvariablen, überwachen.
• Den korrekten Betrieb der Hardware verifizieren und eine Diagnose durchführen.
• Ein sicherheitszertifiziertes RTOS ausführen.

Die nicht sichere Domain ist normalerweise für die Bereitstellung einer umfangreichen Ausführungsumgebung wie einer Benutzeroberfläche oder einer externen Vernetzung zuständig und braucht keine Zertifizierungsanforderungen zu erfüllen (Bild 1).

Trennung und Booten

Bild 4: Das Referenzsystem besteht aus drei Subsystemen, die im Xilinx-Vivado-HLS-Prozessorkonfigurationsassistenten (PCW) erstellt werden. Mentor, a Siemens Business

Einer der wichtigsten Faktoren bei gemischten sicherheitskritischen Systemen ist die Verwendung einer Isolierung, die die verschiedenen Softwarekomponenten voneinander trennt. Diese Isolierung ist wichtig, um die Ausbreitung von Fehlern und Störungen durch den nicht sicheren Bereich zu verhindern. Hardwareunterstützte Trennungsfunktionen, die viele MPSoC-Architekturen bereitstellen, erleichtern die erforderliche Trennung zwischen der sicheren Domain und der nicht sicheren Domain. Dies umfasst die Trennung von Verarbeitungsblöcken, Speicherblöcken, Peripheriegeräten und Systemfunktionen.

Bei Systemen mit einem dedizierten Systemcontroller für das Power Management muss der Controller Teil der sicheren Domain sein. Darüber hinaus muss der Controller korrekte Berechtigungen erzwingen, damit Anforderungen aus der nicht sicheren Domain ordnungsgemäß überprüft werden. Nicht korrekte Berechtigungen können einen Bypass-Kanal für den Zugriff auf sichere Ressourcen ermöglichen. Eine weitere wichtige Entscheidung betrifft die Frage, wann die Isolation durchgesetzt werden soll. Die möglichen Optionen sind Boot-Zeit, Post-Boot-Zeit (Initialisierung) und Laufzeit. Für Systeme mit komplexen Startszenarien wird empfohlen, die Isolation frühzeitig zu erzwingen.

Ein weiterer Faktor eines gemischten sicherheitskritischen Systems ist das Booten. Wie das System gestartet wird, wirkt sich auf die Domaintrennung und ein sicheres Booten aus. Bei der Konstruktion ist darauf zu achten, was zuerst zu konfigurieren ist. Der authentifizierte Start sollte ausreichen, um die Integrität der Komponenten sicherzustellen. Ein sicherer Start mit verschlüsselten Images ist zur Geheimhaltung erforderlich.  Die Vertrauenskette ist wünschenswert, um zu verhindern, dass böswillige Inhalte in das System gelangen. Schließlich kann es weitere spezifische Systemanforderungen geben, zum Beispiel die Anforderung, dass das Gerät innerhalb einer bestimmten Zeit nach dem Einschalten eine gewisse Kommunikation von der Anwendung ermöglichen muss.

Puffer validieren und Interrupt-Überflutung verhindern

Der Systemarchitekt muss überlegen, wie das Design die Daten sicher zwischen den sicheren und nicht sicheren Domains übermittelt. Gemischte sicherheitskritische Systeme müssen den IPC besonders sorgfältig behandeln, um sicherzustellen, dass die sicheren und nicht sicheren Domains getrennt bleiben und dass die nicht sichere Domain die sichere Domain nicht kontaminieren oder stören kann. Es gibt zwei wichtige Punkte für eine zuverlässige Kommunikation zwischen sicheren und nicht sicheren Domains: die Puffervalidierung und das Verhindern der Interrupt-Überflutung.

Pufferparameter wie Adresse, Größe und Berechtigungen sind zu überprüfen, bevor die sichere Domain sie verwendet. Die Grenzen des Puffers müssen gründlich überprüft werden, wobei alle Puffer zu verwerfen sind, die außerhalb des gültigen Bereichs liegen. Dabei ist die Pufferüberprüfung mit der richtigen Fehlerantwort zu kombinieren, um dem Anwender einen Einblick in das System zu geben und möglicherweise böswillige Aktivitäten zu erkennen.

Der nicht sichere Bereich könnte den Kommunikationskanal möglicherweise mit Interrupts überfluten, wobei diese Last die zeitlichen Isolationsanforderungen des Systems verletzen könnte, wenn keine spezielle Behandlung vorgesehen ist. Daher ist ein Mechanismus notwendig, um die Interrupts auf der nicht sicheren Seite zu drosseln, oder auf der sicheren Seite muss der Polling-Modus unterstützt werden (Bild 2).

Multicore Framework Cert

Multicore Framework Cert ist geeignet, um das Problem der Kommunikation zwischen verschiedenen Kritikalitätsbereichen zu lösen. Die Basistechnologien bieten die Möglichkeit, betriebssystemübergreifend auf heterogener Hardware zu kommunizieren. RPMSG definiert das Kommunikationsprotokoll und die APIs. Es verwendet VirtIO als Shared-Memory-basierte Transportabstraktion. Multicore Framework Cert bietet erweiterte gebundene Überprüfungen, um die Integrität von Datenstrukturen mit gemeinsamem Speicher sicherzustellen. Es bietet auch Interrupt-Drosselung und Polling-Modus, um die Interrupt-Überflutung zu verhindern. Der Code wurde einer umfassenden statischen und dynamischen Codeanalyse unterzogen, um eine Vielzahl von Zertifizierungsanforderungen zu erfüllen.  Darüber hinaus bietet das Multicore Framework APIs, mit denen sich die Kommunikation beim Neustart der nicht sicheren Domain nahtlos wiederherstellen lässt.

Anwendungsfall Patientenüberwachung

Bild 5: Der Bootablauf auf Xilinx UltraScale+ MPSoC, beginnend mit der Initialisierung der PMU und der Freigabe der Konfigurations- und Sicherheitseinheit CSU. Mentor, a Siemens Business

Das folgende Beispiel zeigt ein gemischtes sicherheitskritisches System basierend auf der Xilinx-Zynq-UltraScale+-MPSoC-Plattform. Die Plattform besteht aus einem Cluster von ARM-Cortex-A53-Kernen als APU (Application Processing Unit) und einem Cluster von ARM-Cortex-R5-Kernen als Real-Time Processing Unit (RPU). Die RPU ist sehr gut geeignet, um Anwendungen für funktionale Sicherheit auszuführen. Das System enthält zur Systemüberwachung und für das Power Management einen dedizierten Steuerprozessor, die Platform Management Unit (PMU). Es gibt auch Speicher- und Peripherieschutzhardware, die Xilinx Memory Protection Unit (XMPU) und die Xilinx Peripheral Protection Unit (XPPU), um die Isolation zu implementieren.  Darüber hinaus gibt es Optionen für ein sicheres Booten zum Einrichten der Isolation.

Das folgende Beispiel bezieht sich auf ein Patientenüberwachungssystem, bei dem der für die funktionale Sicherheit zertifizierte Softwarekontext auf der RPU die Sensordaten abruft und auch die an den Patienten abgegebene Medikamentendosis steuert. Die Sensordaten enthalten die Werte des Patienten. Die nicht sichere Domain besteht aus dem übergeordneten Betriebssystem, das die Daten auf einem LCD anzeigt und auch eine Internetverbindung bereitstellt.

Das System ist in eine sichere und eine nicht sichere Domain unterteilt (Bild 3). Die sichere Domain umfasst den RPU-Cluster, die PMU, die CSU, das Systemsteuerungsregister und die Peripheriegeräte. Nucleus Safety Cert wird auf der RPU verwendet, um kritische Systemressourcen wie Sensoren und Medikamentendosis zu verwalten. Nucleus Safety Cert auf der RPU-0 verwendet das Multicore Framework Cert für die Kommunikation mit dem nicht sicheren Bereich. Die Systemüberwachung und -verifizierung erfolgt durch die PMU. Die nicht sichere Domain umfasst die APU und verwandte Peripheriegeräte.  Linux wird auf der APU verwendet, um eine umfangreiche Benutzeroberfläche für die Anzeige der Patientenwerte bereitzustellen.  Multicore-Framework-Linux-Treiber kommen zum Einsatz, um die Kommunikation mit der sicheren Domain herzustellen und die Sensordaten abzurufen.

Isolation, Booten und Kommunikation

Bild 4 zeigt das Referenzsystem, das aus drei Subsystemen besteht. Diese Subsysteme werden im Xilinx-Vivado-HLS-Prozessorkonfigurationsassistenten (PCW) erstellt.  Der PCW generiert den Code zum Konfigurieren der XMPU und XPPU, um die gewünschte Isolation zu erzwingen. Der Initialisierungscode wird vom First Stage Bootloader (FSBL) auf der RPU ausgeführt. Bei dieser Architektur ist das APU-System ein nicht sicheres Subsystem (braun gefärbt), während die PMU- und RPU-Subsysteme beide als sichere Systeme (grün gefärbt) gelten. Wenn nicht sichere Regionen mit sicheren Mastern geteilt werden, sind sie blau gefärbt. Die Abbildung zeigt eine detaillierte Ansicht aller Subsysteme sowie die ausschließliche Zuweisung oder gemeinsame Nutzung verschiedener Speicherbereiche, Peripheriegeräte, Steuerregister usw.

Jeder Versuch nicht sicherer Subsystemkomponenten, auf sichere Systemregister oder Speicher zuzugreifen, wird von XPPU und XMPU blockiert. Um den Zugriff auf diese Weise einzuschränken, muss er mit der Xilinx Vivado IDE konfiguriert und ein Hardwareprojekt generiert werden.

Um zu verhindern, dass die Platform Management Unit (PMU) Anforderungen vom nicht sicheren APU-Subsystem bearbeitet, bietet der First Stage Boot Loader (FSBL) ein konfigurierbares Berechtigungsobjekt zur Kompilierungszeit. Dieses Objekt wird von der FSBL während der Initialisierung an die PMU-Firmware übergeben, um die Berechtigungen zu konfigurieren.

Der Bootvorgang beginnt auf der PMU. Die PMU wird initialisiert und gibt dann die Konfigurations- und Sicherheitseinheit (CSU) frei.  Die CSU authentifiziert dann die im boot.bin-Image enthaltene PMU-Firmware und lädt sie. Als nächstes authentifiziert, lädt und startet die CSU den First Stage Bootloader (FSBL) auf der RPU (Bild 5). Der FSBL stellt das PMU-Konfigurationsobjekt für die PMU-Firmware bereit, die die Energieverwaltungsberechtigungen enthält, die verschiedenen Subsystem-Mastern erteilt wurden. Außerdem startet er die Hardware-Isolation, indem sowohl die XPPU als auch die XMPU mit der von den Vivado-Tools generierten Konfiguration programmiert werden. Er authentifiziert, lädt und startet das Nucleus Safety Cert auf der RPU und authentifiziert, lädt und startet die ARM Trusted Firmware sowie U-Boot auf der APU.

Der U-Boot authentifiziert und programmiert den Bitstream der programmierbaren Logik, gefolgt vom Start von Linux auf der APU. RPMSG von Multicore Framework Cert wird verwendet, um die Kommunikation zwischen den Domains Linux und Nucleus Safety Cert bereitzustellen. Intern wird der gemeinsam genutzte Speicher für Puffer und der IPI-Block für Benachrichtigungen verwendet. Die Kommunikation zwischen den Betriebssystemen über RPMSG erfordert zwei Datenwarteschlangen im gemeinsam genutzten Speicher, um eine bidirektionale Datenübertragung zu ermöglichen. Zur Unterstützung der asynchronen Benachrichtigung wird jedem Betriebssystem eine Interrupt-Ressource zugewiesen, und die Xilinx IPI-Komponente signalisiert die Datenverfügbarkeit zwischen den Subsystemen.

(na)