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.

(ID:40109720)