Welche Speicherschutz-Technik ist bei Autosar die richtige?

Mit Autosar entstand in der Automobilindustrie eine Systemplattform, mit der sich Software-Komponenten (SW-Cs) unterschiedlicher Hersteller auf einem Steuergerät (ECU) integrieren lassen. So lassen sich einzelne ECUs besser ausnutzen und einzelne Funktionen in Form von SW-Cs losgelöst von der Hardware vermarkten.

Da bei der Integration unterschiedlicher SW-Cs auf einem Mikrocontroller der Speicher gemeinsam genutzt wird, können sich Programmierfehler auf die Funktionsweise aller Komponenten auswirken. Geeignete Speicher-Schutztechniken zur Isolation einzelner SW-Cs werden daher immer wichtiger.

Method Park

Mit SW-C wird auch Mehrfach-Instanziierung von Funktionen ein Thema. Wurde eine Funktion als SW-C realisiert, zum Beispiel der Einklemmschutz für den Fensterheber auf der Fahrerseite, dann soll es möglich sein, die gleiche Funktion ein weiteres Mal auf dem gleichen Steuergerät zu positionieren, beispielsweise auch für die Beifahrerseite. Was bei zwei getrennten Steuergeräten kein Problem darstellt, ist aufgrund des gemeinsam genutzten Speichers auf einem Mikrocontroller eine Herausforderung für die Software-Entwicklung.

Für beide Aspekte, die Isolation und die Mehrfach-Instanziierung einzelner SW-Cs, gibt es unterschiedliche Lösungsansätze mit sehr unterschiedlichen Vor- und Nachteilen:

• Getrennte Mikrocontroller in einer ECU
• Einsatz einer Memory Management Unit (MMU, Speicherverwaltungseinheit)
• Einsatz einer Memory Protection Unit (MPU, Speicherschutzeinheit) und eine manuelle Mehrfach-Instanziierung der SW-C
• Verwendung

 Mehrere Mikrocontroller auf einem Steuergerät

Vor der Integration von Software unterschiedlicher Hersteller auf einer ECU gewährleisten getrennte Mikrocontroller (MCUs) die Isolation. Dabei sind Hard- und Software eine Komponente und als solche im Fahrzeug integriert.

Ein ECU-Hersteller, der einen maximalen Schutz anstrebt, kann mehrere MCUs nach wie vor auf einer ECU platzieren: zum Beispiel eine für sicherheitskritische Funktionen und eine andere für Komfortfunktionen.

Bild 1: Zwei Konzepte zur getrennten DatengenerierungMethod Park

Die starke und starre Trennung von SW-Cs hat jedoch einige Nachteile, da beispielsweise keine ideale Auslastung der einzelnen MCUs erfolgt. Ressourcen einer MCU (Schnittstellen, Speicher, Rechenzeit) lassen sich nicht von der Software auf einer anderen MCU nutzen.

Verwendung einer MMU

In anderen Anwendungsbereichen wurden bereits Lösungen für Speicherschutz und die Mehrfach-Instanziierung geschaffen. So besitzen PCs oder moderne Smartphones eine Memory Management Unit (MMU).

Mit einer MMU ist es möglich, mehrere virtuelle Prozessoren auf einem physikalischen Prozessor zu realisieren. Üblicherweise verwaltet dazu ein Betriebssystem die Ressourcen. Bei Unix-Systemen tragen diese virtuellen Prozessoren die Bezeichnung „Prozesse“.

Jede SW-C kann bei diesem Ansatz ihre eigene virtuelle MCU erhalten, und die Ressourcen der physikalischen MCU lassen sich flexibel zuordnen. Lediglich die Größe des Arbeitsspeichers begrenzt dabei die Anzahl der möglichen virtuellen MCUs.

Ein zusätzlicher Vorteil ist die gemeinsame Nutzung von Programm-Code und konstanten Daten. MCUs mit einer MMU sind jedoch teurer als ohne MMU. Eine hardwarebasierte Adressumrechnung wurde daher bei der Spezifikation von Autosar nicht in Betracht gezogen.

Verwendung einer MPU

Zur Isolation ist bei Autosar der Einsatz einer reinen MPU (Memory Protection Unit) vorgesehen. Bei einer MPU nutzen alle SW-Cs den gemeinsamen Adressraum des physikalischen Speichers. Eine MPU besitzt keine Adressumrechnung; sie kann lediglich überwachen, auf welchen Speicherbereich eine SW-C zugreift. Ist der Zugriff auf den Speicherbereich nicht erlaubt, so kann die System-Software (beispielsweise Autosar) den Speicherzugriff abfangen, bevor die Daten im Speicher verändert werden.

Die Speicherbereiche und die Zugriffsrechte können umgeschaltet werden, so dass mehrere getrennte Schutzräume entstehen. Die Anzahl der möglichen Schutzräume ist wie bei einer MMU nur durch die Größe des Speichers begrenzt. Jede SW-C könnte einen separaten Schutzraum bekommen. In der Praxis strebt man jedoch an, die Anzahl der separaten Schutzräume zu minimieren, um Ressourcen zu sparen. Im Idealfall kommt eine MCU mit zwei MPU-Konfigurationen aus: eine Konfiguration für die Ausführung von vertrauenswürdigen Programmteilen und eine für nicht vertrauenswürdige.

Die Mehrfach-Instanziierung von SW-Cs wird von einer MPU nicht unterstützt. Die Entwickler müssen daher explizit dafür sorgen, dass sich mehrere Instanzen einer SW-C nicht stören. Die Autosar-Spezifikation ermöglicht es lediglich, die Schnittstellen einer SW-C mehrfach zu instanziieren.

Der Software-Entwickler hat zwei Möglichkeiten, die statischen Daten für jede SW-C getrennt zu anzulegen. Bild 1 veranschaulicht diese beiden Konzepte. Bei Konzept (a) werden zwei Kopien der Daten und des Programm-Codes erzeugt, die bis auf die symbolischen Namen identisch sind. Beim zweiten Ansatz (b) erfolgt eine explizite Trennung der Daten der SW-Cs im Programm. Hierzu dient eine  als weiterer Parameter eingeführte SW-C-Kennung, die als Index für den Zugriff auf die Daten der unterschiedlichen Instanzen fungiert.

Der Verzicht auf eine MMU bei den Steuergeräten hat den Vorteil, dass die Mikrocontroller preiswerter sind und weniger Leistung aufnehmen. Dies bedeutet jedoch auch einen Verzicht auf eine hardwarebasierte Adressumrechnung und als direkte Folge einen höheren Entwicklungsaufwand. In der Autosar-Spezifikation tragen die getrennten Schutzräume die Bezeichnung „Partitionen“. Eine Partition wird unabhängig von den SW-C definiert und kann auch mehrere SW-Cs enthalten. Das kommt dem Bestreben entgegen, möglichst wenige Schutzräume zu schaffen.

Werden die Grenzen einer Partition zu eng gezogen, tritt eine Fehlfunktion auf, die jedoch mit großer Wahrscheinlichkeit vor der Auslieferung der Software entdeckt wird. Kritischer ist es, wenn die Partitionen zu freizügig konfiguriert oder gänzlich inaktiv sind. In diesem Fall funktioniert die Software zwar auf den ersten Blick. Bei einer Fehlfunktion besteht jedoch keine ausreichende Isolation, so dass Fehler sich auf vermeintlich geschützte Bereiche auswirken können.

Softwarebasierte Schutzräume

Für die Isolation von SW-Cs lässt sich auch vollständig auf Hardware-Unterstützung verzichten. Beispiele dafür sind sprachbasierte Ansätze. Dabei beschreibt der Entwickler sein Programm in einer Programmiersprache, die alle Speicherzugriffe überprüft. Die Überprüfung kann dabei zum Teil zum Übersetzungszeitpunkt stattfinden oder auch zur Laufzeit (zum Beispiel durch automatisch generierte Überprüfungen).

Exakt diesen Ansatz verfolgte das Forschungsprojekt KESO an der Universität Erlangen-Nürnberg. KESO steht für „Konstruktiver Eingebetteter Speicherschutz für OSEK“ und ist eine Multi-JVM für Deeply-Embedded-Systems wie OSEK/VDX oder Autosar OS. Die SW-Cs müssen dazu als Java-Bytecode und nicht als Maschinenprogramm vorliegen. Aus dem Bytecode wird Ahead-Of-Time (AOT) ein C-Programm generiert, das der C-Compiler anschließend im etablierten Build-Prozess übersetzt.

Laufzeitüberprüfungen, die im generierten C-Programm enthalten sind, stellen sicher, dass falsche Speicherzugriffe den Speicherinhalt nicht fehlerhaft verändern können. In der Praxis vertrauen beispielsweise Applets in Web-Browsern, Handys oder bei den Sm@rtCafé-Geldkarten auf den Speicherschutz einer JVM. Der Speicherschutz erfolgt bei einer JVM wesentlich feingranularer, da jede Objekt- und jede Array-Grenze überprüft wird. Dabei kommen auch Fehler zum Vorschein, die nur innerhalb einer SW-C Schaden anrichten.

Werden mehrere SW-C in einer einzigen JVM ausgeführt, so nutzen sie die gleichen statischen Felder. KESO bietet daher die Möglichkeit, jede SW-C in eine eigene JVM-Instanz zu kapseln. Dabei erhält jede JVM ihre eigenen statischen Felder, und der Programmcode wird von allen SW-Cs gemeinsam genutzt.

(av)