Auf realen Mikrocontrollern finden Datentransfers aus diversen Gründen nicht nur über Lade-/und Speicherbefehle der CPU statt, sondern sogenannte Multimaster-Architekturen wie z.B. SiliconLabs „Peripheral Flex System“ erlauben unterschiedlichen Peripherien, ohne CPU-Interaktion miteinander zu kommunizieren. Verheerend für die Sicherheitsintegrität der MCU wäre natürlich ein unkontrollierter Datenaustausch zwischen sicher und unsicher Welt.
Die Schaltmatrix AMBA AHB Lite von ARM kann TrustZone nicht unterstützen, daher hat ARM mit dem AMBA 5 AHB 5 eine neue Busarchitektur entwickelt, die auf AMBA 3 AHB Lite aufsetzt, aber sicherheitsrelevante Erweiterungen beinhaltet. Als erstes ist hier die Identifikation von sicheren und unsicheren Übertragungen zu nennen. Ist z.B. ein DMA-Controller als unsicher implementiert, werden alle Transfers in sichere Adressbereiche hardwareseitig unterbunden (Bild 6). Dazu werden mit den Instruktionen LDREX/STREX (Load and Store Register EXclusive) Interaktionen in Multicore-Systemen ermöglicht. Und last but not least werden auch neue Speichertypen unterstützt, wie dies heute schon bei den AXI-Schaltmatrizen der Fall ist.
Ein reales Beispiel aus der IoT-Welt
Bild 7 zeigt ein einfaches Beispiel z.B. für eine IoT-Applikation, die Daten sammelt und dann drahtlos versendet. In der sicheren Welt würde man die Initialisierungs-Routine, die Firmware und einen Kommunikationsstack implementieren, auf der nicht sicheren Seite finden sich neben der eigentlichen Applikation auch noch die Hardware-Treiber. Die zahlreichen Übergänge von der sicheren in die nichtsichere Welt und umgedreht verdeutlichen, warum ARM die einfache Lösung mit der SG-Instruktion gewählt hat – es werden keine langen Latenzzeiten generiert, wie dies bei der Cortex-A-Implementierung von TrustZone der Fall ist. Hier muss man softwaremäßig eine bestimmte Exception auslösen, um in den Monitor-Modus zu wechseln, in welchem der jeweilige Kontext (sicher oder nicht sicher) aus einem zuvor definierten Speicherbereich geladen wird.
Der sichere Bereich eignet sich natürlich noch für viele andere Einsatzbereiche als „nur“ Firmware und Kommunikatiosstack. Man denke z.B. an ein zertifiziertes Betriebssystem, das von der Anwendung nicht verändert werden kann, oder Schlüsselverwaltung/Verschlüsselung/Authentifizierung bei Metering-Anwendungen.
Fazit
ARMv8-M ist mehr als nur technische Evolution: Der Halbleiterhersteller als auch der OEM hat jetzt die Möglichkeit, sich nicht nur über Peripherie (und Preis) zu differenzieren, sondern über Software. So könnte ein Lampenhersteller einen ARMv8-M-Controller erwerben, einen eigenen IoT-Stack draufpacken und das Ganze zusammen als intelligente LED-Leuchte an einen Gebäudeautomatisierer verkaufen. Dieser könnte dann seinerseits noch zusätzliche Anwendungssoftware programmieren, um die Lampe vom Wettbewerb zu differenzieren.
Was uns besonders gefällt, ist die Tatsache, dass die geringen Latenzzeiten, die ein Embedded-Mikrocontroller nun einmal bereitstellen muss und für die Cortex-M-CPUs bekannt sind, bei Simon Craskes Ansatz weitestgehend bewahrt werden konnten.
ARMs Tool-Schmiede Keil hat seine Entwicklungstools und die CMSIS-Bibliothek an ARMv8-M angepasst – man kann ein „unsicheres“ und „sicheres“ Projekt parallel bearbeiten. Auch die üblichen anderen Verdächtigen aus der ARM-Welt wie IAR, GreenHills, Segger, ExpressLogic, Micriµm und Mentor Graphics werden ARMv8-M-kompatible Entwicklungssysteme anbieten. Wann erste reale Produkte (RTL für CPU-IP) erhältlich sein wird, ist noch nicht bekannt.