Fotolia_115428091_M

Compiler für sicherheitsrelevante Software – Was ist zu tun?

Veröffentlicht am Veröffentlicht in Deutsche Blogs, DO178, Funktionale Sicherheit

Der Compiler ist DAS zentrales „Tool“, welches für jede Software Produktentwicklung benötigt wird. Er bildet das Bindeglied zwischen der vom Menschen gut lesbaren Hochsprache (z.B. C und C++) und dem für den Hardwareprozessor interpretierbaren Maschinencode. Für die Entwicklung sicherheitsrelevanter Software nach entsprechenden Funktionalen Sicherheitsstandards wie ISO26262 (Auto), EN50128 (Bahn), IEC61508 (Automatisierung, Allgemein) oder DO178C (Luftfahrt) gelten für die während der Entwicklung verwendete Tools besondere Anforderungen (siehe Blogbeiträge zur Toolqualifikation aus 2016: Blog 1; Blog 2). Der Compiler spielt hier eine Sonderrolle. Einerseits ist der das zentrale Tool jeder Entwicklung, andererseits sind die in den Normen vorgeschlagenen Maßnahmen in der Praxis für Ihn nur bedingt anwendbar. Der Blog zeigt einen Prozess aus der Luftfahrt für die Compilerverifikation/-validation auf, der auch für andere Industrien sehr zu empfehlen ist.

Branchenübergreifende, gängige Methoden einer Toolqualifikation:

  1. Daten aus dem historischen Einsatz des Compilers
  2. Assessment des Entwicklungsprozesses des Compilers
  3. Test der Funktionalität des Compilers
  4. Vollständige Entwicklung des Compilers nach einem Standard der Funktionalen Sicherheit

Die aus Sicherheitsgründen mächtigste Methode Nr. 4 scheidet für den Compiler praktisch aus, da Compiler von kommerziellen Herstellern gebaut werden. Die Kosten für einen Compiler der nach Sicherheitsstandards entwickelt würde, wären so hoch, dass ein gewinnbringender Vertrieb dafür auf dem relativen kleinen Markt der Sicherheitstechnik kaum möglich ist.

Methode Nr. 3 scheidet insofern aus, als dass ein vollständiger Test der Funktionalität eines Compilers aus Gründen der Komplexität nicht möglich ist. Es bleiben entweder zu viele Aspekte ungetestet, oder die Testerstellung ist unwirtschaftlich.

Methode Nr. 2 hat sich bisher am Markt nicht durchgesetzt. Vermutlich auch deswegen, da diese Methode insbesondere auch für Compiler qualitativ nicht hinreichend gute Ergebnisse liefern kann.
Damit verbleibt nur Methode 1. Diese wird auch angewendet. Mir ist kein sicherheitsrelevantes Projekt bekannt, beim dem ein Compiler eingesetzt würde, der ganz neu auf dem Markt ist. In so gut wie allem Funktionalen Sicherheitsprojekten werden hingegen Compiler verwendet, die meist langjährig auf dem Markt sind und schon mehrfach in vergleichbaren Projekten verwendet wurden.
Da aber historische Daten an sich keine allzugroße Sicherheit bieten für einzelnes konkretes Projekt hat die Luftfahrt einen Prozess entwickelt der die Sicherheit einen Compilerfehler zu entdecken deutlich erhöht.

Minimierung des Risikos von unentdeckten Compilerfehler in der Luftfahrt:

Der Prozess in der Luftfahrt besteht aus zwei Elementen:

  1. Für jeden Test werden die genau gleichen Compilereinstellungen verwendet, die auch für den operativen Code zum Einsatz kommen.
  2. Für besonders sicherheits relvante Projekte (DAL A und B) wird eine Traceability vom Objectcode zum Hochsprachencode (C und C++) gefordert.

Die Erfahrung der letzten 20 – 30 Jahren in der Luftfahrt zeigen deutlich, dass die Anwendung dieser beiden Methoden sehr effektiv sind. In Kombination mit dem Einsatz bekannter Compiler wird das Risiko unentedeckter Compilerfehler auf ein absolutes Minimum gedrückt. In den Luftfahrtprojekten die mir aus den letzten 15 Jahren bekannt sind, wurden sind keine Fehler, auch nach langjährigem Feldeinsatz, festgestellt, die auf den Compiler zurückzuführen sind.

Für andere Branchen ist daher auf jeden Fall zu empfehlen zumindest alle Tests immer mit dem operativen Compiler und den entsprechenden Einstellungen zu verwenden. Mit einer guten Teststrategie und durchdachtenTestumgebung auf jeder Ebene (Unittest, Integrationstest und Systemebene) ist dies meist auch mit kaum einem Mehraufwand verbunden.
Wie die Erfahrung aus der Luftfahrt zeigt, sinkt andererseits das Risiko unentdeckter Compilerfehler dramatisch, wenn bei Tests die sowohl eine strukturelle Coverage sowie eine Requirements Coverage von 95% und mehr nachweisen, kein Compilerfehler entdeckt wurde.
Der Nachweis einer vollständigen Funkionalität scheitert beim Compiler an der Komplexität (siehe Ausführungen zu Methode 3 oben). Für ein einzelnes Projekt ist die verwendete Compilerfunktionalität begrenzt und daher eher vollständig testbar. Genau das wird mit dem Vorgehen in der Luftfahrt erreicht.

Gerne unterstütze ich Sie bei individuellen Fragen zu der Thematik. Sowohl mit dem „HEICON Starter“ also auch dem „HEICON Consulting“ hilft bei der Klärung offener Fragen. (www.heicon-ulm.de). Senden Sie eine Mail an: info[at]heicon-ulm.de!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.