-
Die Erfindung betrifft ein Verfahren und eine Schaltungsanordnung zur Überwachung des Programmablaufs eines Prozessors.
-
Stand der Technik
-
Programmierbare integrierte Schaltungen (ICs), wie bspw. Mikroprozessoren, Mikrocontroller und digitale Signalprozessoren, werden heute in vielen technischen Anwendungen eingesetzt. Die grundlegende Eigenschaft dieser Bausteine ist deren Programmierbarkeit. Hauptbestandteile des Prozessors sind die Register, das Rechenwerk, d. h. die arithmetisch-logische Einheit, das Steuerwerk sowie Programm- und Datenspeicher. Das Verhalten der ICs wird dabei regelmäßig von Programmen, bspw. in Form von Maschinencode, bestimmt. Maschinencode bezeichnet ein System von Befehlen bzw. Instruktionen, die der jeweilige Prozessor eines datenverarbeitenden Systems direkt und ohne Kompilierung ausführen kann.
-
Eine besondere Gruppe von Befehlen bilden sogenannte Sprungbefehle. Beim Ausführen eines Sprungbefehls springt das Programm an eine bestimmte, vorgegebene Stelle im Programmcode. Bei bedingten Sprungbefehlen wird dieser Sprung in Abhängigkeit des Inhalts eines Speichers oder des Ergebnisses einer Rechenoperation ausgeführt.
-
Weiterhin ist zu beachten, dass viele Mikroprozessoren interruptfähig sind, d. h. der normale Programmablauf kann durch ein internes oder externes Signal unterbrochen werden. Dieses Signal kann z. B. das Überschreiten eines bestimmten Spannungswertes anzeigen (ereignisgesteuerte Interrupts) oder das Erreichen eines Werts im Zeitgeber bzw. Timer (zeitgesteuerte Interrupts).
-
Wie in allen elektronischen Schaltungen können auch in ICs Fehler auftreten. Dabei kann es sich um Haftfehler, d. h. permanente Fehler, oder um transiente Fehler, die z. B. durch kosmische Strahlung verursacht werden, handeln. Besonders kritisch sind diese Fehler, wenn sie den Programmablauf beeinträchtigen. Vor diesem Hintergrund wurden zahlreiche Arbeiten zur Absicherung des Programmablaufs durchgeführt. Ausführungen hierzu finden sich bspw. in der Veröffentlichung von
Goloubeva et al.: "Software-implemented Hardware Fault Tolerance", Springer-Verlag, 2006, und der Veröffentlichung von
Robinson et al.: "Direct Methods for Synthesis of Selfmonitoring State Machines", International Symposium an Fault-Tolerance Computing, Seiten 306–315, 1992.
-
Ein bekanntes Verfahren zur Überwachung des Programmablaufs ist das sogenannte Signatur-Überwachen bzw. Signature Monitoring. Bei diesem Verfahren wird zur Laufzeit ständig bzw. regelmäßig eine Signatur berechnet und an bestimmten Stellen im Programm mit einer Referenz-Signatur verglichen. Bei Abweichung wird ein Fehler gemeldet. Die Signatur kann deterministische Bitsequenzen aus jeder Ebene der Steuerung enthalten Programmcode, Hardware-Steuersignale. Die Signaturfunktion wiederum kann z. B. eine zyklische Redundanzprüfung (CRC: cyclic redundancy check) sein. Aus der Literatur bekannte Verfahren können allerdings nicht vollständig Sprünge und Unterbrechungen im Programmablauf absichern.
-
Aus der Druckschrift
EP 1 777 622 A2 sind ein Verfahren und eine Vorrichtung zum Implementieren und Ausführen einer hardwaremäßig ausgeführten Control Flow Checking Fehlererkennung im Arbeitsspeicher eines Mikroprozessors bekannt. Bei dem Verfahren werden parallel und synchron zum Befehlsdecoder einer zentralen Recheneinheit Befehlsanweisungen eingelesen und über Programmabschnitte online Signaturen gebildet. Diese Signaturen werden mit Referenzsignaturen verglichen. Bei Ungleichheit wird ein Fehlersignal erzeugt. Nachteilig bei dem beschriebenen Verfahren ist jedoch, dass nicht alle, weiter unten spezifizierten, Fehler erkannt werden können.
-
In der Druckschrift
US 5 974 529 A wird ein Verfahren zur Steuerflussüberprüfung mit Hilfe des Signature Monitorings beschrieben. Bei dem Verfahren wird eine aktuelle Signatur auf Grundlage einer vorliegenden Signatur berechnet, welche mit einer Referenzsignatur verglichen wird. Die aktuelle Signatur wird jeweils in einem Speicher abgelegt. Allerdings ist hier die Signaturüberwachung bei Programmsprüngen nicht lückenlos.
-
Offenbarung der Erfindung
-
Vor diesem Hintergrund werden ein Verfahren zur Überwachung des Programmablaufs mit den Merkmalen des Anspruchs 1 und eine Schaltungsanordnung zur Durchführung des Verfahrens gemäß Anspruch 10 vorgestellt. Weitere Ausgestaltungen der Erfindung ergeben sich aus den abhängigen Patentansprüchen, der Beschreibung und den Zeichnungen.
-
Mit dem vorgestellten Verfahren ist die nahtlose Absicherung des Programmablaufs eines Prozessors gegenüber weiter unten in der Tabelle 1 spezifizierten Fehlern im Steuerwerk gewährleistet. Dabei werden auch Sprünge und Unterbrechungen im Programm abgesichert.
-
Ein weiterer Vorteil des Verfahrens besteht darin, dass dieses zum überwiegenden Teil auf Hardware-Ebene mit wenig zusätzlicher Chipfläche implementiert werden kann. Der für das Signature Monitoring notwendige zusätzliche Programmieraufwand ist somit äußerst niedrig, so dass das vollständige Verfahren mit geringem Aufwand realisiert bzw. implementiert werden kann.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
-
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt ein Beispiel für einen Programmablauf mit möglichen Fehlern.
-
2 zeigt einen Einsatz eines Modifizierpunkts (MP).
-
3 zeigt eine Signaturberechnung bei einem bedingten Sprung.
-
4 zeigt eine Signaturberechnung bei Unterroutinen.
-
5 zeigt alternative Signaturberechnungsmöglichkeiten bei Unterroutinen.
-
6 zeigt ein Beispiel für eine mögliche Implementierung des Signaturüberwachens.
-
Ausführungsformen der Erfindung
-
Die Erfindung ist anhand von Ausführungsformen in den Zeichnungen schematisch dargestellt und wird nachfolgend unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
-
Es ist zunächst zu beachten, dass das grundlegende Prinzip des sogenannten Signature Monitoring in der fortlaufenden Signaturberechnung für alle ausgeführten Befehle und dem regelmäßigen Vergleich der aktuellen Signatur mit einem Referenzwert besteht. Die aktuelle. Signatur wird dabei üblicherweise aus der vorherigen Signatur und aus dem Binärwert des aktuellen Befehls (operation code, opcode) berechnet (Funktion f). Die Referenzsignatur wird bei der Erstellung des Programms berechnet. Das Vergleichen der Referenzsignatur mit der aktuellen Signatur wird an so genannten Überwachungspunkten bzw. Checkpoints (CPs) durchgeführt.
-
Die Signaturberechnung des laufenden Programms sowie der Vergleich mit eifern Referenzwert findet in Ausgestaltung in Hardware statt. Unter Verwendung von geeigneten Signaturfunktionen, wie z. B. Cyclic Redundancy Checks, kann eine Hardwarerealisierung einfach gestaltet werden. Je nach Befehlssatz des Prozessors kann ein schon vorhandener Befehl, wie bspw. der NOP-Befehl (no operation), als Checkpoint verwendet werden. Dabei kann der Referenzwert direkt im Befehlswort stehen, wenn die Speicherbreite des Programmspeichers dies zulässt. Dies führt zu einer besonders aufwandsarmen Realisierung, da keine weiteren Befehle für den Transport der Referenzwerte notwendig sind.
-
Das vom Entwickler geschriebene Programm wird in sogenannte atomare Einheiten (ATE) aufgeteilt. Das sind Programmabschnitte, die keine Sprünge und Schleifen enthalten.
-
In 1 ist ein möglicher Programmablauf skizziert. Die Darstellung zeigt eine Reihe von ersten atomaren Einheiten ATE 10, die jeweils n Befehle umfassen, nämlich Befehl 1 (Bezugsziffer 12) bis Befehl n (Bezugsziffer 14). Eine der ersten ATEs 10 ist, wie durch eine geschwungene Klammer 16 angezeigt ist, als Subroutine im Programmablauf vorgesehen. Weiterhin sind eine zweite ATE 20 mit Befehl 1 (Bezugsziffer 22) bis Befehl k (Bezugsziffer 24), eine dritte ATE 30 mit Befehl 1 (Bezugsziffer 32) bis Befehl m (Bezugsziffer 34), eine vierte ATE 40 mit Befehl 1 (Bezugsziffer 42) bis Befehl p (Bezugsziffer 44), eine fünfte ATE 50 mit Befehl k + 1 (Bezugsziffer 52) bis Befehl n (Bezugsziffer 54), eine sechste ATE 60 mit Befehl m + 1 (Bezugsziffer 62) bis Befehl n (Bezugsziffer 64) und eine siebte ATE 70 mit Befehl p + 1 (Bezugsziffer 72) bis Befehl n (Bezugsziffer 74) vorgesehen.
-
Nach dem Start 80 werden nacheinander verschiedene Programmabschnitte (ATE) ausgeführt. Zwischen den ATEs 10, 20, 30, 40, 50, 60, 70 finden bedingte oder nicht bedingte Sprünge statt. Zusätzlich kann jederzeit ein Interrupt auftreten.
-
Der Programmablauf soll nun gegenüber Fehlern abgesichert werden. Mögliche Fehler sind in
1 gestrichelt eingezeichnet und in Tabelle 1 näher beschrieben.
| Fehler-Nr. | Fehlerbeschreibung |
| 1 | Sprung von einer beliebigen Steller einer ATE zum Anfang einer anderen ATE |
| 2 | Sprung von einer beliebigen Stelle einer ATE zu einer beliebigen Stelle einer anderen ATE |
| 3 | Fehlerhafter Sprung vom Ende einer ATE zum Beginn einer anderen ATE |
| 4 | Sprung vom Ende einer ATE zu einer beliebigen Stelle einer anderen ATE |
| 5 | Sprung innerhalb einer ATE |
| 6 | Falscher bedingter Sprung: Es wurde ein Pfad genommen, der nicht der Bedingung entspricht. |
| 7 | Falscher Rücksprung aus einer Subroutine: Das Programm springt nicht an die ursprüngliche Stelle im Programmcode zurück |
Tabelle 1: Klassifizierung möglicher Fehler im Programmablauf
-
Das vorgeschlagene Verfahren zeichnet sich dadurch aus, dass die Signaturüberwachung auch bei Sprüngen (bedingt oder nicht bedingt), bei Interrupts und bei Subroutinen nahtlos fortgesetzt wird. Im Folgenden wird dies näher beschrieben.
-
Eine ATE kann einen oder mehrere CPs enthalten, an denen die Signaturüberprüfung stattfindet. Bei einem nicht bedingten Sprung wird die Signatur sofort oder einige Takte nach dem Sprung überprüft. Somit wird ein Sprung an den Anfang einer falschen ATE erkannt. Führen nun zum Anfang einer ATE mehrere Pfeile von verschiedenen ATEs, so wird direkt nach dem Sprung in jedem dieser ATEs eine Modifizierung der Signatur durchgeführt (Modifizier-Point, MP). Dabei wird die aktuelle Signatur mit einem bestimmten Modifizier-Wert verknüpft, und zwar derart, dass der resultierende Signaturwert der Referenzsignatur am Anfang der Ziel-ATE entspricht. Auf diese Weise hat die aktuelle Signatur am Anfang des Ziel-ATEs den gleichen Wert unabhängig davon, welche ATE vorher abgearbeitet wurde.
-
Dieses Prinzip ist in 2 dargestellt. Die Darstellung zeigt eine erste ATE 100 mit einer Reihe von Befehlen, nämlich Befehl 1 (Bezugsziffer 102) bis zu einem Sprungbefehl 104 (JUMP_label1), eine zweite ATE 110 mit einer Reihe von Befehlen, nämlich Befehl 1 (Bezugsziffer 112) bis zu einem Sprungbefehl 114 (JUMP_label1) und eine dritte ATE 120 mit einer Reihe von Befehlen, nämlich Befehl 1 (Bezugsziffer 122) bis zu einem Sprungbefehl 124 (JUMP_label1). Eine vierte ATE 130 mit einer Bezeichnung 132 label1, einem Checkpoint 134, einem Referenzwert 136 R1 und einer Reihe an Befehlen, einschließlich Befehl n (Bezugsziffer 138) ist weiterhin vorgesehen.
-
Die Darstellung zeigt weiterhin einen ersten Modifizierpunkt bzw. Modifizier-Point 150 mit einem Modifizierwert 152 M1, einen zweiten Modifizierpunkt 160 mit einem Modifizierwert 162 M2 und einen dritten Modifizierpunkt 170 mit einem Modifizierwert 172 M3.
-
Beim Ausführen des Modifizier-Points 150, 160 oder 170 wird die neue Signatur aus der aktuellen Signatur und dem Modifizierwert M1, M2 oder M3 und ggf. aus dem aktuellen Befehl unter Anwendung der Modifizierfunktion g berechnet. Somit wird vorteilhafterweise eine inkorrekte Signatur durch den Modifizier-Point 150, 160 oder 170 nicht überschrieben, sondern führt zu einer neuen, ebenfalls inkorrekten Signatur. Ein fehlerhafter Zustand bleibt deshalb auch über die Grenzen einer ATE 100, 110, 120 oder 130 erkennbar.
-
Bei einem bedingten Sprung muss zusätzlich überprüft werden, ob der gewählte Pfad der aktuellen Bedingung entspricht. Dies wird dadurch erreicht, dass beim Sprung die Bedingung in die Signaturberechnung mittels einer erweiterten Funktion f' miteinbezogen wird, wie in 3 dargestellt ist. Die Darstellung zeigt eine erste ATE 200 mit einer Bezeichnung 202 label1 und einer Reihe von Befehlen, einschließlich eines Sprungbefehls 204 JUMPx_label2, eine zweite ATE 210 mit einem CP 212, einem Referenzwert 214 R1 und einem Befehl n (Bezugsziffer 216) sowie eine dritte ATE 220 mit einer Bezeichnung 222 label2, einem CP 224, einem Referenzwert 226 R1 und einem Befehl n (Bezugsziffer 228).
-
Die Bedingung ist entweder erfüllt oder nicht, dies entspricht einer binären Null oder Eins. Man kann z. B. das LSB der eben berechneten Signatur mit diesem Binärwert XOR-verknüpfen.
-
Am Anfang der jeweiligen Ziel-ATE oder einige Takte später kann ein CP stehen, der die resultierende Signatur mit dem entsprechenden Referenzwert vergleicht. Auf diese Weise wird überprüft, ob beim Sprung der richtige Pfad genommen wurde. Der CP kann auch wesentlich später durchgeführt werden, denn die Signatur wird stets nur modifiziert, niemals mit einem neuen Wert überschrieben, so dass die Information über einen Fehler erhalten bleibt.
-
Eine weitere Schwierigkeit bei der fortlaufenden Signaturberechnung stellen die Subroutinen bzw. Unterprogramme dar. Hier wird der Programmablauf bedingt oder nicht bedingt unterbrochen und es wird eine Subroutine aufgerufen und ausgeführt. Danach muss das Programm an der unterbrochenen Stelle fortgesetzt werden. Das Signature Monitoring überprüft, ob die Subroutine und der Rücksprung richtig ausgeführt wurden. Dies wird durch vier Maßnahmen erreicht: beim Sprung zur Subroutine wird kein MP ausgeführt, in der Subroutine selber wird kein CP ausgeführt, beim bedingten Sprung zur Subroutine wird im negativen Pfad (d. h. die Sprungbedingung ist nicht erfüllt) ein MP ausgeführt und nach dem Rücksprung aus der Subroutine kann ein CP ausgeführt werden. Die Implementierung aller vier Maßnahmen ermöglicht die Überprüfung der Subroutine und des Rücksprungs.
-
Dieses Prinzip ist in 4 dargestellt. Die Darstellung zeigt eine erste ATE 300 mit einem Befehl 1 (Bezugsziffer 302) und einem Sprungbefehl 304 JUMPx_sub, eine zweite ATE 310 mit einem Befehl 1 (Bezugsziffer 312) und einem Sprungbefehl 314 JUMP_sub und eine dritte ATE 320 mit einem Befehl 1 (Bezugsziffer 322) und einem Sprungbefehl 324 JUMPx_sub. Weiterhin zeigt 4 eine vierte ATE 330 mit einem CP 332, einem Referenzwert 334 R1 und einem Befehl n (Bezugsziffer 336), eine fünfte ATE 340 mit einem CP 342, einem Referenzwert 344 R2 und einem Befehl n (Bezugsziffer 346) sowie eine sechste ATE 350 mit einem CP 352, einem Referenzwert 354 R3 und einem Befehl n (Bezugsziffer 356).
-
Weiterhin sind eine Subroutine 360 mit einer Bezeichnung 362 sub und einem Befehl n (Bezugsziffer 364) sowie ein erster Modifizierpunkt 370 mit einem Modifizierwert 372 M1 und ein zweiter Modifizierpunkt 380 mit einem Modifizierwert 382 M3 bereitgestellt.
-
In der Subroutine selber darf kein CP stehen, denn dort kann der aktuelle Signaturwert verschiedene Werte annehmen, je nach dem, welche ATE vorher abgearbeitet wurde. Nach dem Rücksprung aus der Subroutine steht in der neuen ATE ein CP mit entsprechendem Referenzwert. Hier wird festgestellt, ob das Programm an die richtige Stelle zurückgesprungen ist und ob die Subroutine richtig abgearbeitet wurde.
-
Alternativ kann man beim Aufrufen einer Subroutine einen Modifizier-Point (MP) ausführen. In dieser Variante verzichtet man auf die Erkennung falscher Rücksprünge. Die Signaturüberprüfung innerhalb der Subroutine wird jedoch hierdurch möglich, was zu einer kürzeren Latenzzeit bei Fehlererkennung führt. Dabei ist der Modifizierwert so zu wählen, dass die aktuelle Signatur in der Subroutine den selben Wert aufweist, unabhängig davon welche ATE vorher abgearbeitet wurde. In der Subroutine selber dürfen dann ein oder mehrere Checkpoints enthalten sein. Der Modifizier-Point im negativen Pfad ist bei dieser Variante nicht mehr notwendig. Diese Alternative ist in 5 dargestellt.
-
In Tabelle 2 sind alle Zustände des Signature Monitorings zusammengefasst. Während der normalen Signaturberechnung wird fortlaufend die Signatur aus dem aktuellen Befehl und der vorherigen Signatur berechnet. Bei einem bedingten Sprung wird zunächst die Signatur wie gewohnt berechnet und anschließend wird dieser Wert z. B. XOR-verknüpft mit der Bedingung x. An einem Checkpoint wird zunächst der Signaturwert mit dem Referenzwert verglichen und anschließend wird die neue Signatur aus der vorherigen Signatur und dem aktuellen Befehl berechnet. Bei einem MP wird eine Modifizierfunktion g angewendet. Diese ist nicht notwendigerweise identisch mit der Signaturfunktion. Eine vorteilhafte Funktion ist bspw. die XOR-Verknüpfung der aktuellen Signatur mit dem Modifizierwert, damit der neue Signaturwert einen bestimmten gewünschten Wert hat.
| Normale Signaturberechnung | Signatur(t) = f(Signatur(t – 1), Befehl(t)) |
| Bedingte Signaturberechnung | Signatur(t) = f(Signatur(t – 1), Befehl(t)), x), x: Bedingung |
| Checkpoint (CP) | Vergleiche Signatur(t – 1) mit dem Referenzwert, dann berechne Signatur(t) = f(Signatur(t – 1), Befehl(t)) |
| Modifizier-Point (MP) | Signatur(t) = g(Signatur(t – 1), M, Befehl(t)), M: Modifizierwert |
Tabelle 2: Mögliche Zustände beim Signature Monitoring
-
Das beschriebene Verfahren des Signature Monitorings kann auch bei interruptfähigen Systemen eingesetzt werden. Ein Interrupt kann zu jedem beliebigen Zeitpunkt auftreten, d. h. die Signaturberechnung muss jederzeit bereit sein, auf das Interruptsignal zu reagieren. Dies wird dadurch erreicht, dass beim Auftreten des Interrupts ein Backup der aktuellen Signatur gebildet und beim Start der sogenannten Interrupt-Service-Routine (ISR) eine neue Signaturberechnung gestartet wird. Bei mehrfach interruptfähigen Systemen kann dabei die Anfangssignatur in Abhängigkeit der Interrupt-Ereignisse gewählt werden.
-
Am Ende der ISR wird ein CP ausgeführt. Beim Rücksprung zum Hauptprogramm wird die Backup-Signatur in den Signatur-Speicher zurückgeholt. Mit diesem Wert wird die Signaturberechnung dann fortgesetzt. Auf diese Weise wird der Ablauf des Hauptprogramms und der ISR abgesichert. In der ISR können natürlich gegebenenfalls auch mehrere CPs stehen. Bei mehreren möglichen Interrupt-Ereignissen mit unterschiedlicher Priorität können mehrere Backup-Werte gespeichert werden, z. B. in einem LIFO-Register.
-
Das Signature Monitoring überprüft in typischerweise regelmäßigen Abständen, ob der Prozessor die richtigen Befehle ausgeführt hat. Bei Abweichung der aktuellen Signatur vom Referenzwert kann im Fehlerfall ein Fehler gemeldet werden. Eine Übereinstimmung der aktuellen Signatur mit der vorher berechneten Signatur wird ebenfalls vorteilhafterweise gemeldet. Diese Vorgehensweise hat den entscheidenden Vorteil, dass katastrophale Fehler, die beispielweise zu einem Anhalten der Programmausführung führen, ebenfalls von einem externen Beobachter erkannt werden können, beispielweise durch das Überschreiten einer festgelegten Zeit zwischen zwei Checkpoints.
-
Merkmale des hier vorgestellten Signature Monitorings lassen sich folgendermaßen zusammenfassen:
Grundlegendes Prinzip:
Fortlaufende Signaturberechnung aus der vorherigen Signatur und dem aktuellen Befehl,
typischerweise regelmäßiger Vergleich der aktuellen Signatur mit dem Referenzwert (CP),
Meldung des Ergebnisses des Vergleichs in positivem als auch im negativen Fall (optional),
Verwendung von Modifizierpunkten.
Verhalten beim nicht bedingten Sprung:
Führung zur Zieladresse mehrere Pfade, so wird beim Sprung ein MP durchgeführt.
Verhalten beim bedingten Sprung:
Beim Sprung wird eine bedingte Signaturberechnung durchgeführt.
Abarbeitung von Subroutines:
Beim Sprung zur Subroutine wird kein MP ausgeführt,
in der Subroutine selber wird kein CP ausgeführt,
beim bedingten Sprung zur Subroutine wird im negativen Pfad ein MP ausgeführt.
Abarbeiten von Subroutines (alternativ):
Beim Sprung zur Subroutine wird ein MP ausgeführt,
in der Subroutine selber werden ein oder mehrere CP ausgeführt,
die Notwendigkeit eines MP im negativen Pfad entfällt.
Verhalten beim Interrupt:
Backup der aktuellen Signatur wird gebildet,
beim Start der ISR wird eine neue Signaturberechnung gestartet und am Ende der ISR wird die Signatur überprüft (CP),
beim Rücksprung zum Hauptprogramm wird die Backup-Signatur zurückgeholt und die Signaturberechnung wird fortgesetzt,
bei mehreren Interrupts mit unterschiedlichen Prioritäten werden mehrere Backup-Signaturen gebildet.
Beobachter:
Überwacht, ob ein CP regelmäßig ausgeführt wird um z. B. festzustellen ob, das Programm abgearbeitet wird und der Programm-Counter nicht stehen geblieben ist.
-
In 6 ist eine mögliche Implementierung des Signature Monitorings vereinfacht dargestellt. Durch das Signature Monitoring werden Fehler in Steuerwerk eines Prozessors erkannt. Dazu gehören u. a. ein Programmspeicher 400, ein Programm-Counter bzw. -Zähler 402, ein Hardware-Loop-Counter 404 (z. B. bei digitalen Signalprozessoren) und Teilschaltungen in einem Befehlsdecoder 406, die für Sprünge im Programmablauf zuständig ist. Weiterhin zeigt die Darstellung eine Interrupt-Einheit 408, die Interrupt-Signale 410 aufnimmt, eine Signatur-Überwachungslogik bzw. Signature-Monitoring-Logik 412, die einen Opcode 414 (ein Opcode ist eine Bitfolge, die einen Maschinenbefehl eines Prozessors repräsentiert. Alle Opcodes zusammen bilden den Befehlssatz des Prozessors) vom Programmspeicher 400 empfängt, ein Signaturregister 416, das eine neue Signatur 418 und eine aktuelle Signatur 420 mit der Signature-Monitoring-Logik 412 austauscht, ein Signatur-Sicherungsregister bzw. Signature-Backup-Register 422 und eine elektronische Einheit 424 mit einer ALU 426, einem Speicher 428, einer Ein-/Ausgabe-Einheit 430 und einem Statusregister 432. Steuersignale 434 werden von dem Befehlsdecoder 406 zu der elektronischen Einheit 424 gegeben. Die Signature-Monitoring-Logik 412 kann ein Fehlersignal 436 ausgeben.
-
Das vorgestellte Verfahren bietet eine nahtlose Überwachung des Programmablaufs eines Prozessors, es werden alle Sprünge und Unterbrechungen abgedeckt. Durch die Implementierung auf der Hardware-Ebene lässt sich das Signature Monitoring mit wenig Aufwand realisieren.
-
Das hierin beschriebene Verfahren hat einige wichtige, vorteilhafte Unterschiede im Vergleich zu bekannten Verfahren, wie diese bspw. in der Druckschrift
US 5 974 529 beschrieben sind:
Bei dem beschriebenen Verfahren wird die aktuelle Signatur immer nur modifiziert, niemals aber explizit überschrieben. Dies erhöht die Fehlerabdeckung des Verfahrens.
-
Durch die Verwendung von Modifizier-Points hat die Signatur nach einem Sprung zu einer bestimmten Adresse immer den gleichen Wert, unabhängig davon, aus welchem Programmabschnitt der Sprung stattfand (vergleiche auch
2). Auf diese Weise kann eine lückenlose Signaturberechnung für das komplette Programmdurchgeführt werden. Diese Eigenschaft hat das in der Druckschrift
US 5 974 529 A beschriebene Verfahren nicht.
-
Es erfolgt eine Implementierung des Checkpoints und des Modifizier-Points in einem bestehenden Befehl des Befehlssatzes (z. B. NOP-Befehl). Dadurch wird der zusätzliche Programmcode minimal. Selbstverständlich kann das vorgeschlagene Verfahren auch unter Verwendung eines expliziten Modifizier-Points- und Checkpoint-Befehls realisiert werden.
-
Es bleibt festzuhalten, dass mit dem vorgestellten Verfahren eine erheblich verbesserte Fehlerabdeckung erreicht werden kann.
-
Bei einem Prozessor mit Signature Monitoring kann ein Fehlersignal vorgegeben sein, das einen Fehler oder Nichtfehler im Programmablauf anzeigt. Der Status kann über eine externe Schnittstelle ausgegeben werden.
-
Das vorgestellte Verfahren eignet sich zur Absicherung des Programm- bzw. Steuerflusses aller programmierbarer ICs. Dies ist besonders bei ICs, die in sicherheitskritischen Anwendung eingesetzt werden (z. B. Automobilelektronik, Medizintechnik), von großer Bedeutung.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- EP 1777622 A2 [0007]
- US 5974529 A [0008, 0048]
- US 5974529 [0047]
-
Zitierte Nicht-Patentliteratur
-
- Goloubeva et al.: ”Software-implemented Hardware Fault Tolerance”, Springer-Verlag, 2006 [0005]
- Robinson et al.: ”Direct Methods for Synthesis of Selfmonitoring State Machines”, International Symposium an Fault-Tolerance Computing, Seiten 306–315, 1992 [0005]
