System-on-Chip-Desgin Systempartitionierung für sichere und nicht sichere Anwendungen

Autor / Redakteur: Stefano Zammattio, Clive Davies * / Holger Heller

Mit der Einführung von SoCs, die ARMs Cortex-A9-Multicore-Prozessor und ein FPGA enthalten, bietet sich die Chance, bestehende Systeme in einem Baustein zu konsolidieren. Was ist mit der Sicherheit?

Firmen zum Thema

Partitionierung auf Alteras Cyclone V SoC: mit ARMs TrustZone-Technologie ein sicheres Subsystem erstellen
Partitionierung auf Alteras Cyclone V SoC: mit ARMs TrustZone-Technologie ein sicheres Subsystem erstellen
(Bild: VBM-Archiv)

Separate MCUs und digitale Logik werden heute in einem einzigen Multicore-Baustein vereint. Ein geringerer Stromverbrauch und Platzbedarf sind die Vorteile, aber eine wesentliche Herausforderung ist die Kombination sicherheitskritischer und nicht sicherheitskritischer Softwareelemente in einem Baustein.

Bild 1 zeigt ein typisches Beispiel eines Motorsteuerungssystems, das mit drei diskreten Bausteinen umgesetzt wurde. Das System besteht aus einem nicht sicherheitsrelevanten Netzwerk-/Schnittstellenprozessor, einer Motorsteuerungs-Supervisor-MCU und einem FPGA, das den Echtzeit-Motor-Controller in Hardware implementiert hat. Der grau hinterlegte Teil in Bild 1 enthält die sicherheitskritischen Elemente des Designs und unterliegt einer Sicherheitszertifizierung durch eine externe Stelle.

Bildergalerie

Die Konsolidierung eines Motorsteuerungssystems in ein SoC ermöglicht den Einsatz eines einzigen Bausteins für die Signalverarbeitung, Überwachung und Datenkommunikation. Ein solcher Baustein ist zum Beispiel der 28nm Cyclone V SoC von Altera. Dieser enthält eine stromsparende FPGA Fabric und ein „Hard Processor System“ (HPS), das auf einem ARM Cortex-A9 Dual-Prozessor-Core und entsprechender Peripherie basiert. Das HPS unterstützt auch ARMs TrustZone-Technologie, die sich in die FPGA-Fabric erweitern lässt.

TrustZone ist ARMs Technologie zur Partitionierung eines Multicore-Systems in einen sicheren Bereich für kritische Systemressourcen und in einen nicht sicheren Bereich für alle andere Anwendungen. TrustZone isoliert kritische Pfade des Systems, so dass sie nur aus dem sicheren Bereich zugreifbar sind. Unterstützt wird dies durch die Cortex-A9 MPCore Hardware und den AMBA AXI3-Busstandard.

Sicheres Subsystem innerhalb des SoC-Bausteins

In einem TrustZone-gestützten System enthält jede AXI-Transaktion ein Non-Secure (NS) Bit, welches anzeigt, ob eine Transaktion aus dem nicht sicheren oder aus dem sicheren Bereich erfolgt. Mit dieser Information in jeder Transaktion können die Slaves im System wählen, wie sie entsprechend ihres TrustZone-Status reagieren. Ein Beispiel: Ein System-Reset-Controller im sicheren Modus reagiert nur auf Reset-Anfragen aus dem sicheren Bereich.

Anfragen aus nicht sicheren Bereichen werden ignoriert oder erzeugen eine Fehlermeldung. Dieser Ansatz lässt sich auf alle Slaves im System erweitern, um ein sicheres Subsystem innerhalb des SoC-Bausteins bereitzustellen. Dieses sichere Subsystem ist dann vom nicht sicheren Bereich isoliert und kann somit zum Betrieb vertrauenswürdiger Software – in unserem Fall mit Sicherheitssoftware – verwendet werden, ohne von Schadsoftware oder AXI-Transaktionen im unsicheren Teil des Systems beeinträchtigt zu werden. Diese Art von Schutz ist für einen Sicherheitsprüfer akzeptabel.

Das Beispiel der Motoransteuerung lässt sich mit Alteras Cyclone V SoCs umsetzen: Diese Bausteine enthalten ARMs TrustZone-Technologie im Cortex-A9 MPCore-Prozessor sowie der HPS-Peripherie, dem SDRAM-Controller und dem FPGA-Bereich. Damit lässt sich ein durchgängiges Sicherheitskonzept für sämtliche Peripherie innerhalb des SoC aufbauen. In diesem Beispiel läuft die Steuerungssoftware auf dem µC/OS-II RTOS, während die Software für die Benutzerschnittstelle auf Linux basiert. Um dies zu ermöglichen, muss der Cortex-A9 MPcore-Prozessor für AMP-Betrieb konfiguriert werden: auf einem Core läuft Linux, auf dem anderen Core läuft µC/OS II.

Isolierte Domäne ohne gegenseitige Funktionsbeeinflussung

Die echtzeitkritischen Motorsteuerungsfunktionen laufen auf dem µC/OS-II in Core 1, während Linux und die Anwendungen, die die Steuerung und Kommunikationskanäle bereitstellen, auf Core 0 laufen. Die Grundidee ist, eine isolierte Domäne bereitzustellen, in der die Funktionen auf dem Prozessor-Core 1 ohne Beeinflussung seitens des Core 0 betrieben werden können. Core 1 (µC/OS-II) muss daher in einem sicherheitsrelevanten Bereich laufen, und Core 0 (Linux) im nicht sicheren Bereich.

Die beiden Prozessor-Cores kommunizieren über einen gemeinsamen physikalischen Speicherkanal nach dem OpenMCAPI-Standard (Bild 3). Das HPS-System wurde statisch partitioniert und jedes Betriebssystem auf seine zugewiesenen Ressourcen portiert. Die Memory Map wurde entsprechend in Regionen unterteilt, die entweder µC/OS-II oder Linux zugeordnet sind sowie Regionen, die sich beide Betriebssysteme teilen. Ebenso wurde die Peripherie zwischen µC/OS-II und Linux aufgeteilt – dabei gibt es keine Peripherie, die gemeinsam benutzt wird.

Im System gibt es eine Master-Konfigurationstabelle, die die alle HPS AXI-Master sowie deren TrustZone-Sicherheitsstatus auflistet. Dieser Sicherheitsstatus lässt sich statisch einstellen, sodass ein Master stets nur sichere oder stets nur nicht sichere Zugriffe ausführt. Es gibt aber auch die Möglichkeit die Einstellung so vorzunehmen, dass per Transaktion entschieden wird, ob es sich gerade um einen sicheren oder nicht sicheren Zugriff handeln soll.

Jeder Interrupt wird zu einem bestimmten Core geleitet

Jeder Cortex-A9-Prozessor verfügt über seinen eigenen unabhängigen L1-Cache für Befehls- und Datenzugriffe sowie über ein unabhängiges Timer/Watchdog-Modul. Die Prozessoren teilen sich den L2-Cache, General Interrupt Controller (GIC) und die Snoop Control Unit (SCU). Der GIC verwaltet die Priorisierung und das Routing von Interrupts zum MPCore-Prozessor. Er lässt sich so konfigurieren, dass jeder Interrupt an einen bestimmten Core geleitet wird. Jedem Interrupt kann auch ein TrustZone-Status zugewiesen werden.

Der L2-Cache kann in vielfältiger Weise konfiguriert werden. In unserem Beispiel werden die L2-Konfigurationsregister so eingestellt, dass sie nur von einem sicheren Master beschreibbar sind. Damit kann Linux die L2-Cache-Konfiguration nicht verändern, außer wenn der entsprechende Zugriff über einen sogenannten Secure State Monitor erfolgt. Der L2-Cache ist mehrwege-assoziativ und kann aufgeteilt werden.

In unserem Beispiel werden zwei Wege für µC/OS-II und sechs Wege für den Linux-Core vergeben. Der µC/OS-II Core erhält 1 MByte DDR SDRAM, UART1 und sämtliche Peripherie innerhalb des FPGAs. Alle anderen Ressourcen werden dem Linux-Kernel zugewiesen.

Bootvorgang des SoC erfolgt über drei Stufen

Während der Linux-Kernel die MMU (Memory Management Unit) des ARM-Prozessors selbst verwaltet, ist dies bei µC/OS-II nicht der Fall. Das µC/OS-II BSP wurde daher so angepasst, dass während des Startup eine statische Page-Tabelle erstellt wird. Die dem µC/OS-II zugewiesenen Ressourcen werden dann in der Page-Tabelle platziert, und das µC/OS-II wird so konfiguriert, dass es nur diese Memory Map benutzt. Für Linux enthält der Device Tree, der das System beschreibt und beim Startup an den Kernel weitergereicht wird, keine Referenz zum Speicher oder zur Peripherie, die dem µC/OS-II zugewiesen ist.

Das Booten des SoC ist ein 3-stufiger Vorgang. Die erste Stufe umfasst ein On-Chip Boot-ROM, das eine minimale Konfiguration von Core 0 durchführt und einen externen nicht-flüchtigen Speicher aktiviert. In diesem Speicher wird ein „Preloader“ Software-Image lokalisiert, überprüft und in ein integriertes RAM geladen. Dieses Preloader Image wird zunächst verwendet, um die Konfiguration des SDRAM und der Peripherie-I/Os des SoC vorzunehmen. Nachdem diese Initialisierung abgeschlossen ist, übernimmt der Preloader das Laden und die Ausführung des eigentlichen Boot-Loaders (z.B. U-Boot). Dieser Boot-Loader ist dann für das Laden und Ausführen des letztendlichen Betriebssystems zuständig.

Für unser AMP-System gibt es weitere Anforderungen: z.B. das Laden der zwei getrennten Betriebssysteme in den Speicher und die Konfiguration der TrustZone-Sicherheitsoptionen innerhalb des SoC. Die lokale Timer/Watchdog-Peripherie in Core 1, UART1, Watchdog Timer 1 und die vom µC/OS-II verwendeten Interrupts werden als sicher konfiguriert. Der Zugriff darauf kann daher nur durch das µC/OS-II erfolgen. Alle anderen Peripherieeinheiten und Interrupts werden als nicht sicherheitsrelevant konfiguriert. Danach wird µC/OS-II auf Core 1 und anschließend Linux auf Core 0 gestartet.

Mit diesem Ansatz können Entwickler die Vorteile der Baustein-Konsolidierung mithilfe eines Altera SoCs nutzen und somit gleichzeitig eine strikte, durch TrustZone/Hardware-erzwungene Softwaretrennung für sicherheitskritische Anwendungen gewährleisten.

* * Stefano Zammattio ist Product Manager und Clive Davies ist Manager Automotive System Solutions Engineering bei Altera.

(ID:40109720)