ARM TechCon 2015

Architektur ARMv8-M bringt Hardware-Security in Mikrocontroller

6. November 2015, 9:48 Uhr | Frank Riemenschneider
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

TrustZone-Sicherheit für Mikrocontroller

Die aus AMRv7-M bekannten Modi "Thread" und "Handler" werden für die sichere und unsichere Welt gespiegelt.
Bild 2: Die aus AMRv7-M bekannten Modi "Thread" und "Handler" werden für die sichere und unsichere Welt gespiegelt.
© ARM

Der größte Fortschritt bei ARMv8-M ist zweifelsohne die Implementierung der TrustZone-Technologie, welche Speicher, Register, Code, Interrupts, Stacks und Peripherie in sichere und unsichere Bereiche unterteilt, ohne anders als bei Cortex-A dabei Determinismus und Latenzzeiten (bis auf wenige Ausnahmen) zu beeinträchtigen. Damit kann man z.B. Firmware und Middleware von Drittherstellern gegen Zugriffe von außen isolieren und sichere Verschlüsselungsmechanismen für IoT-Anwendungen implementieren.

Sicherer und unsicherer Code laufen auf einer CPU, wobei die von ARMv7-M bekannten Modi „Handler Mode“ und „Thread Mode“ jeweils in einem sicheren und unsicheren Status existieren (Bild 2). Im sicheren Modus gibt es einen eigenen Stapelzeiger, dazu gibt es eine Stack-Begrenzungs-Überprüfung, um einen Stapelüberlauf zu unterbinden. Ebenfalls enthält der sichere Zustand einen eigenen SysTick-Timer und eine separate MPU. Dazu können im Mainline-Profil jeweils 240 Interrupts für den sicheren und unsicheren Status definiert werden, im Baseline-Profil teilen sich beide Zustände 240 Interrupts. In Keils Tool-Chain können die Interrupts einfach per Anklicken eines Auswahlfeldes als sicher oder unsicher klassifiziert werden.

Warum hat ARM in der sicheren Welt eine MPU implementiert, wo diese doch eigentlich unerlaubte Zugriffe in bestimmte Speicherbereiche unterbinden soll? Zum einen stellt sie einen zusätzlichen Schutz bei Software-Fehlern dar, indem sie z.B. das überschreiben von Code bei fehlerhaften Zeiger-Operationen verhindert. Zum anderen kann man natürlich auch in der sicheren Welt unterschiedliche Container anlegen wie Firmware, einen Kommunikations-Stack und Code für das System-Setup.

Für den Entwickler sichtbarer Adressraum im unsicheren (links) und sicheren (rechts) CPU-Zustand.
Bild 3: Für den Entwickler sichtbarer Adressraum im unsicheren (links) und sicheren (rechts) CPU-Zustand.
© ARM

Im nicht sicheren Betriebszustand sieht der Programmierer den in Bild 3 links dargestellten Speicheradressraum. Dieser entspricht dem eines heutigen Cortex-M mit einem Unterschied: Hat der Entwickler schon z.B. beim Cortex-M4 die MPU benutzt, muss er seinen Code an die neue ARMv8-M-MPU anpassen. Speicherbereiche und Peripherie, die als sicher definiert wurden und auf die somit nur im sicheren Modus zugegriffen werden kann, erscheinen als Löcher im Adressraum, deren Adressierung zu einer Exception führt. Es gibt über eine neue Instruktion SG (Safe Gateway) die Möglichkeit, definierte Einsprungpunkte im sicheren Speicher auch von nicht sicherem Code anzuspringen, dazu später mehr.

Im sicheren Betriebszustand hat der Entwickler Zugriff auf den kompletten Adressraum inklusive sicheren Flash, sicheres RAM und sichere Peripherie (Bild 3 rechts). Eine Security-Attribution-Einheit (SAU) genannte Einheit definiert sichere und unsichere Speicherregionen in einer Auflösung von 32 Byte. Anders formuliert: Ob sich die CPU im sicheren oder unsicheren Zustand befindet, definiert sich ausschließlich über die zugegriffene Speicheradresse und deren Zustandsdefinition über die SAU. Ein MCU-Hersteller hat neben der softwaremäßig programmierbaren SAU auch hardwaremäßig auf Systemebene die Möglichkeit, bestimmte Adressraüme unüberschreibbar als sicher zu definieren – z.B. Verschlüsselungs-Peripherie oder bestimmte Bereiche des Flash-Speichers, in die er Firmware geladen hat.

Obwohl die Adressen der MPU, des SCB (System Control Block, dieser enthält z.B. das Interrupt Control and State Register und das Application Interrupt and Reset Control Register) und des SysTick-Timers im sicheren und unsicheren Modus an der gleichen Adresse liegen, kann man im sicheren Modus trotzdem die unsicheren Varianten programmieren. Diese werden nämlich im sicheren Modus in ungenutzte Adressbereiche gespiegelt. Dies ist auch für Safety-Aspekte nicht unerheblich: Wenn z.B. im sicheren Betriebsmodus ein Fehler im nicht-sicheren Bereich festgestellt wird, kann dieser zurückgesetzt werden und das System in einen Safe-State überführt werden.


  1. Architektur ARMv8-M bringt Hardware-Security in Mikrocontroller
  2. TrustZone-Sicherheit für Mikrocontroller
  3. Interrupts und Funktionsaufrufe in sicherer und unsicherer Welt
  4. Was ist mit Multimaster-Architekturen?

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu ARM Germany GmbH

Weitere Artikel zu Mikrocontroller