-
Die vorliegende Offenbarung bezieht sich auf Verfahren zum Testen eines Computerprogramms.
-
Ein wesentlicher Bestandteil der Entwicklung von Softwareanwendungen ist das Testen und, wenn Fehler gefunden werden, eine entsprechende Fehlerbereinigung. Insbesondere sollten Fehler, die zum Versagen einer Anwendung führen, identifiziert und korrigiert werden. Ein wichtiger Aspekt ist dabei das Testen hinsichtlich darauf, dass
auf wichtige Speicherbereiche nicht ungewollt (oder durch einen Angreifer) zugegriffen wird, d.h. ein Testen mit Speicherüberwachung, wie sie durch einen sogenannten (Speicher-)Sanitizer erfolgt. Das Kompilieren und Testen von Software auf gängiger Desktop- und Server-Hardware, z. B. x86, mit Hilfe verschiedener Sanitizer ist eine Maßnahme, gegen die Fehler wie beispielsweise der Heartbleed-Bug, der zuvor lange unentdeckt geblieben ist, entdeckt werden können.
-
Besonders für Computerprogramme auf eingebetteten Systemen, wie z.B. Steuereinrichtungen für ein Fahrzeug, die oft sicherheitsrelevant sind, ist ein umfassendes Testen, das auch eine solche Speicherüberwachung mit einbezieht, wichtig. Sanitizer, die für Desktop- und Server-Hardware eingesetzt werden, sind für solche Systeme jedoch nicht oder nur schlecht einsetzbar, weil eingebettete Systeme typischerweise über eingeschränkte Ressourcen verfügen und solche Sanitizer einen erheblichen Ressourcenbedarf haben und somit nicht verwendet werden können oder sogar die Ausführung des Computerprogramms so beeinflussen können, dass überhaupt erst ein Fehler entsteht oder ein Fehler unentdeckt bleibt.
-
Es sind deshalb Verfahren für das Testen von Computerprogrammen, die eine Speicherüberwachung ermöglichen und für eingebettete Systeme geeignet sind, wünschenswert.
-
Gemäß verschiedenen Ausführungsformen wird ein Verfahren zum Testen eines Computerprogramms bereitgestellt, aufweisend Ermitteln von uninitialisierte Variablen des Testprogramms, Setzen von Watchpoints auf Speicherstellen, die für die uninitialisierten Variablen reserviert sind und Ausführen des Computerprogramms, wobei das Verfahren für jeden gesetzten Watchpoint aufweist: Entfernen des Watchpoints, falls in die Speicherstelle, auf die der Watchpoint gesetzt ist, geschrieben wird und Anzeigen, dass das Computerprogramm einen Fehler hat, falls der Watchpoint durch einen Lesezugriff ausgelöst wird.
-
Dies kann für jeden oder zumindest mehrere Speicherfreigabefehle, die im Computerprogramm auftreten, vorgenommen werden (z.B. abhängig davon, wie viele Watchpoints zur Verfügung stehen). Die Watchpoints können Lese-Watchpoints, Schreibe-Watchpoints oder Watchpoints sein, die sowohl beim Lesen als auch beim Schreiben auslösen.
-
Das oben beschriebene Verfahren ermöglicht ein Testen mit Speicherüberwachung (d.h. mit einem Sanitizer) hinsichtlich uninitialisierter Lesezugriffe (d.h. Lesezugriffen auf uninitialisierte Speicherbereiche) auf einem eingebetteten System mit Hilfe eines Debuggers. Dies eignet sich besonders beim Testen mit Fuzzing, da auch Fuzzing Debugger-gesteuert implementiert werden kann und auf diese Weise effektiv für eingebettete Systeme verwendet werden kann.
-
Sanitizer können mittels Code-Instrumentierung implementiert werden. Dazu muss aber entweder der Quellcode zur Verfügung stehen, oder es ist eine anweisungssatzspezifische Instrumentierung auf der Grundlage der Binärdatei (binäre Instrumentierung) erforderlich, die sehr anfällig ist. Eine alternative, auf einem Emulator basierende Instrumentierung ist ebenfalls sehr plattformspezifisch, und jede eingebettete Plattform benötigt einen eigenen Emulator. Das oben beschriebene Verfahren ermöglicht das Testen mit einem Debugger-gesteuerten Sanitizer und erfordert keine Instrumentierung oder Emulation und ist daher in vielen Fällen anwendbar.
-
Im Folgenden werden verschiedene Ausführungsbeispiele angegeben.
-
Ausführungsbeispiel 1 ist ein Verfahren zum Testen eines Computerprogramms wie oben beschrieben.
-
Ausführungsbeispiel 2 ist das Verfahren nach Ausführungsbeispiel 1, wobei das Computerprogramm bis zum Aufruf des Speicherallokierungsbefehls ausgeführt wird, Informationen darüber, welcher Speicherbereich durch den Speicherallokierungsbefehl allokiert wird, gespeichert werden und anhand der gespeicherten Informationen die ein oder mehreren Speicherstellen, auf die Watchpoints gesetzt werden, ermittelt werden.
-
In anderen Worten kann bei einem Speicherallokierungsbefehl die Ausführung angehalten werden (mittels Setzen von Breakpoints) und es können Informationen über den jeweiligen allokierten Speicherbereich gespeichert werden
-
Ausführungsbeispiel 3 ist das Verfahren nach Ausführungsbeispiel 1 oder 2, aufweisend Freigeben des Speicherbereichs und Entfernen der ein oder mehreren Watchpoints, abhängig von einer Laufzeit (z.B. bei Überschreiben eines vorgegebenen Schwellwerts in Form einer absoluten Zeit (z.B. Millisekunden) oder einer Anzahl von Taktzyklen) des Computerprogramms (z.B. seit dem Erreichen des Speicherfreigabebefehls).
-
Damit wird vermieden, dass der Speicherbereich dauerhaft blockiert ist (d.h. nicht mehr neu allokiert werden kann), was bei längeren Programmen bzw. solchen, die einen hohen Speicherbedarf haben, zu Problemen führen könnte.
-
Ausführungsbeispiel 4 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 3, aufweisend Ausführen des Computerprogramms auf einem eingebetteten System und Setzen der Watchpoints durch ein mit dem eingebetteten System verbundenes Testsystem.
-
Gemäß verschiedenen Ausführungsformen wird insbesondere das Testen eines Computerprogramms für ein eingebettetes System auf dem eingebetteten System selbst inklusive einer Speicherüberwachung ermöglicht.
-
Ausführungsbeispiel 5 ist das Verfahren nach einem der Ausführungsbeispiele 1 bis 4, wobei das Computerprogramm ein Steuerprogramm für eine Robotervorrichtung ist und die Robotervorrichtung abhängig von einem Ergebnis des Testens des Computerprogramms mit dem Computerprogramm gesteuert wird.
-
Ausführungsbeispiel 6 ist eine Testanordnung, die eingerichtet ist, ein Verfahren nach einem der Ausführungsbeispiele 1 bis 5 durchzuführen.
-
Ausführungsbeispiel 7 ist ein Computerprogramm mit Befehlen, die, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor ein Verfahren nach einem der Ausführungsbeispiele 1 bis 5 durchführt.
-
Ausführungsbeispiel 8 ist ein computerlesbares Medium, das Befehle speichert, die, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor ein Verfahren nach einem der Ausführungsbeispiele 1 bis 5 durchführt.
-
In den Zeichnungen beziehen sich ähnliche Bezugszeichen im Allgemeinen auf dieselben Teile in den ganzen verschiedenen Ansichten. Die Zeichnungen sind nicht notwendigerweise maßstäblich, wobei die Betonung stattdessen im Allgemeinen auf die Darstellung der Prinzipien der Erfindung gelegt wird. In der folgenden Beschreibung werden verschiedene Aspekte mit Bezug auf die folgenden Zeichnungen beschrieben.
- 1 zeigt einen Computer für die Entwicklung und/oder das Testen von Softwareanwendungen.
- 2 zeigt ein Ablaufdiagramm, das ein Verfahren zum Testen eines Computerprogramms gemäß einer Ausführungsform darstellt.
-
Die folgende ausführliche Beschreibung bezieht sich auf die begleitenden Zeichnungen, die zur Erläuterung spezielle Details und Aspekte dieser Offenbarung zeigen, in denen die Erfindung ausgeführt werden kann. Andere Aspekte können verwendet werden und strukturelle, logische und elektrische Änderungen können durchgeführt werden, ohne vom Schutzbereich der Erfindung abzuweichen. Die verschiedenen Aspekte dieser Offenbarung schließen sich nicht notwendigerweise gegenseitig aus, da einige Aspekte dieser Offenbarung mit einem oder mehreren anderen Aspekten dieser Offenbarung kombiniert werden können, um neue Aspekte zu bilden.
-
Im Folgenden werden verschiedene Beispiele genauer beschrieben.
-
1 zeigt einen Computer 100 für die Entwicklung und/oder das Testen von Softwareanwendungen.
-
Der Computer 100 weist eine CPU (Central Processing Unit) 101 und einen Arbeitsspeicher (RAM) 102 auf. Der Arbeitsspeicher 102 wird zum Laden von Programmcode verwendet, z.B. von einer Festplatte 103, und die CPU 101 führt den Programmcode aus.
-
Im vorliegenden Beispiel wird davon ausgegangen, dass ein Benutzer beabsichtigt, mit dem Computer 100 eine Softwareanwendung zu entwickeln und/oder zu testen.
-
Dazu führt der Benutzer eine Softwareentwicklungsumgebung 104 auf der CPU 101 aus.
-
Die Softwareentwicklungsumgebung 104 ermöglicht es dem Benutzer, eine Anwendung 105 für verschiedene Geräte 106, also ein Ziel-Hardware, wie eingebettete Systeme zum Steuern von Robotervorrichtungen, inklusive Roboterarme und autonome Fahrzeuge, oder auch für mobile (Kommunikations-)Geräte, zu entwickeln und zu testen. Dazu kann die CPU 101 als Teil der Softwareentwicklungsumgebung 104 einen Emulator ausführen, um das Verhalten des jeweiligen Geräts 106 zu simulieren, für das eine Anwendung entwickelt wird oder wurde. Wird sie nur zum Testen einer Software aus anderer Quelle eingesetzt, kann die Softwareentwicklungsumgebung 104 auch als Softwaretestumgebung angesehen werden bzw. ausgestaltet sein.
-
Der Benutzer kann die fertige Anwendung über ein Kommunikationsnetzwerk 107 an entsprechende Geräte 106 verteilen. Statt über ein Kommunikationsnetzwerk 107 kann dies auch auf andere Weise erfolgen, beispielsweise mittels eines USB-Sticks.
-
Bevor dies geschieht, sollte der Benutzer jedoch die Anwendung 105 testen, um zu vermeiden, dass eine nicht ordnungsgemäß funktionierende Anwendung an die Geräte 106 verteilt wird.
-
Ein Testverfahren ist das sogenannte Fuzzing. Fuzzing oder Fuzz-Testing ist ein automatisiertes Software-Testverfahren, bei dem einem zu testenden Computerprogramm ungültige, unerwartete oder zufällige Daten als Eingaben zugeführt werden. Das Programm wird dann auf Ausnahmen wie Abstürze, fehlende fehlgeschlagene integrierte Code-Assertions oder potenzielle Speicherlecks hin überwacht.
-
Typischerweise werden Fuzzer (d.h. Testprogramme, die Fuzzing verwenden) zum Testen von Programmen verwendet, die strukturierte Eingaben verarbeiten. Diese Struktur ist z. B. in einem Dateiformat oder einem Dateiformat oder Protokoll spezifiziert und unterscheidet zwischen gültigen und ungültigen Eingaben. Ein effektiver Fuzzer erzeugt halb-gültige Eingaben die „gültig genug“ sind, um nicht direkt vom Eingabeparser des zu testenden Programms zurückgewiesen zu werden, aber „ungültig genug“ sind, um unerwartete Verhaltensweisen und Grenzfälle aufzudecken, die im zu testenden Programm nicht richtig behandelt werden.
-
Im Folgenden wird im Zusammenhang mit Fuzzing verwendete Terminologie beschrieben:
- • Fuzzing oder Fuzz-Testing ist der automatisierte Test-Prozess, zufällig generierte Eingaben an ein Zielprogramm (zu testendes Programm) zu senden und seine Reaktion zu beobachten.
- • Ein Fuzzer oder eine Fuzzing-Engine ist ein Programm, das automatisch Eingaben generiert. Sie ist also nicht mit der zu testenden Software verknüpft, und es wird auch keine Instrumentierung durchgeführt. Es hat jedoch die Fähigkeit, Code zu instrumentieren, Testfälle zu erzeugen und zu testende Programme auszuführen. Bekannte Beispiele sind afl und libfuzzer.
- • Ein Fuzz-Target ist ein Softwareprogramm oder eine Funktion, die durch Fuzzing getestet werden soll. Ein Hauptmerkmal eines Fuzz-Targets sollte sein, dass es potenziell nicht vertrauenswürdige Eingaben annimmt, die vom Fuzzer während des während des Fuzzing-Prozesses erzeugt wird.
- • Ein Fuzz-Test ist die kombinierte Version eines Fuzzers und eines Fuzz-Targets. Ein Fuzz-Target kann dann instrumentierter Code sein, bei dem ein Fuzzer mit seinen Eingaben verknüpft ist (d.h. diese liefert). Ein Fuzz-Test ist ausführbar. Ein Fuzzer kann auch mehrere Fuzz-Tests starten, beobachten und stoppen (normalerweise Hunderte oder Tausende pro Sekunde), jeder mit einer etwas anderen Eingabe, die vom Fuzzer erzeugt wird.
- • Ein Testfall ist eine bestimmte Eingabe und ein bestimmter Testdurchlauf aus einem Fuzz-Test. Normalerweise werden für die Reproduzierbarkeit interessante Läufe (Finden von neuen Codepfaden oder Abstürzen) gespeichert. Auf diese Weise kann ein bestimmter Testfall mit der entsprechenden Eingabe auch auf einem Fuzz-Target ausgeführt werden, das nicht mit einem Fuzzer verbunden ist, z.B. die Release-Version eines Programms.
- • Abdeckungsgesteuertes Fuzzing (engl. coverage-guided fuzzing) verwendet Code-Abdeckungsinformationen als Feedback während des Fuzzings, um zu erkennen, ob eine Eingabe die Ausführung neuer Code-Pfade oder Blöcke verursacht hat.
- • Generator-basiertes Fuzzing (engl. generation-based fuzzing) verwendet vorheriges Wissen über das Zielprogramm (Fuzz-Target), um Testeingaben zu erstellen. Ein Beispiel für ein solches Vorwissen ist eine Grammatik, die der Eingabespezifikation des Fuzz-Targets entspricht, d.h. die Eingabe-Grammatik des Fuzz-Targets (d.h. des zu testenden Programms).
- • Statische Instrumentierung ist das Einfügen von Anweisungen in ein (zu testendes) Programm, um Feedback über die Ausführung zu erhalten. Sie wird meist durch den Compiler realisiert und kann zum Beispiel die erreichten Codeblöcke während der Ausführung angeben.
- • Dynamische Instrumentierung ist die Steuerung der Ausführung eines (zu testenden) Programms während der Laufzeit, um Feedback aus der Ausführung zu generieren. Sie wird meist durch Betriebssystem-Systemfunktionalitäten oder durch die Verwendung von Emulatoren realisiert.
- • Ein Debugger ist eine Vorrichtung oder ein Programm, das ein Zielgerät oder Zielprogramm steuern kann und Funktionen bereitstellen kann, z.B. zum Abrufen von Register- oder Speicherwerten und zum Pausieren und Ausführen es Zielprogramms in Einzelschritten.
- • Ein Breakpoint wird über einen Debugger auf eine Anweisung des Zielprogramms oder Geräts gesetzt, um die Ausführung bei Erreichen zu stoppen und den steuernden Prozess darüber zu informieren.
- • Ein (Daten-)Watchpoint wird über einen Debugger auf eine Speicheradresse eines Zielprogramms oder Zielgeräts gesetzt, um die Ausführung anzuhalten, wenn auf die Speicheradresse zugegriffen wird, und den steuernden Prozess darüber zu informieren, indem ein Interrupt ausgelöst wird.
-
Eingebettete Systeme verfügen in der Regel über einen Mikrocontroller, der Eingaben verarbeitet und mit Ausgaben reagiert, um eine bestimmte Aufgabe zu erfüllen. Obwohl Mikrocontroller das gleiche Speichermodell verwenden und mit den gleichen Programmiersprachen programmiert werden wie normale Benutzerprogramme, sind ihre Programme wesentlich schwieriger zu testen. Um das Debugging zu ermöglichen, bieten Mikrocontroller in der Regel die Möglichkeit, das Programm mit Breakpoints (Haltepunkten) zu unterbrechen, die Anweisungen des Programms in Einzelschritten zu durchlaufen und Watchpoints auf Speicheradressen zu setzen. Watchpoints lösen einen Interrupt aus, wenn auf die entsprechenden Speicherbereiche zugegriffen wird. Hardware-Break- und Watchpoints sind typischerweise als physische Register in der Debug-Einheit eines Mikrocontrollers implementiert und ihre Anzahl ist daher begrenzt und hängt vom jeweiligen System ab. Beispielsweise ist die maximale Anzahl für einen typischen Mikrocontroller vier Breakpoints und zwei Daten-Watchpoints. Normalerweise können Watchpoints zwischen Lese- und Schreibzugriffen unterscheiden.
-
Breakpoints und Watchpoints können insbesondere für die Realisierung eines Debugger-gesteuerten Fuzzings verwendet werden, sodass es keine Instrumentierung erfordert.
-
Fuzzing, auch Debugger-gesteuertes Fuzzing, ist sehr effizient beim Auffinden von Fehlern, die ein beobachtbares Verhalten auslösen, wie z.B. einen Absturz oder Neustart. Allerdings können ganze Klassen von Fehlern nicht beobachtet werden, da das Programm bei diesen stillschweigend versagt. Ein Beispiel ist der Heartbleed-Bug. Der Kern des Heartbleed-Bugs lag darin, dass er nur über die Grenze eines Arrays hinaus liest, während eine Schreiboperation einen leicht zu beobachtenden Segmentierungsfehler verursacht hätte.
-
Der Heartbleed-Bug wurde erst mit Hilfe des Address Sanitizer (ASan) gefunden. ASan fügt während der Kompilierung eines Programms zusätzliche Anweisungen, Metadaten und Überprüfungen ein, um Fehler bei der Speicherbeschädigung zu verhindern. Wenn solche Sanitizer-Anweisungen in einem Programm verfügbar sind, können beim Debuggen des Programms mehr Fehler gefunden werden als ohne Sanitizer. Insbesondere automatisierte Tests, wie Fuzzing, glänzen, wenn ein Sanitizer im zu testenden Programm (d.h. im Fuzz-Target) vorgesehen ist, um zusätzliche Fehler aufdecken.
-
Für eingebettete Systeme, wie einer Datenverarbeitungsvorrichtung mit ARM-Architektur, sind solche Sanitizer nicht so einfach verwendbar wie für Standardplattformen, wie x86-Plattformen. Dafür gibt es mehrere Gründe:
- • Ein eingebettetes System ist zu ressourcenbeschränkt, um einen Sanitizer zu implementieren. Zum Beispiel benötigt Asan den doppelten Speicher, MSan (MemorySanitizer) benötigt das 2,5-fache der Ressourcen, und UBSan (UndefinedBehaviorSanitizer) benötigt sogar das Dreifache des Arbeitsspeichers des Programms.
- • Sanitizer erhöhen die Größe der kompilierten Binärdatei. In der Automobilindustrie entspricht die Größe solcher Binärdateien in der Regel nahezu dem verfügbaren Flash-Speicher der Zielhardware. Eine zusätzliche Instrumentierung eines Sanitizers würde deshalb nicht in den Flash-Speicher passen.
- • Aufgrund der zusätzlichen Instrumentierung von Sanitizern und der Sammlung und Verfolgung von Metadaten führt die Verwendung eines Sanitizers zu einer langsameren Laufzeit eines Binärprogramms auf der jeweiligen Hardware. Eingebettete Systeme sind stark abhängig von asynchronen Ereignissen, wie z. B. Interrupts, und daher können Sanitizer zu zeitbasierten Falsch-Positiv-Fehlern führen, d.h. ein Sanitizer kann während der Laufzeit neue Fehler einführen.
- • Eingebettete Systeme haben in der Regel keine Benutzeroberfläche zur Anzeige von Laufzeitfehlern. Auf x86-Systemen wird beispielsweise ein Segmentierungsfehler an STDERR weitergeleitet, so dass der Benutzer den Absturz sieht. Eingebettete Systeme hingegen versagen stillschweigend, d. h. ohne dass der Benutzer es bemerkt, und starten nach einem solchen Absturz neu.
-
Gemäß verschiedenen Ausführungsformen wird deshalb eine Herangehensweise bereitgestellt, die die Verwendung einer Speicherüberwachung (d.h. einer Sanitizer-Funktionalität) für ein eingebettetes System ermöglicht, insbesondere so, dass die Speicherüberwachung für ein Debugger-gesteuertes Fuzzing verwendet werden kann. Dabei wird die Speicherüberwachung selbst mit Hilfe eines (bzw. des für das Fuzzing verwendeten) Debuggers ermöglicht.
-
Beim Debugger-basierten Fuzzing erfolgen Interaktionen zwischen dem System, das den Test durchführt (und das z.B. dem Computer 100 entspricht) und dem Zielsystem (Zielhardware, z.B. einem eingebetteten System, beispielsweise einem Zielgerät 106) über eine Debug-Verbindung (d.h. Debug-Schnittstelle), die beispielsweise von einer dedizierten Debugger-Hardware-Vorrichtung bereitgestellt wird. Die Test-Eingabedaten werden in Form eines Eingabevektors, z.B. über WiFi oder einen CAN-Bus (je nach Typ des Zielgeräts 106) an das Zielsystem 106 übertragen, d.h. das Kommunikationsnetzwerk 107 ist bei diesem Testen eine solche Debug-Verbindung (beim Verteilen der getesteten Software kann das Kommunikationsnetzwerk dann irgendein anderes Kommunikationsnetzwerk sein). Das System, das den Test durchführt, im Folgenden auch als Testsystem 100 bezeichnet, steuert die Ausführung des Zielprogramms (d.h. des zu testenden Programms) im Zielsystem über die Debug-Verbindung, d.h. startet die Ausführung und nimmt die Ausführung nach einem Interrupt (insbesondere einen Interrupt, der durch einen Daten-Watchpoint ausgelöst wurde) wieder auf.
-
Ein Debugger-gesteuerter Sanitizer benötigt keine Instrumentierung oder Emulation, sondern nur eine Debug-Schnittstelle zum Zielsystem (z.B. einem eingebetteten System, auf dem die Software ausgeführt wird) mit der Möglichkeit, Break- und Watchpoints zu setzen. Diese Art von Debug-Schnittstellen und - Fähigkeiten sind generisch und weithin verfügbar, was zu einer breiten und einfachen Anwendbarkeit der im Folgenden beschriebenen Herangehensweise führt. Außerdem wird der Speicher des Zielsystems nur wenig belastet, z. B. für Metadaten, da die meisten oder alle Sanitizer-bezogenen Informationen auf der Host-Seite des Debuggers (d.h. im testenden System 100) gesammelt und gespeichert werden, sodass das eingebettete System auch in seiner fertigen Version (wie es z.B. verkauft wird) getestet werden kann. Die Größe der kompilierten Binärdatei des Zielprogramms wird nicht erhöht, da sie so wie sie für das Zielsystem 106 für den Einsatz vorgesehen ist beim Testen verwendet werden kann.
-
Ein Debugger hält das Zielsystem an, wenn ein Breakpoint erreicht wird. Daher führt die im Folgenden beschriebenen Herangehensweise nur in seltenen Fällen zu zeitbasierten Fehlalarmen. Diese Fehlalarme können auch durch andere Testtechniken ausgeschlossen werden, z. B. durch anschließende Validierung eines gefundenen Fehlers auf dem Zielsystem. Die Verwendung eines Debuggers bietet außerdem einen guten Einblick in die Interna eines Zielsystems.
-
Die im Folgenden beschriebene Herangehensweise dient zur Detektion des Lesens von uninitialisiertem Speicher. Dabei wird insbesondere eine geringe Zahl von falsch-positiv Detektionsergebnissen gering gehalten, beispielsweise in Hinblick darauf, dass der C++14-Standard explizit die Propagierung uninitialisierter Werte durch ein Programm erlaubt, solange sie nicht verwendet werden (d.h. solche uninitialisierte Werten werden gemäß verschiedenen Ausführungsformen nicht als Fehler detektiert).
-
Dafür werden die Speicherstellen, die für uninitialisierte Variablen reserviert sind, mittels Watchpoints überwacht. Da die Anzahl der Watchpoints begrenzt sein kann, ist es möglich, dass nicht alle Speicherstellen auf diese Weise in jedem Testlauf des zu testenden Programms überwacht werden können. Ist dies der Fall, kann das Testsystem die Teilmenge der Speicherbereiche, die überwacht werden sollen, zufällig auswählen oder die Speicherbereiche werden hintereinander in mehreren Durchläufen des Zielprogramms (z.B. Fuzz-Testdurchläufen) überwacht.
-
Beispielsweise führt das Testsystem 100 Folgendes durch:
- 1. Festlegen der zu überwachenden Speicherstellen. Diese beinhalten beispielsweise die Speicherstellen für alle Variablen des jeweiligen Programms ohne statische Variablen und vorinitialisierte Variablen.
- 2. Anlegen einer Schatten-Speicherkarte (engl. shadow memory map) für die zu überwachenden Speicherstellen (z.B. die Speicherstellen (z.B. Bytes oder auch mehr Bytes, je nach Größe der Variablen), die für die Menge verbleibender (d.h. ohne statische und vorinitialisierte) Variablen reserviert sind). Beispielsweise ist jedem Byte der zu überwachenden Speicherbereiche ein jeweiliges Bit der Schatten-Speicherkarte zugeordnet. Die Schatten-Speicherkarte wird mit „Dirty-Bits“ gefüllt (z.B. alle Bits der Schatten-Speicherkarte werden zunächst auf eine Wert gesetzt (z.B. 1), der anzeigt, dass das jeweilige Byte noch nicht initialisiert wurde).
- 3. Durchführen ein oder mehrerer Testläufe des Programms (z.B. abhängig von der Anzahl der zu überwachenden Speicherstellen und der Anzahl zur Verfügung stehenden Watchpoints) und dabei jeweils:
- a. Setzen von Watchpoints auf Speicherbereiche (z.B. Bytes), für die die Schatten-Speicherkarte ein Dirty-Bit enthält.
- b. Beim Auslösen eines Watchpoints
- i. Falls er durch ein Schreiben ausgelöst wurde, Löschen des Watchpoints.
- ii. Falls er durch ein Lesen ausgelöst wurde, wird dies als Fehler gewertet (uninitialisiertes Lesen aus dem Speicher). Das Testsystem 100 zeigt in diesem Fall deshalb an, dass ein Fehler aufgetreten ist, was wiederum die Ausführung einer Sicherheitsmaßnahme auslösen kann.
- c. Aktualisieren der Schatten-Speicherkarte für die jeweilige Speicherstelle, d.h. Entfernen des Dirty-Bits der Schatten-Speicherkarte für die jeweilige Speicherstelle (z.B. Setzen der Schatten-Speicherkarte auf 0 für die jeweilige Speicherstelle), abhängig von der gewählten Strategie für das Platzieren der Watchpoints. Werden die Watchpoints beispielsweise nacheinander (über mehrere Testläufe hinweg) auf die zu überwachenden Speicherstellen gesetzt, ist die Aktualisierung der Schatten-Speicherkarte beispielsweise nicht nötig, sondern es werden einfach für einen nächsten Testlauf (mit neu gesetzten Watchpoints) die nächsten (bisher noch nicht überwachten) Speicherstellen mit Watchpoints versehen. Werden jedoch als Ziel für die Watchpoints in jedem Testlauf Speicherstellen gesampelt, auf den die Watchpoints gesetzt werden, kann es wünschenswert sein, die Schatten-Speicherkarte zu aktualisieren, damit die Speicherstellen gleichmäßig überwacht werden (wobei es aber auch sinnvoll sein kann, Speicherstellen in mehreren Testläufen zu überwachen, falls im Sinne von Fuzzing Eingaben des Programms von Testlauf zu Testlauf geändert werden).
-
Eine Speicherstelle wird hier als eine Einheit des Speichers verstanden, die von einem Watchpoint überwacht wird, also z.B. der einer Speicheradresse (die als Ziel eines Watchpoints gewählt werden kann) zugeordnete Speicherbereich.
-
Zusammengefasst wird gemäß verschiedenen Ausführungsformen ein Verfahren bereitgestellt, wie in 2 dargestellt.
-
2 zeigt ein Ablaufdiagramm 200, das ein Verfahren zum Testen eines Computerprogramms gemäß einer Ausführungsform darstellt.
-
In 201 werden uninitialisierte Variablen des Testprogramms ermittelt.
-
In 202 werden Watchpoints auf Speicherstellen gesetzt, die für die uninitialisierten Variablen reserviert sind.
-
In 203 wird das Computerprogramm ausgeführt, wobei das Verfahren für jeden gesetzten Watchpoint aufweist:
- • Entfernen des Watchpoints, falls in die Speicherstelle, auf die der Watchpoint gesetzt ist, geschrieben wird; und
- • Anzeigen, dass das Computerprogramm einen Fehler hat, falls (d.h. in Reaktion darauf, dass) der Watchpoint durch einen Lesezugriff ausgelöst wird.
-
Das Verfahren von 2 kann durch einen oder mehrere Computer mit einer oder mehreren Datenverarbeitungseinheiten durchgeführt werden. Der Begriff „Datenverarbeitungseinheit“ kann als irgendein Typ von Entität verstanden werden, die die Verarbeitung von Daten oder Signalen ermöglicht. Die Daten oder Signale können beispielsweise gemäß mindestens einer (d.h. einer oder mehr als einer) speziellen Funktion behandelt werden, die durch die Datenverarbeitungseinheit durchgeführt wird. Eine Datenverarbeitungseinheit kann eine analoge Schaltung, eine digitale Schaltung, eine Logikschaltung, einen Mikroprozessor, einen Mikrocontroller, eine Zentraleinheit (CPU), eine Graphikverarbeitungseinheit (GPU), einen Digitalsignalprozessor (DSP), eine integrierte Schaltung einer programmierbaren Gatteranordnung (FPGA) oder irgendeine Kombination davon umfassen oder aus dieser ausgebildet sein. Irgendeine andere Weise zum Implementieren der jeweiligen Funktionen, die hierin genauer beschrieben werden, kann auch als Datenverarbeitungseinheit oder Logikschaltungsanordnung verstanden werden. Es können ein oder mehrere der im Einzelnen hier beschriebenen Verfahrensschritte durch eine Datenverarbeitungseinheit durch eine oder mehrere spezielle Funktionen ausgeführt (z. B. implementiert) werden, die durch die Datenverarbeitungseinheit durchgeführt werden.
-
Die Herangehensweise von 2 dient zum Testen eines Programms, beispielsweise einer Steuersoftware für eine Robotervorrichtung. Der Begriff „Robotervorrichtung“ kann als sich auf irgendein technisches System beziehend verstanden werden, wie z. B. eine computergesteuerte Maschine, ein Fahrzeug, ein Haushaltsgerät, ein Elektrowerkzeug, eine Fertigungsmaschine, einen persönlichen Assistenten oder ein Zugangssteuersystem. Die Steuersoftware kann auch für datenverarbeitende Systeme wie z.B. ein Navigationsgerät verwendet werden.
-
Das Verfahren von 2 wird beispielsweise durch eine Testanordnung (z.B. Computer 100 und Zielgerät 106 von 1) durchgeführt.
-
Obwohl spezielle Ausführungsformen hier dargestellt und beschrieben wurden, wird vom Fachmann auf dem Gebiet erkannt, dass die speziellen Ausführungsformen, die gezeigt und beschrieben sind, gegen eine Vielfalt von alternativen und/oder äquivalenten Implementierungen ausgetauscht werden können, ohne vom Schutzbereich der vorliegenden Erfindung abzuweichen. Diese Anmeldung soll irgendwelche Anpassungen oder Variationen der speziellen Ausführungsformen abdecken, die hier erörtert sind. Daher ist beabsichtigt, dass diese Erfindung nur durch die Ansprüche und die Äquivalente davon begrenzt ist.