Die 10 Kodierungsregeln der NASA zum Schreiben sicherheitskritischer Programme

Große und komplexe Softwareprojekte verwenden verschiedene Codierungsstandards und Richtlinien. Diese Richtlinien legen die Grundregeln fest, die beim Schreiben von Software befolgt werden müssen. Normalerweise bestimmen sie:

a) Wie sollte der Code aufgebaut sein?
b) Welche Sprachfunktion sollte verwendet werden oder nicht?

Um effektiv zu sein, muss das Regelwerk klein und spezifisch genug sein, damit es leicht verstanden und erinnert werden kann.

Die weltweit führenden Programmierer, die bei der NASA arbeiten, befolgen eine Reihe von Richtlinien für die Entwicklung sicherheitskritischen Codes. Tatsächlich konzentrieren sich viele Agenturen, darunter das Jet Propulsion Laboratory (JPL) der NASA, auf Code, der in der Programmiersprache C geschrieben wurde. Dies liegt daran, dass es für diese Sprache eine umfassende Werkzeugunterstützung gibt, wie z. B. Logikmodell-Extraktoren, Debugger, stabile Compiler, starke Quellcode-Analysatoren und Metrik-Tools.

In kritischen Fällen wird es notwendig, diese Regeln anzuwenden, insbesondere wenn menschliches Leben von ihrer Richtigkeit und Effizienz abhängen kann. Zum Beispiel Softwareprogramme zur Steuerung von Flugzeugen, Raumfahrzeugen oder Kernkraftwerken.

Aber wissen Sie, nach welchen Standards Raumfahrtbehörden ihre Maschinen betreiben? Nachfolgend haben wir die 10 Kodierungsregeln der NASA aufgelistet, die vom leitenden JPL-Wissenschaftler Gerard J. Holzmann festgelegt wurden. Sie konzentrieren sich alle hauptsächlich auf Sicherheitsparameter, und Sie können sie auch auf andere Programmiersprachen anwenden.

Regel Nr. 1 – Einfacher Kontrollfluss

Schreiben Sie Programme mit sehr einfachen Kontrollflusskonstrukten – Verwenden Sie nicht setjmp oder longjmp Konstrukte, goto Aussagen und direkte oder indirekte Rekursion .

Grund: Ein einfacher Kontrollfluss führt zu verbesserter Code-Klarheit und stärkeren Verifizierungsmöglichkeiten. Ohne Rekursion gibt es keinen zyklischen Funktionsaufrufgraphen. Somit bleiben alle Ausführungen, die begrenzt werden sollen, tatsächlich begrenzt.

Regel Nr. 2 – Feste Obergrenze für Schleifen

Alle Schleifen müssen eine feste Obergrenze haben. Es sollte für ein Verifikationstool möglich sein, statisch nachzuweisen, dass eine voreingestellte Obergrenze für die Anzahl der Iterationen einer Schleife nicht überschritten werden kann.

Die Regel gilt als verletzt, wenn die Schleifenbindung statisch nicht bewiesen werden kann.

Grund:  Das Vorhandensein von Schleifengrenzen und das Fehlen von Rekursionen verhindern unkontrollierten Code. Die Regel gilt jedoch nicht für Iterationen, die nicht beendet werden sollen (z. B. Process Scheduler). In solchen Fällen gilt die umgekehrte Regel – Es muss statisch beweisbar sein, dass die Iteration nicht terminiert werden kann.

Regel Nr. 3 – Keine dynamische Speicherzuweisung

Verwenden Sie nach der Initialisierung keine dynamische Speicherzuweisung.

Grund: Speicherzuweisungen wie malloc , und Garbage Collectors haben oft ein unvorhersehbares Verhalten, das die Leistung außergewöhnlich beeinträchtigen kann. Darüber hinaus können Speicherfehler auch aufgrund eines Programmierfehlers auftreten, einschließlich

• Versuch, mehr Speicher zuzuweisen, als physisch verfügbar ist
• Vergessen, Speicher freizugeben
• Speicher nach Freigabe weiterhin verwenden
• Überschreitung der Grenzen des zugewiesenen Speichers

Wenn Sie alle Module zwingen, in einem festen, vorab zugewiesenen Speicherbereich zu leben, können diese Probleme beseitigt und die Speichernutzung einfacher überprüft werden.

Eine Möglichkeit, Speicher ohne Speicherzuweisung vom Heap dynamisch zu beanspruchen, besteht darin, Stapelspeicher zu verwenden.

Regel Nr. 4 – Keine großen Funktionen

Keine Funktion sollte länger sein als das, was auf einem einzigen Blatt Papier in einem Standardreferenzformat mit einer Zeile pro Erklärung und einer Zeile pro Erklärung gedruckt werden könnte. Das bedeutet, dass eine Funktion nicht mehr als 60 Zeilen Code haben sollte.

Grund: Zu lange Funktionen sind oft ein Zeichen für eine schlechte Struktur. Jede Funktion sollte eine logische Einheit sein, die sowohl verständlich als auch überprüfbar ist. Eine logische Einheit, die sich über mehrere Bildschirme auf einem Computerbildschirm erstreckt, ist ziemlich schwer zu verstehen.

Regel Nr. 5 – Niedrige Aussagedichte

Die Assertionsdichte des Programms sollte auf mindestens zwei Assertionen pro Funktion durchschnittlich sein. Assertions werden verwendet, um auf abnormale Bedingungen zu prüfen, die in realen Ausführungen niemals auftreten sollten. Sie sollten als Boolesche Tests definiert werden. Wenn eine Assertion fehlschlägt, sollte eine explizite Wiederherstellungsaktion durchgeführt werden.

Wenn ein statisches Prüftool beweist, dass die Zusicherung niemals fehlschlagen oder niemals gelten kann, gilt die Regel als verletzt.

Grund: Laut der Coding-Effort-Statistik der Branche erfassen Unit-Tests mindestens einen Fehler pro 10 bis 100 Codezeilen. Die Wahrscheinlichkeit, Fehler abzufangen, steigt mit der Assertionsdichte.

Die Verwendung von Assertion ist ebenfalls wichtig, da sie Teil einer starken defensiven Codierungsstrategie sind. Sie werden verwendet, um Vor- und Nachbedingungen einer Funktion, eines Parameters und eines Rückgabewerts einer Funktion und von Schleifeninvarianten zu überprüfen. Zusicherungen können nach dem Testen des leistungskritischen Codes selektiv deaktiviert werden.

Regel Nr. 6 – Deklarieren von Datenobjekten auf kleinstem Umfang

Dieser unterstützt das Grundprinzip des Data Hiding. Alle Datenobjekte müssen auf dem kleinstmöglichen Umfang deklariert werden.

Grund: Wenn ein Objekt nicht im Gültigkeitsbereich liegt, kann sein Wert nicht referenziert oder beschädigt werden. Diese Regel rät von der Wiederverwendung von Variablen für mehrere, inkompatible Zwecke ab, die die Fehlerdiagnose erschweren können.

Lesen Sie: 20 die besten Computerprogrammierer aller Zeiten

Regel Nr. 7 – Parameter und Rückgabewert prüfen

Die Rückgabewerte von nicht-void-Funktionen sollten von jeder aufrufenden Funktion überprüft werden, und die Gültigkeit von Parametern sollte innerhalb jeder Funktion überprüft werden.

In ihrer strengsten Form bedeutet diese Regel sogar den Rückgabewert von printf Aussagen und Datei schließen Aussagen sollten überprüft werden.

Grund: Wenn sich die Reaktion auf einen Fehler zu Recht nicht von der Reaktion auf einen Erfolg unterscheidet, sollte man einen Rückgabewert explizit überprüfen. Dies ist normalerweise der Fall bei Aufrufen zum schließen und printf . Es ist akzeptabel, den Rückgabewert der Funktion explizit in void –  . umzuwandeln zeigt an, dass der Coder explizit (nicht versehentlich) beschließt, einen Rückgabewert zu ignorieren.

Regel Nr. 8 – Begrenzte Verwendung des Präprozessors

Die Verwendung des Präprozessors sollte sich auf die Aufnahme von Header-Dateien und Makrodefinitionen beschränken. Rekursive Makroaufrufe, das Einfügen von Token und Listen mit variablen Argumenten sind nicht zulässig.

Es sollte auch bei großen Anwendungsentwicklungsprojekten eine Rechtfertigung für mehr als eine oder zwei bedingte Kompilierungsanweisungen geben, die über die Standard-Boilerplate hinausgehen, die das mehrfache Einfügen derselben Header-Datei vermeidet. Jede solche Verwendung muss durch einen toolbasierten Checker gekennzeichnet und im Code begründet werden.

Grund: Der C-Präprozessor ist ein leistungsstarkes und mehrdeutiges Tool, das die Codeklarheit zerstören und viele textbasierte Checker verwirren kann. Die Wirkung von Konstrukten in unbegrenztem Präprozessorcode kann selbst mit einer formalen Sprachdefinition außergewöhnlich schwer zu entziffern sein.

Ebenso wichtig ist die Warnung vor der bedingten Kompilierung – mit nur 10 Anweisungen zur bedingten Kompilierung könnte es 1024 mögliche Versionen (2^10) des Codes geben, was den erforderlichen Testaufwand erhöhen würde.

Lesen Sie:9 neue Programmiersprachen, die Sie dieses Jahr lernen sollten

Regel Nr. 9 – Begrenzte Verwendung von Zeigern

Die Verwendung von Zeigern muss eingeschränkt werden. Es ist nicht mehr als eine Dereferenzierungsebene zulässig. Zeigerdereferenzierungsoperationen sollten nicht in typedef . versteckt sein Deklaration oder Makrodefinitionen.

Funktionszeiger sind ebenfalls nicht erlaubt.

Grund: Zeiger werden leicht missbraucht, selbst von Experten. Sie erschweren es, den Datenfluss in einem Programm zu verfolgen oder zu analysieren, insbesondere durch werkzeugbasierte statische Analysatoren.

Funktionszeiger schränken auch die Art der Prüfungen ein, die von statischen Analysatoren durchgeführt werden. Daher sollten sie nur verwendet werden, wenn es eine starke Begründung für ihre Umsetzung gibt. Wenn Funktionszeiger verwendet werden, wird es für ein Werkzeug fast unmöglich, das Fehlen einer Rekursion nachzuweisen, daher sollten alternative Methoden bereitgestellt werden, um diesen Verlust an analytischen Fähigkeiten auszugleichen.

Lesen Sie: 14 beste Programmiersoftware zum Schreiben von Code

Regel Nr. 10 – Kompilieren Sie den gesamten Code

Der gesamte Code muss ab dem ersten Tag der Entwicklung kompiliert werden. Die Compilerwarnung muss bei der genauesten Einstellung des Compilers aktiviert werden. Der Code muss ohne Vorwarnung mit diesen Einstellungen kompiliert werden.

Der gesamte Code sollte täglich mit mindestens einem (vorzugsweise mehr als einem) hochmodernen statischen Quellcode-Analysator überprüft werden und den Analyseprozess ohne Warnung bestehen.

Grund :Es gibt viele effektive Quellcode-Analysatoren auf dem Markt; einige davon sind Freeware-Tools. Es gibt absolut keine Entschuldigung für jeden Programmierer, diese leicht verfügbare Technologie nicht zu nutzen. Wenn der Compiler oder statische Analysator verwirrt wird, sollte der Code, der die Verwirrung/den Fehler verursacht, neu geschrieben werden, damit er trivialer wird.

Lesen Sie:30 erstaunliche NASA-Erfindungen, die wir in unserem täglichen Leben verwenden

Was sagt die NASA zu diesen Regeln?