Sicherheitskritische Systeme MISRA C++ im eigenen Projekt einführen
Alle Programmiersprachen enthalten Aspekte, die unvollständig spezifiziert, mangelhaft festgelegt, oder so definiert sind, dass Compilerimplementierungen ein unterschiedliches Verhalten für so ein spezifisches Sprachkonstrukt zeigen. Jede dieser Unsicherheiten (Insecurities) kann zu einem unvorsehbaren Programmverhalten führen. C++ ist da keine Ausnahme. Dieser Beitrag zeigt wie die MISRA C++-Sprachuntermenge die inhärenten Unsicherheiten von C++ in effizienter, kosteneffektiver Weise abmildert und bietet Leitlinien für den erfolgreichen Einsatz in einem Projekt.
Anbieter zum Thema
Eine Sprachuntermenge hat die Verbesserung eines oder mehrere Aspekte hinsichtlich Portierbarkeit und Sicherheit eines Programms zum Ziel. Die MISRA C++-Untermenge (MISRA C++:2008) wurde speziell zu dem Zweck entwickelt die Programmsicherheit zu verbessern, indirekt adressiert sie aber auch einige Problemstellungen zur Integrität und Portierbarkeit. Da MISRA C++ speziell auf die Sicherheitsaspekte eines Programms abzielt, ist seine vorrangige Aufgabe jene inhärenten Unsicherheiten der C++-Sprache abzumildern, die die Programmsicherheit berühren. Zu diesem Zweck wurde die Sprachuntermenge so entwickelt, dass die Unsicherheiten, die der volle Sprachumfang enthält, in ihr nicht vorhanden sind. Sie wurden unter anderem durch Ausschluss oder Beschränkung der Sprachkonstrukte mit denen sie assoziiert sind entfernt.
Beispielsweise bezeichnet die Regel 2-13-1 dass „nur jene Escape-Folgen, die in ISO/IEC 14882:2003 definiert sind verwendet werden sollen“ und verweist deshalb auf „Undefiniert 2.13(3)“. Ein Nachschlagen bei Paragraph 3, Abschnitt 2.13.2 bei ISO/IEC 14882:2003 zeigt, dass ein nicht definiertes Verhalten entsteht, wenn „das Zeichen, dem ein Backslash vorausgeht keine gültige Escape-Sequenz ergibt“. Unglücklicherweise wird von Compiler nicht die Ausgabe einer Diagnosemeldung (Fehlermeldung) gefordert, wenn ungültige Escape-Folgen dieses Typs in einem Programm vorkommen.
Die MISRA-Regel mildert diesen Effekt durch die Anforderung, dass Überprüfungswerkzeuge solche im Code vorhandenen ungültige Escape-Folgen entdecken und aufzeichnen. Es lohnt sich darauf hinzuweisen, dass die Charakteristiken einer Sprachuntermenge einfach einer beschränkten Version des vollen Sprachumfangs entsprechen. Die Attribute einer Untermenge garantieren, dass ein Programm, welches diese Untermenge verwendet dieselbe Semantik benutzt, die es im Falle des vollen Sprachumfangs verwenden würde, wenn bei seiner Implementierung strikt die vorgegebenen Semantikregeln eingehalten werden.
Die Adaptierung einer Untermenge wie MISRA C++ hat viele Vorteile:
- Die Untermenge ist immer noch ein Teil der Standardsprache, sodass Werkzeugketten von der Stange verwendet werden können.
- Die notwendigen Fertigkeiten/Kenntnisse sind häufig vorhanden und wieder verwendbar.
- Werkzeuge, die den Standard erzwingen können, sind vorhanden.
- Das Vertrauen und die Übernahme wachsen mit der Vertrautheit.
Klar haben Untermengen auch Nachteile:
- Verbotene oder eingeschränkte Merkmale können die Codekomplexität erhöhen. Beispielsweise muss durch das Verbot der dynamischen Speicherzuweisung eine andere Speicherverwaltungsstrategie implementiert werden.
- Einige sichere Konstrukte mögen ausgeschlossen oder eingeschränkt sein als Folge einer spezifischen Unsicherheit.
- Einschränkungen können eine wortreichere Beschreibung verlangen als im Falle eines gedrängteren Konstrukts (z.B. zusätzliche Klammern um die Operatorpräzedenz explizit zu zeigen).
- Die Programmeffizienz kann sich vermindern, speziell wenn große Spracherweiterungen (z.B. Objektspeicherplatzierung) verboten sind.
Wichtige Überlegungen für die Einführung von MISRA C++
Bei der Einführung von MISRA C++ für neue Projekte fällt die Entscheidung leicht. Die Anwendung von MISRA C++ auf vorhandenen Code entmutigt dagegen Entwicklungsteams, da oft viele Verstöße gegen Standards der zu Grunde gelegten Untermenge aufgezeigt werden. Dies kann besonders dann frustrierend sein, wenn der vorhandene Code von hoher Qualität ist. Als Strategie könnte der Basiscode neu geschrieben werden, was zeitaufwendig und teuer ist und nur dann empfohlen werden kann, wenn er zertifiziert werden muss. Alternativ können Teile des Codes während der Wartung dementsprechend modifiziert werden. Bei jedem Projekt sollte festgelegt werden wie dies vor sich gehen soll, entweder Funktion für Funktion, Klasse für Klasse oder Datei für Datei. Ein rollierender Aktualisierungsprozess ist eine andere Möglichkeit die gesamte Codebasis auf den neuen Standard zu trimmen, entweder als Teil eines vorgesehenen Aktualisierungsplans oder durch die Verwendung von Ersatz-Ressourcen.
Nach der Zeitplanung muss die Entwicklungsmannschaft die verschiedenen Ebenen der Standarderzwingung in Betracht ziehen. MISRA C++ kategorisiert die Regeln in erforderlich, ratsam, oder als aufgezeigt. Die erforderlichen und einfach aufgezeigten Regeln müssen auf alle Projekte angewendet werden, können aber Abweichungen unterliegen. Regeln zu denen einfach geraten wird sollten befolgt werden. Es ist aber auch möglich sie zu ignorieren, wenn eine Risikobetrachtung ergibt, dass damit keine Sicherheitskompromisse eingegangen werden. Obwohl diese Regeln einigen Ermessensspielraum öffnen, lohnt es sich oft vorzuschreiben, dass sie immer erzwungen werden sollten, da sie ein zusätzliches Vertrauen in den untersuchten Code schaffen.
Es sei darauf hingewiesen, dass die Erzeugung von standardkonformem Code anfänglich für die darin unerfahrenen Entwickler einen zusätzlichen Aufwand bedeutet. Die Produktion von MISRA-C++-konformen Code wird jedoch bald zur zweiten Natur und minimiert im Folgenden den zusätzlichen Aufwand.
(ID:277121)