Software-Sicherheit in TriCore-Anwendungen

Das Zusammenfassen von Funktionen in einem Gerät setzt voraus, dass die Sicherheit des Gesamtsystems nicht gefährdet wird. Der TriCore bietet mit seiner Memory Protection Unit einen besonderen Mechanismus zum Kapseln von Software-Modulen an. Sinnvoll...

Das Zusammenfassen von Funktionen in einem Gerät setzt voraus, dass die Sicherheit des Gesamtsystems nicht gefährdet wird. Der TriCore bietet mit seiner Memory Protection Unit einen besonderen Mechanismus zum Kapseln von Software-Modulen an. Sinnvoll nutzen lässt sich dieses Feature aber nur, wenn auch die gesamte Tool-Kette mitspielt.

Mehr Sicherheit. Mehr Komfort. Mehr Infotainment. Um all diesen Forderungen in automotiven wie auch industriellen Anwendungen gleichzeitig Rechnung tragen zu können, bedarf es in der Regel etlicher zusätzlicher Steuergeräte und Speichereinheiten. Doch wer trägt die zusätzlichen Kosten inklusive der gegebenenfalls nötigen zusätzlichen Zertifizierungen? Und wohin mit den ganzen Komponenten?

Auf den ersten Blick verlockend scheint hier natürlich die Vereinigung mehrerer Software-Module in einem Steuergerät. Ein wesentlicher Vorteil dieser Integration ist neben der Platz-, Gewichts- und Kostenersparnis die Wiederverwendbarkeit von betriebsbewährten Software-Modulen. Ärgerlicherweise birgt dieser Lösungsansatz aber das Risiko, dass sich Software-Module gegenseitig beeinflussen. So könnte ein einziger Fehler in einem Modul, das z.B. von einem Drittanbieter stammt, unter Umständen die Sicherheit des Gesamtsystems gefährden. Um dieses Risiko zu eliminieren oder zumindest zu reduzieren, wäre es erforderlich, alle Software-Module nach den gleichen hohen Sicherheitsstandards zu entwickeln, was wiederum aus Kostengründen praktisch so gut wie unmöglich ist. Fazit: Ohne zusätzliche kostenintensive Maßnahmen ist dieser Lösungsansatz für automotive oder sicherheitskritische industrielle Anwendungen ungeeignet.

Um eine sichere Funktionsintegration auf einem Steuergerät zu ermöglichen und gleichzeitig eine gegenseitige Beeinflussung und Fehlerfortpflanzung auszuschließen, bedarf es de facto einer strikten Kapselung aller zum Einsatz kommenden Software-Module. Besonders pfiffig, weil absolut sicher, wurde dieses Problem beim Echtzeit-Betriebssystem PXROS-HR der Firma HighTec EDV-Systeme gelöst. Die Kapselung von Software-Modulen erfolgt hier nicht softwareseitig, sondern PXROS-HR verwendet die Memory Protection Unit (MPU) der TriCore-Architektur, um einen hardwaregestützten Speicherschutz zu realisieren – so als liefe jedes Software-Modul bzw. jede Kapsel auf einem eigenen Controller. Das Betriebssystem übernimmt dabei die Verwaltung der MPU und überwacht während der Laufzeit die Einhaltung der Kapselgrenzen.

Wie das Prinzip in der Praxis funktioniert, zeigt Bild 1. Im Fall der abgebildeten Drive-Anwendung setzt sich das Basissystem aus dem Echtzeit-Betriebssystem PXROS-HR, Treibern und Protokollen, dem Debug-Monitor und einer Motorsteuerungs-Einheit zusammen. Die TriCore-Architektur unterscheidet für Software-Module die Privilegstufen „Supervisor“ und „User-Modes“. Im User-Mode 1 sind Zugriffe auf einige Special Function Register (SFR) und Peripherie-Einheiten noch gestattet, wohingegen im User-Mode 0 weder SFR- noch Peripheriezugriffe zulässig sind. Die Software-Module außerhalb des Basissystems, in Bild 1 als VCU bezeichnet (Virtual Control Units), sollten typischerweise im User-Mode 0 ablaufen. Diese so genannten PXROS-HR-Tasks können Dienste des Basissystems über ein Application Programming Interface (API) ausführen. Indem mit Hilfe der MPU die Ressourcen durch Speichergrenzen festgelegt wurden, ist jede dieser Komponenten gekapselt. Die Kommunikation zwischen Software-Modulen erfolgt ebenfalls ausschließlich durch Austausch von gekapselten Nachrichten.