Neue Mikroarchitektur für Cortex-M

KI auf Mikrocontrollern mit Armv8.1-M und Helium

14. Februar 2019, 15:00 Uhr | Joseph Yiu, Senior Principal Engineer bei Arm, und Frank Riemenschneider

Fortsetzung des Artikels von Teil 2

Verbesserungen bei der Gleitkomma-Verarbeitung

Genau wie die Armv8.0-M-Architektur unterstützt Armv8.1-M optional skalare Gleitkommazahlen-Berechnungen in einfacher Genauigkeit (32 Bit) und doppelter Genauigkeit (64 Bit). Neben sämtlichen FPv5-Anweisungen werden neu jedoch auch skalare Gleitkommazahlen von halber Genauigkeit (16 Bit) und im Rahmen der Vektor-Datenverarbeitung Gleitkommazahlen von halber und einfacher Genauigkeit (16 bzw. 32 Bit) unterstützt (letztere nur bei implmentierten Helium-Erweiterungen).

Gleitkommazahl-Unterstützung von halber Genauigkeit kann in der Audiovorverarbeitung für Keyword-Spotting und Sprachsteuerung genützt werden. In diesen Anwendungen muss das Audio keine sehr hohe Auflösung aufweisen, aber eine gute Unterstützung des Dynamikbereichs ist sehr wünschenswert. Durch die Umstellung der Verarbeitung von Zahlen einfacher Genauigkeit auf Zahlen mit halber Genauigkeit kann der Prozessor mit Helium die doppelte Datenmenge in der gleichen Zeit verarbeiten.

Die Verwendung dieses Gleitkommaformats kann auch dazu beitragen, den Speicherbedarf für Daten (zum Beispiel Filterkoeffizienten) zu reduzieren.

Sicherheitsbezogene Verbesserungen

Armv8.0-M führte die TrustZone-Sicherheitserweiterung ein, die es ermöglichte, neue Generationen von Sicherheitslösungen auf kostengünstigen, stromsparenden Embedded-Systemen mit Cortex-M-Prozessoren zu implementieren. Eines der Hauptmerkmale von TrustZone für Armv8-M ist, dass es direkte Funktionsaufrufe zwischen Secure-Software (geschützte Umgebung) und Non-Secure Software (normale Umgebung) ermöglicht, und Armv8.1-M fügt weiterhin Verbesserungen in diesem Bereich hinzu.

Um TrustZone für Armv8-M zu unterstützen, definieren Arm-C-Language-Extension (ACLE) verschiedene erforderliche C-Compiler-Funktionen, konkret die Cortex-M-Security-Extensions (CMSE). Eine der Anforderungen ist, dass, wenn Non-secure-Software eine Secure-API aufruft, der Nachspann der Secure-Funktion (Code-Einfügung durch den C-Compiler am Ende der Secure-API) den Inhalt im Floating-Point-Status-and-Control-Register (FPSCR) löschen muss, um zu verhindern, dass Informationen auf die Non-secure-Seite gelangen. Dies ist gut für die Sicherheit, kann aber auch ein Problem für nicht sichere Software in Bezug auf die ABI-Kompatibilität darstellen. So können FPU-Konfigurationen geändert werden wie zum Beispiel die Rundungsmodus-Konfiguration.

In Armv8.1-M wurden Befehlssatzerweiterungen hinzugefügt, um die Kontextspeicherung von nicht-sicheren FPSCR-Zuständen (FPCXT_NS) im Prolog der Secure-API und die Kontextwiederherstellung im Epilog zu ermöglichen. Die erweiterten Anweisungen beinhalten FPU-Speicherzugriffsanweisungen (VLDR, VSTR) und FPU-Registerzugriffsanweisungen (VMRS, VMSR). Um diese neue Funktion nutzen zu können, ist ein C-Compiler-Update erforderlich. In diesem Zusammenhang fügt Armv8.1-M auch eine neue Anweisung für den Clearing-Kontext in der Registerbank (CLRM und VSCCLRM) hinzu.

Eine weitere Sicherheitsverbesserung ist innerhalb der Speicherschutzeinheit (MPU) ein neues MPU-Regionattribut namens Privileged-eXecute-Never (PXN). Wenn eine MPU-Region das PXN-Attribut gesetzt hat und der Prozessor versucht, den Code innerhalb dieser Region im priviligierten Modus auszuführen, wird die Exzeption Memory-Management-Fault ausgelöst, wobei das IACCVIOL-bit im MemManage-Fault-State-Register auf 1 gesetzt wird.

Das PXN-Attribut-bit befindet sich in Bit 4 von MPU_RLAR (Region Limit Address Register) und seinen Alias-Registern. Es ist sowohl in sicherer als auch in ungesicherter MPU verfügbar, und dieses Bit wurde zuvor in Armv8.0-M auf 0 festgelegt.

Anbieter zum Thema

zu Matchmaker+
arm
Bild 5: Prozessor Daten-Cache mit ECC-Speichersystem. Die beschädigte Cache-Linie wurde verworfen, mit Hilfe des Seitenbandsignals wird der Beschädigungs-Zustand im Speichersystem gespeichert.
© arm

Die PXN-Funktion ermöglicht es privilegierter Software, bestimmte Anwendungsaufgaben (Threads) nur auf unprivilegierter Ebene auszuführen. Beispielsweise kann ein Hacker die Stack-Korruption in einem privilegierten peripheren Handler nicht verwenden, um in unprivilegierte Codes zu verzweigen und sie mit privilegierter Ebene auszuführen.

Diese Funktion ist auch besonders nützlich für TrustZone-fähige Systeme mit sicheren Firmware-Komponenten verschiedener Softwarehersteller. In diesen Fällen sind einige der Sicherheits-Firmwarekomponenten möglicherweise nicht vollständig vertrauenswürdig und müssen auf die unprivilegierte Ausführung beschränkt werden. Wenn solche Systeme mit Armv8.0-M implementiert werden, dürfen die nicht privilegierten Softwarekomponenten keine eigenen sicheren Einstiegspunkte haben, die aus dem unsicheren Zustand aufgerufen werden können, da die Softwarekomponenten in einem privilegierten Zustand ausgeführt würden, wenn sie direkt aus dem unsicheren Handhabungsmodus aufgerufen würden. Infolgedessen müssen die Einstiegspunkte separat mit Sicherheitskontrolle implementiert werden, was den Software-Overhead erhöht. Mit dem in Armv8.1-M verfügbaren PXN-Attribut können diese unprivilegierten Softwarekomponenten ihre eigenen Secure API-Eingangspunkte haben, und nur wenn die APIs von unsicheren Handlern aufgerufen werden, kann der MemManage-Fehler-Exception-Handler den Prozessor abfangen und in den unprivilegierten Zustand schalten, damit die Secure-APIs ausgeführt werden können.

Debug-Erweiterungen 
 
Bei Systemen mit Secure-Softwarebibliotheken von Drittanbietern gibt es Situationen, in denen ein Softwareentwickler möglicherweise die unprivilegierte Softwarebibliothek debuggen muss, ihm aber von den Anbietern anderer Secure-Firmwarekomponenten nicht vollständig vertraut wird. In Armv8.0-M kann der Softwareentwickler, wenn Secure-Debug aktiviert ist, vollen Debug-Zugriff auf privilegierte und unprivilegierte Software haben, was in diesem Fall unerwünscht ist. Während es möglich ist, den Debug-Zugriff einzuschränken (anstatt den vollständigen sicheren Debug-Zugriff über den Debug-Zugriffsport bereitzustellen, kann sichere privilegierte Software den Debug-Monitor mit einem Kommunikationskanal wie beispielsweise CoreSight SDC-600 verwenden, um den eingeschränkten Debug-Zugriff auf die sichere unpriviligierte Welt bereitzustellen), erfordert dies mehr Software-Overhead.

Armv8.1-M bietet einen neuen Modus zur Aktivierung von Debug-Mechanismen durch die unprivilegierte Debug-Erweiterung an. Wenn Secure-Debug deaktiviert ist, kann sichere privilegierte Software die unprivilegierte Debug-Erweiterung über das Debug-Authentication-Control-Register (DAUTHCTRL) aktivieren. Wenn es sich um mehrere Secure-Firmware-Bibliotheken handelt, sollte die sichere privilegierte Software, die sich mit dem Kontextwechsel in der sicheren Welt beschäftigt (zum Beispiel Secure-Partition-Manager in PSA), die DAUTHCTRL-Register programmieren, wenn zwischen verschiedenen Kontexten gewechselt wird. In Bild 3 hat der Software-Entwickler beispielsweise Debug-Zugriff auf alle nicht sichere Software und die Bibliothek X, die nicht privilegiert ist. Eine Halteanforderung kann akzeptiert werden, wenn der Prozessor die Software ausführt, ist aber nicht möglich, wenn der Bibliotheksmanager oder die Bibliothek Y und Z ausgeführt werden.

Mit der unprivilegierten Debug-Erweiterung wird der Debug-Zugriff auf den Speicher des aktuellen Sicherheitsstatus (mit Ausnahme bestimmter Debug-Komponenten im Prozessor) bei laufendem Prozessor blockiert und ist erlaubt, wenn der Prozessor im unprivilegierten Zustand angehalten wird, wobei das unprivilegierte Debug aktiviert ist (UIDEN-bit in DAUTHCTRL auf 1 gesetzt). Die Debug-Zugriffe prüfen auch gegen die Berechtigung in der MPU des aktuellen Zustands, wenn für diesen Zustand unprivilegiertes Debug verwendet wird.

In Bild 3 können Softwareentwickler auf den nicht sicheren Speicher zugreifen und den Prozessor anhalten, wenn er sich in einem nicht sicheren Zustand befindet. Sie können ihn nur anhalten, wenn der Prozessor Bibliothek X ausführt (DAUTHCTRL wird vom Bibliotheksmanager in Kontext-Wechseln konfiguriert) und auf Speicherplatz zugreifen, der für Bibliothek X zugänglich ist (Berechtigung basierend auf Secure-MPU).

Die unprivilegierte Debug-Erweiterung ist sowohl für die sichere als auch für die nicht sichere Welt verfügbar (betrifft die UIDEN- und UIDAPEN-bits in DAUTH-CTRL). Um unprivilegiertes Debugging zu unterstützen, müssen die Debugger-Tools und der Bibliotheksmanager aktualisiert werden. Das unprivilegierte Debugging ist jedoch eine Erweiterung der Debug-Architektur und bestehende Debug-Funktionalitäten sind nicht betroffen. 

arm
Bild 6: Prozessor-Daten-Cache mit ECC-Speichersystem. Der im Speichersystem abgelegte Zustand hinsichtlich beschädigter Daten löst beim späteren Laden der Daten in ein Register eine Exzeption aus.
© arm

  1. KI auf Mikrocontrollern mit Armv8.1-M und Helium
  2. Helium-Funktionen
  3. Verbesserungen bei der Gleitkomma-Verarbeitung
  4. Performance-Monitoring-Einheit (PMU)
  5. Migration der Software auf Armv8.1-M und Fazit

Das könnte Sie auch interessieren

Verwandte Artikel

ARM Germany GmbH