Sicherheit Embedded Automotive Software

Schnittstellen erhöhen das Risiko

9. März 2015, 15:09 Uhr | Von Paul Anderson

Fortsetzung des Artikels von Teil 2

Die beiden wichtigsten Klauseln bei MISRA

Auch wenn Statische-Analyse-Tools nicht alle Verstöße gegen unentscheidbare (undecidable) Regeln aufdecken können, ist ihr Einsatz sehr wichtig, um so viele Regelverletzungen wie möglich aufzuspüren, denn genau hier verbergen sich die meisten kritischen Fehler. Im MISRA-Standard gibt es zwei besonders relevante Klauseln – eine Regel und eine Richtlinie:

Regel 1.3: „Es darf kein undefiniertes oder kritisches unspezifiziertes Verhalten eintreten.“
Richtlinie 4.1: „Run-Time-Fehler müssen minimiert werden.

Hier handelt es sich wohl um die zwei wichtigsten Klauseln im gesamten Standard, die beide auf die Achillesferse der C-Programme abzielen. Undefiniertes Verhalten ist im ISO-Standard für C (Annex J im C99-Dokument) ausdrücklich besprochen und deckt eine breite Fülle an Aspekten der Sprache ab. Viele C-Programmierer sind überrascht, dass es dem Standard völlig entspricht, wenn ein C-Programm bei undefiniertem Verhalten gar nichts tut. Manchmal wird das spöttisch als „Catch Fire“-Semantik bezeichnet, weil der Compiler die Freiheit hat, den Computer im übertragenen Sinn in Brand zu setzen.

Natürlich sind die Compiler-Schreiber keine Pyromanen. Deshalb melden Compiler in der Regel einen Fehler, wenn sie ein undefiniertes Verhalten entdecken. Allerdings kann es vorkommen, dass ein solches Verhalten vom Compiler gar nicht bemerkt wird. Undefiniertes Verhalten ist dabei keine selten anzutreffende Nische: Der C99-Standard enthält 191 unterschiedliche Varianten. Als Konsequenz kann es sogar für den gründlichsten Programmierer schwierig sein, undefiniertes Verhalten vollständig zu vermeiden. Unspezifiziertes Verhalten ist weniger gefährlich, hat aber auch seine eigenen Fallgruben. In diesem Fall spezifiziert der Standard zulässige Verhaltensweisen, überlässt aber dem Compiler-Verfasser die Wahl, welche er einsetzen möchte. Das gibt ihm Spielraum für die Auswahl der Interpretation mit der besten Leistung, bedeutet aber, dass der Code unterschiedliche Semantik besitzen kann, wenn er von verschiedenen Compilern übersetzt wird.

Auch schwerwiegende Fehler identifizieren

Es liegt auf der Hand, dass undefiniertes Verhalten beinahe immer ein Grund zur Besorgnis für den Programmierer darstellt. Denn er kann viele der schlimmsten Fehler auslösen, beispielsweise

Buffer Overruns und Underruns
Invalid Pointer Indirection
Use After Free
Double Close
Data Races
Division durch Null
Nutzung von nicht initialisiertem Speicher

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Bei der Entwicklung von sicherer Embedded Software geht es deshalb darum, nicht nur Verstöße gegen vordergründige syntaktische Regeln aufzuspüren, sondern – wie es der MISRA-Standard fordert – auch ernste Fehler, die aus undefiniertem Verhalten entstehen.

Selbst wenn einfache Statische-Analyse-Tools einige der offensichtlichsten Fehler finden können, entdecken nur hoch entwickelte Statische-Analyse-Tools (z.B. CodeSonar4 von GrammaTech, Bild 3) die subtileren Ereignisse.

Für eine erfolgreiche Kundengewinnung müssen die Autohersteller verstehen, dass ihre Marken immer enger mit der Qualität und Sicherheit der zugrunde liegenden Software verknüpft sind. Und sie müssen schnell handeln, um Sicherheitsprobleme wegen Software-Schwachstellen im Vorfeld zu vermeiden, bevor Kunden in Gefahr geraten. Darum ist es unverzichtbar, dass bei der Software-Entwicklung bewährte, automatisierte Analyse-Tools eingesetzt werden, um die Codequalität sicherzustellen.

Der Autor

Dr. Paul Anderson
leitet die Entwicklungsabteilung bei GrammaTech. Er hat über 20 Jahre Erfahrung in der Entwicklung von statischen Analysewerkzeugen und automatisierten Test Tools. Anderson besitzt einen Hochschulabschluss (Bachelor of Science) des King‘s College, Universität London und einen Doktortitel der City University London.