Startseite > Messen + Testen > Testsysteme > Verlässlichkeit auf Systemdesign-Basis

Fachinterview Safety&Security

Verlässlichkeit auf Systemdesign-Basis

28. Juni 2019, 10:37 Uhr | Dr. Constantin Tomaras

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 3

Kontrollflussmethoden

D&E: Obige Methoden härten das System sozusagen mit der Implementierung auf Hard- oder Softwareebene ab. Welche Gegenmaßnahmen greifen noch speziell in der Ausführung?

DZ: Das leisten Kontrollflussüberwachungen. Hierbei wird die Ausführung mit einer gegebenen Spezifizierung abgeglichen. Sie wird meist statisch zur Übersetzungszeit gegeben. Die Maßnahme härtet nicht nur gegen Schadsoftware, sondern auch gegenüber strahlungsinduzierte Fehler, Alterungseffekte und invasiv physische Angriffe.

Dazu gibt es Software- und Hardware-Methoden. Eine bekannte software-basierte Methode erstellt einen Kontrollflussgraphen anhand von Annahmen. Dann werden spezielle Steuerbefehle am Anfang und Ende eines Grundblocks eingefügt, die prüfen ob das Programm diese Routine korrekt durchlaufen hat (Bild 3).

Dazu prüft ein zusätzlicher Kontrollfluss-Identifizierer, ob der nächste Block erreicht wird, also die Ausführungsabfolge eingehalten wird. Das nimmt natürlich Einfluss auf die Performanz und bietet nur Sicherheit an den Übergängen der Blöcke. Feinere Methoden geben jedem Programmblock eine Signatur und validieren die Ausführung im Vergleich mit einer gespeicherten oder berechneten Folge.

Jobangebote+ passend zum Thema

Ingenieur/Elektroingenieur/Elektrotechniker als Field Application Engineer

GEYER Electronic GmbH, Planegg

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Auf Bagchi und weitere geht eine präventive Signatur-Prüfung zurück, die Verzweigungen und Sprünge im Fehlerfall verhindern kann. Dabei wird die Zieladresse zur Laufzeit, mit der validen Adresse aus dem übersetzten Code, abgeglichen. Bei invalider nächster Adresse wird eine Ausnahme ausgelöst.

Eine Hardware-basierte Methode ist ein Watchdog-Co-Prozessor, der das Verhalten des ausführenden Kerns überwacht. Speicherzugriff, Kontrollfluss, Steuersignale oder sogar die Bewertung von Rechenergebnissen können überwacht werden. Im Fehlerfall kann der Co-Prozessor, z.B. über einen Interrupt eingreifen und eine Ausführung anhalten. Der Co-Prozessor kann über den Systembus oder direkt angeschlossen werden. Hier entsteht kein großer Perfomanz-Overhead wie bei Programm-Manipulation. Für Kontrollflusschecks haben Watchdog-Prozessoren eine eigene Routine: an den Verzweigungen werden dabei Marken eingefügt.

Die Methoden werden dann anhand der Speicherung dieser Marken kategorisiert - im Programmcode (ESM, Bild 4a) oder einem separaten Speicherblock (ASM, Bild 4b). Die ASM-Methoden haben keinen Einfluss auf die Programmperformanz, dafür liegt die Herausforderung in der Synchronisierung von CPU und Watchdog. Infolge sind Interrupts, Multi-Threading und indirekte Verzweigungen nicht vollständig oder nur sehr schwer auflösbar.

D&E: Sie haben auch eigene Kontrollfluss-Checks entwickelt?

DZ: Ja das stimmt. Wir haben zwei Verfahren zur Auflösung von direkten Sprüngen und Verzweigungen und eine Möglichkeiten für indirekte Sprünge angedacht. Sehr direkt können diese an einem RISC-Prozessor illustriert werden.

Im Allgemeinen kategorisieren sich Kontrollflussbefehle in bedingte Verzweigungen und unbedingte Sprünge. Bedingungen sind dabei logischer oder arithmetischer Natur. Die meisten Prozessorarchitekturen handeln Arithmetik in einem sogenannten »Integer-Condition-Codes«-Register. Dort werden auch Signale zur Beschreibung des Ergebnis' gesetzt. Anhand dieser Signale wird die Verzweigung ausgeführt.

Die Evaluationsart wird statisch gesetzt, erfolgt aber zur Laufzeit - die Ziele von Kontrollflussbefehlen können in direkte (statisch) oder indirekte (zur Laufzeit) unterteilt werden. Bei direkten Kontrollflussbefehlen wird das Ziel von einem Sprung oder Verzweigung mit der Übersetzung als absolute oder relative Adressinformation angegeben. Bei indirekten wird diese erst mit der Programmausführung evaluiert und gesetzt.

Direkte Kontrollflussbefehle sind z.B. call, goto, if, then, else, indirekte vor allem return-Anweisungen. Indirekte bedingungsabhängige Verzweigungen kommen in bekannten Architekturen üblicherweise nicht vor.

SoCs führen oft nur eine handvoll Programme aus, gerade im Embedded-Bereich, bei dem das Produkt bis auf Firmware- oder Software-Updates unangetastet bleibt. Oft führen auch rechenintensive Anwendungen nur wenige Subroutinen aus, deshalb ist es wirksam deren Verzweigungen und Sprünge statisch zu analysieren. Beinhaltet ein Codeabschnitt nur direkte Steuerbefehle, so kann der zugehörige Kontrollfluss sogar befehlsgenau validiert werden. Dazu müssen Adressen von Kontrollflussbefehl und Zieladresse mit dem Programmzähler verglichen werden. Bei Abweichung wird ein Fehlersignal erzeugt.

Das kann auch auf andere Befehlsarten angewandt werden: ein Fehlersignal wird erzeugt, wenn der Programmzähler nicht erhöht wurde. Die zu validierenden Adressdaten werden mit der CF- oder der CFI-Methode gespeichert: die CF-Methode analysiert eine Menge von Grundblöcken, bei denen Sprünge/Verzweigungen nur am Blockende auftreten.

Der Beginn ist durch den ersten Befehl, den Folgebefehl eines Kontrollflussbefehls, oder das Ziel eines Kontrollflussbefehls gegeben. Der Kontrollfluss-Graph ordnet dann die Anfangsadressen dieser Blöcke mit wachsenden Adressen in einem Zustandsdiagramm. Die Kanten zwischen den Grundblöcken zeigen den Übergang von Block zu Block. Die Kontrollflussinformation des Zustandsautomaten kann dann mit drei Puffern für Kontrollfluss-Befehlsadresse, Ziel des Sprungs und Sprungart gespeichert werden. Schlussendlich wird die Ausführung mit diesem Zustandsautomaten in einer zusätzlichen Überprüfungseinheit abgeglichen.

Die CFI-Methode betrachtet nicht die Blockadressen sondern die Kontrollflussbefehle. Bei direkten Sprüngen/Zweigen sind die Adressen im Maschinencode enthalten. Gegenüber der CF-Methode ist das Zustandsdiagramm noch kompakter, da Blockübergänge ohne explizite Sprünge nicht berücksichtigt werden. Trotzdem fällt der Overhead für die Prüfroutine beim CFI in der Sparc V8 Architektur höher aus.

Indirekte Sprünge und Verzweigungen sind weitaus schwieriger zu überprüfen, da die Adressen nicht aus dem statischen Code gewonnen werden können. Aus der Hardware-Perspektive sind alle erreichbaren Zieladressen eines Sprunges spezifikationskonform. Indirekte Sprünge sind daher Angriffspunkt der meisten Malware-Attacken. Auf der Logikseite sind solche Sprünge durchaus durch den Übersetzer reguliert, der etwa eine Sprungtabelle verwendet. Werden indirekte Sprünge dagegen händisch gesetzt, so werden sie unberechenbar: händisches ASM-Programmieren hat durchaus Nachteile auf der Security-Seite!

Zur Validierung in der Laufzeit muss der Kontrollfluss überwacht werden. Typischerweise kehrt der Programmzeiger zur nachfolgenden Adresse des Subroutinen-Aufrufes zurück. Spezielle Einheiten können die Zieladresse einer indirekten Verzweigung vorhersagen. Die Vorhersage wird dabei anhand des früheren Sprungverhaltens getroffen. Damit kann eine Aussage getroffen werden, wie verlässlich die genommene Sprungadresse ist. Eine nicht-vorhergesagte Sprungadresse hat eine niedrigere Vertrauenswürdigkeit. Mit so einer Methode kann aber keine exakte Aussage getroffen werden.