Implementierung mit TrustZone Autonome Safety-Mechanismen für ArmV8-Controller

Anbieter zum Thema

Hitex GmbH

Data Modul AG

MicroConsult Academy GmbH

ISH Ingenieursozietät GmbH

Die Verbreitung der Embedded-Systeme mit ArmV8-Controllern wird sich spätestens mit der erhöhten Anforderung durch die Data Security verstärken. TrustZone verspricht neben Isolation und Trennung auch Speicherschutz und Zugriffskontrolle, sicheres Booten und die gleiche Echtzeitfähigkeit wie der Rest der CPU. Dies alles steht im Einklang mit den gängigen Standards durch das Plattform Security Architecture (PSA) Framework.

Die Methoden zur Prozessisolation haben aber nicht nur Einfluss auf die Data Security. Auch für Systeme mit Anforderungen der funktionalen Sicherheit wird ein massiver Einfluss durch diese Technologie bestehen. Hier stellt sich die Frage ob die Funktionen und Methoden von TrustZone auch positive Effekte auf die funktionale Sicherheit haben können.

Insbesondere Systeme mit Software-Teilen in unterschiedlichem Safety Integrity Level (SIL) müssen den Nachweis zur Unabhängigkeit der Softwarekomponenten erbringen (Stichwort: Freedom of Interference). Wer möchte zum Beispiel einen zugelieferten Kommunikations-Stack für funktionale Sicherheit qualifizieren, wenn diese Software nicht Teil der Sicherheitskette ist?

Herausforderungen in herkömmlichen Embedded-Systemen

Herkömmliche embedded Systeme zeichnen sich durch die Integration der funktionalen Sicherheit in die gegebene Funktions-Software auf den Mikrocontrollern aus. Räumliche Prozess-Separation ist durch die Allokation in spezifizierten und nur dafür vorgesehenen integrierten Speicher (Flash und RAM) realisiert. Die zeitliche Separation der Prozesse ist nur soweit möglich, wie es die Funktions-Software zulässt. In einer Motorsteuerung steht z.B. die Berechnung der Motorsignale im Vordergrund. Dies hat somit im zeitlichen Ablauf höchste Priorität.

Das bedeutet auch eine zeitliche Integration in diejenigen Lücken, die die Berechnung lässt, und damit keine echte temporale Prozess-Trennung. Schon dieses Beispiel zeigt, dass durch die zeitliche Abfolge der Prozesse immer wieder Prozesse überlagert oder ausgesetzt werden und dadurch die zeitliche Abfolge nur eine bedingte Separation erlaubt.

Um Größenordnungen komplexer werden hier die Einflüsse von Interrupts. Hilfe kann dann die Einführung von Prioritäten bieten, die aber zwingende Abfolgen und den Schutz vor Race Conditions erfordern. Die Nutzung von hardware-basierenden Funktionen wie der MPU kann ebenfalls helfen den Beweis der Unabhängigkeit der Software-Komponenten zu führen.

TrustZone als Lösung

Hier kann TrustZone als Methode zur Prozess-Isolation herangezogen werden. Um die Prozesse örtlich vom Rest der Applikation zu trennen, können alle Maßnahmen der funktionalen Sicherheit im Secure Teil der Applikation implementiert werden. Eine Schnittstelle zur Ausführung wird durch die Secure Gateway Funktionen bereitgestellt. Dies macht insofern Sinn, da dieser Teil der Software selten oder gar nicht durch Updates verändert wird. Es wird aber durch Methoden wie Secure Boot und Secure Storage ein Höchstmaß and Vertrauen in diesen Teil der Applikation implementiert.

Zusätzliche Überlegungen zur Softwarearchitektur

Die Integration funktionale Sicherheit bedarf aber einiger zusätzlicher Überlegungen in der Softwarearchitektur:

• Können alle Teile der funktionalen Sicherheit in den Secure Bereich verschoben werden?

• Wie kann sichergestellt werden, dass die Methoden der Funktionale Sicherheit auch immer und vollständig bedient werden

• Wie kann sichergestellt werden, dass auch bei korrumpierter oder defekter Nicht-Sicherer Software im Non-Secure Bereich die funktionale Sicherheit nicht übergangen wird?

Das Ziel der Software-Architektur soll doch eine Integration aller benötigten Anforderungen aus funktionaler Sicherheit sowie der Applikation sein Dies soll in einer Form erfolgen, die auch Testbarkeit und Qualifikation erlauben. Von Vorteil wäre eine unabhängige Software für den Secure Teil, die für die funktionale Sicherheit sorgt und dazu nur einmalig qualifiziert werden muss. Die zeitliche Integration in die Applikation muss dennoch flexibel aus dieser heraus gesteuert werden.

Aktive Secure-Software: Eine notwendige Maßnahme

Diese Punkte führen zur zwingenden Erkenntnis, dass dies mit einer herkömmlichen passiven Secure-Software nicht gelingen kann. Weder die Vollständigkeit der Ausführung noch die Gewissheit vor einfacher Ausblendung der Safety Maßnahmen können von einem passiven Secure-Teil garantiert werden.

Hitex hat aus diesem Grund eine Variation der Selbsttest Bibliotheken (STL) für ArmV8 Controller vorgestellt, die genau diese Maßnahmen beinhaltet. Ein spezifisches Single Call Interface aus dem Non-Secure Teil reicht, um die Tests in einer fest strukturierten Abfolge im Secure Teil auszuführen. Autonom überprüft die STL aber auch den Ablauf und die Vollständigkeit der Ausführung. Sollten hier Abweichungen von der Konfiguration festgestellt werden, so ist der Secure Teil auch unabhängig von der Non-Secure-Applikation in der Lage zu reagieren und das System in einen sicheren Zustand zu bringen. Gleichzeitig ist durch die teils statische und teils dynamische Konfiguration genügend Flexibilität vorhanden, um der Applikation eine Integration in den Ablauf zu ermöglichen. (sg)

* Stefan Grohmann ist Team Leader Application Engineering bei Hitex

(ID:50378119)