Sicherheit Embedded Automotive Software
Schnittstellen erhöhen das Risiko
Fortsetzung des Artikels von Teil 1
Die Schattenseite von C
Bei der Entwicklung von Embedded Software für Fahrzeuge ist C immer noch die populärste Programmiersprache. Auch wenn andere Sprachen wie Ada, C++ und Java in manchen Fällen zum Einsatz kommen, beruht über die Hälfte des Codes von Embedded-Automotive-Systemen auf manuell programmiertem C.
Dabei ist C in vieler Hinsicht eine tolle Sprache – Fahrzeugherstellern bietet sie speziellen Nutzen als Schnittstelle zwischen mehreren Geräten. Bedauerlicherweise ist C auch eine extrem gefährliche Sprache. Wegen ihrer großen Flexibilität können Programmierern leicht Fehler unterlaufen. Weil die Definition, woraus ein zulässiges C-Programm besteht, sehr liberal ausgelegt ist, finden die Compiler viele Fehler nicht. Zudem ist der Standard durchsetzt mit Zweideutigkeiten. Darum kann Code, der perfekt mit einem Compiler funktioniert, beim Einsatz eines anderen versagen, denn die Compiler basieren auf unterschiedlichen gültigen Interpretationen des Standards. In Summe ist ein C-Programm sehr anfällig für ernste Speicherzugangsfehler wie Buffer Overruns und Null-Pointer-Referenzierungen. Auch andere Fehlerklassen wie Speicherlöcher oder die Nutzung von nicht initialisiertem Speicher treten häufig auf.
Schleppende Übernahme des MISRA-C-Standards
Die Einhaltung des deutlich sichereren MISRA-C-Standards variiert zur Zeit noch stark nach Hersteller und Land.
Jobangebote+ passend zum Thema
| Codier-Standard | Wird nicht beachtet | Vollständige Einhaltung | Selektiv forciert durch interne Qualitätsziele | Unbekannt |
|---|---|---|---|---|
| MISRA C | 31,1 % | 17,8 % | 26,7 % | 24,4 % |
| MISRA C++ | 13,3 % | 20,0 % | 44,4 % | 22,2 % |
Einsatz von MISRA-C und MISRA-C++ innerhalb des Marktsegments Auto/Zug/Transportwesen. (Quelle: VDC Research, 2014)
Nach Angaben von VDC Research ist hier reichlich Platz für Verbesserungen. So sind die Hersteller, die MISRA-C und MISRA-C++ komplett befolgen, noch klar in der Minderheit (Tabelle 1). Außerdem liegen laut VDC die US-amerikanischen Autohersteller mit der Übernahme von Prozessstandards historisch hinter ihren europäischen Mitbewerbern – eine potenzielle Schwäche der US-Hersteller im Wettbewerb.
Für den Einsatz von MISRA spricht besonders, dass heute automatisierte Statische-Analyse-Tools verfügbar sind, die einen Verstoß gegen den Standard zuverlässig aufdecken. Während ältere Tools nur oberflächliche syntaktische Eigenschaften des Codes wahrnehmen können, bieten die moderneren Tools tiefes semantisches Wissen über das gesamte Programm und decken damit viel subtilere und gefährlichere Fehler auf (Bild 2).
Regel-Entscheidbarkeit als Schlüsselkriterium
Der aktuelle Standard MISRA-C:2012 markiert jede Regel mit ihrer Entscheidbarkeit. Eine als „entscheidbar“ gekennzeichnete Regel bedeutet, dass es für Statische-Analyse-Tools möglich ist, alle Verletzungen ohne False-Positive-Ergebnisse (Fehlalarme) zu entdecken; die meisten der syntaktischen Regeln werden so markiert. Im Gegensatz dazu bedeutet eine als „unentscheidbar“ gekennzeichnete Regel, dass es generell für ein Statische-Analyse-Tool nachweislich unmöglich ist, alle Verletzungen ohne jeglichen Fehlalarm zu entdecken. Das bedeutet nicht, dass die statische Analyse für solche Regeln nicht empfohlen ist, sondern nur, dass Tools manche Verletzungen nicht auffinden und auch False-Positive-Ergebnisse liefern können.
Ein Beispiel hierfür ist Regel 2.2: „Es darf kein ungenutzter Code (Dead Code) auftreten.“ Dead Code ist definiert als jeglicher Vorgang ohne Auswirkung auf das Programmverhalten. Es ist leicht zu ermessen, wie schwer das nachweisbar ist – ein Analyse-Tool muss die Semantik aller möglichen Ausführungen des Programms verstehen und sagen können, welche Teile dieses Codes keine Auswirkungen haben. Während es einige leicht auffindbare Bereiche geben wird, ist es unmöglich, alle Instanzen ohne Fehlalarme festzustellen.
| Schlüsselanforderungen für Statische-Analyse-Tools |
|---|
| Bei der Entscheidung für ein konkretes Analyse-Tool sollten Käufer auf die folgenden Merkmale achten: Genauigkeit: Das Tool kann Code genau in der gleichen Art wie der Compiler verarbeiten. Alle Compiler sind unterschiedlich, und Analyse-Tools, die das nicht in Betracht ziehen, können falsche Ergebnisse liefern. Fluß- und Pfad-Analysen: Das Tool unterstützt eine präzise Fehlerfindung und Berichterstattung. Löschen von unausführbaren Pfaden: Dieses Merkmal ist wichtig, damit das Tool die Anzahl der False-Positive-Ergebnisse reduzieren kann. Nativer MISRA-Checker: Mit Hilfe von speziellen Werkzeugen wird die Einhaltung des MISRA-Standards sichergestellt. |
- Schnittstellen erhöhen das Risiko
- Die Schattenseite von C
- Die beiden wichtigsten Klauseln bei MISRA
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
ITK Engineering
Software-Entwicklung sicherheitskritischer Systeme nach ISO 26262-6
Methodik zur ISO-26262-Konformität
Reduzierter Dokumentationsaufwand
Firmware
Warum die Autoindustrie neue Software Updates braucht
Taint-Analyse
Schutz vor faulen Daten
