DE102011005209B4 - Programmanweisungsgesteuerte Instruktionsflusskontrolle - Google Patents

Programmanweisungsgesteuerte Instruktionsflusskontrolle Download PDF

Info

Publication number
DE102011005209B4
DE102011005209B4 DE102011005209.7A DE102011005209A DE102011005209B4 DE 102011005209 B4 DE102011005209 B4 DE 102011005209B4 DE 102011005209 A DE102011005209 A DE 102011005209A DE 102011005209 B4 DE102011005209 B4 DE 102011005209B4
Authority
DE
Germany
Prior art keywords
signature
program
interrupt
subfunction
function
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102011005209.7A
Other languages
English (en)
Other versions
DE102011005209A1 (de
Inventor
Dr. Mangard Stefan
Dr. Gammel Berndt
Steffen Sonnekalb
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Infineon Technologies AG
Original Assignee
Infineon Technologies AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies AG filed Critical Infineon Technologies AG
Priority to DE102011005209.7A priority Critical patent/DE102011005209B4/de
Priority to FR1200600A priority patent/FR2972545B1/fr
Priority to US13/409,369 priority patent/US10515206B2/en
Priority to CN201210057989.0A priority patent/CN102708013B/zh
Publication of DE102011005209A1 publication Critical patent/DE102011005209A1/de
Application granted granted Critical
Publication of DE102011005209B4 publication Critical patent/DE102011005209B4/de
Priority to US16/678,397 priority patent/US10867028B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Executing Machine-Instructions (AREA)
  • Storage Device Security (AREA)
  • Debugging And Monitoring (AREA)
  • Selective Calling Equipment (AREA)

Abstract

Vorrichtung zum Ausführen eines Programms, die eine Recheneinheit und ein Signaturmodul aufweist, wobei das Signaturmodul ausgebildet ist, um auf der Grundlage von Instruktionen eine Signatur zu berechnen und in einem Signaturregister abzulegen, wobei bei der Ausführung des Programms durch die Recheneinheit Aufrufe von Unterbrechungsroutinen oder Unterfunktionen auftreten, wobei die Vorrichtung zum Ausführen des Programms ausgebildet ist, um: wenn ein Aufruf einer Unterbrechungsroutine stattfindet, die dem unterbrochenen Programm zugeordnete Signatur mittels einer Programmanweisung der Unterbrechungsroutine aus dem Signaturmodul auszulesen und zu speichern, und vor dem Verlassen der Unterbrechungsroutine mittels einer Programmanweisung der Unterbrechungsroutine die gespeicherte Signatur in das Signaturmodul zu schreiben, oder wenn ein Aufruf einer Unterfunktion stattfindet: – vor dem Aufruf der Unterfunktion mittels einer eine relative Änderung der Signatur bewirkenden Programmanweisung die Signatur in dem Signaturregister an einen Anfangsreferenzsignaturwert anzupassen, der einem Anfang der Unterfunktion zugeordnet ist, so dass bei ordnungsgemäßem Aufrufen der Unterfunktion die Signatur beim Aufruf der Unterfunktion mit dem Anfangsreferenzsignaturwert übereinstimmt, und – nach einem Rücksprung aus der Unterfunktion mittels einer weiteren, eine relative Änderung der Signatur bewirkenden Programmanweisung die Signatur in dem Signaturregister an eine Signatur des Programmabschnitts anzupassen, aus dem der Aufruf der Unterfunktion stattfand, so dass bei ordnungsgemäßem Rückspringen von der Unterfunktion zum Programm, die Signatur an einem definierten Punkt des Programms mit einer dem definierten Punkt zugeordneten Referenzsignatur des Programms übereinstimmt, wobei der definierte Punkt nach der weiteren Programmanweisung ist.

Description

  • Ausführungsbeispiele der vorliegenden Erfindung schaffen eine Vorrichtung zum Ausführen eines Programms, die eine Recheneinheit und ein Signaturmodul aufweist. Das Signaturmodul ist eine Komponente, die einer Instruktionsflusskontrolle der Ausführung des Programms auf der Recheneinheit dient. Weitere Ausführungsbeispiele der vorliegenden Erfindung schaffen ein Signaturmodul, das ausgebildet ist, um bei der Ausführung eines Programms durch eine Recheneinheit auf der Grundlage von Programmanweisungen an die Recheneinheit eine Signatur zu berechnen und in einem Signaturregister des Signaturmoduls abzulegen. Weitere Ausführungsbeispiele der vorliegenden Erfindung schaffen ein Verfahren zum Berechnen einer Signatur auf der Grundlage von Instruktionen, die von einer Recheneinheit während der Ausführung eines Programms ausgeführt werden, und zum Ablegen der Signatur in einem Signaturregister eines Signaturmoduls.
  • Wenn ein Programm (Software) auf einer Recheneinheit (Hardware) ausgeführt wird, so wird in der Regel erwartet, dass das Programm auch tatsächlich so ausgeführt wird, wie es vom Kompilierer zur Kompilierzeit vorgesehen war. In der Realität kann die Ausführung eines Programms bzw. eines Codes jedoch von dem ursprünglich geplanten Programmablauf abweichen. Verantwortlich hierfür sind beispielsweise Fehler in der Hardware, Störsignale oder auch gezielte, mutwillige Manipulationen an der Recheneinheit. Fehler in der Hardware können beispielsweise auf ungewollte Leitungskurzschlüsse, Leitungsunterbrechungen oder hängende Schaltelemente (sog. „stuck-at faults”) zurückgeführt werden, um einige häufig auftretende Arten von Hardwarefehlern zu nennen. Störsignale können während des Betriebs der Recheneinheit beispielsweise durch elektromagnetische Felder oder auch in Form von extremen Temperaturen, die außerhalb des für die Recheneinheit vorgesehenen Temperaturbereichs liegen, auftreten. Mutwillige Manipulationen der Hardware können beispielsweise durch Kurzschließen von ausgewählten Kontakten, Leitungsunterbrechungen oder Laserbestrahlung der Recheneinheit und/oder eines an die Recheneinheit angeschlossenen Speichers erfolgen. Die genannten Fehlerarten können beispielsweise innerhalb der Recheneinheit selbst, innerhalb eines Speichers, in dem das Programm gespeichert ist, innerhalb weiterer Komponenten eines Systems, welches die Recheneinheit umfasst, oder in elektrischen Verbindungen zwischen den Komponenten des Rechnersystems auftreten. Um derartige Fehler während der Ausführung des Programms zu detektieren, kann eine Instruktionsflusskontrolle durchgeführt werden.
  • Für die Zwecke der Instruktionsflusskontrolle wird in der Regel während der Programmerstellung ein Prüfwert berechnet, der sich aus den Instruktionen des Programms an die Recheneinheit ergibt. Beispielsweise können die Operationscodes (Opcodes) der Instruktionen aufaddiert werden, um auf diese Weise eine Prüfsumme zu bilden. Bei einem linearen Programm, welches in der Regel vom Programmbeginn bis Programmende einschließlich aller dazwischenliegenden Instruktionen ausgeführt wird, kann somit eine einzige Prüfsumme (bzw. allgemeiner: Prüfwert) berechnet werden, die am Programmende oder nach dem Programmende geprüft werden kann. Für diese Überprüfung wird parallel zur Ausführung einer jeden Instruktion durch die Recheneinheit der Wert dieser Instruktion (beispielsweise in Form des als Bitmuster vorliegenden opcodes) mit dem Inhalt eines speziellen Registers verrechnet, z. B. zu dem Registerinhalt addiert oder mit dem Registerinhalt bitweise Exklusiv-Oder (XOR) verknüpft. Sobald alle Instruktionswerte auf diese Weise in dem speziellen Register berücksichtigt wurden, kann der sich ergebende Wert des speziellen Registers mit einem Referenz-Prüfwert verglichen werden, um festzustellen, ob eine Übereinstimmung zwischen beiden Werten vorliegt. Sofern eine Übereinstimmung vorliegt, kann in der Regel von einer ordnungsgemäßen Ausführung des Programms ausgegangen werden, d. h. das Programm wurde tatsächlich so ausgeführt, wie es zum Zeitpunkt der Programmerstellung geplant war. Der Referenz-Prüfwert kann beispielsweise als Konstante im Programmcode abgelegt sein. Je nachdem, auf welche Weise und mit welcher Programmiersprache das Programm erstellt wurde, kann der Referenz-Prüfwert von einem Kompilierer („compiler”) berechnet und in den Programmcode hineingeschrieben werden.
  • Häufig weisen Programme Verzweigungen im Programmfluss auf, die auch als „bedingte Sprünge” angesehen werden können. Nach einer Verzweigung kann das Programm auf zumindest zwei Pfaden fortgesetzt werden, wobei sich die Entscheidung darüber, welcher der zwei oder mehr möglichen Pfade gewählt wird, erst zur Laufzeit des Programms durch die Auswertung einer Bedingung ergibt. Man beachte, dass sich Verzweigungspunkte mit mehr als zwei möglichen Verzweigungspfaden in der Regel in elementare Verzweigungspunkte zerlegen lassen, d. h. in Verzweigungspunkte, die jeweils nur zwei mögliche Verzweigungspfade aufweisen. Für den Wert, der während der Laufzeit des Programms berechnet wird, bedeutet dies, dass er davon abhängt, welche Pfade wie oft durchlaufen wurden. Damit beispielsweise gegen Ende des Programms oder an einem anderen Punkt innerhalb des Programmablaufs ein Vergleich zwischen dem aktuellen Prüfwert und einem für diesen Punkt definierten Referenz-Prüfwert durchgeführt werden kann, besteht die Möglichkeit, den Prüfwert innerhalb der verschiedenen Pfade, die durchlaufen werden können, aneinander auszurichten. Dies kann in der Form erfolgen, dass der Kompilierer in einen Pfad eine oder mehrere für den Programmablauf an sich überflüssige Instruktion(en) einbaut, die den Prüfwert derart verändern, dass der besagte Pfad an einem Zusammenführungspunkt mit einem anderen Pfad den gleichen Prüfwert wie dieser andere Pfad hat.
  • Neben Verzweigungspunkten, die innerhalb eines Programms auftauchen und von dem Code dieses Programms definiert werden, kann es auch vorkommen, dass die Abarbeitung des Programms durch die Recheneinheit zeitweilig unterbrochen wird, um ein anderes Programm auszuführen bzw. fortzusetzen. Eine derartige Unterbrechung wird mit dem englischen Begriff „interrupt” bezeichnet. Eine weitere Möglichkeit, von der bei der Programmierung von Programmen für Computersysteme und ähnlichen Systemen relativ häufig Gebrauch gemacht wird, besteht darin, dass ein bestimmtes Programm eine Funktion aufruft, die in einem anderen Programm (beispielsweise einer Programmbibliothek („software library”)) vorhanden ist. Da die in der Programmbibliothek definierte Funktion bzw. Unterfunktion üblicherweise nicht gemeinsam mit dem Hauptprogramm kompiliert wurde, ist es in der Regel nicht möglich, die Unterfunktion in die Prüfwertberechnung des Hauptprogramms mit einzubeziehen. Soll für die Unterfunktion bzw. das Unterprogramm auch eine Instruktionsflusskontrolle durchgeführt werden, so kann die Unterfunktion mit einem eigenen Prüfwert separat getestet werden. Der Prüfwert des Unterprogramms ist somit unabhängig vom Prüfwert des Hauptprogramms. Fehler, die im Zusammenhang mit einem Wechsel der Recheneinheit von einer Verarbeitung des Hauptprogramms zu einer Verarbeitung des Unterprogramms oder umgekehrt auftreten, bleiben häufig unentdeckt.
  • Aus der US 5 974 529 A1 ist ein Befehlsflussüberwachungsmechanismus bekannt, bei dem ein Signaturüberwacher bewirkt, dass ein Befehlsfluss auf Fehler überprüft wird, indem eine vorberechnete Referenzsignatur mit einer aktuellen Signatur verglichen wird. Bei einem Aufruf einer Unterfunktion oder einer Unterbrechungsroutine wird die aktuelle Signatur zwischengespeichert und eine neue aktuelle Signatur wird während der Ausführung der Unterfunktion oder der Unterbrechungsroutine verwendet.
  • Bei Galla, T. u. a.: Control Flow Monitoring for a Time-Triggered Communication Controller. 10th European Workshop on Dependable Computing (EWDC-10), Mai 1999, ist eine hardwarebasierte Implementierung zur Signatur-Einstellung und zur Überprüfung beschrieben. Jedes Codewort, das zu einem Decoder gelangt, wird einem Signaturüberwacher zugeführt. Der Decoder führt immer einen Stall-Zyklus aus, nachdem er eine Sprung- oder Verzweigungsanweisung verarbeitet hat. Dies verhindert eine Prozessierung des Einstellwerts.
  • Es ist die Aufgabe der vorliegenden Erfindung, Vorrichtungen und Verfahren zum Sichern eines Programms durch Instruktionssignaturen zuschaffen, die es ermöglichen, ohne automatische Hardware-Stapelspeichermechanismen für die Zwecke der Instruktionssignaturverarbeitung auszuommen.
  • Diese Aufgabe wird durch eine Vorrichtung zum Ausführen eins Programms nach Anspruch 1 und ein Verfahren zum Berechnen einer Signatur nach Anspruch 15 gelöst.
  • Ausführungsbeispiele der hierin offenbarten technischen Lehre schaffen eine Vorrichtung zum Ausführen eines Programms, die eine Recheneinheit und ein Signaturmodul aufweist, wobei das Signaturmodul ausgebildet ist, auf der Grundlage von Instruktionen eine Signatur zu berechnen und in einem Signaturregister abzulegen. Bei der Ausführung des Programms durch die Recheneinheit können Aufrufe von Unterbrechungsroutinen oder Unterfunktionen auftreten. In diesem Zusammenhang ist die Vorrichtung zum Ausführen des Programms ausgebildet, um:
    wenn ein Aufruf einer Unterbrechungsroutine stattfindet, die dem unterbrochenen Programm zugeordnete Signatur mittels einer Programmanweisung der Unterbrechungsroutine aus dem Signaturmodul auszulesen und zu speichern,
    und vor dem Verlassen der Unterbrechungsroutine mittels einer Programmanweisung der Unterbrechungsroutine die gespeicherte Signatur in das Signaturregister zu schreiben.
  • Zusätzlich oder alternativ kann die Vorrichtung zum Ausführen des Programms ausgebildet sein, um:
    wenn ein Aufruf einer Unterfunktion stattfindet, vor dem Aufruf der Unterfunktion mittels einer eine relative Änderung der Signatur bewirkenden Programmanweisung die Signatur in dem Signaturregister an eine Signatur der Unterfunktion anzupassen, und nach einem Rücksprung aus der Unterfunktion mittels einer weiteren, eine relative Änderung der Signatur bewirkenden Programmanweisung die Signatur in dem Signaturregister an eine Signatur des Programmabschnitts, aus dem der Aufruf der Unterfunktion stattfand, anzupassen.
  • Zumindest ein Ziel der offenbarten technischen Lehre ist die Absicherung des Programmflusses mittels Instruktionssignaturen gegen Fehlerangriffe oder auch gegen zufällige Fehler, insbesondere bei bestimmten Programmstrukturen. Insbesondere Sicherheitscontroller sind ein häufiges Ziel für mutwillige Fehlerangriffe, aber auch andere Arten von Computersystemen und/oder Recheneinheiten sind derartigen Fehlerangriffen ausgesetzt. Wie zuvor erwähnt, ist das Grundprinzip von Instruktionssignaturen, zur Laufzeit eines Programms die ausgeführten Instruktionen in einer Prüfsumme (Signatur) aufzusummieren und an vorgegebenen Stellen gegen Referenzwerte zu prüfen.
  • Zur Absicherung von verschachtelten Funktionen bzw. von Unterbrechungsroutinen (engl.: „interrupt routine” bzw. „interrupt service routine” (ISR)) werden bisher automatische Stapelspeichermechanismen („stacking”) in der Hardware eingesetzt, um Signaturwerte beim Aufrufen von Funktionen bzw. Unterbrechungsroutinen zu sichern.
  • Aufgrund der Notwendigkeit der automatischen Stapelspeicherverwendung erfordern bisherige Verfahren häufig Architekturänderungen in existierenden Standardprozessoren (wie z. B. Prozessoren, die auf der ARM-Architektur basieren), damit eine Funktionsaufruf-übergreifende Instruktionsflusskontrolle implementiert werden kann. Der Stapelspeicherzugriff kann zudem zu geringerer Leistungsfähigkeit führen. Ein weiterer Punkt, der beachtet werden sollte, ist, dass der Speicher und insbesondere das sogenannte „random access memory” (RAM) eine limitierte Ressource auf eingebetteten Systemen ist und durch die Signaturen somit zusätzlich belastet wird.
  • Die hierin offenbarte-technische Lehre betrifft das technische Gebiet von Verfahren und Vorrichtungen für Instruktionssignaturen, die ohne automatische Hardware-Stapelspeichermechanismen (auch für Unterbrechungen und Unterfunktionen) für die Zwecke der Instruktionssignaturverarbeitung auskommt. Die hierin offenbarte technische Lehre schließt die Verwendung derartiger Hardware-Stapelspeichermechanismen jedoch nicht grundsätzlich aus.
  • Gemäß der hierin offenbarten technischen Lehre wird sowohl im Zusammenhang mit einem Aufruf einer Unterbrechungsroutine als auch im Zusammenhang mit einem Aufruf einer Unterfunktion eine damit einhergehende Umkonfiguration der Signatur bzw. des Signaturregisters mittels Programmanweisungen gesteuert, so dass eine Hardware-gebundene Stapelspeicherverwendung vermieden werden kann. Mittels Programmanweisungen (d. h. Softwaregesteuert) wird auf die in dem Signaturregister abgelegte Signatur zugegriffen. Je nach Zweck und Art der Programmanweisung kann es sich bei dem Zugreifen auf das Signaturregister um ein (Zwischen-)Speichern der Signatur, ein (Zurück-)Schreiben der Signatur oder um eine Aktualisierung der Signatur (zwecks Ausrichten der Signatur) handeln. Andere Formen der Datenverarbeitung, die die Signatur betreffen, sind ebenfalls grundsätzlich denkbar.
  • Gemäß weiteren Ausführungsbeispielen kann die Vorrichtung zum Ausführen des Programms weiterhin ausgebildet sein, eine Überprüfung der Signatur während der Ausführung der aufgerufenen Unterbrechungsroutine oder der aufgerufenen Unterfunktion durchzuführen. Eine Überprüfung der Signatur im Rahmen der aufgerufenen Unterbrechungsroutine oder der aufgerufenen Unterfunktion kann einer Feststellung dienen, ob die Unterbrechungsroutine oder die Unterfunktion korrekt aufgerufen wurde, also beispielsweise einen Einsprungschutz in die Unterbrechungsroutine oder die Unterfunktion bereitzustellen. Insbesondere im Zusammenhang mit Unterfunktionen ist es denkbar, dass die Recheneinheit und/oder der Programmspeicher derart manipuliert wurde, dass statt einer planmäßigen Unterfunktion eine andere Unterfunktion aufgerufen wird, wodurch sich für einen potentiellen Angreifer weitergehende Manipulationsmöglichkeiten ergeben könnten. Durch eine frühzeitige Detektion des fehlerhaften Einsprungs in die Unterfunktion können derartige Manipulationsmöglichkeiten jedoch verhindert oder reduziert werden.
  • Gemäß Ausführungsbeispielen kann die Vorrichtung zum Ausführen des Programms weiterhin ausgebildet sein, mittels einer Programmanweisung einen Zustand des Signaturmoduls für eine Routine, die zum Zeitpunkt des Aufrufs der Unterbrechungsroutine oder der Unterfunktion ausgeführt wird, zu sichern und/oder eine Signaturberechnung für die Unterbrechungsroutine bzw. die Unterfunktion zu aktivieren. Die Vorrichtung zum Ausführen des Programms kann weiterhin ausgebildet sein, vor dem Verlassen der Unterbrechungsroutine oder wenn der Rücksprung aus der Unterfunktion stattfindet, den Zustand des Signaturmoduls für die Routine, die zum Zeitpunkt des Aufrufs der Unterbrechungsroutine oder der Unterfunktion ausgeführt wird, mittels einer Programmanweisung wiederherzustellen. Das Sichern und Wiederherstellen des Zustands des Signaturmoduls für die Routine, die zum Zeitpunkt des Aufrufs der Unterbrechungsroutine oder der Unterfunktion ausgeführt wird bzw. wurde, stellt eine Alternative zu der Hardware-Stapelspeicherverwendung dar. Weiterhin eröffnen sich für Softwareentwickler mehr und flexiblere Möglichkeiten der Einflussnahme auf die Signaturmodulverwaltung, als dies mit einem rein Hardware-gestützten Signaturverwaltungskonzept möglich wäre.
  • Gemäß weiteren Ausführungsbeispielen kann die Signatur durch die entsprechende Programmanweisung zum Anpassen der Signatur aktualisiert werden, bevor der Aufruf der Unterfunktion stattfindet, so dass bei ordnungsgemäßem Aufrufen der Unterfunktion die Signatur bei Aufruf der Unterfunktion mit einer einem Anfang der Unterfunktion zugeordneten Anfangs-Referenzsignatur übereinstimmt. Dies stellt eine mögliche Ausgestaltung des bereits zuvor erwähnten Einsprungsschutzes in die Unterfunktion dar.
  • Gemäß weiteren Ausführungsbeispielen kann die Signatur durch die entsprechende Programmanweisung zum Anpassen der Signatur derart aktualisiert werden, dass bei ordnungsgemäßem Rückspringen von der Unterfunktion zum Programm bzw. zu der zum Zeitpunkt des Aufrufs der Unterfunktion ausgeführten Routine, die Signatur an einem definierten Punkt des Programms mit einer dem definierten Punkt zugeordneten Referenzsignatur des Programms übereinstimmt. Auf diese Weise kann ein relativ zuverlässiger Aussprungschutz aus der Unterfunktion zuruck zum Programm bereitgestellt werden. Der definierte Punkt kann beispielsweise kurz nach einem Rücksprungpunkt aus der Unterfunktion zurück in das Programm vorgesehen sein, so dass kurz nach der Durchführung des Rücksprungs festgestellt werden kann, ob dieser Rücksprung korrekt war.
  • Gemäß weiteren Ausführungsbeispielen kann dem Rücksprung aus der Unterfunktion ein Endreferenzsignaturwert zugeordnet sein, mit dem die Signatur im Signaturregister bei ordnungsgemäßer Ausführung der Unterfunktion übereinstimmt und der auch einem Rücksprungziel in dem aufrufenden Programmabschnitt als Referenzsignaturwert zugeordnet ist, wobei die Signatur in dem Signaturregister beim Rücksprung gleich bleibt und vom aufrufenden Programmabschnitt überprüft wird oder mittels relativer Änderung der Signatur derart aktualisiert wird, dass an einem Punkt im aufrufenden Programmabschnitt ein sich ergebender Signaturwert bei ordnungsgemäßer Ausführung mit einem zweiten Referenzsignaturwert, der dem Punkt im aufrufenden Programmabschnitt zugeordnet ist, übereinstimmt.
  • Gemäß weiteren Ausführungsbeispielen kann der Anfangsreferenzsignaturwert und/oder der Endreferenzsignaturwert als Funktion einer Adresse oder eines Namens der Unterfunktion abgeleitet sein.
  • Gemäß weiteren Ausführungsbeispielen kann der Anfangsreferenzsignaturwert und/oder der Endreferenzsignaturwert zufällig, paarweise verschieden, für Gruppen von Funktion gleich oder für alle Funktionen jeweils gleich gewählt sein. Eine Gruppe von Funktionen kann beispielsweise aus mehreren Funktionen bestehen, die einem ähnlichen Zweck (beispielsweise Durchführung bestimmter ähnlicher Berechnungen, Zugriff auf bestimmte Datenquellen, etc.) dienen oder andere Ähnlichkeitskriterien erfüllen (beispielsweise Zugehörigkeit zu Programmbibliotheken etc.) dienen. Die Kriterien für die Gruppierung der Funktionen können auch vom Programmierer vorgegeben werden.
  • Gemäß Ausführungsbeispielen kann die Vorrichtung zum Ausführen des Programms weiterhin ausgebildet sein, die Signatur im Kontext der Unterbrechungsroutine oder der Unterfunktion mittels einer Programmanweisung zu aktualisieren, so dass bei ordnungsgemäßer Ausführung der Unterbrechungsroutine oder der Unterfunktion die Signatur an einem definierten Punkt der Unterbrechungsroutine oder der Unterfunktion mit einer dem definierten Punkt der Unterbrechungsroutine oder der Unterfunktion zugeordneten Referenzsignatur übereinstimmt. Die gemäß der hierin offenbarten technischen Lehre vorgesehene Möglichkeit, mittels einer Programmanweisung auf die Signatur bzw. das Signaturregister Einfluss zu nehmen, eroffnet die Möglichkeit, die Signaturberechnung innerhalb der Unterbrechungsroutine oder der Unterfunktion in die Signaturverarbeitung der aufrufenden Routine bzw. des Programms mit aufzunehmen.
  • Gemäß weiteren Ausführungsbeispielen kann das Aufrufen der Unterfunktion in Form eines indirekten Funktionsaufrufs erfolgen. Das Anpassen der Signatur kann eine Bestimmung eines Aktualisierungswerts auf der Basis eines eindeutigen Identifizierers der Unterfunktion und ein Modifizieren der Signatur mittels des Aktualisierungswerts umfassen. Bei indirekten Funktionsaufrufen kann es vorkommen, dass sich erst zur Laufzeit des Programms entscheidet, welche Funktion von möglicherweise vielen Funktionen aufgerufen werden soll, bzw. wo die aufzurufende Funktion überhaupt gespeichert ist. Dies wirkt sich auch auf die Signaturberechnung aus, da ebenfalls erst zur Laufzeit entschieden werden kann, in welcher Weise, d. h. um welchen Wert, die Signatur anzupassen ist, damit sie beim Einsprung in die indirekt aufgerufene Funktion mit einer innerhalb der indirekt aufgerufenen Funktion definierten Referenzsignatur übereinstimmt.
  • Gemäß Ausführungsbeispielen kann der eindeutige Identifizierer der indirekt aufgerufenen Unterfunktionen auf zumindest einem von
    • – einer Speicheradresse der Unterfunktion,
    • – einem Namen der Unterfunktion,
    • – einem Ergebnis einer Zuordnungsabbildung für den Identifizierer,
    • – einem Eintrag in einer Zuordnungstabelle für den Identifizierer und
    • – einer fixen Konstante, die für alle indirekt aufgerufenen Funktionen gleich ist
    basieren. Zur Laufzeit des Programms sind die genannten Daten einer Unterfunktion eindeutig zugeordnet, ggf. auch schon vorher. Da der Aktualisierungswert auf der Basis des eindeutigen Identifizierers bestimmt wird, kann mit dieser Information die Signatur derart modifiziert werden, dass sie mit einer Anfangssignatur der indirekt aufgerufenen Funktion übereinstimmt, jedenfalls bei ordnungsgemäßem Programmablauf.
  • Gemäß weiteren Ausführungsbeispielen kann die Bestimmung des Aktualisierungswerts an die Auswertung zumindest eines von einer Auswertung einer Aktualisierungswertabbildung und einer Auswertung einer Aktualisierungswerttabelle umfassen. Während es im vorigen Absatz um den eindeutigen Identifizierer der indirekt aufgerufenen Unterfunktion ging, ist hier der eigentliche Aktualisierungswert der Signatur gemeint, welcher dafür sorgt, dass die Signatur an einem bestimmten Punkt innerhalb des Programmablaufs mit der diesem Punkt zugewiesenen Referenzsignatur übereinstimmt, unabhängig davon, welcher Programmpfad an einem oder mehreren Verzweigungspunkten ausgeführt wurde. Da die in den zur Auswahl stehenden Programmpfaden ausgeführten Instruktionen zur Kompilierzeit häufig bekannt sind, ist es möglich, die Aktualisierungswertabbildung bzw. die Aktualisierungswerttabelle zu bestimmen, in welche der eindeutige Identifizierer (oder eine davon abgeleitete Variable) als Argument eingeht.
  • Gemäß weiteren Ausführungsbeispielen kann das Signaturmodul das Signaturregister umfassen.
  • Gemäß weiteren Ausführungsbeispielen kann das Signaturmodul eine Signaturberechnungseinheit zur Bereitstellung der Signatur umfassen, die in das Signaturregister abgelegt wird. Typischerweise wird der in dem Signaturregister gespeicherte Signaturwert gemäß einer bestimmten Rechenvorschrift mit einem neuen Instruktionswert verknüpft. Die Rechenvorschrift kann eine Verknüpfung des gespeicherten Signaturregisterinhalts mit dem neuen Instruktionswert mittels arithmetischer Operationen (z. B. Addition, Multiplikation) oder Operationen in endlichen Körpern (z. B. zyklische Codes, Polynomdivision), umfassen.
  • Gemäß Ausführungsbeispielen kann das Signaturmodul eine Unterbrechungsinformationsschnittstelle mit der Recheneinheit zum Empfangen von Unterbrechungsinformationen von der Recheneinheit und eine Unterbrechungsinformationsauswerteeinheit zum Setzen eines Aktivitätszustandes der Signaturberechnungseinheit umfassen, so dass die Signaturberechnungseinheit bei Vorliegen zumindest einer ersten Bedingung der Unterbrechungsinformationen aktiv ist, und dass die Signaturberechnungseinheit bei Vorliegen zumindest einer zweiten Bedingung inaktiv ist und das Signaturregister über einen entsprechenden Inaktivitätszeitraum eine zuletzt von der Berechnungseinheit bestimmte Signatur beibehält. Wenn die Signaturberechnungseinheit aktiv ist, wird während des Durchführens einer Unterbrechungsroutine eine Signatur basierend auf Programmanweisungen der Unterbrechungsroutine berechnet und in dem Signaturregister abgelegt. Über die Unterbrechungsinformationsschnittstelle erhält das Signaturmodul Informationen darüber, welche Unterbrechungsroutine zur Zeit von der Recheneinheit ausgeführt wird. Das Signaturmodul kann somit prüfen, ob für diese Unterbrechungsroutine eine Signaturberechnung durchzuführen ist, was davon abhängen kann, in was für einem Zustand sich das Signaturmodul gegenwärtig befindet. Stimmen die von der Recheneinheit übermittelten Unterbrechungsinformationen hinsichtlich der zumindest einen ersten Bedingung mit dem Zustand des Signaturmoduls überein, so soll das Signaturmodul eine Signaturberechnung durchführen und dementsprechend „aktiv” sein. Ansonsten ist das Signaturmodul inaktiv, d. h. es wird keine Signaturberechnung durchgeführt. Man beachte, dass die erwähnte zumindest eine zweite Bedingung gegebenenfalls die komplementäre Bedingung zu der zumindest einen ersten Bedingung sein kann.
  • Die offenbarte technische Lehre kann es ermöglichen, dass abhängig von einer aufgerufenen/laufenden Unterbrechungsroutine Ausnahmebedingungen („exception” bzw. „trap”) einer zugrunde liegenden Hardware (Prozessor) unterschiedliche Konfigurationen Ausnahmebedingungs-fein zugeordnet werden können. Dies können z. B. spezielle Rechte sein oder auch das Aktivieren/Deaktivieren bestimmter Hardware-Elemente. Die offenbarte technische Lehre stellt somit eine Alternative zu einer generellen Umschaltung für Unterbrechungsroutinen dar, die in identischer Art und Weise für alle Unterbrechungsroutinen gilt. Die offenbarte technische Lehre ermoglicht Interruptfeine Hardwarekonfigurationen. Damit ist es möglich, eine aufwendige Softwareumkonfiguration zu sparen bzw. Anwendungsszenerien zu schaffen, die sonst nicht so möglich bzw. nicht so einfach möglich waren. Die offenbarte technische Lehre nutzt einen Exception/Interrupt-Identifizierer wie Trap- oder Interruptlevel, um abhängig von diesen eine von mehreren Hardwarekonfigurationen auszuwählen. Diese Konfigurationen können entweder fest vorgegeben sein oder auch Softwareprogrammierbar sein. Die ausgewählte Konfiguration hat dann einen Einfluss auf die abzuarbeitende Interruptroutine.
  • Die offenbarte technische Lehre kann genutzt werden, um mit ihr eine Instruktionsflusssignatur auch in unterbrechungsfähigen Prozessorsystemen zu implementieren, ohne in deren Architektur wie Stapelspeicherverwaltung (Stackverwaltung) eingreifen zu müssen. Dazu kann das Signaturmodul Software programmierbar einer bestimmten Interruptroutine zugeordnet werden. Nur wenn diese Routine aktiv ist, läuft die Signaturberechnung. Sie stoppt, sobald die Routine verlassen bzw. unterbrochen wird und startet wieder, sobald in die Routine zurückgesprungen wird. Durch die Änderung der Modulzuordnung und -verwaltung der Signatur-Ressourcen wird so aus einem einfachen Signaturmodul ein voll Multithread-fähig einsetzbares Modul. Es sei hier angemerkt, dass der Begriff Interruptroutine die Grundtask nicht ausschließt.
  • Der soeben erläuterte Sachverhalt kann auch auf folgende Weise beschrieben werden. In bisherigen Lösungen wird bei Auftreten eines Interrupt die Signatur automatisch (von der Recheneinheit) auf den Stack gelegt. Gemäß der offenbarten technischen Lehre kann die Berechnung der Instruktionssignatur jeweils für nur eine oder mehrere bestimmte Interrupt-Nummer(n) aktiviert werden. Beim Auftreten eines Interrupt tritt in der Regel eine Änderung der aktuellen Interrupt-Nummer auf. Daraus folgt, dass beim Auftreten eines Interrupt die Signaturberechnung implizit abgeschaltet wird (da die Interrupt-Nummer der Recheneinheit nicht mehr mit der Interrupt-Nummer des Signaturmoduls übereinstimmt). Beim Rücksprung aus dem Interrupt kann dann ein (von der Recheneinheit veranlasster) Wechsel zur ursprünglichen Interrupt-Nummer erfolgen und somit die Berechnung wieder aktiviert werden. Im Gegensatz zu einer Implementierung, die die Signaturberechnung in Interrupts komplett abschaltet, kann eine Vorrichtung bzw. ein Verfahren gemäß der offenbarten technischen Lehre verschachtelte Interrupts behandeln. Dies funktioniert wie folgt: Innerhalb eines Interrupt kann zunächst der aktuelle Signaturwert in eine lokale Variable gesichert werden und anschließend kann für die aktuelle Interrupt-Nummer die Signaturberechnung aktiviert werden. Am Ende des Interrupt wird diese dann deaktiviert und der gesicherte Wert restauriert. Diese Implementierung kann zu jedem Zeitpunkt von einem weiteren Interrupt unterbrochen werden, ohne dass Signaturprobleme auftreten. Würde das Ein/Ausschalten nicht impliziert basierend auf der Interrupt-Nummer geschehen, sondern einfach nur hart ein- oder ausgeschaltet werden, wäre dies nicht möglich. Der Grund hierfür ist, dass bei verschachteltem Interrupt der Zustand des vorherigen Interrupt nicht zuverlässig gesichert werden kann. Weiterhin ist es so, dass bei dem Interrupt das Restaurieren des unterbrochenen Signaturwerts bzw. Einschaltsignals ohne implizite Bindung an die Interrupt-Nummer typischerweise nicht möglich ist (wenn z. B. die Signatur eingeschaltet war zum Zeitpunkt der Unterbrechung, so muss diese exakt beim Rücksprung wieder aktiviert werden. Sie darf nicht von der Interruptroutine schon vorher als z. B. letzte Instruktion des Interrupt aktiviert werden).
  • Weitere Ausführungsbeispiele der offenbarten technischen Lehre schaffen ein Signaturmodul, das ausgerichtet ist, um bei der Ausführung eines Programms durch eine Recheneinheit auf der Grundlage von Programmanweisungen an die Recheneinheit eine Signatur zu berechnen und in einem Signaturregister des Signaturmoduls abzulegen, wobei das Signaturmodul eine Berechnungseinheit, eine Unterbrechungsinformationsschnittstelle und eine Unterbrechungsinformationsauswertungseinheit umfasst. Die Berechnungseinheit ist ausgebildet zum Erzeugen eines Signaturwerts auf der Basis von Programmanweisungen, die auf der Recheneinheit ausgeführt werden. Die Unterbrechungsinformationsschnittstelle ist ausgebildet zum Empfangen von Unterbrechungsinformationen von der Recheneinheit. Die Unterbrechungsinformationsauswertungseinheit ist ausgebildet zum Bestimmen eines Aktivitätszustands der Berechnungseinheit auf der Grundlage der Unterbrechungsinformation, so dass die Berechnungseinheit bei Erfüllen zumindest einer ersten Bedingung der Unterbrechungsinformation aktiv ist, um während des Durchführens einer Unterbrechungsroutine eine Signatur basierend auf Programmanweisungen der Unterbrechungsroutine zu berechnen und in dem Signaturregister abzulegen, und dass die Berechnungseinheit bei Erfüllen zumindest einer zweiten Bedingung inaktiv ist und das Signaturregister eine zuletzt von der Berechnungseinheit bestimmte Signatur beibehält.
  • Gemäß weiteren Ausführungsbeispielen kann die Unterbrechungsinformation einen Unterbrechungsidentifizierer umfassen, der angibt, welche Unterbrechung auf der Recheneinheit gegenwärtig ausgeführt wird.
  • Gemäß weiteren Ausführungsbeispielen kann die Unterbrechungsinformationsauswerteeinheit ein Identifiziererregister umfassen, in dem ein konfigurierter Unterbrechungsidentifizierer gespeichert werden kann, der angibt, dass für eine gegenwärtige Unterbrechungsroutine mit einem entsprechenden Unterbrechungsidentifizierer die Berechnungseinheit aktiv ist. Das Identifiziererregister kann beispielsweise mittels Programmanweisungen konfigurierbar sein, so dass im Zusammenhang mit einer bestimmten Unterbrechungsroutine entschieden werden kann, ob für diese Unterbrechungsroutine eine Signaturberechnung durchzuführen ist. In diesem Fall kann die Unterbrechungsroutine ihren eigenen Unterbrechungsidentifizierer in das Identifiziererregister schreiben, d. h. das Identifiziererregister entsprechend umkonfigurieren. Der Unterbrechungsidentifizierer ist meistens an einer Schnittstelle der Recheneinheit verfügbar, so dass diesbezüglich keine Änderung der Recheneinheit bzw. des Prozessors erforderlich ist.
  • Gemäß weiteren Ausführungsbeispielen kann die Unterbrechungsinformationsauswertungseinheit einen Komparator für einen Vergleich des Unterbrechungsidentifizierers und des konfigurierten Unterbrechungsidentifizierers umfassen.
  • Gemäß weiteren Ausführungsbeispielen kann das Identifiziererregister konfiguriert sein, einen konfigurierten Aktivitätszustand der Berechnungseinheit zu speichern, welcher bei einer Bestimmung eines Aktivitätszustandes der Berechnungseinheit berücksichtigt wird. Alternativ kann der konfigurierte Aktivitätszustand auch in einem weiteren Speicherelement des Signaturmoduls gespeichert sein. Der konfigurierte Aktivitätszustand kann als eine Art Aktivitäts-Flag verstanden werden.
  • Gemäß weiteren Ausführungsbeispielen kann das Signaturmodul eine Konfigurationsschnittstelle zum Konfigurieren des Identifiziererregisters mittels einer Programmanweisung umfassen.
  • Gemäß alternativen Ausführungsbeispielen ist das Signaturmodul wie zuvor ausgebildet, um bei der Ausführung eines Programms durch eine Recheneinheit auf der Grundlage von Programmanweisungen an die Recheneinheit eine Signatur zu berechnen und in einem Signaturregister des Signaturmoduls abzulegen. Das Signaturmodul umfasst in diesem Fall eine Berechnungseinheit zum Erzeugen eines Signaturwerts auf der Basis von Programmanweisungen, die auf der Recheneinheit ausgeführt werden und eine Instruktionsinformationsschnittstelle zum Empfangen zumindest einer Instruktionsinformation von der Recheneinheit, welche angibt, ob eine aktuell von der Recheneinheit ausgeführte Instruktion indirekt oder direkt angesprungen wurde. Grundsätzlich ist es auch möglich, Signaturaktualisierungen beim Einsprungspunkt (also beim Zielpunkt des Sprungs/Funktionsaufrufs) durchzuführen. Um eine erhöhte Sicherheit zu bieten, kann die Signaturaktualisierung an dieser Stelle davon abhängig gemacht werden, ob die Stelle direkt oder indirekt angesprungen wurde. Es kann somit sichergestellt werden, dass indirekte Einsprungsziele tatsächlich nur indirekt angesprungen werden und direkte tatsächlich nur direkt. Die Instruktionsinformationsschnittstelle dient als (Teil einer) Kommunikationseinrichtung zwischen Recheneinheit und Signaturmodul, über die mitgeteilt wird, ob der aktuell in der Recheneinheit ausgeführte Befehl indirekt oder direkt angesprungen wurde, bzw. die mitteilt, ob die folgende Instruktion direkt oder indirekt angesprungen wird. Diese Information wird vom Signaturmodul aufgenommen, um die Signaturberechnung zu beeinflussen und/oder zusätzlich abzusichern.
  • Das Signaturmodul kann ferner ausgebildet sein, um die über die Instruktionsinformationsschnittstelle bereitgestellte Information in der Signaturberechnung zu berücksichtigen.
  • Im Hinblick auf ein Verfahren schaffen Ausführungsbeispiele der offenbarten technischen Lehre ein Verfahren zum Berechnen einer Signatur auf der Grundlage von Instruktionen, die von einer Recheneinheit während der Ausführung eines Programms ausgeführt werden. Das Verfahren ist auch zum Ablegen der Signatur in einem Signaturregister eines Signaturmoduls vorgesehen, wobei bei der Ausführung des Programms durch die Recheneinheit Aufrufe von Unterbrechungsroutinen oder Unterfunktionen auftreten können. Das Verfahren umfasst:
    Auslesen, wenn eine Unterbrechungsanforderung empfangen wird, der dem unterbrochenen Programm zugeordneten Signatur aus dem Signaturmodul mittels einer Programmanweisung einer der Unterbrechungsanforderung zugeordneten Unterbrechungsroutine,
    Speichern der Signatur mittels einer Programmanweisung der Unterbrechungsroutine und
    Schreiben der gespeicherten Signatur in das Signaturmodul mittels einer Programmanweisung der Unterbrechungsroutine vor dem Verlassen der Unterbrechungsroutine.
  • Alternativ oder zusätzlich kann das Verfahren folgende Aktionen umfassen, wenn ein Aufruf einer Unterfunktion stattfindet: Anpassen der Signatur in dem Signaturregister an eine Signatur der Unterfunktion mittels einer eine relative Änderung der Signatur bewirkenden Programmanweisung vor dem Aufruf der Unterfunktion, und
    Anpassen der Signatur in dem Signaturregister an eine Signatur eines Programmabschnitts des Programms, aus dem der Aufruf der Unterfunktion erfolgte, mittels einer weiteren, eine relative Änderung der Signatur bewirkenden Programmanweisung nach einem Rücksprung aus der Unterfunktion zu dem Programmabschnitt.
  • Gemäß Ausführungsbeispielen kann das Verfahren weiterhin eine Überprüfung der Signatur während der Ausführung der aufgerufenen Unterbrechungsroutine oder der aufgerufenen Unterfunktion umfassen.
  • Gemäß Ausführungsbeispielen kann das Verfahren weiterhin umfassen:
    Sichern eines Zustands des Signaturmoduls für eine Routine, die zum Zeitpunkt des Aufrufs der Unterbrechungsroutine oder Unterfunktion ausgeführt wird, mittels einer Programmanweisung; und
    Wiederherstellen, mittels einer Programmanweisung vor dem Verlassen der Unterbrechungsroutine oder wenn der Rücksprung auf der Unterfunktion stattfindet, des Zustands des Signaturmoduls für die Routine, die zum Zeitpunkt des Aufrufs der Unterbrechungsroutine oder der Unterfunktion ausgeführt wird bzw. wurde.
  • Gemäß Ausführungsbeispielen kann das Verfahren weiterhin umfassen: Aktivieren einer Signaturberechnung für die Unterbrechungsroutine oder die Unterfunktion.
  • Gemäß Ausführungsbeispielen kann, wenn der Rücksprung aus der Unterfunktion stattfindet, die Signatur durch die entsprechende Programmanweisung zum Anpassen der Signatur derart aktualisiert werden, dass bei ordnungsgemäßem Rückspringen von der Unterfunktion zum Programm die Signatur an einem definierten Punkt des Programms mit einer dem definierten Punkt zugeordneten Referenzsignatur des Programms übereinstimmt.
  • Gemäß weiteren Ausführungsbeispielen kann nach dem Rücksprung aus der Unterfunktion die Signatur durch die entsprechende Programmanweisung zur relativen Änderung der Signatur derart aktualisiert werden, dass bei ordnungsgemäßem Rückspringen von der Unterfunktion zum Programm die Signatur an einem definierten Punkt des Programms mit einem dem definierten Punkt zugeordneten Referenzsignaturwert des Programms übereinstimmt.
  • Gemäß weiteren Ausführungsbeispielen kann dem Rücksprung aus der Unterfunktion ein Endreferenzsignaturwert zugeordnet sein, mit dem die Signatur im Signaturregister bei ordnungsgemäßer Ausführung der Unterfunktion übereinstimmt und der auch einem Rücksprungziel in dem aufrufenden Programmabschnitt als Referenzsignaturwert zugeordnet ist, wobei die Signatur in dem Signaturregister beim Rücksprung gleich bleibt und vom aufrufenden Programmabschnitt mittels relativer Änderung der Signatur derart aktualisiert wird, dass an einem Punkt im aufrufenden Programmabschnitt ein sich ergebender Signaturwert bei ordnungsgemäßer Ausführung mit einem zweiten Referenzsignaturwert, der dem Punkt im aufrufenden Programmabschnitt zugeordnet ist, übereinstimmt.
  • Der Anfangsreferenzsignaturwert und/oder der Endreferenzsignaturwert können als Funktion einer Adresse oder eines Namens der Unterfunktion abgeleitet sein. Alternativ können der Anfangsreferenzsignaturwert und/oder der Endreferenzsignaturwert zufällig gewählt sein oder für alle Funktionen jeweils gleich sein.
  • Gemäß weiteren Ausführungsbeispielen kann das Aktualisieren der Signatur im Kontext der Unterbrechungsroutine oder der Unterfunktion mittels einer Programmanweisung erfolgen, so dass bei ordnungsgemäßer Ausführung der Unterbrechungsroutine oder der Unterfunktion die Signatur an einem definierten Punkt der Unterbrechungsroutine oder der Unterfunktion mit einem dem definierten Punkt der Unterbrechungsroutine oder Unterfunktion zugeordneten Referenzsignaturwert übereinstimmt.
  • Gemäß weiteren Ausführungsbeispielen kann das Aufrufen der Unterfunktion in Form eines indirekten Funktionsaufrufs erfolgen und das Anpassen der Signatur eine Bestimmung eines Aktualisierungswerts auf der Basis eines eindeutigen Identifizierers der Unterfunktion und ein Modifizieren der Signatur mittels des Aktualisierungswerts umfassen.
  • Der eindeutige Identifizierer der indirekt aufgerufenen Unterfunktion kann basieren auf zumindest einem von:
    • – einer Speicheradresse der Unterfunktion,
    • – einem Namen der Unterfunktion,
    • – einem Ergebnis einer Zuordnungsabbildung für den Identifizierer,
    • – einem Eintrag in einer Zuordnungstabelle für den Identifizierer und
    • – einer fixen Konstante, die für alle indirekt aufgerufenen Funktionen gleich ist.
  • Die Bestimmung des Aktualisierungswerts kann die Auswertung zumindest eines von einer Auswertung einer Aktualisierungswertabbildung und einer Auswertung einer Aktualisierungswerttabelle umfassen.
  • Gemäß weiteren Ausführungsbeispielen kann das Verfahren weiterhin umfassen: Empfangen von Unterbrechungsinformationen von der Recheneinheit über eine Unterbrechungsinformationsschnittstelle des Signaturmoduls; Setzen eines Aktivitätszustands der Signaturberechnung, so dass die Signaturberechnung bei Vorliegen zumindest einer ersten Bedingung aktiv ist und dass die Signaturberechnung bei Vorliegen zumindest einer zweiten Bedingung inaktiv ist; und, falls die Signaturberechnung inaktiv ist, Beibehalten einer zuletzt bestimmten Signatur über einen entsprechenden Inaktivitätszeitraum.
  • Gemäß weiteren Ausführungsbeispielen kann das Verfahren weiterhin umfassen: Auswerten eines Unterbrechungsidentifzierers, der angibt, welche Unterbrechung auf der Recheneinheit gegenwärtig ausgeführt wird.
  • Gemäß weiteren Ausführungsbeispielen kann das Verfahren weiterhin umfassen: Speichern eines konfigurierten Unterbrechungsidentifizierers in einem Identifiziererregister einer Unterbrechungsinformationsauswertungseinheit, wobei der konfigurierte Unterbrechungsidentifizierer angibt, dass für eine gegenwärtige Unterbrechungsroutine mit einem entsprechenden Unterbrechungsidentifizierer die Signaturberechnung aktiv ist.
  • Gemäß weiteren Ausführungsbeispielen kann das Verfahren weiterhin umfassen: Vergleichen des Unterbrechungsidentifizierers und des konfigurierten Unterbrechungsidentifizierers, um aus einem Ergebnis des Vergleichs einen Rückschluss auf den Aktivitätszustand der Signaturberechnung zu ziehen.
  • Gemäß weiteren Ausführungsbeispielen kann das Verfahren weiterhin umfassen: Speichern eines konfigurierten Aktivitätszustands der Signaturberechnung, welcher bei einer Bestimmung des Aktivitätszustandes der Signaturberechnung berücksichtigt wird.
  • Gemäß weiteren Ausführungsbeispielen kann das Verfahren weiterhin umfassen: Konfigurieren eines Identifiziererregisters mittels einer Programmanweisung.
  • Gemäß weiteren Ausführungsbeispielen kann das Verfahren weiterhin umfassen: Empfangen einer Unterbrechungsanforderung und Ausführen eines entsprechenden Kontextwechsels vor dem Speichern der dem unterbrochenen Programm zugeordneten Signatur.
  • Weitere Ausführungsbeispiele der hierin offenbarten technischen Lehre schaffen ein Computerprogramm mit einem Programmcode zur Durchführung des zuvor definierten Verfahrens, wenn das Computerprogramm auf einem Computer abläuft.
  • Weitere Ausführungsbeispiele der offenbarten technischen Lehre schaffen ein Verfahren zum Erstellen des zuvor erwähnten Computerprogramms. Das Verfahren zum Erstellen des Computerprogramms kann zum Beispiel ein Verfahren zum Kompilieren oder Übersetzen eines Computerprogramms in Maschinencode aus einem Quelltext sein. Ein weiteres Ausführungsbeispiel der offenbarten Lehre betrifft einen entsprechenden Kompilierer.
  • Im Hinblick auf Merkmale, die im Zusammenhang mit dem Aufruf der Unterfunktion und/oder dem Rücksprung aus der Unterfunktion stehen, wird darauf hingewiesen, dass Formulierungen wie „wenn ein Aufruf einer Unterfunktion stattfindet” oder „wenn der Rücksprung aus der Unterfunktion stattfindet” nicht unbedingt als Zeitangabe zu verstehen sind, sondern vielmehr einen allgemeinen Zusammenhang zwischen zwei Ereignissen ausdrücken. Somit können Aktionen oder Ereignisse, die durch die erwähnten Formulierungen näher spezifiziert sind, auch einige Instruktionen vor oder nach dem Aufruf bzw. dem Rücksprung erfolgen. Als Bedingung für eine zulässige Entfernung einer Aktion oder eines Ereignisses von dem Aufruf oder dem Rücksprung kann ggf. folgende Aussage herangezogen werden: Zwischen der Aktion bzw. dem Ereignis und dem Aufruf bzw. Rücksprung bzw. Ziel des Rücksprungs in der aufrufenden Funktion sollte das Programm linear ablaufen, d. h. keine Verzweigungspunkte, Zusammenführungspunkte und/oder optionale Pfade umfassen.
  • Ausführungsbeispiele der vorliegenden Erfindung werden im Folgenden anhand der beiliegenden Figuren näher beschrieben. Es zeigen:
  • 1 ein schematisches Blockschaltbild einer Vorrichtung zum Ausführen eines Programms mit einer Recheneinheit und einem Signaturmodul;
  • 2 eine schematische Darstellung eines direkten Unterfunktion-Aufrufs;
  • 3 eine schematische Darstellung eines indirekten Unterfunktion-Aufrufs;
  • 4 ein schematisches Blockschaltbild einer Vorrichtung zum Ausführen eines Programms gemäß einem weiteren Ausführungsbeispiel der offenbarten technischen Lehre;
  • 5 eine schematische Darstellung einer Unterbrechungsanforderung und einem dazugehörigen Rücksprung;
  • 6A, 6B eine ähnliche schematische Darstellung wie 5, jedoch mit zwei Unterbrechungsanforderungen und zwei jeweils dazugehörigen Rücksprüngen;
  • 7A, 7B ein schematisches Ablaufdiagramm für eine Verarbeitung einer Unterbrechungsanforderung und damit zusammenhängenden Aktionen zur Signaturberechnung; und
  • 8 ein schematisches Flussdiagramm für ein Verfahren zum Berechnen einer Signatur gemäß einem Ausführungsbeispiel der offenbarten technischen Lehre.
  • Bevor im Folgenden Ausführungsbeispiele anhand der beiliegenden Figuren erläutert werden, wird darauf hingewiesen, dass gleiche Elemente oder Elemente gleicher Funktion mit denselben oder ähnlichen Bezugszeichen versehen sind und dass auf eine wiederholte Beschreibung dieser Elemente verzichtet wird. Beschreibungen von Elementen mit gleichen oder ähnlichen Bezugszeichen sind daher untereinander austauschbar.
  • Durch die hierin offenbarte technische Lehre wird es ermöglicht, dass ein vollständiger Ein-/Aussprungschutz in Unterfunktionen existiert und dass Instruktionssignaturen in Interrupts verwendet werden können, ohne dass hierfür ein Hardware-Stacking vorhanden sein muss. Die Lehre ist daher geeignet, um bestehende Prozessoren, wie z. B. Prozessoren mit ARM-Architektur, ohne Änderung der Architektur mit einem Instruktionsmechanismus zu versehen. Bei der Absicherung des Programmflusses mittels Instruktionssignaturen ohne Verwendung eines Hardware-Stapelspeicher-Mechanismus (d. h. ohne Hardware-Stacking) sind insbesondere die Absicherung von Unterfunktionsaufrufen, von indirekten Sprüngen und von Unterbrechungen („interrupts”) von Relevanz. Im Folgenden sind die technischen Verfahren und Vorrichtungen für diese kritischen Punkte sowie für weitere Maßnahmen aufgeführt, die die Integration von Instruktionssignaturen in Standardprozessoren erleichtern.
  • 1 zeigt ein schematisches Blockschaltbild einer Vorrichtung 100 zum Ausführen eines Programms 140. Die Vorrichtung 100 umfasst eine Recheneinheit 110 und ein Signaturmodul 120. Die Recheneinheit 110 ist mit einem Speicher 130 operativ verbunden, in welchem sowohl ein Programmcode mit auszuführenden Instruktionen, als auch von dem Programm 140 zu verarbeitende Daten gespeichert sind. Eine derartige Verwendung des Speichers 140 ist jedoch für die Zwecke der hierin offenbarten technischen Lehre nicht notwendig, so dass der Programmcode und die zu verarbeitenden Daten auch in unterschiedlichen Speichern gespeichert werden könnten. Beispielsweise ist es denkbar, dass der Programmcode in einem Nur-Lese-Speicher („Read-Only Memory”, ROM) gespeichert ist, während die zu verarbeitenden Daten in einem Schreib-Lese-Speicher („Random Access Memory”, RAM) gespeichert sind und gespeichert werden können.
  • Zur Ausführung des Programms 140 durch die Recheneinheit 110 wird das Programm 140 in den Speicher 130 geladen. Das Programm 140 umfasst eine Vielzahl von Programmanweisungen ANW 1 bis ANW I. Die Programmanweisungen des Programms 140 werden innerhalb des Speichers 130 in einen Anweisungs-Adressraum des Programms geladen. Das Programm 140 umfasst Anweisungen, die einer Verwaltung bzw. Steuerung der Signaturberechnung dienen und ebenfalls in den Anweisungsadressraum des Programms geladen werden, und zwar im Beispiel von 1 an die Speicherplätze 132 und 134 im Speicher. Auf die Anweisungen zur Verwaltung bzw. Steuerung der Signaturberechnung dienen wird weiter unten noch detaillierter eingegangen.
  • Der Speicher 130 umfasst auch einen Datenadressraum für das Programm 140. In dem Datenadressraum werden z. B. lokale Variablen des Programms gespeichert, die zur Laufzeit des Programms berechnet und/oder verändert werden können. Zugriffe auf lokale Variablen etc. des Programms 140 werden typischerweise von der Recheneinheit 110 durch Schreib-/Lesezugriffe auf den Speicher 130 vorgenommen. Daneben ist es aber auch möglich, dass beispielsweise Peripheriegeräte wie Drucker oder Scanner auf den Speicher 130 direkt zugreifen.
  • Wenn das Programm 140 in den Speicher 130 geladen ist, kann die Recheneinheit 110 die Anweisungen durch Speicherzugriffe auf den Speicher 130 lesen. Zu diesem Zweck umfasst die Recheneinheit 110 ein Befehlszeigerregister 112, in dem ein Befehlszeiger gespeichert ist, der auf eine Adresse im Anweisungsadressraum des Programms 140 zeigt, an der sich typischerweise die nächste von der Recheneinheit 110 auszuführende Anweisung befindet. Die nächste auszuführende Anweisung wird von der Recheneinheit in ein Instruktionsregister 114 geladen, damit die Recheneinheit 110 so gesteuert werden kann, dass die zu der Anweisung gehörigen Instruktionen in der vorgesehenen Weise ausgeführt werden können. Auf diese Weise verarbeitet die Recheneinheit 110 Daten, die z. B. im Datenadressraum des Programms 140 abgelegt sind. Der Befehlszeiger wird nach der Ausführung der zu der Anweisung gehörenden Instruktion(en) inkrementiert, um auf die darauffolgende Anweisung zu zeigen. Es ist auch möglich, dass ein von dem Programm 140 bestimmter Wert für den Befehlszeiger in das Befehlszeigerregister 112 geladen wird, wodurch Verzweigungen und bedingte Sprünge im Programmablauf ausgeführt werden können.
  • Durch Fehler in der Hardware oder durch äußere Einflüsse kann es zu Fehlern während der Abarbeitung des Programms 140 kommen. Beispielsweise kann der Speicher 130 innerhalb des Anweisungsdatenraums für das Programm 140 einen Defekt aufweisen (z. B. eine Speicherzelle mit einem Haftfehler (engl.: „stuck-at fault”), so dass das zugehörige Bit dauerhaft einen logischen Wert „0” oder „1” hat). Ein solcher Fehler kann auch gezielt provoziert werden, indem der Speicherchip z. B. mit Laser bestrahlt wird. Auch auf der Verbindung zwischen dem Speicher 130 und der Recheneinheit 110, die häufig von einem Bus bereitgestellt wird, kann es zu einem Fehler kommen.
  • Erhält die Recheneinheit 110 aufgrund eines derartigen Fehlers eine fehlerbehaftete Instruktion, wird das Programm 140 nicht mehr in der von einem Kompilierer (engl.: „compiler”) vorgesehenen Weise ausgeführt. Zur Detektion von fehlerbehaftete Instruktionen umfasst die Vorrichtung 100 das Signaturmodul 120. Das Signaturmodul 120 ist an die Verbindung zwischen Speicher 130 und Recheneinheit 110 angeschlossen, typischerweise möglichst nah an der Recheneinheit 110, damit das Signaturmodul 120 mit hoher Wahrscheinlichkeit dieselben Daten erhält, wie die Recheneinheit 110. Als Alternative zu der in 1 dargestellten Konfiguration ist auch denkbar, dass das Signaturmodul 120 über eine Schnittstelle der Recheneinheit 110 Zugriff auf das Instruktionsregister 114 hat und das Instruktionsregister 114 somit auslesen kann.
  • Das Signaturmodul 120 umfasst ein Signaturregister 122 und eine Signaturberechnungseinheit 124. Bei jeder neuen Instruktion, die vom Speicher 130 zur Recheneinheit 110 übermittelt wird, wird diese Instruktion von der Signaturberechnungseinheit 124 mitgelesen und gemäß einer Signaturberechnungsvorschrift ein neuer Signaturwert berechnet, der in dem Signaturregister 122 gespeichert wird. In die Signaturberechnungsvorschrift geht typischerweise auch ein aktueller Wert der Signatur ein, der bis dahin in dem Signaturregister 122 gespeichert war. Die Signaturberechnungsvorschrift kann z. B. eine XOR-Verknüpfung und/oder eine Polynomdivision umfassen. Nach jeder neuen Instruktion an die Recheneinheit 110 hat die in dem Signaturregister 122 gespeicherte Signatur einen Wert, der sich aus den vorherigen Instruktionen an die Recheneinheit und aus der aktuellen Instruktion an die Recheneinheit ergibt. Dieser Wert kann bereits vorab von dem Kompilierer berechnet werden und in dem Programm 140 gespeichert werden.
  • Das Programm 140 kann Anweisungen enthalten, mit denen der von dem Kompilierer bestimmte Wert mit dem zur Laufzeit des Programms 140 berechnete und in dem Signaturregister 122 abgelegten Wert verglichen wird. Bei einer Übereinstimmung beider Werte kann mit hoher Wahrscheinlichkeit davon ausgegangen werden, dass das Programm 140 so ausgeführt wurde, wie es zur Kompilierzeit vom Kompilierer vorgesehen war. Andernfalls wurde vermutlich ein Fehler detektiert und das Programm 140 kann auf diesen in angemessener Weise reagieren, z. B. durch Beenden der Programmausführung, Ausgeben einer entsprechenden Fehlermeldung, etc..
  • Bei der Ausführung des Programms 140 kann es dazu kommen, dass Unterprogramme oder -funktionen aufgerufen werden, die nicht gemeinsam mit dem Hauptprogramm kompiliert wurden. Somit kann der Kompilierer das Unterprogramm oder die Unterfunktion beim Kompilieren des Hauptprogramms typischerweise nicht mit in die Signaturberechnung mit einbeziehen. Für das Unterprogramm oder die Unterfunktion kann eine eigene Signaturberechnung vorgesehen sein. Der Aufruf des Unterprogramms/der Unterfunktion und der Rücksprung aus dem Unterprogramm/der Unterfunktion sind dann jedoch nicht im Rahmen der Signaturberechnung geschützt. Damit für das Unterprogramm oder die Unterfunktion eine eigene Prüfsumme berechnet werden kann, wäre es typischerweise erforderlich, dass im Zusammenhang mit dem Wechsel zum/vom Unterprogramm das Signaturregister 122 des Signaturmoduls 120 gesichert bzw. restauriert wird. Dies würde typischerweise über einen Hardware-Stapelspeicher-Mechanismus erfolgen, bei dem die Recheneinheit das Signaturregister 122 bei einem Unterfunktionsaufruf automatisch auf einem Stapelspeicher 138 sichert und beim Rücksprung wieder vom Stapelspeicher restauriert. Der Stapelspeicher 138 ist in 1 als Teil des Speichers 130 dargestellt, könnte aber auch als eine eigene Speicherstruktur implementiert sein oder Teil eines anderen Speichers sein. Die Verwaltung des Stapelspeichers ist in der Regel Aufgabe der Recheneinheit 110. Somit wird der Begriff hardware-Stapelspeichermechanismus hierin so verstanden, dass die Hardware selbst etwas auf den Stapel (Stack) legt bzw. von dem Stapel abruft – ohne dass explizite Programmanweisungen hierfür vorliegen. Die Recheneinheit 110 ist bei bisherigen Lösungen ausgelegt für das Sichern und Restaurieren des Signaturregisters 122 des Signaturmoduls 120, was unter Umständen entsprechende Vorkehrungen innerhalb der Recheneinheit 110 erforderlich macht.
  • Neben dem Aufruf von Unterprogrammen und/oder Unterfunktionen unterstützen viele Rechnersysteme auch Unterbrechungen (engl.: „interrupts”) bei der Ausführung eines Programms, um zwischendurch ein anderes Programm auszuführen. Auch in diesem Fall werden bei bisherigen Lösungen, sofern die Signaturberechnung während der Abarbeitung der Unterbrechung nicht für alle Unterbrechungen allgemein deaktiviert wurde, Hardware-Stapelspeicher-Mechanismen eingesetzt, die von der Recheneinheit 110 vorgenommen werden.
  • 1 illustriert einige Aspekte einer Möglichkeit, für die Zwecke der Signaturberechnung ohne Hardware-Stapelspeicher-Mechanismen auszukommen. Das Programm 140 umfasst Programmanweisungen, mit welchen das Signaturmodul 120 gesteuert werden kann und bei Unterprogrammaufrufen, Unterfunktionsaufrufen und/oder Unterbrechungen für eine Signaturberechnung im Zusammenhang mit dem Unterprogramm, der Unterfunktion bzw. der Unterbrechungsroutine konfiguriert werden kann. Der Stapelspeicher wird dann nicht automatisiert von Recheneinheit 110 mit Zuständen des Signaturmoduls befüllt, sondern dies geschieht explizit mittels entsprechender Programmanweisungen.
  • Als Beispiel sind in 1 zwei Anweisungen 132 und 134 dargestellt, die im Anweisungsadressraum des Programms 140 gespeichert sind. Die Anweisung 132 betrifft eine Vorbereitung des Signaturregisters 122 und die Anweisung 134 betrifft eine Nachbereitung des Signaturregisters 122, wobei die Vor- und Nachbereitung sich auf einen Kontextwechsel beziehen, wie er z. B. beim Aufruf eines Unterprogramms, einer Unterfunktion und/oder einer Unterbrechungsroutine auftritt.
  • Wenn der Befehlszeiger des Recheneinheit 110 zu der Anweisung 132 gelangt, wird die zu der Anweisung 132 gehörende Instruktion von der Recheneinheit 110 ausgeführt. Diese Instruktion kann z. B. das Speichern des Werts des Signaturregisters 122 in eine lokale Variable des Programms 140 betreffen. Die lokale Variable kann im Datenadressraum des Programms an einem Speicherplatz 136 gespeichert werden. Zum Beispiel kann zu Beginn einer Unterbrechungsroutine auf diese Weise die Signatur des Programms, das zum Zeitpunkt der Unterbrechung ausgeführt wurde, gesichert werden. Gegen Ende der Unterbrechungsroutine kann die zuvor gesicherte Signatur wieder in das Signaturregister 122 zuruckgeschrieben werden, was von der Programmanweisung 124 veranlasst wird. Ab dem Zeitpunkt des Zurückschreibens der Signatur wird die Unterbrechungsroutine das Signaturregister 122 typischerweise nicht mehr verändern, d. h. entweder ist die Signaturberechnung zu diesem Zeitpunkt bereits deaktiviert oder das Zurückschreiben der Signatur geschieht kurz vor dem Rücksprung aus der Unterbrechungsroutine. Typischerweise handelt es sich bei dem Programm 140 um die Unterbrechungsroutine.
  • Im Falle eines Unterprogramms oder einer Unterfunktion kann das Vorbereiten darin bestehen, dass die Signatur im Signaturregister 122 so aktualisiert bzw. angepasst wird, dass sie während der Ausführung des Unterprogramms/der Unterfunktion mit Referenzsignaturen übereinstimmt, die für bestimmte Punkte in dem Unterprogramm bzw. der Unterfunktion im Code hinterlegt sind (sofern bis dahin kein Fehler in der Programmausführung aufgetreten ist, der durch das Signaturmodul 120 detektiert werden soll). Entsprechendes gilt für das Nachbereiten des Signaturregisters 122 und den Rücksprung aus dem Unterprogramm oder der Unterfunktion: Unabhängig davon, welches Unterprogramm bzw. Unterfunktion ausgeführt wurde, und unabhängig davon, welcher Ablaufpfad innerhalb des Unterprogramms durchlaufen wurde, kann die programmgesteuerte Nachbereitung des Signaturregisters 122 dafür sorgen, dass an einem Punkt nach dem Rücksprung aus dem Unterprogramm bzw. der Unterfunktion die Signatur in einer Funktion, die das Unterprogramm oder die Unterfunktion aufgerufen hat, wieder mit einem für diesen Punkt hinterlegten Referenzsignaturwert übereinstimmt (sofern bis dahin kein Fehler in der Programmausführung aufgetreten ist, der durch das Signaturmodul 120 detektiert werden soll).
  • 2 zeigt ein schematisches Funktionsaufrufdiagramm das einige Aspekte der hierin offenbarten technischen Lehre für direkte Funktionsaufrufe illustriert. Direkte Funktionsaufrufe sind Funktionsaufrufe, deren Zieladresse bereits beim Kompilieren fixiert ist. Um den Einsprung und den Aussprung bei direkten Funktionsaufrufen abzusichern, werden beim Kompilieren des Programms bzw. beim Erstellen des binären Programmcodes für jede Funktion eine Anfangssignatur SIGA und eine Endsignatur SIGE generiert. Für die Generierung dieser Signaturen gibt es drei Varianten: Die Werte können für jede Funktion zufällig generiert, von der Adresse der jeweiligen Funktion abgeleitet oder für alle Funktionen gleich sein (letztere Variante bietet nur einen limitierten Ein-/Aussprungschutz). Unabhängig davon, wie die Werte selektiert werden, erfolgt die Absicherung des Programmflusses dann wie in 2 skizziert.
  • In der aufrufenden Funktion (Caller) wird die Anfangssignatur SIGA(n – 1) so gewählt, dass beim Einsprung in die Funktion n der Wert der Instruktionssignatur genau SIGA(n) entspricht. Alternativ wird im Falle eines vorgegebenen Werts SIGA(n – 1) eine Aktualisierung der Signatur vor dem Einsprung durchgeführt, dass beim Einsprung in die Funktion n der Wert der Instruktionssignatur genau SIGA(n) entspricht. In der Funktion n wird durch eine Anpassung bzw. ein Update (an beliebiger Position vor der ersten Verzweigung in der Funktion) die Signatur so korrigiert, dass beim Erreichen des Endes der Funktion (und bei ordnungsgemäßer Ausführung der Funktion) der Wert der Instruktionssignatur genau SIGE(n) ist. In der aufrufenden Funktion wird nach dem Rücksprung analog ein Update der Signatur durchgeführt, so dass am Ende der Funktion der Wert SIGE(n – 1) erreicht wird.
  • 3 zeigt ein schematisches Funktionsaufrufdiagramm das einige Aspekte der hierin offenbarten technischen Lehre für indirekte Funktionsaufrufe illustriert. Für die Absicherung von indirekten Funktionen gemäß der offenbarten technischen Lehre wird vorgeschlagen, dass SIGA und SIGE von einer Funktionsidentifikationsnummer der zu schützenden Funktion abgeleitet sind (dies kann z. B. die Adresse an sein – wie in 2 bei direkten Funktionsaufrufen). Die Grundidee der Absicherung besteht darin, dass vor und nach dem Aufruf der Unterfunktion Updatewerte basierend auf der Funktionsidentifikationsnummer so berechnet und angewendet werden, dass Anfangs- und Endsignatur der aufrufenden Funktion und der aufgerufenen Funktion korrekt berechnet werden (sofern kein physikalischer Angriff, Hardware-Fehler etc. aufgetreten ist). Für die Berechnung des Aktualisierungswerts der Anfangssignatur wird eine Abbildung fA verwendet, in die die Funktionsidentifikationsnummer als Argument eingeht, also fA(an).
  • Die Abbildung fA(an) kann ausgewertet werden, sobald feststeht, welche Funktion mittels indirektem Funktionsaufruf aufgerufen werden soll, die Funktionsidentifikationsnummer also feststeht.
  • Für die Berechnung des Aktualisierungswerts der Endsignatur wird eine weitere Abbildung fE verwendet, in die ebenfalls die Funktionsidentifikationsnummer an als Argument eingeht, also fA(an). Die Aktualisierung der Endsignatur SigE(n) wird nach dem dem Rücksprung in die aufrufende Funktion durchgeführt. Da die Endsignatur SigE(n) der Unterfunktion bekannt ist, kann mithilfe der Funktionsidentifikationsnummer an ein passender Aktualisierungswert fE(an) berechnet werden, so dass die Signatur innerhalb der aufrufenden Funktion an einem Punkt nach der Aktualisierung einer diesem Punkt zugewiesenen Referenzsignatur entspricht, sofern das Programm ordnungsgemäß durchgeführt wurde. Da die Aktualisierungswerte auf der Basis der Funktionsidentifikationsnummer zur Laufzeit berechnet werden, nachdem diese bestimmt wurde, können somit auch Funktionsaufrufe über eine Instruktionssignaturüberwachung abgesichert werden, die zum Kompilierzeitpunkt nicht bekannt sind, sondern sich erst zur Laufzeit ergeben.
  • Indirekte Sprünge können analog zu indirekten Funktionsaufrufen geschützt werden. Für den indirekten Sprung wird basierend auf der Zieladresse ein passender Aktualisierungswert bzw. Updatewert berechnet.
  • 4 zeigt ein Blockschaltbild einer Vorrichtung 100 gemäß einem weiteren Ausführungsbeispiel der offenbarten technischen Lehre. Die in 4 gezeigte Vorrichtung 100 ist ausgelegt, bei Unterbrechungsanforderungen eine Signaturberechnung innerhalb einer entsprechenden Unterbrechungsroutine zu ermöglichen, wobei für die Signatur kein Hardware-Stapelspeicher-Mechanismus erforderlich ist.
  • Die Recheneinheit 110 umfasst neben bereits im Zusammenhang mit 1 erläuterten Komponenten eine Unterbrechungsanforderungsverarbeitung 116, ein Register 117 fur einen Unterbrechungsidentifizierer und eine Instruktionsverarbeitung 118.
  • Das Signaturmodul 120 umfasst eine Unterbrechungsinformationsschnittstelle 123 und eine Unterbrechungsinformationsauswertungseinheit, welche mehrere Unterkomponenten umfasst. Insbesondere umfasst die Unterbrechungsinformationsauswertungseinheit ein Identifiziererregister 125, eine Speichereinheit 126 für einen Aktivitätszustand der Berechnungseinheit 124 des Signaturmoduls 120, einen Komparator 127 und ein logisches Gatter 128.
  • Bei Empfangen einer Unterbrechungsanforderung durch die Recheneinheit 110 wird diese der Unterbrechungsanforderungsverarbeitung 116 zugeführt. Die Unterbrechungsanforderungsverarbeitung 116 kann die Unterbrechungsanforderung identifizieren und den Unterbrechungsidentifizierer bereitstellen, der in dem Register 117 für den Unterbrechungsidentifizierer gespeichert wird. Über eine von der Recheneinheit 110 bereitgestellte Schnittstelle kann der Unterbrechungsidentifizierer für Peripheriegeräte und andere Baugruppen eines Rechnersystems zur Verfügung gestellt werden. Auf diese Weise kann auch das Signaturmodul 120 den Unterbrechungsidentifizierer auswerten.
  • Das Signaturmodul 120 empfängt den Unterbrechungsidentifizierer über die Unterbrechungsinformationsschnittstelle 123 und leitet ihn an den Komparator 127 weiter. Der Komparator 127 ist dazu ausgebildet, den aktuellen Unterbrechungsidentifizierer mit dem Inhalt des Identifiziererregisters 125 zu vergleichen. Stimmen die beiden Werte überein, so bedeutet dies, dass das Signaturmodul 120 gegenwärtig für die aktuelle Unterbrechungsroutine konfiguriert ist. Der Ausgang des Komparators 127 ist mit einem Eingang eines logischen UND-Gatters 128 verbunden. Der andere Eingang des logischen UND-Gatters 128 ist mit der Speichereinheit 126 für den Aktivitätszustand der Berechnungseinheit 124 verbunden. Am Ausgang des logischen Gatters 128 wird ein Freigabesignal für die Berechnungseinheit 124 ausgegeben. Aus dem Zusammenspiel von Komparator 127 und logischem Gatter 128 folgt, dass das Freigabesignal für die Berechnungseinheit 124 den Wert „1” bzw. „wahr” hat, wenn der aktuelle Unterbrechungsidentifizierer mit dem Inhalt des Identifiziererregisters 125 übereinstimmt und der Aktivitätszustand der Berechnungseinheit 124 den logischen Wert „wahr” hat. Somit erfolgt unter diesen Bedingungen eine Signaturberechnung durch die Berechnungseinheit 124. Andernfalls wird die Signatur in dem Signaturregister 122 beibehalten. Das Identifiziererregister 125 ermöglicht es, dass das Signaturmodul 120 für ausgewählte Unterbrechungsroutinen aktiv ist, für andere Unterbrechungsroutinen dagegen inaktiv.
  • Bei einem Kontextwechsel der Recheneinheit 110, wie einer Unterbrechungsanforderung oder einem Funktionsaufruf ist die Vorrichtung 100 in der Lage, unter anderem auch einen Zustand des Signaturmoduls 120 zu sichern und zu einem späteren Zeitpunkt wieder zu restaurieren. Das Programm 140 kann Anweisungen enthalten, die die Recheneinheit 110 und deren Instruktionsverarbeitung 118 veranlassen, auf eines der Register des Signaturmoduls 120 zuzugreifen, um dort einen Schreibzugriff oder einen Lesezugriff durchzuführen. Die Recheneinheit 110 kann also programmgesteuert auf das Identifiziererregister 125 und/oder auf das Signaturregister zugreifen.
  • Ein Zugriff auf das Identifiziererregister 125 ist typischerweise ein Schreibzugriff und dient dazu, das Signaturmodul 120 für eine (gegebenenfalls soeben aufgerufene) Unterbrechungsroutine zu konfigurieren, so dass im Rahmen dieser Unterbrechungsroutine eine Signaturberechnung durchgeführt werden kann, ohne eine zuvor durchgeführte Signaturberechnung einer anderen (Unterbrechungs-)Routine zu stören bzw. zu korrumpieren. In diesem Fall wird der Unterbrechungsidentifizierer in das Register 125 geschrieben. Das Programm 130 kann diesen Wert z. B. durch Auswertung des Registers 117 der Recheneinheit 110 bestimmen. Dies ist in 4 durch einen Pfeil vom Datenadressraum des Programms zu der Unterbrechungsinformationsauswertungseinheit 125, 126 des Signaturmoduls 120 dargestellt.
  • Ein Zugriff auf das Signaturregister 122 kann ein Lese- oder ein Schreibzugriff sein und der Sicherung bzw. Restaurierung der Signatur dienen. Die Sicherung bzw. Restaurierung erfolgt wiederum programmgesteuert bzw. programmveranlasst. Dementsprechend weist das Programm 130 im Falle der Signatursicherung die Recheneinheit 110 an, den im Signaturregister 122 gespeicherten Wert zu lesen und in eine lokale Variable im Datenadressraum des Programms 130 zu schreiben, genauer gesagt an die mit dem Bezugszeichen 136 bezeichnete Speicheradresse. Bei der Restaurierung wird die lokale Variable gelesen und der Wert in das Signaturregister 122 geschrieben. Dies ist in 4 durch einen doppelseitigen Pfeil gekennzeichnet, der das Signaturregister 122 mit dem Datenadressraum des Programms schematisch verbindet.
  • Ein ähnliches Signaturmodul wie das in 4 gezeigte Signaturmodul kann anstelle von oder zusätzlich zu der Unterbrechungsinformationsschnittstelle eine Instruktionsinformationsschnittstelle umfassen. Über die Instruktionsinformationsschnittstelle kann das Signaturmodul Informationen von der Recheneinheit darüber empfangen, ob die aktuelle Instruktion direkt oder indirekt angesprungen wurde. Mittels dieser zusätzlichen Information kann das Signaturmodul die Signaturberechnung beeinflussen und/oder zusätzlich absichern. Die über die Instruktionsinformationsschnittstelle bereitgestellte Information kann somit in der Signaturberechnung berücksichtigt werden.
  • 5 illustriert in schematischer Weise die Vorgänge bei einer Unterbrechungsanforderung und einer entsprechenden Rückkehr nach Abarbeitung der Unterbrechungsanforderung. Dabei kann z. B. eine Vorrichtung 100, wie sie in 4 dargestellt ist, zum Einsatz kommen.
  • Die Vorrichtung 100 befindet sich zunächst in einem Zustand, in dem eine Unterbrechungsroutine für eine Unterbrechung 0 abgearbeitet wird. Die Signaturberechnung für die Unterbrechungsroutine 0 ist aktiv. Das Identifiziererregister 125 und die beigeordnete Speichereinheit 126 für den konfigurierten Aktivitätszustand der Berechnungseinheit 124 sind in 5 dargestellt und enthalten den Wert 0 für den konfigurierten Unterbrechungsidentifizierer und den Wert 1 für den Aktivitätszustand.
  • Während der Abarbeitung der Unterbrechungsroutine 0 wird eine Unterbrechungsanforderung empfangen für eine Unterbrechung 1. Die Recheneinheit führt einen Kontextwechsel durch, um die Unterbrechungsroutine 1 auszuführen. Da sich im Zusammenhang mit dem Kontextwechsel auch die Nummer der aktuellen Unterbrechung ändert und somit nicht mehr mit dem konfigurierten Identifizierer im Identifiziererregister 125 übereinstimmt, wird die Signaturberechnung ausgeschaltet bzw. inaktiv gesetzt (gepunktete Linie in 5).
  • Die Recheneinheit 110 beginnt nun mit der Ausführung der Unterbrechungsroutine 1. Als erste Anweisung 1) wird eine Sicherung des Signaturregisters 122 durchgeführt. Eine zweite Anweisung 2) aktiviert die Signaturberechnung für die Unterbrechungsroutine 1. Die beinhaltet ein Umkonfigurieren des Identifiziererregisters 125 des Signaturmoduls 120. Im Anschluss an die zweite Anweisung 2) steht damit eine „1” für die Unterbrechungsroutine 1 in dem Identifiziererregister 125.
  • In einem als „geschützter Bereich” bezeichneten Programmabschnitt der Unterbrechungsroutine 1 können nun die eigentlichen Anweisungen oder Instruktionen durchgeführt werden, für die die Unterbrechungsroutine vorgesehen ist.
  • Nach Abarbeitung der Anweisungen in dem geschützten Bereich trifft die Unterbrechungsroutine 1 Vorbereitungen für die bevorstehende Rückkehr zur Unterbrechungsroutine 0.
  • Dazu wird aufgrund einer Programmanweisung 3) wieder eine „0” in das Identifiziererregister 125 geschrieben. Da sich die Recheneinheit 110 noch in der Unterbrechungsroutine 1 befindet, wird nun keine Signaturberechnung mehr durchgeführt.
  • Mittels einer Programmanweisung 4) wird das Signaturregister 122 und ggf. ein Konfigurationsregister des Signaturmoduls wiederhergestellt. Die Unterbrechungsroutine 1 ist damit beendet und die Recheneinheit 110 wechselt wieder zurück zur Unterbrechungsroutine 0. Sobald die Recheneinheit 110 den Kontextwechsel vollzogen hat und in dem Register 117 den aktuellen Unterbrechungsidentifizierer „0” eingetragen hat, wird die Signaturberechnung wieder eingeschaltet.
  • Die 6A und 6B zeigen ein ähnliches Schema wie 5, jedoch für einen Fall, in dem drei Unterbrechungsroutinen 0, 1, und 2 beteiligt sind. Für die Unterbrechungsroutinen 0 und 2 soll jeweils eine Signaturberechnung durchgeführt werden. Für die dazwischenliegenden Unterbrechungsroutine 1 soll dagegen keine Signaturberechnung durchgeführt werden. Dies wurde z. B. von dem zuständigen Programmentwickler so entschieden.
  • Beim Wechsel von der Unterbrechung 0 zur Unterbrechung 1 ändert die Recheneinheit 110 (in 6A und 6B auch mit CPU bezeichnet für engl. „central processing unit”) wie gewohnt den Inhalt des Registers 117, um auf die aktuell bearbeitete Unterbrechungsroutine hinzuweisen bzw. um sich diese zu merken. Da das Signaturmodul 120 noch für die Unterbrechungsroutine 0 konfiguriert ist, wird während der Ausführung der Unterbrechungsroutine 1 keine Signaturberechnung durchgeführt, was der Entscheidung des Programmentwicklers entspricht.
  • Beim Wechsel von der Unterbrechung 1 zur Unterbrechung 2 konfiguriert die Unterbrechungsroutine 2 das Signaturmodul 120 um, so dass für die Unterbrechungsroutine 2 eine Signaturberechnung durchgeführt wird (Anweisung „SIG an für Intrpt #2” in 5). Zuvor wurde noch der Inhalt des Signaturregisters 122 gesichert, in welchem immer noch der Wert der Signatur steht, wie er für die Unterbrechungsroutine 0 zum Zeitpunkt der Unterbrechungsanforderung 1 bestand.
  • Innerhalb der Unterbrechungsroutine 2 gibt es einen geschützten Bereich, in dem die eigentlichen Instruktionen der Unterbrechungsroutine 2 ausgeführt werden können und in dem die Signaturberechnung für die Unterbrechungsroutine 2 aktiv ist.
  • Bei Beendigung der Unterbrechungsroutine 2 wird mittels einer Programmanweisung der Unterbrechungsroutine 2 dafür gesorgt, dass das Signaturregister 122 und das Konfigurationsregister 125, 126 wieder aus lokalen Variablen restauriert wird. Das Signaturmodul 120 ist nun wieder so konfiguriert, wie es für die Signaturberechnung in der Unterbrechungsroutine 0 vorgesehen ist.
  • Nach dem Rücksprung aus der Unterbrechungsroutine 2 in die Unterbrechungsroutine 1 wird keine Signaturberechnung durchgeführt, da der Unterbrechungsidentifizierer der Recheneinheit 110 (Register 117) nicht mit dem konfigurierten Identifizierer des Signaturmoduls 120 übereinstimmt.
  • Dagegen wird nach dem Rücksprung in die Unterbrechungsroutine 0 die Signaturberechnung mit den Werten fortgesetzt, die zum Zeitpunkt der Unterbrechungsanforderung 1 im Signaturmodul 120 gespeichert waren.
  • Im unteren Abschnitt von 6A und 6B ist eine Tabelle gezeigt, die darstellt, wie sich die Registerinhalte und Zustände der Recheneinheit 110 und des Signaturmoduls 120 zeitlich verändern. Der Unterbrechungsidentifizierer für die Recheneinheit 110 („CPU Intpt#”) ändert sich im Wesentlichen synchron zu den Kontextwechseln, die von der Recheneinheit 110 ausgeführt werden. Der konfigurierte Identifizierer „SIG Intpt#” wird mittels gezielter Programmanweisungen geändert. Dies geschieht innerhalb der Unterbrechungsroutine 2 im Rahmen der Programmanweisung „SIG an für Intpt #2” und gegen Ende der Unterbrechungsroutine 2 mittels der Programmanweisung „SIG Register und CFG Register restaurieren aus lokalen Variablen”.
  • Der Aktivitätszustand „SIG an/aus” des Signaturmoduls 120 ist in der untersten Zeile dargestellt und ergibt sich aus einer logischen Verknüpfung der zwei darüber liegenden Zeilen. Die Darstellung in den 6A und 6B zeigt nicht den konfigurierten Aktivitätszustand des Signaturmoduls, wie er in dem Speicherelement 126 gespeichert ist, sondern zur Vereinfachung wurde hier angenommen, dass der Aktivitätszustand stets „aktiv” ist.
  • 7A und 7B zeigen eine Mischform eines Ablaufdiagramms und eines Kommunikationsdiagramms, aus dem die Interaktion zwischen dem Signaturmodul 120 und einem Programm 140 bei Unterbrechungsanforderungen hervorgeht.
  • Bevor die Unterbrechungsanforderung empfangen wird, werden zu Beginn Programmanweisungen einer Routine ausgeführt, wie bei 701 dargestellt. Gegebenenfalls führt das Signaturmodul 120 eine entsprechende Signaturberechnung durch, wie mit dem Bezugszeichen 702 angedeutet.
  • Mit 703 ist eine Unterbrechungsanforderung gekennzeichnet, die von der Recheneinheit 110 empfangen wurde und die die Recheneinheit 110 veranlasst, in die entsprechende Unterbrechungsroutine zu wechseln. Bedingt durch den Wechsel in die neue Unterbrechungsroutine wird die Signaturberechnung ausgesetzt (Bezugszeichen 704).
  • Da innerhalb der neuen Unterbrechungsroutine eine Signaturberechnung erfolgen soll, sorgt eine Programmanweisung 705 dafür, dass das Signaturregister 122 und das Konfigurationsregister 125, 126 des Signaturmoduls 120 in einer oder mehreren lokalen Variablen der neuen Unterbrechungsroutine gesichert werden. Eine zweite Programmanweisung 706 konfiguriert das Signaturmodul 120 für eine Signaturberechnung innerhalb der neuen Unterbrechungsroutine.
  • Aufgrund der Umkonfigurierung des Signaturmoduls 120 wird die Signaturberechnung bei 707 wieder aktiviert. Die nachfolgenden Programmanweisungen 708 der Unterbrechungsroutine werden somit vom Signaturmodul 120 überwacht.
  • Optional kann während der Unterbrechungsroutine eine Überprüfung der Signatur durchgeführt werden. Zu diesem Zweck wird mittels einer Programmanweisung 709 das Signaturregister 122 ausgelesen. Bei 710 wird der ausgelesene Wert mit einer Referenzsignatur verglichen, die von einem Kompilierer der Unterbrechungsroutine in den Code der Unterbrechungsroutine geschrieben wurde. Wenn eine Abweichung festgestellt wird, kann z. B. eine Fehlermeldung ausgegeben und die Unterbrechungsroutine beendet werden. Sind die Werte dagegen identisch, wird das Verfahren in 7B fortgesetzt, wie durch die Verbindungspunkte A und A' angedeutet.
  • Bei 711 wird die Konfiguration des Signaturmoduls 120 für die alte Routine wieder restauriert. Dies führt bei 712 dazu, dass die Signaturberechnung angehalten wird. Mittels einer Programmanweisung 713 wird nun auch das Signaturregister 122 wieder restauriert mit dem Wert, der zum Zeitpunkt des Empfangens der Unterbrechungsanforderung 703 in dem Signaturregister stand. Durch eine spezielle Programmanweisung 714 kehrt die Recheneinheit von der Unterbrechungsroutine zu der vorherigen Routine zurück. Die spezielle Programmanweisung 714 kann z. B. ein RET-Befehl sein.
  • Nach der Rückkehr zu der vorherigen Routine wird die Signaturberechnung bei 715 implizit wieder eingeschaltet, da die Unterbrechungsidentifizierer übereinstimmen. Die vorherige, unterbrochene Routine wird mit der nächsten anstehenden Programmanweisung 716 fortgesetzt. Damit ist die Verarbeitung der Unterbrechungsanforderung 703 einschließlich Signaturberechnung abgeschlossen.
  • 8 zeigt ein schematisches Flussdiagramm eines Verfahrens zum Berechnen einer Signatur auf der Grundlage von Instruktionen, die von einer Recheneinheit während der Ausführung eines Programms ausgeführt werden.
  • Bei einer Verzweigung 802 wird zunächst unterschieden zwischen einer Unterbrechungsanforderung (UNTERBR.) und einem Aufruf einer Unterfunktion. Falls es sich um eine Unterbrechungsanforderung handelt, werden die Aktionen 804 bis 810 ausgeführt, von denen einige jedoch optional sind.
  • Im Falle der Unterbrechungsanforderung führt die Recheneinheit 110 bei 804 einen Kontextwechsel durch.
  • Im Rahmen der Unterbrechungsroutine, die aufgrund des Kontextwechsels gestartet wurde, wird nun bei 806 die Signatur in einem Datenadressraum der Unterbrechungsroutine gespeichert.
  • Optional werden bei 808 sonstige Instruktionen durchgeführt, die in der Unterbrechungsroutine definiert sind. Typischerweise dienen diese sonstigen Instruktionen dazu, den mit der Unterbrechungsroutine beabsichtigten Zweck zu erfüllen (z. B. Abholen von Daten von einem Peripheriegerät wie einer Computertastatur).
  • Um die Unterbrechungsroutine abzuschließen, wird die bei 806 gespeicherte Signatur wieder in das Signaturregister 122 zurückgeschrieben, wie durch die Aktion 810 gezeigt.
  • Falls bei der Verzweigung 802 ein Unterfunktionsaufruf vorliegt, folgt auf die Verzweigung 802 die Aktion 812, in welcher die im Signaturregister 122 gespeicherte Signatur angepasst wird. Bei 814 wird dann von der Recheneinheit 110 die Unterfunktion aufgerufen. Die Aktionen 812 und 814 sind in ihrer Reihenfolge vertauschbar.
  • Optional werden bei 816 sonstige Instruktionen durchgeführt, die in der Unterfunktion definiert sind. Typischerweise dienen diese sonstigen Instruktionen dazu, den mit der Unterfunktion beabsichtigten Zweck zu erfüllen (z. B. Durchführung einer bestimmten Berechnung).
  • Der Rücksprung aus der Unterfunktion erfolgt bei 818 und bei 820 wird die Signatur im Signaturregister erneut angepasst. Auch hier sind die Aktionen 818 und 820 in der Reihenfolge umkehrbar.
  • Anschließend an die Aktionen 810 und 820 in den zwei unterschiedlichen Pfaden vereinigt sich das Verfahren wieder und endet dann.
  • Die offenbarte technische Lehre betrifft auch eine Instruktionsflusskontrollvorrichtung für ein Programm, die auf einer programmierbaren Vorrichtung ausgeführt wird, wobei die Instruktionsflusskontrollvorrichtung konfiguriert ist, folgende Operationen auszuführen:
    Ausführen einer Programm-Anweisung zum Konfigurieren einer Instruktionssignatur;
    Ausführen zumindest einer von der Programm definierten Instruktion durch die programmierbare Vorrichtung;
    Verarbeiten der zumindest einen von der Programm definierten Instruktion durch eine Instruktionsflusskontrollvorrichtung, wobei die zumindest eine von der Programm definierte Instruktion die Instruktionsflusssignatur modifiziert;
    Ausführen einer weiteren Programm-Anweisung zum Restaurieren der Instruktionssignatur.
  • Die offenbarte technische Lehre betrifft ferner eine Instruktionsflusskontrollvorrichtung für ein Programm, das auf einer programmierbaren Vorrichtung ausgeführt wird, die Instruktionsflusskontrollvorrichtung umfassend:
    eine Prüfwertwertzeugungseinheit zum Erzeugen eines Prüfwerts auf der Basis von Instruktionsidentifizierern von Instruktionen, die auf der programmierbaren Vorrichtung ausgeführt werden;
    einen Prüfwertspeicher zum Speichern des Prüfwerts;
    eine Unterbrechungsinformationsschnittstelle zum Empfangen von Unterbrechungsinformationen von einer Instruktionsverarbeitungseinheit der programmierbaren Vorrichtung; und
    eine Unterbrechungsinformationsauswertungseinheit zum Setzen eines Aktivitätszustands der Prüfwerterzeugungseinheit, so dass die Prüfwerterzeugungseinheit bei Vorliegen zumindest einer ersten Bedingung der Unterbrechungsinformationen aktiv ist, und dass die Prüfwerterzeugungseinheit bei Vorliegen zumindest einer zweiten Bedingung inaktiv ist und der Prüfwertspeicher einen zuletzt von der Prüfwerterzeugungseinheit bestimmten Prüfwert beibehält.
  • Die offenbarte technische Lehre betrifft auch ein Verfahren zur Instruktionsflusskontrolle eines Programms, das auf einer programmierbaren Vorrichtung ausgeführt wird, das Verfahren umfassend:
    Ausführen einer Programms-Anweisung zum Konfigurieren einer Instruktionssignatur;
    Ausführen zumindest einer von der Programm definierten Instruktion durch die programmierbare Vorrichtung;
    Verarbeiten der zumindest einen von der Programm definierten Instruktion durch eine Instruktionsflusskontrollvorrichtung, wobei die zumindest eine von der Programm definierte Instruktion die Instruktionsflusssignatur modifiziert; und
    Ausführen einer weiteren Programm-Anweisung zum Restaurieren der Instruktionssignatur.
  • Die offenbarte technische Lehre betrifft auch ein Verfahren zur Instruktionsflusskontrolle eines Programms, das auf einer programmierbaren Vorrichtung ausgeführt wird, das Verfahren umfassend:
    Erzeugen eines Prüfwerts auf der Basis von Instruktionsidentifizierern von Instruktionen, die auf der programmierbaren Vorrichtung ausgeführt werden;
    Speichern des Prüfwerts;
    Empfangen von Unterbrechungsinformationen von der programmierbaren Vorrichtung; und
    Setzen eines Aktivitätszustands der Erzeugung des Prüfwerts, so dass die Erzeugung des Prüfwerts bei Vorliegen zumindest einer ersten Bedingung der Unterbrechungsinformationen aktiv ist, und dass die Erzeugung des Prüfwerts bei Vorliegen zumindest einer zweiten Bedingung inaktiv ist und ein zuletzt bestimmten Prüfwert beibehalten wird.
  • Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, sodass ein Block oder ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden Blocks oder Details oder Merkmals einer entsprechenden Vorrichtung dar. Einige oder alle der Verfahrensschritte können durch einen Hardware-Apparat (oder unter Verwendung eines Hardware-Apparats), wie zum Beispiel einen Mikroprozessor, einen programmierbaren Computer oder eine elektronische Schaltung ausgeführt werden. Bei einigen Ausführungsbeispielen können einige oder mehrere der wichtigsten Verfahrensschritte durch einen solchen Apparat ausgeführt werden.
  • Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einem programmierbaren Computersystem derart zusammenwirken können oder zusammenwirken, dass das jeweilige Verfahren durchgeführt wird. Deshalb kann das digitale Speichermedium computerlesbar sein.
  • Manche Ausführungsbeispiele gemäß der Erfindung umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird.
  • Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Computerprogrammprodukt mit einem Programmcode implementiert sein, wobei der Programmcode dahin gehend wirksam ist, eines der Verfahren durchzuführen, wenn das Computerprogrammprodukt auf einem Computer abläuft.
  • Der Programmcode kann beispielsweise auch auf einem maschinenlesbaren Träger gespeichert sein.
  • Andere Ausführungsbeispiele umfassen das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren, wobei das Computerprogramm auf einem maschinen-lesbaren Träger gespeichert ist.
  • Mit anderen Worten ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens somit ein Computerprogramm, das einen Programmcode zum Durchführen eines der hierin beschriebenen Verfahren aufweist, wenn das Computerprogramm auf einem Computer abläuft.
  • Ein weiteres Ausführungsbeispiel der erfindungsgemäßen Verfahren ist somit ein Daten-träger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.
  • Ein weiteres Ausführungsbeispiel des erfindungsgemäßen Verfahrens ist somit ein Datenstrom oder eine Sequenz von Signalen, der bzw. die das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom oder die Sequenz von Signalen kann bzw. können beispielsweise dahin gehend konfiguriert sein, über eine Datenkommunikationsverbindung, beispielsweise über das Internet, transferiert zu werden.
  • Ein weiteres Ausführungsbeispiel umfasst eine Verarbeitungseinrichtung, beispielsweise einen Computer oder ein programmierbares Logikbauelement, die dahin gehend konfiguriert oder angepasst ist, eines der hierin beschriebenen Verfahren durchzuführen.
  • Ein weiteres Ausführungsbeispiel umfasst einen Computer, auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren installiert ist.
  • Ein weiteres Ausführungsbeispiel gemäß der Erfindung umfasst eine Vorrichtung oder ein System, die bzw. das ausgelegt ist, um ein Computerprogramm zur Durchführung zumindest eines der hierin beschriebenen Verfahren zu einem Empfänger zu übertragen. Die Übertragung kann beispielsweise elektronisch oder optisch erfolgen. Der Empfänger kann beispielsweise ein Computer, ein Mobilgerät, ein Speichergerät oder eine ähnliche Vorrichtung sein. Die Vorrichtung oder das System kann beispielsweise einen Datei-Server zur Übertragung des Computerprogramms zu dem Empfänger umfassen.
  • Bei manchen Ausführungsbeispielen kann ein programmierbares Logikbauelement (beispielsweise ein feldprogrammierbares Gatterarray, ein FPGA) dazu verwendet werden, manche oder alle Funktionalitäten der hierin beschriebenen Verfahren durchzuführen. Bei manchen Ausführungsbeispielen kann ein feldprogrammierbares Gatterarray mit einem Mikroprozessor zusammenwirken, um eines der hierin beschriebenen Verfahren durchzuführen. Allgemein werden die Verfahren bei einigen Ausführungsbeispielen seitens einer beliebigen Hardwarevorrichtung durchgeführt. Diese kann eine universell einsetzbare Hardware wie ein Computerprozessor (CPU) sein oder für das Verfahren spezifische Hardware, wie beispielsweise ein ASIC.
  • Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifi– schen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.

Claims (36)

  1. Vorrichtung zum Ausführen eines Programms, die eine Recheneinheit und ein Signaturmodul aufweist, wobei das Signaturmodul ausgebildet ist, um auf der Grundlage von Instruktionen eine Signatur zu berechnen und in einem Signaturregister abzulegen, wobei bei der Ausführung des Programms durch die Recheneinheit Aufrufe von Unterbrechungsroutinen oder Unterfunktionen auftreten, wobei die Vorrichtung zum Ausführen des Programms ausgebildet ist, um: wenn ein Aufruf einer Unterbrechungsroutine stattfindet, die dem unterbrochenen Programm zugeordnete Signatur mittels einer Programmanweisung der Unterbrechungsroutine aus dem Signaturmodul auszulesen und zu speichern, und vor dem Verlassen der Unterbrechungsroutine mittels einer Programmanweisung der Unterbrechungsroutine die gespeicherte Signatur in das Signaturmodul zu schreiben, oder wenn ein Aufruf einer Unterfunktion stattfindet: – vor dem Aufruf der Unterfunktion mittels einer eine relative Änderung der Signatur bewirkenden Programmanweisung die Signatur in dem Signaturregister an einen Anfangsreferenzsignaturwert anzupassen, der einem Anfang der Unterfunktion zugeordnet ist, so dass bei ordnungsgemäßem Aufrufen der Unterfunktion die Signatur beim Aufruf der Unterfunktion mit dem Anfangsreferenzsignaturwert übereinstimmt, und – nach einem Rücksprung aus der Unterfunktion mittels einer weiteren, eine relative Änderung der Signatur bewirkenden Programmanweisung die Signatur in dem Signaturregister an eine Signatur des Programmabschnitts anzupassen, aus dem der Aufruf der Unterfunktion stattfand, so dass bei ordnungsgemäßem Rückspringen von der Unterfunktion zum Programm, die Signatur an einem definierten Punkt des Programms mit einer dem definierten Punkt zugeordneten Referenzsignatur des Programms übereinstimmt, wobei der definierte Punkt nach der weiteren Programmanweisung ist.
  2. Vorrichtung gemäß Anspruch 1, wobei die Vorrichtung zum Ausführen des Programms weiterhin ausgebildet ist, eine Überprüfung der Signatur während der Ausführung der aufgerufenen Unterbrechungsroutine oder der aufgerufenen Unterfunktion durchzuführen.
  3. Vorrichtung gemäß Anspruch 1 oder 2, wobei die Vorrichtung zum Ausführen des Programms weiterhin ausgebildet ist, eine Signaturberechnung für die Unterbrechungsroutine oder die Unterfunktion zu aktivieren.
  4. Vorrichtung gemäß einem der Ansprüche 1 bis 3, wobei die Vorrichtung zum Ausführen des Programms weiterhin ausgebildet ist, mittels einer Programmanweisung einen Zustand des Signaturmoduls für eine Routine, die zum Zeitpunkt des Aufrufs der Unterbrechungsroutine ausgeführt wird, zu sichern und vor dem Verlassen der Unterbrechungsroutine den Zustand des Signaturmoduls für die Routine, die zum Zeitpunkt des Aufrufs der Unterbrechungsroutine ausgeführt wird, mittels einer Programmanweisung wieder herzustellen.
  5. Vorrichtung gemäß einem der Ansprüche 1 bis 4, wobei dem Rücksprung aus der Unterfunktion ein Endreferenzsignaturwert zugeordnet ist, mit dem die Signatur im Signaturregister bei ordnungsgemäßer Ausführung der Unterfunktion übereinstimmt und der auch einem Rücksprungziel in dem aufrufenden Programmabschnitt als Referenzsignaturwert zugeordnet ist, wobei die Signatur in dem Signaturregister beim Rücksprung gleich bleibt und vom aufrufenden Programmabschnitt überprüft wird oder mittels relativer Änderung der Signatur derart aktualisiert wird, dass an einem Punkt im aufrufenden Programmabschnitt ein sich ergebender Signaturwert bei ordnungsgemäßer Ausführung mit einem zweiten Referenzsignaturwert, der dem Punkt im aufrufenden Programmabschnitt zugeordnet ist, übereinstimmt.
  6. Vorrichtung gemäß einem der Ansprüche 1 bis 5, wobei der Anfangsreferenzsignaturwert und/oder der Endreferenzsignaturwert als Funktion einer Adresse oder eines Namens der Unterfunktion abgeleitet sind.
  7. Vorrichtung gemäß einem der Ansprüche 1 bis 5, wobei der Anfangsreferenzsignaturwert und/oder der Endreferenzsignaturwert zufällig, paarweise verschieden, für Gruppen von Funktion gleich oder für alle Funktionen jeweils gleich gewählt sind.
  8. Vorrichtung gemäß einem der Ansprüche 1 bis 7, weiterhin ausgebildet, die Signatur im Kontext der Unterbrechungsroutine oder der Unterfunktion mittels einer Programmanweisung zu aktualisieren, so dass bei ordnungsgemäßer Ausführung der Unterbrechungsroutine oder der Unterfunktion die Signatur an einem definierten Punkt der Unterbrechungsroutine oder der Unterfunktion mit einem dem definierten Punkt der Unterbrechungsroutine oder der Unterfunktion zugeordneten Referenzsignaturwert übereinstimmt.
  9. Vorrichtung gemäß einem der Ansprüche 1 bis 8, wobei das Aufrufen der Unterfunktion in Form eines indirekten Funktionsaufrufs erfolgt und wobei das Anpassen der Signatur eine Bestimmung eines Aktualisierungswerts auf der Basis eines eindeutigen Identifizierers der Unterfunktion und ein Modifizieren der Signatur mittels des Aktualisierungswerts umfasst.
  10. Vorrichtung gemäß Anspruch 9, wobei der eindeutige Identifizierer der indirekt aufgerufenen Unterfunktion auf zumindest einem von – einer Speicheradresse der Unterfunktion, – einem Namen der Unterfunktion, – einem Ergebnis einer Zuordnungsabbildung für den Identifizierer, – einem Eintrag in einer Zuordnungstabelle für den Identifizierer und – einer fixen Konstante, die für alle indirekt aufgerufenen Funktionen gleich ist basiert.
  11. Vorrichtung gemäß einem der Ansprüche 9 bis 10, wobei die Bestimmung des Aktualisierungswerts die Auswertung zumindest eines von einer Auswertung einer Aktualisierungswertabbildung und einer Auswertung einer Aktualisierungswerttabelle umfasst.
  12. Vorrichtung gemäß einem der Ansprüche 1 bis 12, wobei das Signaturmodul das Signaturregister umfasst.
  13. Vorrichtung gemäß einem der Ansprüche 1 bis 12, wobei das Signaturmodul eine Signaturberechnungseinheit zur Bereitstellung der Signatur umfasst, die in das Signaturregister abgelegt wird.
  14. Vorrichtung gemäß Anspruch 13, wobei das Signaturmodul eine Unterbrechungsinformationsschnittstelle mit der Recheneinheit zum Empfangen von Unterbrechungsinformationen von der Recheneinheit und eine Unterbrechungsinformationsauswertungseinheit zum Setzen eines Aktivitätszustandes der Signaturberechnungseinheit umfasst, so dass die Signaturberechnungseinheit bei Vorliegen zumindest einer ersten Bedingung der Unterbrechungsinformationen aktiv ist, und dass die Signaturberechnungseinheit bei Vorliegen zumindest einer zweiten Bedingung inaktiv ist und das Signaturregister über einen entsprechenden Inaktivitätszeitraum eine zuletzt von der Berechnungseinheit bestimmte Signatur beibehält.
  15. Verfahren zum Berechnen einer Signatur auf der Grundlage von Instruktionen, die von einer Recheneinheit während der Ausführung eines Programms ausgeführt werden, und zum Ablegen der Signatur in einem Signaturregister eines Signaturmoduls, wobei bei der Ausführung des Programms durch die Recheneinheit Unterbrechungsanforderungen oder Aufrufe von Unterfunktionen auftreten, wobei das Verfahren umfasst: Auslesen, wenn eine Unterbrechungsanforderung empfangen wird, der dem unterbrochenen Programm zugeordneten Signatur aus dem Signaturmodul mittels einer Programmanweisung einer der Unterbrechungsanforderung zugeordneten Unterbrechungsroutine, Speichern der Signatur mittels einer Programmanweisung der Unterbrechungsroutine und Schreiben der gespeicherten Signatur in das Signaturmodul mittels einer Programmanweisung der Unterbrechungsroutine vor dem Verlassen der Unterbrechungsroutine, oder, wenn ein Aufruf einer Unterfunktion stattfindet, Anpassen der Signatur in dem Signaturregister mittels einer eine relative Änderung der Signatur bewirkenden Programmanweisung vor dem Aufruf der Unterfunktion an einen Anfangssignaturwert, der einem Anfang der Unterfunktion zugeordnet ist, so dass bei ordnungsgemäßem Aufrufen der Unterfunktion die Signatur beim Aufruf der Unterfunktion mit dem Anfangsreferenzsignaturwert übereinstimmt, und Anpassen der Signatur in dem Signaturregister an eine Signatur eines Programmabschnitts des Programms, aus dem der Aufruf der Unterfunktion erfolgte, mittels einer weiteren, eine relative Änderung der Signatur bewirkenden Programmanweisung nach einem Rücksprung aus der Unterfunktion zu dem Programmabschnitt, so dass bei ordnungsgemäßem Rückspringen von der Unterfunktion zum Programm, die Signatur an einem definierten Punkt des Programms mit einer dem definierten Punkt zugeordneten Referenzsignatur des Programms übereinstimmt.
  16. Verfahren gemäß Anspruch 15, weiterhin umfassend eine Überprüfung der Signatur während der Ausführung der aufgerufenen Unterbrechungsroutine oder der aufgerufenen Unterfunktion.
  17. Verfahren gemäß Anspruch 15 oder 16, weiterhin umfassend: Aktivieren einer Signaturberechnung für die Unterbrechungsroutine oder die Unterfunktion.
  18. Verfahren gemäß einem der Ansprüche 15 bis 17, weiterhin umfassend: Sichern eines Zustands des Signaturmoduls für eine Routine, die zum Zeitpunkt des Aufrufs der Unterbrechungsroutine ausgeführt wird, mittels einer Programmanweisung innerhalb der Unterbrechungsroutine; und Wiederherstellen, mittels einer Programmanweisung vor dem Verlassen der Unterbrechungsroutine, des Zustands des Signaturmoduls für die Routine, die zum Zeitpunkt des Aufrufs der Unterbrechungsroutine ausgeführt wird.
  19. Verfahren gemäß einem der Ansprüche 15 bis 18, wobei nach dem Rücksprung aus der Unterfunktion, die Signatur durch die entsprechende Programmanweisung zur relativen Änderung der Signatur derart aktualisiert wird, dass bei ordnungsgemäßem Rückspringen von der Unterfunktion zum Programm die Signatur an einem definierten Punkt des Programms mit einem dem definierten Punkt zugeordneten Referenzsignaturwert des Programms übereinstimmt.
  20. Verfahren gemäß Anspruch 19, wobei dem Rücksprung aus der Unterfunktion ein Endreferenzsignaturwert zugeordnet ist, mit dem die Signatur im Signaturregister bei ordnungsgemäßer Ausführung der Unterfunktion übereinstimmt und der auch einem Rücksprungziel in dem aufrufenden Programmabschnitt als Referenzsignaturwert zugeordnet ist, wobei die Signatur in dem Signaturregister beim Rücksprung gleich bleibt und vom aufrufenden Programmabschnitt mittels relativer Änderung der Signatur derart aktualisiert wird, dass an einem Punkt im aufrufenden Programmabschnitt ein sich ergebender Signaturwert bei ordnungsgemäßer Ausführung mit einem zweiten Referenzsignaturwert, der dem Punkt im aufrufenden Programmabschnitt zugeordnet ist, übereinstimmt.
  21. Verfahren gemäß einem der Ansprüche 19 bis 20, wobei der Anfangsreferenzsignaturwert und/oder der Endreferenzsignaturwert als Funktion einer Adresse oder eines Namens der Unterfunktion abgeleitet sind.
  22. Verfahren gemäß einem der Ansprüche 19 bis 20, wobei der Anfangsreferenzsignaturwert und/oder der Endreferenzsignaturwert zufällig gewählt sind oder für alle Funktionen jeweils gleich sind.
  23. Verfahren gemäß einem der Ansprüche 15 bis 22, weiterhin umfassend: Aktualisieren der Signatur im Kontext der Unterbrechungsroutine oder der Unterfunktion mittels einer Programmanweisung, so dass bei ordnungsgemäßer Ausführung der Unterbrechungsroutine oder der Unterfunktion die Signatur an einem definierten Punkt der Unterbrechungsroutine oder der Unterfunktion mit einem dem definierten Punkt der Unterbrechungsroutine oder Unterfunktion zugeordneten Referenzsignaturwert übereinstimmt.
  24. Verfahren gemäß einem der Ansprüche 15 bis 23, wobei das Aufrufen der Unterfunktion in Form eines indirekten Funktionsaufrufs erfolgt und wobei das Anpassen der Signatur eine Bestimmung eines Aktualisierungswerts auf der Basis eines eindeutigen Identifizierers der Unterfunktion und ein Modifizieren der Signatur mittels des Aktualisierungswerts umfasst.
  25. Verfahren gemäß Anspruch 24, wobei der eindeutige Identifizierer der indirekt aufgerufenen Unterfunktion auf zumindest einem von – einer Speicheradresse der Unterfunktion, – einem Namen der Unterfunktion, – einem Ergebnis einer Zuordnungsabbildung für den Identifizierer, – einem Eintrag in einer Zuordnungstabelle für den Identifizierer und – einer fixen Konstante, die für alle indirekt aufgerufenen Funktionen gleich ist basiert.
  26. Verfahren gemäß einem der Ansprüche 24 bis 25, wobei die Bestimmung des Aktualisierungswerts die Auswertung zumindest eines von einer Auswertung einer Aktualisierungswertabbildung und einer Auswertung einer Aktualisierungswerttabelle umfasst.
  27. Verfahren gemäß einem der Ansprüche 15 bis 26, weiterhin umfassend: Empfangen von Unterbrechungsinformationen von der Recheneinheit über eine Unterbrechungsinformationsschnittstelle des Signaturmoduls; Setzen eines Aktivitätszustands der Signaturberechnung, so dass die Signaturberechnung bei Vorliegen zumindest einer ersten Bedingung aktiv ist und dass die Signaturberechnung bei Vorliegen zumindest einer zweiten Bedingung inaktiv ist; und, falls die Signaturberechnung inaktiv ist, Beibehalten einer zuletzt bestimmten Signatur über einen entsprechenden Inaktivitätszeitraum.
  28. Verfahren gemäß Anspruch 27, weiterhin umfassend: Auswerten eines Unterbrechungsidentifzierers, der angibt, welche Unterbrechung auf der Recheneinheit gegenwärtig ausgeführt wird.
  29. Verfahren gemäß Anspruch 27 oder 28, weiterhin umfassend: Speichern eines konfigurierten Unterbrechungsidentifizierers in einem Identifiziererregister einer Unterbrechungsinformationsauswertungseinheit, wobei der konfigurierte Unterbrechungsidentifizierer angibt, dass für eine gegenwärtige Unterbrechungsroutine mit einem entsprechenden Unterbrechungsidentifizierer die Signaturberechnung aktiv ist.
  30. Verfahren gemäß Anspruch 29, weiterhin umfassend: Vergleichen des Unterbrechungsidentifizierers und des konfigurierten Unterbrechungsidentifizierers, um aus einem Ergebnis des Vergleichs einen Rückschluss auf den Aktivitätszustand der Signaturberechnung zu ziehen.
  31. Verfahren gemäß einem der Ansprüche 29 oder 30, weiterhin umfassend: Speichern eines konfigurierten Aktivitätszustands der Signaturberechnung, welcher bei einer Bestimmung des Aktivitätszustandes der Signaturberechnung berücksichtigt wird.
  32. Verfahren gemäß einem der Ansprüche 29 bis 31, weiterhin umfassend: Konfigurieren eines Identifiziererregisters mittels einer Programmanweisung.
  33. Verfahren gemäß einem der Ansprüche 15 bis 32, weiterhin umfassend: Empfangen einer Unterbrechungsanforderung und Ausführen eines entsprechenden Kontextwechsels vor dem Speichern der dem unterbrochenen Programm zugeordneten Signatur.
  34. Computerprogramm mit einem Programmcode zur Durchführung des Verfahrens nach einem der Ansprüche 15 bis 33, wenn das Computerprogramm auf einem Computer abläuft.
  35. Verfahren zum Erstellen eines Computerprogramms gemäß Anspruch 34.
  36. Kompilierer zum Erstellen eines Computerprogramms gemäß Anspruch 34.
DE102011005209.7A 2011-03-07 2011-03-07 Programmanweisungsgesteuerte Instruktionsflusskontrolle Active DE102011005209B4 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE102011005209.7A DE102011005209B4 (de) 2011-03-07 2011-03-07 Programmanweisungsgesteuerte Instruktionsflusskontrolle
FR1200600A FR2972545B1 (fr) 2011-03-07 2012-02-29 Controle de flux d'instruction commande par des instructions de programme
US13/409,369 US10515206B2 (en) 2011-03-07 2012-03-01 Program-instruction-controlled instruction flow supervision
CN201210057989.0A CN102708013B (zh) 2011-03-07 2012-03-07 用于程序语句控制的指令流控制的设备、签名模块及方法
US16/678,397 US10867028B2 (en) 2011-03-07 2019-11-08 Program-instruction-controlled instruction flow supervision

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102011005209.7A DE102011005209B4 (de) 2011-03-07 2011-03-07 Programmanweisungsgesteuerte Instruktionsflusskontrolle

Publications (2)

Publication Number Publication Date
DE102011005209A1 DE102011005209A1 (de) 2012-09-13
DE102011005209B4 true DE102011005209B4 (de) 2016-06-23

Family

ID=46705258

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102011005209.7A Active DE102011005209B4 (de) 2011-03-07 2011-03-07 Programmanweisungsgesteuerte Instruktionsflusskontrolle

Country Status (4)

Country Link
US (2) US10515206B2 (de)
CN (1) CN102708013B (de)
DE (1) DE102011005209B4 (de)
FR (1) FR2972545B1 (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011005209B4 (de) * 2011-03-07 2016-06-23 Infineon Technologies Ag Programmanweisungsgesteuerte Instruktionsflusskontrolle
US9323920B2 (en) * 2013-10-23 2016-04-26 Infineon Technologies Ag Data processing arrangement and method for ensuring the integrity of the execution of a computer program
EP3080668B1 (de) 2013-12-09 2017-06-14 dSPACE digital signal processing and control engineering GmbH Verfahren zur beeinflussung eines steuerprogramms eines steuergeräts
DE102014204417A1 (de) * 2014-03-11 2015-09-17 Siemens Aktiengesellschaft Vorrichtung und Verfahren zum Detektieren einer Manipulation an einem Programmcode
US9805099B2 (en) 2014-10-30 2017-10-31 The Johns Hopkins University Apparatus and method for efficient identification of code similarity
DE102014116144A1 (de) * 2014-11-05 2016-05-12 Hella Kgaa Hueck & Co. Elektronische Einrichtung zum Sperren von Unterbrechungsanforderungen
DE102015119031A1 (de) * 2015-11-05 2017-05-11 Technische Universität Dresden Verfahren zur Übergabe von zumindest einem Übergabewert, Verfahren zur Übergabe zumindest eines Übergabewerts von einem ersten Programm an ein zweites Programm, Verfahren zur Überprüfung der Funktionstüchtigkeit eines Programms und Überprüfungseinheiten für diese Verfahren
US10108404B2 (en) * 2016-10-24 2018-10-23 International Business Machines Corporation Compiling optimized entry points for local-use-only function pointers
US10108406B2 (en) * 2016-10-24 2018-10-23 International Business Machines Corporation Linking optimized entry points for local-use-only function pointers
US10108407B2 (en) * 2016-10-24 2018-10-23 International Business Machines Corporation Loading optimized local entry points for local-use-only function pointers
FR3094513B1 (fr) 2019-03-29 2023-07-14 Proton World Int Nv Procédé d'authentification d'un processeur
FR3094512A1 (fr) 2019-03-29 2020-10-02 Stmicroelectronics (Rousset) Sas Procédé d'authentification d'un processeur
CN113127273B (zh) * 2019-12-31 2023-07-14 华润微集成电路(无锡)有限公司 单片机检测电路及相应的检测的方法
CN111240816A (zh) * 2020-01-03 2020-06-05 上海瀚之友信息技术服务有限公司 一种程序可中断运行系统及方法
CN112181539B (zh) * 2020-09-27 2023-12-05 深圳市元征科技股份有限公司 文件处理方法、装置、设备及介质
US11698969B1 (en) * 2021-06-25 2023-07-11 Amazon Technologies, Inc. Boot security of integrated circuit device

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5974529A (en) * 1998-05-12 1999-10-26 Mcdonnell Douglas Corp. Systems and methods for control flow error detection in reduced instruction set computer processors

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4488227A (en) 1982-12-03 1984-12-11 Honeywell Information Systems Inc. Program counter stacking method and apparatus for nested subroutines and interrupts
US5274817A (en) 1991-12-23 1993-12-28 Caterpillar Inc. Method for executing subroutine calls
FR2790844B1 (fr) 1999-03-09 2001-05-25 Gemplus Card Int Procede et dispositif de surveillance du deroulement d'un programme, dispositif programme permettant la surveillance de son programme
FR2849226B1 (fr) 2002-12-20 2005-12-02 Oberthur Card Syst Sa Procede et dispositif de securisation de l'execution d'un programme informatique.
WO2008111382A1 (ja) 2007-02-22 2008-09-18 Nec Corporation 情報処理装置、情報処理方法およびプログラム
CN101042670A (zh) 2007-04-24 2007-09-26 上海华龙信息技术开发中心 一种指令异常处理方法
DE102011005209B4 (de) * 2011-03-07 2016-06-23 Infineon Technologies Ag Programmanweisungsgesteuerte Instruktionsflusskontrolle

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5974529A (en) * 1998-05-12 1999-10-26 Mcdonnell Douglas Corp. Systems and methods for control flow error detection in reduced instruction set computer processors

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GALLA, T. u.a.: Control Flow Monitoring for a Time-Triggered Communication Controller. 10th European Workshop on Dependable Computing (EWDC-10). Mai 1999 *

Also Published As

Publication number Publication date
CN102708013A (zh) 2012-10-03
DE102011005209A1 (de) 2012-09-13
US10867028B2 (en) 2020-12-15
US10515206B2 (en) 2019-12-24
US20120233446A1 (en) 2012-09-13
CN102708013B (zh) 2016-01-06
FR2972545A1 (fr) 2012-09-14
FR2972545B1 (fr) 2018-05-04
US20200074076A1 (en) 2020-03-05

Similar Documents

Publication Publication Date Title
DE102011005209B4 (de) Programmanweisungsgesteuerte Instruktionsflusskontrolle
WO2017137256A1 (de) Verfahren und ausführungsumgebung zum gesicherten ausführen von programmbefehlen
EP3437012B1 (de) Verfahren, prozessor und gerät zur integritätsprüfung von nutzerdaten
DE102010037457B4 (de) Verfahren zur Datenverarbeitung zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, Verfahren zur Datenverarbeitung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, Verfahren zum Erzeugen von Programm-Code, Datenverarbeitungsanordnungen zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, Datenverarbeitungsanordnungen zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, und Datenverarbeitungsanordnungen zum Erzeugen von Programm-Code
CN104820626A (zh) 用于使具有不同的安全等级的软件在多核处理器系统中共存的方法
DE102012212343A1 (de) Verteilter Kompilierungsprozess mit Befehlssignaturunterstützung
CN111090915B (zh) 自动驾驶仿真方法、装置和存储介质
EP3864547B1 (de) Verfahren zur detektion sicherheitsrelevanter datenflüsse
DE102014117971B4 (de) Verfahren zur Datenverarbeitung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, und Datenverarbeitungsanordnungen zum Erzeugen von Programm-Code
EP3001313A1 (de) Verfahren zur Simulation eines Anwendungsprogramms eines elektronischen Steuergeräts auf einem Computer
DE102011108077A1 (de) Verfahren zur Speicherplatzverwaltung in einem multitaskingfähigen Datenverarbeitungssystem
EP1854007A2 (de) Verfahren, betriebssysem und rechengerät zum abarbeiten eines computerprogramms
DE102020124498A1 (de) Vorrichtung und Verfahren zur Durchsetzung von Kontrollfluss-Integrität
EP1805617A1 (de) Verfahren zur abarbeitung eines computerprogramms auf einem computersystem
WO2006045754A1 (de) Verfahren, betriebssystem und rechengerät zum abarbeiten eines computerprogramms
US20070174703A1 (en) Method for enhancing debugger performance of hardware assisted breakpoints
US20130191819A1 (en) Method for reconfiguring software parameters in a microcontroller as well as a microcontroller and control unit
EP2228723B1 (de) Verfahren zur Fehlerbehandlung eines Rechnersystems
DE102011007467A1 (de) Mehrkernige integrierte Mikroprozessorschaltung mit Prüfeinrichtung, Prüfverfahren und Verwendung
DE102005046696B4 (de) Verfahren zum Erzeugen von geschütztem Programmcode und Verfahren zum Ausführen von Programmcode eines geschützten Computerprogramms sowie Computerprogrammprodukt
DE102020211540A1 (de) Verfahren zur Absicherung eines Mikrocontrollers
DE102009000874A1 (de) Verfahren zur Verbesserung der Analysierbarkeit von Softwarefehlern in einem Mikrocontroller
DE102021212994B3 (de) Verfahren zur Erkennung von auf eine Manipulation hindeutenden Anomalien während eines sicheren Startvorgangs einer softwaregesteuerten Vorrichtung
DE102012010102A1 (de) Verfahren und Vorrichtung zur Datenverarbeitung
EP3893113B1 (de) Überwachung einer komponente eines steuerungssystems für ein fortbewegungsmittel

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R083 Amendment of/additions to inventor(s)
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R082 Change of representative