DE102010037457A1 - 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 - Google Patents

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 Download PDF

Info

Publication number
DE102010037457A1
DE102010037457A1 DE102010037457A DE102010037457A DE102010037457A1 DE 102010037457 A1 DE102010037457 A1 DE 102010037457A1 DE 102010037457 A DE102010037457 A DE 102010037457A DE 102010037457 A DE102010037457 A DE 102010037457A DE 102010037457 A1 DE102010037457 A1 DE 102010037457A1
Authority
DE
Germany
Prior art keywords
program
code
error
value
reference numbers
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.)
Granted
Application number
DE102010037457A
Other languages
English (en)
Other versions
DE102010037457B4 (de
Inventor
André Schmitt
Ute Schiffel
Christof Fetzer
Martin Süßkraut
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.)
Silistra Systems De GmbH
Original Assignee
Technische Universitaet Dresden
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 Technische Universitaet Dresden filed Critical Technische Universitaet Dresden
Priority to DE102010037457A priority Critical patent/DE102010037457B4/de
Priority to US13/821,837 priority patent/US9304872B2/en
Priority to EP11767393.9A priority patent/EP2614438A1/de
Priority to PCT/EP2011/065606 priority patent/WO2012032140A1/de
Priority to KR1020137009176A priority patent/KR20130105656A/ko
Publication of DE102010037457A1 publication Critical patent/DE102010037457A1/de
Application granted granted Critical
Publication of DE102010037457B4 publication Critical patent/DE102010037457B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/28Error detection; Error correction; Monitoring by checking the correct order of processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1479Generic software techniques for error detection or fault masking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/085Error detection or correction by redundancy in data representation, e.g. by using checking codes using codes with inherent redundancy, e.g. n-out-of-m codes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/47Error detection, forward error correction or error protection, not provided for in groups H03M13/01 - H03M13/37
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/47Error detection, forward error correction or error protection, not provided for in groups H03M13/01 - H03M13/37
    • H03M13/49Unidirectional error detection or correction
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/47Error detection, forward error correction or error protection, not provided for in groups H03M13/01 - H03M13/37
    • H03M13/51Constant weight codes; n-out-of-m codes; Berger codes

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Computer Hardware Design (AREA)
  • Detection And Correction Of Errors (AREA)
  • Debugging And Monitoring (AREA)

Abstract

In einem Ausführungsbeispiel wird ein Verfahren zur Datenverarbeitung zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, bereitgestellt. Das Verfahren kann enthalten: Ermitteln eines Zahlenwertes basierend auf einer von einem Überprüfungs-Schaltkreis außerhalb des Programmes ermittelten Mehrzahl von Referenz-Zahlen; Ermitteln einer Signatur mindestens einer Anweisung des Programmes mittels eines arithmetischen Codes; Aktualisieren eines Akkumulator-Wertes basierend auf dem Zahlenwert und der Signatur; und Übermitteln des aktualisierten Akkumulator-Wertes an den Überprüfungs-Schaltkreis zum Ermitteln, ob bei der Ausführung des Programms ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert.

Description

  • Die Erfindung betrifft 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.
  • Es ist zu erwarten, dass Standard-Hardware oder Massen-Hardware (engl.: „Commodity Hardware”) immer weniger zuverlässig wird aufgrund der kontinuierlich steigenden Integrationsdichte und schrumpfenden Strukturbreiten von neuen Generationen von integrierten Schaltkreisen. Aufgrund ökonomischer Faktoren gibt es Bestrebungen, immer mehr Standard-Hardware mit ungenügender Fehler-Erkennung in kritischen Anwendungen zu benutzen. Hieraus ergibt sich die Notwendigkeit, Hardwarefehler in Software zu erkennen. Eine mögliche Lösung zum Detektieren von Hardware-Fehlern in Software ist die Verwendung von AN-Codes, wie im Folgenden noch näher beschrieben wird. Mit der Hilfe von AN-Codes können codierte Programme erzeugt werden. Diese Codes detektieren Hardware-Fehler unabhängig von dem tatsächlichen Fehler-Modus der zugrundeliegenden Hardware. Jedoch haben Messungen gezeigt, dass mit AN-Codes codierte Programme immer noch zu hohe Raten von nicht-erkannten stillen Daten-Fehlern (englisch: „Silent Data Corruption”, SDC) enthalten. Diese hohen Raten von unerkannten SDCs werden durch unzureichenden Schutz des Kontrollflusses (oder Ablaufflusses) und Datenflusses durch AN-Codes verursacht. Im Gegensatz dazu versprechen ANB- und ANBD-Codes, wie sie im Folgenden noch näher erklärt werden, viel höhere Fehler-Erkennungs-Raten, weil sie auch Fehler im Kontroll- und Daten-Fluss detektieren.
  • Aus DE 102 19 501 B4 ist eine CPU bekannt, die ein originales und ein codiertes Programm nacheinander ausführt als Kombination aus Diversität und Codierung, und in der eine Überprüfungseinheit (englisch: Watchdog) die Ausgaben beider Programme vergleicht. Dadurch wird aber dynamischer Speicher nicht unterstützt, weil das beschriebene Verfahren (besonders die beschriebene Codierung) auf sehr spezielle Programmiersprachen (KOP (Kontaktplan)/FUP (Funktionsplan)) aus der Automatisierungstechnik ausgerichtet ist. Die Kombination aus Diversität und vereinfachter Codierung schützt nicht gegen permanente Fehler. Die Codierung ist einfacher als ANB und ANBD und deckt aber auch weniger Fehlerbilder ab. Die Codierung alleine kann folgende Fehler nicht erkennen: Kontrollflussfehler (Sprung zum falschen Ziel); Operandenfehler (also vertauschte Operanden: statt x + y wird x + z mit z nicht gleich y gerechnet); Lost-Stores (deutsch: verlorene Speicherungen; ein Wert wird nicht wie vorgegeben an Adresse p sondern an Adresse q nicht gleich p abgespeichert). Diese drei Fehlerklassen können nur in Kombination mit der Diversität erkannt werden. Jedoch schützt die beschriebene Diversität nur unzureichend gegen permanente Fehler. Permanente Fehler werden jedoch in Zukunft häufiger auftreten, weil Hardware, bedingt durch schrumpfende Strukturbreiten, schneller altert.
  • Der Erfindung liegt das Problem zu Grunde, Datenverarbeitungsanordnungen und Verfahren bereitzustellen zum zuverlässigen Erkennen von Fehlern in einem Programm-Ablauf.
  • Das Problem wird durch Verfahren und Datenverarbeitungsanordnungen mit den Merkmalen gemäß den unabhängigen Patentansprüchen gelöst.
  • Weiterbildungen ergeben sich aus den abhängigen Ansprüchen.
  • Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Weiteren näher erläutert.
  • 1 zeigt ein Flussdiagram, das ein Verfahren zur Datenverarbeitung zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung illustriert.
  • 2 zeigt ein Flussdiagram, das ein Verfahren zur Datenverarbeitung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung illustriert.
  • 3 zeigt ein Flussdiagram, das ein Verfahren zum Erzeugen von Programm-Code zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung illustriert.
  • 4 zeigt eine Datenverarbeitungsanordnung zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung.
  • 5 zeigt eine Datenverarbeitungsanordnung zum Ermitteln, ob in einer Programmausführung ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung.
  • 6 zeigt eine Datenverarbeitungsanordnung zum Erzeugen von Programm-Code zum Bereitstellen eines Wertes zum Ermitteln, ob in einer Programmausführung ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung.
  • 7 zeigt eine Datenverarbeitungsanordnung gemäß einem Ausführungsbeispiel der Erfindung.
  • 8 zeigt eine Datenverarbeitungsanordnung gemäß einem Ausführungsbeispiel der Erfindung.
  • 9 zeigt ein Diagramm zum Rechenzeitvergleich von Verfahren gemäß einem Ausführungsbeispiel der Erfindung.
  • 10 zeigt ein Diagramm zum Rechenzeitvergleich von Verfahren gemäß einem Ausführungsbeispiel der Erfindung.
  • 11 zeigt Diagramme zum Rechenzeitvergleich von Verfahren gemäß einem Ausführungsbeispiel der Erfindung.
  • 1 zeigt ein Flussdiagram 100, das ein Verfahren zur Datenverarbeitung zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms (anders ausgedrückt: ob bei (oder: ob in) einer Programmausführung) ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung illustriert. In 102 kann ein Zahlenwert ermittelt werden basierend auf einer von einem Überprüfungs-Schaltkreis außerhalb des Programmes ermittelten Mehrzahl von Referenz-Zahlen. In 104 kann eine Signatur mindestens einer Anweisung des Programmes mittels eines arithmetischen Codes ermittelt werden. In 106 kann ein Akkumulator-Wert basierend auf dem Zahlenwert und der Signatur aktualisiert werden. In 108 kann der aktualisierte Akkumulator-Wert übermittelt werden an den Überprüfungs-Schaltkreis zum Ermitteln, ob bei der Ausführung des Programms ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert.
  • In einer Ausführungsform kann der arithmetische Code ein arithmetischer Code mit Signaturen sein. In einer Ausführungsform kann der arithmetische Code jeder beliebige arithmetische Code sein, der um Signaturen erweitert werden kann oder ist.
  • In einer Ausführungsform kann der arithmetische Code mindestens einen der folgenden Codes enthalten oder mindestens einer der folgenden Codes sein: ein AN-Code, wie er weiter unten erklärt wird; ein ANB-Code, wie er weiter unten erklärt wird; ein ANBD-Code, wie er weiter unten erklärt wird; ein ANBDmem-Code, wie er weiter unten erklärt wird; ein dem Fachmann als solches bekannter Residuum-Code (englisch: Residue-Code); und ein dem Fachmann als solches bekannter Berger-Code.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine Mehrzahl von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine geordnete Liste von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann der Zahlenwert eine Differenz zweier Referenz-Zahlen sein.
  • In einer Ausführungsform kann der Zahlenwert eine Differenz zweier aufeinanderfolgender Referenz-Zahlen sein.
  • In einer Ausführungsform kann der Akkumulator-Wert aktualisiert werden basierend auf einer Subtraktion einer Signatur eines Basis-Blocks (englisch: Basic-Block) des Programms, und jeweils einer Addition der Signatur des Nachfolger-Basis-Blocks.
  • Ein Basis-Block ist eine Sequenz von Programmanweisungen (in anderen Worten: Anweisungen; in anderen Worten: Instruktionen) mit genau einem Einsprungpunkt (am Beginn der Sequenz) und genau einem Austrittspunkt am Ende der Sequenz. Der Austrittspunkt ist ein bedingter, unbedingter Sprung oder ein Rücksprung zur aufgerufenen Funktion. Funktionsaufrufe können durch Austrittspunkte oder eine einfache Programmanweisung innerhalb der Sequenz darstellen.
  • In einer Ausführungsform kann der Akkumulator-Wert aktualisiert werden basierend auf einer Addition des Zahlenwertes.
  • In einer Ausführungsform kann ein Identifikator eines Basis-Blocks des Programms ermittelt werden.
  • In einer Ausführungsform kann der Akkumulator-Wert aktualisiert werden ferner basierend auf dem Identifikator des Blocks.
  • In einer Ausführungsform kann der aktualisierte Akkumulator-Wert übermittelt werden nach einer oder jeder Funktion des Programms, nach einer oder jeder Programmanweisung (Instruktion) des Originalprogramms, nach einem oder jedem Basis-Block, und/oder zusammen mit den Ausgaben des Programms, für die bzw. für den ermittelt werden soll, ob ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist.
  • In einer Ausführungsform kann der Akkumulator-Wert mindestens zweimal (beispielsweise vor und nach einer Aktualisierung, oder nach einer ersten Aktualisierung und nach einer zweiten Aktualisierung) übermittelt werden, und es kann ermittelt werden, ob zwischen dem ersten Übermitteln und dem zweiten Übermitteln ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist.
  • In einer Ausführungsform kann ermittelt werden, ob ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist, basierend auf einer Überprüfung, ob der übermittelte Akkumulator-Wert der Differenz zweier Referenz-Zahlen entspricht.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis in sicherer Hardware implementiert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis durch Redundanz abgesichert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis durch arithmetische Codes abgesichert sein.
  • 2 zeigt ein Flussdiagram 200, das ein Verfahren zur Datenverarbeitung zum Ermitteln, ob in einer Ausführung eines Programms (anders ausgedrückt: ob bei (oder: ob in) einer Programmausführung) ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung illustriert. In 202 kann eine Mehrzahl von Referenz-Zahlen in einem Überprüfungs-Schaltkreis außerhalb des Programmes ermittelt werden. In 204 kann ein in einem Programm basierend auf der Mehrzahl von Referenz-Zahlen und einer mittels eines arithmetischen Codes ermittelten Signatur mindestens einer Anweisung des Programmes erzeugter Akkumulator-Wert von einem Programm in dem Überprüfungs-Schaltkreis empfangen werden. In 206 kann in dem Überprüfungs-Schaltkreis ermittelt werden, ob bei der Ausführung des Programms ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert.
  • In einer Ausführungsform kann der arithmetische Code ein arithmetischer Code mit Signaturen sein. In einer Ausführungsform kann der arithmetische Code jeder beliebige arithmetische Code sein, der um Signaturen erweitert werden kann oder ist.
  • In einer Ausführungsform kann der arithmetische Code mindestens einen der folgenden Codes enthalten oder mindestens einer der folgenden Codes sein: ein AN-Code, wie er weiter unten erklärt wird; ein ANB-Code, wie er weiter unten erklärt wird; ein ANBD-Code, wie er weiter unten erklärt wird; ein ANBDmem-Code, wie er weiter unten erklärt wird; ein dem Fachmann als solches bekannter Residuum-Code (englisch: Residue-Code); und ein dem Fachmann als solches bekannter Berger-Code.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine Mehrzahl von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine geordnete Liste von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann ein Identifikator eines Basis-Blocks des Programms ermittelt werden.
  • In einer Ausführungsform kann der aktualisierte Akkumulator-Wert empfangen werden nach einer oder jeder Funktion des Programms, nach einer oder jeder Programmanweisung (Instruktion) des Originalprogramms, nach einem oder jedem Basis-Block, und/oder zusammen mit den Ausgaben des Programms, für die bzw. für den ermittelt werden soll, ob ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist.
  • In einer Ausführungsform kann der Akkumulator-Wert mindestens zweimal (beispielsweise vor und nach einer Aktualisierung, oder nach einer ersten Aktualisierung und nach einer zweiten Aktualisierung) empfangen werden, und es kann ermittelt werden, ob zwischen dem ersten Empfangen und dem zweiten Empfangen ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist.
  • In einer Ausführungsform kann ermittelt werden, ob ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist, basierend auf einer Überprüfung, ob der empfangene Akkumulator-Wert der Differenz zweier Referenz-Zahlen entspricht.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis in sicherer Hardware implementiert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis durch Redundanz abgesichert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis durch arithmetische Codes abgesichert sein.
  • 3 zeigt ein Flussdiagram 300, das ein Verfahren zum Erzeugen von Programm-Code zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms (anders ausgedrückt: ob bei (oder: ob in) einer Programmausführung) ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung illustriert. In 302 kann eine Mehrzahl von Referenz-Zahlen ermittelt werden. In 304 kann eine Signatur mindestens einer Anweisung eines Programmes mittels eines arithmetischen Codes ermittelt werden. In 306 kann ein Programm-Code-Abschnitt zum Aktualisieren eines Akkumulator-Wertes basierend auf der Mehrzahl von Referenz-Zahlen und der Signatur erzeugt werden. In 308 kann ein Programm-Code-Abschnitt zum Übermitteln des aktualisierten Akkumulator-Wertes an einen Überprüfungs-Schaltkreis außerhalb des Programmes-Codes zum Ermitteln, ob bei der Ausführung des Programm-Codes ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert, erzeugt werden.
  • In einer Ausführungsform kann der arithmetische Code ein arithmetischer Code mit Signaturen sein. In einer Ausführungsform kann der arithmetische Code jeder beliebige arithmetische Code sein, der um Signaturen erweitert werden kann oder ist.
  • In einer Ausführungsform kann der arithmetische Code mindestens einen der folgenden Codes enthalten oder mindestens einer der folgenden Codes sein: ein AN-Code, wie er weiter unten erklärt wird; ein ANB-Code, wie er weiter unten erklärt wird; ein ANBD-Code, wie er weiter unten erklärt wird; ein ANBDmem-Code, wie er weiter unten erklärt wird; ein dem Fachmann als solches bekannter Residuum-Code (englisch: Residue-Code); und ein dem Fachmann als solches bekannter Berger-Code.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine Mehrzahl von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine geordnete Liste von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann der Zahlenwert eine Differenz zweier Referenz-Zahlen sein.
  • In einer Ausführungsform kann der Zahlenwert eine Differenz zweier aufeinanderfolgender Referenz-Zahlen sein.
  • In einer Ausführungsform kann der Akkumulator-Wert aktualisiert werden basierend auf einer Subtraktion einer Signatur eines Basis-Blocks des Programms, und jeweils einer Addition der Signatur jeder Funktion in dem Block.
  • In einer Ausführungsform kann der Akkumulator-Wert aktualisiert werden basierend auf einer Addition des Zahlenwertes.
  • In einer Ausführungsform kann ein Identifikator eines Basis-Blocks des Programms ermittelt werden.
  • In einer Ausführungsform kann ein Programm-Code-Abschnitt zum Aktualisieren des Akkumulator-Werts ferner basierend auf dem Identifikator des Blocks erzeugt werden.
  • In einer Ausführungsform kann ein Programm-Code-Abschnitt zum Übermitteln des Akkumulator-Wertes nach einer oder jeder Funktion des Programms, nach einer oder jeder Programmanweisung (Instruktion) des Originalprogramms, nach einem oder jedem Basis-Block, und/oder zusammen mit den Ausgaben des Programms, für die bzw. für den ermittelt werden soll, ob ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist, erzeugt werden.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis in sicherer Hardware implementiert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis durch Redundanz abgesichert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis durch arithmetische Codes abgesichert sein.
  • 4 zeigt eine Datenverarbeitungsanordnung 400 zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms (anders ausgedrückt: ob bei (oder: ob in) einer Programmausführung) ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung. Die Datenverarbeitungsanordnung 400 kann enthalten einen Zahlenwert-Ermittlungs-Schaltkreis 402, der eingerichtet ist zum Ermitteln eines Zahlenwertes basierend auf einer von einem Überprüfungs-Schaltkreis (nicht gezeigt) außerhalb des Programmes ermittelten Mehrzahl von Referenz-Zahlen; einen Signatur-Ermittlungs-Schaltkreis 404, der eingerichtet ist zum Ermitteln einer Signatur mindestens einer Anweisung des Programmes mittels eines arithmetischen Codes; einen Aktualisierungs-Schaltkreis 406, der eingerichtet ist zum Aktualisieren eines Akkumulator-Wertes basierend auf dem Zahlenwert und der Signatur; und einen Übermittlungs-Schaltkreis 408, der eingerichtet ist zum Übermitteln des aktualisierten Akkumulator-Wertes an den Überprüfungs-Schaltkreis zum Ermitteln, ob bei der Ausführung des Programms ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert. Der Zahlenwert-Ermittlungs-Schaltkreis 402, Signatur-Ermittlungs-Schaltkreis 404, der Aktualisierungs-Schaltkreis 406, und der Übermittlungs-Schaltkreis 408 können über eine Verbindung 410, beispielsweise einem Draht, einer Mehrzahl von separaten Drähten, einem Bus, oder mittels einer drahtlosen Verbindung miteinander kommunizieren und Informationen austauschen können.
  • Anschaulich kann die Datenverarbeitungsanordnung 400 eine Anordnung sein zum Ausführen eines Programms, das auf Fehler überwacht werden soll.
  • In einer Ausführungsform kann der arithmetische Code ein arithmetischer Code mit Signaturen sein. In einer Ausführungsform kann der arithmetische Code jeder beliebige arithmetische Code sein, der um Signaturen erweitert werden kann oder ist.
  • In einer Ausführungsform kann der arithmetische Code mindestens einen der folgenden Codes enthalten oder mindestens einer der folgenden Codes sein: ein AN-Code, wie er weiter unten erklärt wird; ein ANB-Code, wie er weiter unten erklärt wird; ein ANBD-Code, wie er weiter unten erklärt wird; ein ANBDmem-Code, wie er weiter unten erklärt wird; ein dem Fachmann als solches bekannter Residuum-Code (englisch: Residue-Code); und ein dem Fachmann als solches bekannter Berger-Code.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine Mehrzahl von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine geordnete Liste von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann der Zahlenwert eine Differenz zweier Referenz-Zahlen sein.
  • In einer Ausführungsform kann der Zahlenwert eine Differenz zweier aufeinanderfolgender Referenz-Zahlen sein.
  • In einer Ausführungsform kann der Aktualisierungs-Schaltkreis 406 eingerichtet sein zum Aktualisieren des Akkumulator-Werts basierend auf einer Subtraktion einer Signatur eines Basis-Blocks des Programms, und jeweils einer Addition der Signatur des Nachfolger-Basis-Blocks.
  • In einer Ausführungsform kann der Aktualisierungs-Schaltkreis 406 eingerichtet sein zum Aktualisieren des Akkumulator-Werts basierend auf einer Addition des Zahlenwertes.
  • In einer Ausführungsform kann die Datenverarbeitungsanordnung 400 ferner enthalten einen Block-Signatur-Ermittlung-Schaltkreis (nicht gezeigt), der eingerichtet ist zum Ermitteln eines Identifikators eines Basis-Blocks des Programms.
  • In einer Ausführungsform kann der Aktualisierungs-Schaltkreis 406 eingerichtet sein zum Aktualisieren des Akkumulator-Werts ferner basierend auf dem Identifikator des Blocks.
  • In einer Ausführungsform kann der Übermittlungs-Schaltkreis 408 eingerichtet sein zum Übermitteln des aktualisierten Akkumulator-Werts nach einer oder jeder Funktion des Programms, nach einer oder jeder Programmanweisung (Instruktion) des Originalprogramms, nach einem oder jedem Basis-Block, und/oder zusammen mit den Ausgaben des Programms, für die bzw. für den ermittelt werden soll, ob ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist.
  • In einer Ausführungsform kann der Übermittlungs-Schaltkreis 408 eingerichtet sein zum mindestens zweimaligen Übermitteln des Akkumulator-Wertes (beispielsweise vor und nach einer Aktualisierung, oder nach einer ersten Aktualisierung und nach einer zweiten Aktualisierung), und der Überprüfungs-Schaltkreis kann eingerichtet sein zum Überprüfen, ob zwischen dem ersten Übermitteln und dem zweiten Übermitteln ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis eingerichtet sein zum Ermitteln, ob ein Fehler aufgetreten ist, basierend auf einer Überprüfung, ob der übermittelte Akkumulator-Wert der Differenz zweier Referenz-Zahlen entspricht.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis in sicherer Hardware implementiert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis durch Redundanz abgesichert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis durch arithmetische Codes abgesichert sein.
  • 5 zeigt eine Datenverarbeitungsanordnung 500 zum Ermitteln, ob bei einer Ausführung eines Programms (anders ausgedrückt: ob bei (oder: ob in) einer Programmausführung) ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung. Die Datenverarbeitungsanordnung 500 kann enthalten: einen Referenz-Zahlen-Ermittlungs-Schaltkreis 502, der eingerichtet ist zum Ermitteln einer Mehrzahl von Referenz-Zahlen in einem Überprüfungs-Schaltkreis 506 außerhalb des Programmes; einen Empfangs-Schaltkreis 504, der eingerichtet ist zum Empfangen eines in einem Programm basierend auf der Mehrzahl von Referenz-Zahlen und einer mittels eines arithmetischen Codes ermittelten Signatur mindestens einer Anweisung des Programmes erzeugten Akkumulator-Wertes von einem Programm in dem Überprüfungs-Schaltkreis; und einen Überprüfungs-Schaltkreis 506, der eingerichtet ist zum Ermitteln, ob bei der Ausführung des Programms ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert. Der Referenz-Zahlen-Ermittlungs-Schaltkreis 502, der Empfangs-Schaltkreis 504 und der Überprüfungs-Schaltkreis 506 können über eine Verbindung 508, beispielsweise einem Draht, einer Mehrzahl von separaten Drähten, einem Bus, oder mittels einer drahtlosen Verbindung miteinander kommunizieren und Informationen austauschen können.
  • Anschaulich kann die Datenverarbeitungsanordnung 500 eine Anordnung sein zum Überprüfen, ob ein Fehler (in anderen Worten: ein Ausführungsfehler) in einer anderen Datenverarbeitungseinrichtung aufgetreten ist.
  • In einer Ausführungsform kann der arithmetische Code ein arithmetischer Code mit Signaturen sein. In einer Ausführungsform kann der arithmetische Code jeder beliebige arithmetische Code sein, der um Signaturen erweitert werden kann oder ist.
  • In einer Ausführungsform kann der arithmetische Code mindestens einen der folgenden Codes enthalten oder mindestens einer der folgenden Codes sein: ein AN-Code, wie er weiter unten erklärt wird; ein ANB-Code, wie er weiter unten erklärt wird; ein ANBD-Code, wie er weiter unten erklärt wird; ein ANBDmem-Code, wie er weiter unten erklärt wird; ein dem Fachmann als solches bekannter Residuum-Code (englisch: Residue-Code); und ein dem Fachmann als solches bekannter Berger-Code.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine Mehrzahl von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine geordnete Liste von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann die Datenverarbeitungsanordnung 500 ferner enthalten einen Schaltkreis (nicht gezeigt), der eingerichtet ist zum Ermitteln eines Identifikators eines Basis-Blocks des Programms.
  • In einer Ausführungsform kann der Empfangs-Schaltkreis 504 eingerichtet sein zum Empfangen des aktualisierten Akkumulator-Werts nach einer Anweisung des Programms, für die ermittelt werden soll, ob ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist.
  • In einer Ausführungsform kann der Empfangs-Schaltkreis 504 eingerichtet sein zum mindestens zweimaligen Empfangen des Akkumulator-Werts (beispielsweise vor und nach einer Aktualisierung, oder nach einer ersten Aktualisierung und nach einer zweiten Aktualisierung), und der Überprüfungs-Schaltkreis 506 kann eingerichtet seines zum Ermitteln, ob zwischen dem ersten Empfangen und dem zweiten Empfangen ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis 506 eingerichtet sein zum Ermitteln, ob ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist, basierend auf einer Überprüfung, ob der empfangene Akkumulator-Wert der Differenz zweier Referenz-Zahlen entspricht.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis 506 in sicherer Hardware implementiert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis 506 durch Redundanz abgesichert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis 506 durch arithmetische Codes abgesichert sein.
  • 6 zeigt eine Datenverarbeitungsanordnung 600 zum Erzeugen von Programm-Code zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms (anders ausgedrückt: ob bei (oder: ob in) einer Programmausführung) ein Fehler aufgetreten ist, gemäß einem Ausführungsbeispiel der Erfindung. Die Datenverarbeitungsanordnung 600 kann enthalten: einen Referenz-Zahlen-Ermittlungs-Schaltkreis 602, der eingerichtet ist zum Ermitteln einer Mehrzahl von Referenz-Zahlen; einen Signatur-Ermittlungs-Schaltkreis 604, der eingerichtet ist zum Ermitteln einer Signatur mindestens einer Anweisung eines Programmes mittels eines arithmetischen Codes; einen Aktualisierungs-Programm-Code-Abschnitt-Erzeugungs-Schaltkreis 606, der eingerichtet ist zum Erzeugen eines Programm-Code-Abschnittes zum Aktualisieren eines Akkumulator-Wertes basierend auf der Mehrzahl von Referenz-Zahlen und der Signatur; und einen Übermittlungs-Programm-Code-Abschnitt-Erzeugungs-Schaltkreis 608, der eingerichtet ist zum Erzeugen eines Programm-Code-Abschnittes zum Übermitteln des aktualisierten Akkumulator-Wertes an einen Überprüfungs-Schaltkreis außerhalb des Programmes-Codes zum Ermitteln, ob bei einer Ausführung des Programm-Codes ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert. Der Referenz-Zahlen-Ermittlungs-Schaltkreis 602, der Signatur-Ermittlungs-Schaltkreis 604, der Aktualisierungs-Programm-Code-Abschnitt-Erzeugungs-Schaltkreis 606, und der Übermittlungs-Programm-Code-Abschnitt-Erzeugungs-Schaltkreis 608 können über eine Verbindung 610, beispielsweise einem Draht, einer Mehrzahl von separaten Drähten, einem Bus, oder mittels einer drahtlosen Verbindung miteinander kommunizieren und Informationen austauschen können.
  • Anschaulich kann die Datenverarbeitungsanordnung 600 ein Compiler sein zum Erzeugen eines Programm-Codes, der von einer Datenverarbeitung zur Ausführung eines Programms ausgeführt werden kann.
  • In einer Ausführungsform kann der arithmetische Code ein arithmetischer Code mit Signaturen sein. In einer Ausführungsform kann der arithmetische Code jeder beliebige arithmetische Code sein, der um Signaturen erweitert werden kann oder ist.
  • In einer Ausführungsform kann der arithmetische Code mindestens einen der folgenden Codes enthalten oder mindestens einer der folgenden Codes sein: ein AN-Code, wie er weiter unten erklärt wird; ein ANB-Code, wie er weiter unten erklärt wird; ein ANBD-Code, wie er weiter unten erklärt wird; ein ANBDmem-Code, wie er weiter unten erklärt wird; ein dem Fachmann als solches bekannter Residuum-Code (englisch: Residue-Code); und ein dem Fachmann als solches bekannter Berger-Code.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine Mehrzahl von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann die Mehrzahl von Referenz-Zahlen eine geordnete Liste von vorgegebenen Zufallszahlen sein.
  • In einer Ausführungsform kann der Zahlenwert eine Differenz zweier Referenz-Zahlen sein.
  • In einer Ausführungsform kann der Zahlenwert eine Differenz zweier aufeinanderfolgender Referenz-Zahlen sein.
  • In einer Ausführungsform kann der Aktualisierungs-Programm-Code-Abschnitt-Erzeugungs-Schaltkreis 606 eingerichtet sein zum Erzeugen eines Programm-Code-Abschnitts zum Aktualisieren des Akkumulator-Werts basierend auf einer Subtraktion einer Signatur eines Basis-Blocks des Programms, und jeweils einer Addition der Signatur des Nachfolger-Basis-Blocks.
  • In einer Ausführungsform kann der Aktualisierungs-Programm-Code-Abschnitt-Erzeugungs-Schaltkreis 606 eingerichtet sein zum Erzeugen eines Programm-Code-Abschnitts zum Aktualisieren des Akkumulator-Werts basierend auf einer Addition des Zahlenwertes.
  • In einer Ausführungsform kann die Datenverarbeitungsanordnung 600 ferner enthalten einen Schaltkreis (nicht gezeigt), der eingerichtet ist zum Ermitteln eines Identifikators eines Basis-Blocks des Programms.
  • In einer Ausführungsform kann der Aktualisierungs-Programm-Code-Abschnitt-Erzeugungs-Schaltkreis 606 eingerichtet sein zum Erzeugen eines Programm-Code-Abschnitts zum Aktualisieren des Akkumulator-Werts ferner basierend auf dem Identifikator des Blocks.
  • In einer Ausführungsform kann der Übermittlungs-Programm-Code-Abschnitt-Erzeugungs-Schaltkreis 608 eingerichtet sein zum Erzeugen eines Programm-Code-Abschnitts zum Übermitteln des Akkumulator-Wert nach einer oder jeder Funktion des Programms, nach einer oder jeder Programmanweisung (Instruktion) des Originalprogramms, nach einem oder jedem Basis-Block, und/oder zusammen mit den Ausgaben des Programms, für die bzw. für den ermittelt werden soll, ob ein Fehler (in anderen Worten: ein Ausführungsfehler) aufgetreten ist.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis in sicherer Hardware implementiert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis durch Redundanz abgesichert sein.
  • In einer Ausführungsform kann der Überprüfungs-Schaltkreis durch arithmetische Codes abgesichert sein.
  • Gemäß Ausführungsformen kann ein Verfahren zur Kommunikation zweier mittels arithmetischer Codes codierter Programme bereitgestellt werden, wobei die beiden Programme Werte austauschen, die mittels gleichen arithmetischen Codes codiert sind.
  • Gemäß Ausführungsformen kann eine Datenverarbeitungsvorrichtung bereitgestellt werden, eingerichtet für die Kommunikation zweier mittels arithmetischer Codes codierter Programme, wobei die beiden Programme Werte austauschen, die mittels gleichen arithmetischer Codes codiert sind.
  • Gemäß Ausführungsformen können Datenverarbeitungsanordnungen und Verfahren bereitgestellt werden für die automatische Überwachung eines Programmablaufs von durch arithmetische Codes mit Signaturen geschützten Programmen zur frühzeitigen Erkennung von fehlerhaften Abweichungen im Kontroll- und Datenfluss des Programms.
  • Gemäß Ausführungsformen können Datenverarbeitungsanordnungen und Verfahren bereitgestellt werden zum Überprüfen des Kontrollflusses und Detektieren der Ausführung nicht erlaubter Sequenzen von Anweisungen während des Programmablaufs.
  • Gemäß Ausführungsformen können Datenverarbeitungsanordnungen und Verfahren bereitgestellt werden für arithmetische Codes, funktionale Sicherheit, Software-Fehlerdetektion, und Kontrollfluss-Überprüfung.
  • Im Folgenden werden weitere Techniken beschrieben. Algorithmus-basierte Fehlertoleranz und selbst-kontrollierende Software können Invarianten verwenden um die Gültigkeit der generierten Ergebnisse zu überprüfen. Wenn entsprechende Invarianten gegeben sind, kann sich eine Möglichkeit zur Erkennung von Störungen ergeben.
  • Software-Ansätze zur Erkennung von Hardware-Fehler können replizierte Ausführung und Vergleich (englisch: Voting) der erzielten Ergebnisse sein. Die zu schützende Software kann während oder vor der Compilierung verändert werden. Es kann dynamische Instrumentierung zur Laufzeit angewendet werden. Die Replizierung kann auf verschiedenen Ebenen angewendet werden. Einzelne Anweisungen können innerhalb eines Verarbeitungsstranges (englisch: Thread) verdoppelt werden. Andere können Duplikate des gesamten Programms mit mehreren Threads ausführen.
  • Fehlererkennung in Hardware kann durch doppelte, dreifache oder nochmehrfache redundante Ausführung erzielt werden. Weiterhin können eingebaute Selbst-Tests direkt in Hardware implementiert werden.
  • Programme können geschützt werden mit arithmetischen Codes mit Signaturen mittels VCP und SEP.
  • Bei der alleinigen Überprüfung des Kontrollflusses können keine Fehler erkannt werden, welche nur den Datenfluss eines Programms betreffen. Der Kontrollfluss kann nur zwischen Basis-Blöcken (englisch: basic blocks) in einem Programm überprüft werden und Kontrollflussfehler innerhalb eines Blocks können nicht erkannt werden.
  • Gemäß Ausführungsformen kann Unterstützung für Programme mit beliebig dynamisch, verschachtelten Kontrollstrukturen, dynamisch zugewiesenen und zugegriffenen Speicher bereitgestellt und Ausgaben an beliebigen Punkten im Programmablauf erlaubt werden und die Implementierung von „fail-fast” (deutsch: „schnelles Scheitern”) Verhalten in Programmen ermöglicht werden, das heißt Fehler können so schnell wie möglich erkannt werden, was eine frühzeitige Reaktion erlauben kann.
  • Gemäß Ausführungsformen können Datenverarbeitungsanordnungen und Verfahren bereitgestellt werden zum Verwenden von zur Laufzeit des Programms durch codierte Ausführung erzeugten Signaturen. Die erzeugten Signaturen können dabei unauflösbar vom Kontroll- und Datenfluss der durch den arithmetischen Code mit Signaturen geschützten Ausführung des Programms abhängen. Falls es zu einem Ausführungsfehler kommt, kann die codierte Anwendung nicht den durch den Watchdog (deutsch: Überprüfungs-Schaltkreis) erwarteten Wert zur Überprüfung senden.
  • Gemäß Ausführungsformen kann die Frequenz der an den Watchdog zur Überprüfung gesendeten Werte von „nach jeder Instruktion” bis „vor der Ausgabe” angepasst werden, so dass Fehler erkannt werden können ehe eine fehlerhafte Ausgabe extern sichtbar wird.
  • Gemäß Ausführungsformen können die Werte, die der Watchdog überprüft, statisch während des Transformationsprozesses erzeugt werden und vom Programm völlig unabhängige, zufällig wählbare Werte beliebiger Größe und Anzahl sein, so dass eine zufällige Erzeugung dieser Werte trotz transienter oder permanenter Fehler während der Ausführung des Programms mit beliebiger Wahrscheinlichkeit ausgeschlossen werden kann.
  • Gemäß Ausführungsformen kann der zu schützende Quellcode des Programms vor der eigentlichen Ausführung in eine semantisch identische aber geschützte Version transformiert werden, deren korrekte Abarbeitung dann zur Laufzeit durch einen sicheren Watchdog-Prozess überprüft werden kann. Hierfür kann durch den Software-Codier-Compiler (englisch: Software Encoding Compiler) automatisch die Ablaufbeschreibung des Programms in eine durch einen arithmetischen Code mit Signaturen geschützte Version transformiert werden und anschließend ein auf der Zielplattform ausführbares codiertes Programm erzeugt werden.
  • Gemäß Ausführungsformen kann der Transformationsprozess sicherstellen, dass nachdem dieser abgeschlossen ist, durch den Watchdog-Prozess erkannt werden kann, wenn die spätere Ausführung des Programms von der durch den Programmierer festgelegten Ablaufbeschreibung abweicht.
  • Gemäß Ausführungsformen kann ein vollständig automatisierter Schutz von dynamischen und geschachtelten Ablaufbeschreibungen und des Kontroll- und Datenflusses von beliebigen Programmen zur Erkennung von Fehlern während der Ausführung bereitgestellt werden.
  • Gemäß Ausführungsformen kann ein kombinierter Schutz des Datenflusses in unauflösbarer Verbindung mit der Erkennung von fehlerhafter Instruktionsausführung bereitgestellt werden.
  • Gemäß Ausführungsformen können akkumulierte Signaturen für arithmetisch codierte Programme generiert werden, was eine flexible Anpassung des Schutzes an die geforderte Sicherheit erlauben und wenig zusätzlichem Speicher- und CPU-Overhead erfordern kann.
  • Gemäß Ausführungsformen kann automatischer Schutz der Ablaufbeschreibung von mit arithmetischen Codes mit Signaturen geschützten Programmen bereitgestellt werden.
  • Gemäß Ausführungsformen können nur wenig zusätzliche CPU-Zyklen und Programmspeicher benötigt werden.
  • Gemäß Ausführungsformen kann das durch den Software-Codier-Compiler erzeugte, geschützte Programm direkt auf unsicherer Hardware ausgeführt werden.
  • Gemäß Ausführungsformen kann der Umfang des Schutzes durch den Anwender flexibel bestimmt werden.
  • Gemäß Ausführungsformen können Unterstützung für Programme mit beliebig dynamisch, verschachtelten Kontrollstrukturen und dynamisch zugewiesenen Speicher bereitgestellt und Ausgaben an beliebigen Punkten im Programmablauf erlaubt werden.
  • Gemäß Ausführungsformen kann die Implementierung von „fail-fast” Verhalten in Programmen ermöglicht werden, das heißt Fehler können so schnell wie möglich erkannt werden, bereitgestellt werden, was eine frühzeitige Reaktion erlauben kann.
  • Gemäß Ausführungsformen kann flexibel die Ausführung des Programms inklusive des Kontroll- und Datenflusses mit einer bestimmten mathematisch nachweisbaren Wahrscheinlichkeit geschützt werden.
  • Gemäß Ausführungsformen können mehrere geschützte und ungeschützte Programme auf einem Rechner parallel laufen.
  • Ausführungsformen können in sicherheitsrelevanten Anwendungen, beispielsweise in der Automobiltechnik, der Flugzeugtechnik oder der Medizintechnik eingesetzt werden.
  • 7 zeigt eine Datenverarbeitungsanordnung 700 gemäß einem Ausführungsbeispiel der Erfindung. Die Datenverarbeitungsanordnung 700 kann eingesetzt werden als eine oder mehrere der oben genannten Datenverarbeitungsanordnungen (beispielsweise wie in 4 bis 6 beschrieben). Die Datenverarbeitungsanordnung 700 kann enthalten Speichermedien 702, die ein Programm 710 oder mehrere Programme sowie Eingabedaten 712 enthalten können. Das Programm 710 kann ein Programm sein, dass eines der oben genannten Verfahren ausführen kann, beispielsweise eine Compilierung, einen Programmablauf, der auf Fehler überwacht werden soll, oder einen Programmablauf, der Fehler bei einer Ausführung eines anderen Programms überwacht. Die Eingabedaten 712 können dabei im Falle des Compilierens den Quell-Code des zu compilierenden Programms enthalten. Ferner kann die Datenverarbeitungsanordnung 700 einen Arbeitsspeicher 704 enthalten, in dem Daten 714 enthalten sein können. Die Daten 714 können Daten eines momentan ausgeführten Programms beinhalten. Ferner kann die Datenverarbeitungsanordnung 700 eine zentral Verarbeitungseinheit 706 (engl.: „Central Processing Unit”, CPU) enthalten, die die Verarbeitung steuert und ausführt. Ferner kann die Datenverarbeitungsanordnung 700 gesicherte Spezialhardware 708 enthalten. Beispielsweise kann der oben beschriebene Überprüfungsschaltkreis 506 in der gesicherten Spezialhardware 708 bereitgestellt werden, die gesichert fehlerfrei arbeitet. Die beschriebenen Komponenten der Datenverarbeitungsanordnung 700 können mit einer Verbindung 714, beispielsweise einem Draht, einer Mehrzahl von separaten Drähten, einem Bus, oder mittels einer drahtlosen Verbindung miteinander kommunizieren und Informationen austauschen können.
  • Gemäß Ausführungsformen wird ein Codier-Compiler (englisch: „Encoding Compiler”) bereitgestellt, der automatisch AN-, ANB- und/oder ANBD-Code auf eine Anwendung anwendet. Fehler-Injektionen zeigen, dass AN-, ANB- und ANBD-Codes erfolgreich Fehler detektieren können und dass ANB- und ANBD-Codes die SDC-Rate effektiver als AN-Codes reduzieren können. Der Unterschied zwischen ANBD- und ANB-Codes kann auch sichtbar sein, aber kann weniger stark ausgeprägt sein.
  • Gemäß Ausführungsformen werden Datenverarbeitungsanordnungen und Verfahren zum ANB-, ANBDmem-, Residuum- und/oder Berger-Codieren und zum Ermitteln von Hardware-Fehlern in Software bereitgestellt.
  • In der Zukunft wird die Steigerung der Integrationsdichte bzw. das Schrumpfen der Strukturbreiten von integrierten Schaltkreisen zu weniger zuverlässiger Hardware führen. Momentan verwendete Hardware-basierte Lösungen zum Ermitteln von Hardware-Fehlern können teuer und um einer Größenordnung langsamer als Standard-Hardware sein. Daher werden aus Kostendruckgründen immer mehr kritische System auf unzuverlässiger Standard-Hardware aufgebaut werden oder diese verwenden. Jedoch zeigt Standard-Hardware nicht nur Fehler-Stopp-Verhalten (englisch: Fail-Stop), sondern auch schwieriger zu detektierende und zu maskierend Silent Data Corruptions (SDC), d. h. sie erzeugt eine fehlerhafte Ausgabe anstatt abzustürzen. Um diese unzuverlässige Hardware in kritischen Systemen einzusetzen, ist es erforderlich, ihre eingeschränkten Fehler-Detektions-Möglichkeiten mit der Hilfe von Software zu erweitern.
  • Gemäß Ausführungsformen wird die Möglichkeit zur Überwachung des Programmablaufs von mit arithmetischen Codes mit Signaturen geschützten Programmen geschaffen, um zu erkennen, wenn die Ausführung des Programms von der durch den Programmierer festgelegten Ablaufbeschreibung abweicht, Gemäß Ausführungsformen können Abweichungen im Daten- und im Kontrollfluss des Programms frühzeitig während der Ausführung des Programms mit einer bestimmten Wahrscheinlichkeit erkannt werden.
  • Durch Erkennen dieser Fehler können andernfalls willkürlich ausfallende Systeme in einen sicheren Zustand (englisch: fail-safe) überführt und entsprechende Fehlerbehandlungsmaßnahmen angestoßen werden, z. B. der Versuch einer erneuten Ausführung. Gemäß Ausführungsformen werden neue Konzepte optimistischer Programmausführung (englisch: Retry and Error) und Sicherheitsmaßnahmen bereitgestellt.
  • Derzeit verwendete hardware-basierte Lösungen, um Fehler zu erkennen, können teuer sein, Spezialhardware benötigen und um Größenordnungen langsamer sein als die aktuelle Hardwaregeneration erlaubt.
  • Gemäß Ausführungsbeispielen wird ein System, das SDCs in viel einfacher zu handhabende Stopp-Fehler umwandelt, bereitgestellt, dass ohne spezielle Hardware auskommt.
  • Wenn die Detektion oder Erkennung von Hardware-Fehlern in Software implementiert wird, werden mehr CPU-Zyklen zur Ausführung einer Anwendung oder eines Programms benötigt. Jedoch kann anstelle von spezieller zuverlässiger Hardware Standard-Hardware verwendet werden. Beispielsweise kann Standard-Hardware billiger sein als spezielle zuverlässige Hardware, und auch schneller, weil sie die neuesten Hardware-Bauteile verwendet. Ferner kann in einigen System nur eine geringe Anzahl von Anwendungs-Komponenten kritisch sein und nur für diese Komponenten kann es gewünscht sein, sie durch zusätzliche Fehler-Erkennung zu schützen. Daher kann die Auswirkung des Leistungsunterschieds nur kritische Anwendungs-Komponenten betreffen.
  • Gemäß Ausführungsformen kann ein Fehler-Erkennungs-Ansatz bereitgestellt werden basierend auf arithmetischen Codes, die Ende-zu-Ende-Software-implementierte Hardware-Fehler-Erkennung unterstützt, d. h. er kann Daten schützen vor unerkannten Fehlern während des Speicherns, des Transports und Berechnungen. Seine Fehler-Erkennungs-Möglichkeiten können entkoppelt sein von der eingesetzten Hardware.
  • Zum Verwenden von arithmetischen Codes kann es vorteilhaft sein, Programme zu haben, die mit arithmetisch codierten Daten arbeiten können. Gemäß Ausführungsformen wird ein Codier-Compiler bereitgestellt, der verschiedene arithmetische Codes unterstützt, wie sie weiter unten beschrieben werden bzw. dem Fachmann als solches bekannt sind: AN-Code, ANB-Code, ANBD-Code, ANBDmem-Code, Residuum-Code und Berger-Code. Diese Codes können verschiedene Fehler-Erkennungs-Raten zu verschiedenen Laufzeit-Kosten bereitstellen. Daher kann die Fehler-Erkennungs-Rate gegen die Laufzeit-Kosten abgewogen werden.
  • Gemäß Ausführungsbeispielen kann mittels ANB-, ANBD-, ANBDmem-, Residuum- und/oder Berger-Codes die Erkennung von Daten- und Kontrollfluss-Fehlern bereitgestellt werden. Gemäß Ausführungsbeispielen wird beliebiger Kontroll- und Daten-Fluss, der nicht vorhersagbar ist zu der Zeit des Codierens, (in anderen Worten zu der Zeit des Compilierens), unterstützt.
  • Gemäß Ausführungsbeispielen kann die Anzahl von SDCs für ANB- und ANBDmem-codierte Programme verglichen mit uncodierten Programmen um 99.2% bzw. 99.7% reduziert werden. AN-Codierung kann zu einer Reduzierung um 93.5% führen.
  • Gemäß Ausführungsbeispielen können arithmetische Codes eine Technik zum Erkennen von Hardware-Fehlern zur Laufzeit sein. Das Codieren kann Redundanz zu allen Daten-Wörtern hinzufügen. Gültige Code-Wörter können nur eine kleine Teilmenge aller möglichen Daten-Wörter sein. Dabei kann die Menge aller möglichen Datenwörter die Menge aller darstellbaren Daten einer bestimmten Größe sein, und die Menge der Code-Wörter kann die Untermenge aller möglichen Datenwörter erzeugt durch einen Code sein.
  • Korrekt ausgeführte arithmetische Operationen können den Code erhalten, d. h. mit einem gültigen Code-Wort als Eingabe kann die Ausgabe auch ein gültiges Code-Wort sein. Eine fehlerhafte arithmetische Operation oder eine mit nicht-codierten Wörtern aufgerufene Operation kann mit hoher Wahrscheinlichkeit ein Ergebnis produzieren, welches ein ungültiges Code-Wort ist. Ferner können arithmetische Codes auch Fehler erkennen, die Daten während des Speicherns oder des Transports verändern.
  • Gemäß Ausführungsformen kann, wenn eine Anwendung unter Verwendung arithmetischer Codes codiert ist, sie nur codierte Daten verarbeiten, d. h. es kann gewünscht sein, dass alle Eingaben codiert werden, und alle Berechnungen können codierte Daten verwenden und produzieren. Daher kann es gewünscht sein, nur Operationen zu verwenden, die den Code im fehlerfreien Fall erhalten.
  • Gemäß Ausführungsformen kann für einen AN-Code die codierte Version von xc einer Variable x erhalten werden durch Multiplizieren ihres ursprünglichen Funktionswertes xf mit einer Konstante A. Um den Code zu überprüfen, kann der Rest von xc bei Teilung durch A (welcher „xc Modulus A” genannt werden kann) berechnet werden, welcher Null sein kann für ein gültiges Code-Wort.
  • Ein AN-Code kann fehlerhafte Operationen detektieren, d. h. unkorrekt ausgeführte Operationen, und modifizierte Operanden, also beispielsweise Daten, die von einem Bit-Fehler, beispielsweise einem Bit-Flip (also ein falscher Wert in einem Bit) getroffen wurden. Diese Fehler können detektiert werden, weil sie zu Daten führen, die mit hoher Wahrscheinlichkeit nicht ein Vielfaches von A sind. Die Wahrscheinlichkeit, dass solch ein Fehler zu einem gültigen Code führt, kann in etwa 1/A sein. Trotzdem kann, wenn ein Bit Flip auf dem (uncodierten) Adress-Bus passiert, auf ein falsches Speicher-Wort zugegriffen werden, das mit hoher Wahrscheinlichkeit auch ein Vielfaches von A enthält. Daher kann der so-genannte „ausgetauschte Operand” nicht mit einem AN-Code detektiert werden, weil der Fehler auch ein Vielfaches von A ist. Ein Bit-Flip in der Instruktions-Einheit einer CPU kann das Ausführen einer falschen Operation (sogenannte „ausgetauschte Operation”) zu Folge haben, was auch nicht erkannt werden kann von einem AN-Code, weil viele Operatoren den AN-Code beibehalten.
  • Als solches bekannt sind auch ANB-Codes, beispielsweise mittels statischer Signaturen (so genannte „B”s). Der resultierende ANB-Code kann zusätzlich Fehler von ausgetauschten Operatoren und ausgetauschten Operanden detektieren. Das Codieren einer Variable x in ANB-Code ist definiert als xc = A·xf + Bx, wobei Bx für jede Eingangsvariable mit 0 < Bx < A gewählt werden kann Zum Überprüfen des Codes von xc wird der Rest von xc bei Teilung durch A berechnet. Das Ergebnis muss gleich Bx sein, wobei Bx entweder zugeordnet oder vorab berechnet wird zur Codier-Zeit.
  • Zur Veranschaulichung sei folgender uncodierter C-Code betrachtet:
    Figure 00330001
  • Der oben angegebene Pseudo-Code ist der Übersichtlichkeit halber vereinfacht und ignoriert Über- und Unterlauf-Problematiken. Die angegebenen Kommentare im Quellcode geben den Variablen-Inhalt im fehlerfreien Fall an.
  • Gemäß Ausführungsformen können, wenn das Programm f codiert wird, den Eingangsvariablen x, y und z statische Signaturen zugeordnet werden. Wenn das Programm bekannt ist, können die erwarteten Signaturen Bv = Bx + By + Bz des Ergebnisses vorab berechnet werden. Wenn dynamisch allokierter Speicher implementiert wird, können als solche bekannte dynamische Signaturen verwendet werden. Diese können zur Laufzeit zugeordnet werden. Falls ein Fehler eine Variable yc mit einer anderen codierten Variable uc = A·uf + Bu vertauscht, wäre die berechnete Signatur vc mod A des Ergebnisses (Bx + Bu + Bz) anstatt der vorab berechneten, d. h. erwarteten (Bx + By + Bz). Falls die erste Addition fehlerhafterweise durch eine Subtraktion ersetzt würde, wäre die resultierende berechnete Signatur (Bx – By + Bz) anstelle von (Bx + By + Bz). Gemäß Ausführungsformen kann ein ANB-Code ausgetauschte Operanden und Operatoren zusätzlich zur fehlerhaften Operationen und modifizierten Operanden erkennen. Jedoch kann, wenn ein Bit Flip auf dem Adress-Bus auftritt wenn die Variable yc gespeichert wird, eine verlorene Aktualisierung von yc auftreten, weil yc an eine falsche Speicher-Stelle gespeichert wird. Wenn yc das nächste Mal gelesen wird, kann die alte Version von yc gelesen werden, welche korrekt ANB-codiert aber veraltet sein kann.
  • Gemäß Ausführungsformen kann zum Ermitteln der Verwendung von veralteten Operanden, d. h. verlorener Aktualisierung, eine als solches bekannte Version D verwendet werden, die die Variablen-Aktualisierungen zählt. Im resultierenden ANBD-Code kann die codierte Version von x wie folgt sein: xc = A·xf + Bx + D. Der Code-Überprüfer muss das erwartete D wissen zum Überprüfen der Validität von Code-Wörtern. Gemäß Ausführungsformen kann eine ANBD-Code-Implementierung verwendet werden, die Versionen nur auf den Speicher (englisch: memory), auf den während Lade- und Speicher-Instruktionen zugegriffen wird, aber nicht auf Register anwendet. Dieser Code kann daher als ANBDmem-Code bezeichnet werden.
  • Codieren einer Anwendung oder eines Programms, d. h. das ihr oder ihm Ermöglichen, codierte Daten zu verarbeiten, kann zu verschiedenen Abschnitten der Lebensdauer der Anwendung oder des Programms erfolgen: vor dem Compilieren durch Codieren des Quell-Codes, während des Compilierens durch Codieren einer Zwischen-Repräsentation des Programms, oder zur Laufzeit durch Codieren des Binär-Programms (englisch: Binary) während der Ausführung. Gemäß als solches bekannten Vital-Codierten-Prozessors (englisch: Vital Coded Processor, VCP), kann eine Anwendung ANBD-codieren auf Quell-Code-Ebene. VCP benötigt Wissen über den kompletten Daten- und Kontrollfluss des codierten Programms zum vorab berechnen der Signaturen aller Ausgabe-Variablen für eine Code-Überprüfung. Dies kann die Verwendung von dynamisch zugewiesenem Speicher und Funktions-Zeigern verhindern. Ferner sind codierte Schleifen und geschachtelte Kontrollfluss-Strukturen auf Quell-Code-Ebene mühsam.
  • Gemäß als solchem bekannten Software-Codierter-Verarbeitung (englisch: Software Encoded Processing, SEP) kann ANBD-Codierung auf Assembler-Ebene zur Laufzeit implementiert sein. Es kann ein Interpreter für ein als Binär-Programm gegebenes Programm bereitgestellt werden, der selbst mit den Prinzipien von VCP codiert ist. So können beliebige Programme mit beliebigem Kontrollfluss codiert werden. Zum Codieren von dynamisch allokiertem Speicher können dynamische Signaturen, die zur Laufzeit ermittelt werden, verwendet werden. Fehler-Injektions-Verfahren können zeigen, dass SEP erfolgreich fehlerhafte Ausgabe verhindert. Jedoch macht die beobachtete Verlangsamung SEP in der Praxis schwer einsetzbar.
  • Gemäß Ausführungsformen wird ein Compiler-Basiertes-Codieren (englisch: Compiler Based Encoding, CBE) bereitgestellt. CBE kann Programme codieren an der Zwischen-Code-Ebene, beispielsweise durch Verwendung von LLVM (Low Level Virtual Machine) Code, Java Bytecode, .Net Bytecode, GIMPLE und/oder Assembler. Gemäß Ausführungsformen werden das Hinzufügen des Codierens zur Zwischen-Code-Ebene (englisch: Intermediate Code Level) zur Compilier-Zeit und neue Konzepte zum Codieren des Kontrollflusses bereitgestellt. Gemäß Ausführungsformen kann das Codieren von Kontrollfluss vereinfacht werden verglichen mit VCP, weil keine verschachtelten Kontroll-Strukturen explizit gehandhabt werden müssen. Im Gegensatz zu VCP, kann CBE gemäß Ausführungsformen Unterstützung für Programme mit beliebig verschachtelten Kontroll-Strukturen und dynamisch allokierten Speicher bereitstellen. Ferner können gemäß Ausführungsformen alle Programmier-Sprachen, für die ein Zwischen-Code-Compiler existiert, beispielsweise C, unterstützt werden. Ausführungsformen sind aber nicht auf diese Programmiersprachen beschränkt.
  • Im Gegensatz zu SEP kann CBE einen vollständigeren Schutz bereitstellen, denn es kann auch bitweise logische Operatoren und Fließkomma-Operationen, die von SEP nicht abgedeckt sind, codieren, und es kann auch gegen Fehler (englisch: Bugs) in der Synthese-Ebene des Compilers (englisch: Compiler Back-End), das Code für eine spezielle Maschine erzeugt, schützen. Gleichzeitig kann CBE viel weniger Overhead als SEP einführen, weil keine teure Interpretation benötigt wird. Ferner kann CBE die Verwendung von teuren Speicher-Signaturen für dynamisch allokierten Speicher einschränken. CBE kann statische Signaturen (d. h. durch Compilier-Zeit berechnete Signaturen) für den gesamten statisch allokierten Speicher verwenden. Im Gegensatz dazu kann in SEP jedes Datum der Daten eine dynamische Signatur haben, weil alle Signaturen zur Laufzeit wegen der Interpreter-basierten Implementierung zugewiesen werden.
  • Zum Codieren eines Programms mit einem AN-, ANB-, ANBD-, ANBDmem-, Residuum- oder Berger-Code kann es erwünscht sein, dass jede Instruktion und jede Variable durch ihre passend codierte Version ersetzt wird. Gemäß Ausführungsformen kann folgendes bereitgestellt werden, wie weiter unten näher beschrieben wird:
    • 1. codierte Versionen aller Instruktionen, beispielsweise aller durch den Zwischen-Code unterstützter Instruktionen,
    • 2. Codieren aller Konstanten und Initialisierungs-Werte,
    • 3. Verarbeitung von Aufrufen zu externen Bibliotheken, und
    • 4. Encodieren von Kontroll- und Daten-Fluss, beispielsweise durch Überprüfen, dass Instruktionen in der richtigen Reihenfolge mit den richtigen Operanden ausgeführt werden und dass alle Sprung-Bedingungen korrekt ausgeführt werden.
    • (1) Codierte Instruktionen: Grundlegende arithmetische und boolesche Operationen können codiert werden, wie es als solches bekannt ist. Codieren komplexerer Operationen wie bitweise logische Operationen, Typ-Umwandlung, Schiebeoperationen, oder Fließkomma-Operationen können ebenfalls codiert werden, wie es als solches bekannt ist. Gemäß Ausführungsformen wird ein Codieren der Kontrolle und von Daten bereitgestellt.
    • (2) Codieren von Konstanten und Initialisierern: Gemäß Ausführungsformen werden A und die statischen Signaturen zur Codier-Zeit, also zur Compilier-Zeit, gewählt, und es können die uncodierten Konstanten und Initialisierer durch ihre codierten Versionen zur Compilier-Zeit ersetzt werden.
    • (3) Externe Aufrufe: Im Gegensatz zu SEP kann die statische Instrumentierung von CBE den Schutz von externen Bibliotheken, deren Quellcode nicht zur Compilier-Zeit verfügbar ist, nicht ermöglichen. Für den Aufruf zu diesen Bibliotheken können gemäß Ausführungsformen Schnittstellen (englisch: Wrapper) bereitgestellt werden, welche Parameter decodieren (und beispielsweise auch den Code überprüfen), und, nach Ausführen des uncodierten Originals, die erhaltenen Ergebnisse codieren. Zum Implementieren dieser Wrapper kann gemäß Ausführungsformen auf die Spezifikationen der externen Funktionen zurückgegriffen werden.
    • (4) Daten- und Kontrollfluss (englisch: Data and Control Flow (CF)): Während AN-Code nur Ausführungs- und Modifizierte-Operanden-Fehler detektieren kann, kann gemäß Ausführungsformen ANB-Code so eingesetzt werden, dass er auch die Detektion von ausgetauschten Operanden und Operatoren und beliebige Kombinationen dieser Fehler sicherstellt. Der ANBDmem-Code kann gemäß Ausführungsformen auch detektieren, ob Aktualisierungen (englisch: Updates) des Speichers verloren gegangen sind.
  • VCP erfordert statisch vorhersagbaren Kontrollfluss und ermöglicht eine Ausgabe nur an einer spezifischen Stelle in der Programmausführung. Nur an dieser Stelle sind Ausführungsfehler detektierbar, weil nur dort der Code der Ausgabe überprüft wird. Im Gegensatz dazu kann gemäß Ausführungsformen für CBE ein kontinuierliches Überprüfen der Programmausführung bereitgestellt werden, weil CBE Ausgaben an beliebigen Stellen erlaubt und der Kontrollfluss nicht statisch bekannt sein muss und CBE schnelle Fehlererkennung (englisch: fail-fast behavior) bereitstellt, d. h. beispielsweise Fehler so schnell wie möglich bereitstellt und dadurch eine frühere Reaktion auf sie erlaubt.
  • Gemäß Ausführungsformen kann eine codierte Anwendung (anders ausgedrückt: das codierte Programm) kontinuierlich Überprüfungswerte produzieren, welches sie an einen Überprüfungs-Schaltkreis (englisch: Watchdog) sendet. Gemäß Ausführungsformen kann durch die Codierung, falls ein Ausführungsfehler auftritt, die codierte Anwendung nicht den erwarteten Überprüfungs-Wert zu dem Überprüfungs-Schaltkreis schicken. Die erwarteten Überprüfungs-Werte können statisch ermittelt werden und an den Überprüfungs-Schaltkreis beispielsweise als eine geordnete Liste s übergeben werden, welche mit einem Zähler i indiziert ist. i kann die empfangenen Überprüfungsnachrichten zählen. Die codierte Anwendung kann auch einen Zähler i für gesendete Überprüfungs-Nachrichten haben. Dies kann der Anwendung ermöglichen, den erwarteten Überprüfungswert in einem fehlerfreien Lauf bereitzustellen. Die Anwendung kann eine Liste delta haben, welche die gleiche Größe haben kann wie die Liste des Überprüfungsschaltkreises. Jedoch kann die Liste delta die Differenzen von aufeinanderfolgenden Elementen haben, beispielsweise definiert durch delta[i] = s[i+1]-s[i]. Der Erste Wert der Liste delta kann der erste Wert der Liste s sein.
  • Gemäß Ausführungsformen können allen Eingabe-Variablen (Parametern, Speicher-Zugriffen, und Rückgabe-Werten von externen Funktionen) Signaturen zugewiesen werden zur Codier-Zeit. Unter Verwendung dieser Signaturen kann, beispielsweise auch zur Codier-Zeit, für jeden Basis-Block eine Block-Signatur (BBx), die die Summe der Signaturen aller in diesem Block produzierten Ergebnisse sein kann, berechnet werden.
  • Ferner kann gemäß Ausführungsformen ein Akkumulator acc zu der Anwendung hinzugefügt werden. acc kann für jeden Basis-Block x initialisiert werden, so dass er das nächste s[i] minus der Basis-Block-Signatur BBx enthält. Während der Basis-Block ausgeführt wird, können die Signaturen aller produzierten Ergebnisse zu acc addiert werden. Am Ende des Blocks sollte acc gleich s[i] sein und kann an den Überprüfungs-Schaltkreis (Watchdog) gesendet werden (beispielsweise mittels des Befehls send). Gemäß Ausführungsformen kann acc mit einer bestimmten Wahrscheinlichkeit nicht den erwarteten Wert enthalten, falls irgendein Fehler den Datenfluss, Berechnungen oder Daten geändert hat. Nach Senden des acc kann er für den nächsten Basis-Block angepasst werden. Dadurch kann gemäß Ausführungsformen Kontrollfluss-Überprüfung bereitgestellt werden. Gemäß Ausführungsformen kann Kontrollfluss-Überprüfung bereitgestellt werden, die über Inter-Basis-Block-Überprüfung hinausgeht. Gemäß Ausführungsformen kann überprüft werden, dass jede Instruktion in der richtigen Reihenfolge, mit den richtigen Operationen ausgeführt wurde, und dass ihre Ausführung selbst fehlerfrei war.
  • Gemäß Ausführungsformen kann, um zu verhindern, dass von irgendwo vor dem Senden von acc zu irgendeinem anderen send gesprungen wird, jedem Basis-Block ein Identifikator (englisch: Identifier, ID) BBx_id zugeordnet werden. Gemäß Ausführungsformen kann die ID BBx_id von dem acc subtrahiert werden, bevor ein Block ausgeführt wird, auch zu dem Überprüfungs-Schaltkreis gesendet werden. Der Überprüfungs-Schaltkreis kann überprüfen, ob acc+BBx_id == s[i] gilt, also ob acc+BBx_id gleich ist s[i]. Falls nicht, kann der Überprüfungs-Schaltkreis ermitteln, dass ein Fehler aufgetreten ist, und beispielsweise die Anwendung herunterfahren oder abbrechen.
  • Inter-Basis-Block-CF und unbedingte Sprünge: Im Folgenden wird der folgenden LLVM Byte-Code betrachtet:
    Figure 00400001
  • Gemäß Ausführungsformen kann ein ANB/ANBDmem-Codier-Compilierer dieses Beispiel transformieren in:
    Figure 00410001
  • Die Kommentare (angegeben durch ';') zeigen den erwarteten Wert des Akkumulators. Es ist anzumerken, dass xc die codierte Version von x bedeutet, wobei x entweder eine Variable oder eine Funktion/Instruktion ist.
  • Zeile 1 zeigt, welchen Wert acc am Anfang des Blocks bb1 hat. Dies wird durch den zuvor ausgeführten Block sichergestellt. Zeilen 2 und 4 enthalten die codierten Versionen der ursprünglichen Instruktionen, deren Signaturen zu acc addiert werden direkt nach Ausführen der Instruktionen. In Zeile 5 hat acc den Wert s[i]-BB1_id. In der nächsten Zeile werden acc und die Konstante BB1_id zu der Überprüfungs-Einheit gesendet, die überprüft, ob die Summe beider Werte gleich dem erwarteten Wert s[i] ist. Die folgenden Zeilen passen acc für den nächsten Basis-Block an. Zeile 8 stellt sicher, dass acc den nächsten Überprüfungs-Wert s[i+1] enthält und Zeile 10 addiert BB1_id-BB2-BB2_id. Es ist anzumerken, dass dieser Wert zur Compilier-Zeit berechnet wird und daher zur Laufzeit konstant ist. Seine Addition entfernt die ID BB1_id des Blocks und führt stattdessen die ID BB2_id und Signatur BB2 des nächsten Blocks ein.
  • Bedingte Sprünge: Gemäß Ausführungsformen wird für bedingte Sprünge ein Überprüfen, dass das erreichte Sprung-Ziel der aktuellen Verzweigungs-Bedingung entspricht, bereitgestellt. Im Folgenden wird das folgende Beispiel betrachtet, in dem cond die Verzweigungs-Bedingung ist:
    Figure 00420001
  • Die codierte Version ist:
    Figure 00420002
  • In Zeile 4 wird acc verwendet zum Überprüfen der Berechnung der Bedingung condc mit dem bereits dargestellten Ansatz. Nach dem Senden von acc, wird acc in Zeile 8 für den Basis-Block bb_true angepasst und für ein Überprüfen, ob die ausgeführte Verzweigung der condc entspricht. Für das letztere wird A*1+Bcond subtrahiert, als der Wert, den condc hat, falls cond wahr (englisch: true) ist. Der in Zeile 8 addierte Wert ist eine zur Codier-Zeit bekannte Konstante. In Zeile 11 wird condc addiert. Falls die Bedingung wahr (true) ist, enthält acc nun die korrekte Block-Signatur und ID zu Beginn von bb_true. Falls sie falsch (englisch: false) ist, werden zusätzliche Korrekturen durchgeführt, welche in dem Basis-Block bb_false correction vor einem Sprung zu dem eigentlichen Ziel bb_false ausgeführt werden. Diese Korrekturen stellen sicher, dass, wenn in bb_false eingetreten wird, acc die Signatur und ID von bb_false enthält. Falls die Verzweigung (englisch: branch) in Zeile 12 nicht condc entspricht, wird acc nicht die erwartete Block-Signatur und -ID enthalten, und es wird ein falscher Überprüfungs-Wert an den Überprüfungs-Schaltkreis geschickt. Dadurch ist es gewünscht, dass BBfalse+BBfalse_id ≠ BBtrue+BBtrue_id, in anderen Worten, dass die Summe aus Signatur und ID für die Blöcke bb_true und bb_false verschieden ist.
  • Funktionsaufruf: Gemäß Ausführungsformen kann für einen Funktionsaufruf validiert werden, dass die richtige Funktion aufgerufen wird und dass sie mit den richtigen, unveränderten Parametern aufgerufen wird, und dass die Funktion richtig ausführt wird.
  • Um sicherzustellen, dass die richtige Funktion aufgerufen wird, kann gemäß Ausführungsformen jeder Funktion eine Funktions-Signatur zugeordnet werden, durch welche acc modifiziert werden soll. Bevor die Funktion zurückkehrt (also bevor sie beendet wird), passt sie acc für den verbleibenden Teil des aufrufenden Basis-Blocks minus dieser Funktions-Signatur an. Für nicht-void Funktionen (also für Funktionen mit Rückgabe-Wert) kann dem Rückgabe-Wert eine zusätzliche Signatur zugewiesen werden. Dies kann eine vorhersagbare Signatur für den Rückgabewert sicherstellen.
  • Um sicherzustellen, dass die Funktion mit den richtigen unmodifizierten Parametern aufgerufen wird, können gemäß Ausführungsformen die erwarteten Signaturen der Parameter, die beispielsweise zur Codier-Zeit bekannt und daher konstant sein können, zu acc addiert werden vor dem Aufrufen der Funktion. In der Funktion können die Signaturen der tatsächlich benutzten Parameter (die beispielsweise zur Laufzeit berechnet werden) abgezogen werden. Falls sie nicht übereinstimmen, wird acc ungültig werden. Danach können die Signaturen der Parameter korrigiert werden auf funktions-spezifische Signaturen, welche unabhängig sind von der Aufruf-Stelle. Dadurch können statisch berechnete Korrektur-Werte verwendet werden, welche von der Aufruf-Stelle abhängen und so als konstante Funktions-Parameter gegeben sein können.
  • Um sicherzustellen, dass die Funktion richtig ausgeführt wird, kann gemäß Ausführungsformen vor dem Start der Ausführung der Funktion acc angepasst werden. Die verbleibende Signatur und ID des Basis-Blocks, welche die Aufruf-Stelle enthält, kann entfernt werden und die Signatur und ID des ersten Basis-Blocks der Funktion kann addiert werden. Der verwendete Korrektur-Wert kann ermittelt werden zur Codier-Zeit und bereitgestellt werden als konstanter Funktions-Parameter. Danach kann die Ausführung wie oben beschrieben fortgesetzt werden und die Basis-Blöcke der aufgerufenen Funktion ausgeführt und überprüft werden.
  • Gemäß Ausführungsformen kann ein Überprüfungs-Schaltkreis (Watchdog) verwendet werden zum Überprüfen der korrekten Ausführung des codierten Programms während seiner Laufzeit. Er kann außerhalb des codierten Programms angeordnet sein, also beispielsweise kein Teil des codierten Programms sein. Gemäß Ausführungsformen kann der Überprüfungs-Schaltkreis zuverlässig außerhalb des codierten Programms ausgeführt werden.
  • Um die Ausführung zu überprüfen, kann gemäß Ausführungsformen der Überprüfungs-Schaltkreis überprüfen, ob die Summe der empfangenen Werte acc und Basis-Block ID gleich s[i] ist. Falls der Überprüfungs-Schaltkreis ein unerwartetes s[i] ermittelt oder die Anwendung aufhört, Werte zu senden (was mittels eines Zeitlimits (englisch: timeout) ermittelt werden kann), kann der Überprüfungs-Schaltkreis die Anwendung beenden. Wenn das Ende von s erreicht ist, können sowohl die Anwendung als auch der Überprüfungs-Schaltkreis wieder mit dem Anfang von s beginnen durch Setzen von i auf den Wert 0. Gemäß Ausführungsformen kann der Überprüfungs-Schaltkreis über s iterieren, periodische Vergleiche mit den empfangen Überprüfungswerten durchführen und testen, ob die Applikation noch am Leben ist (also beispielsweise noch läuft). Gemäß Ausführungsformen kann die einfache Implementierung die Anwendung von verschiedenen Mechanismen unterstützen um ihre Ausführung sicher zu machen, beispielsweise redundante Ausführung auf verschiedener Hardware wie beispielsweise onboard FPGAs (onboard Field Programmable Gate Array; deutsch: Feld-Programmierbare-Gatter-Anordnung auf der Hauptplatine) oder Grafikeinheiten, oder hand-codieren gemäß VCP. Zusätzlich können gemäß Ausführungsformen mehrere Überprüfungs-Schaltkreise parallel bereitgestellt werden, um das Risiko eines fehlerhaften Überprüfungs-Schaltkreises weiter zu reduzieren.
  • Gemäß Ausführungsformen können in Registern gespeicherte Werte, bei denen statische Signaturen, die zur Codier-Zeit bekannt sind, bereitgestellt werden. Gemäß Ausführungsformen können dynamische Speicher-Zugriffs-Muster zur Codier-Zeit nicht vorhergesagt werden, und es können dynamische Signaturen, die zur Laufzeit berechnet werden, für im Speicher gespeicherte Werte verwendet werden. Wenn ein Wert gespeichert wird, kann seine statische Signatur in eine dynamische Signatur, die von der Adresse, an der der Wert gespeichert wird, abhängen kann, konvertiert werden. Wenn der Wert aus dem Speicher geladen wird, kann die dynamische Signatur zurück in eine statische Signatur, die von der Lade-Instruktion abhängt, konvertiert werden. Diese Änderungen können auch codiert werden.
  • Gemäß Ausführungsformen kann die für Speicher mit Versionen verwendete dynamische Signatur zusätzlich von der Anzahl von zuvor von der Anwendung ausgeführten Speicherungen abhängen (beispielsweise in Form einer Versionszählers version). Der verwendete Versions-Zähler kann codiert sein, beispielsweise dadurch, dass er acc ändern kann. Für ein Laden kann die erwartete dynamische Signatur und Version entfernt werden und sie können durch die statische Signatur des Ziel-Registers ersetzt werden. Diese Änderungen und die Signatur-Verwaltung können codiert werden. Die folgende Anweisungs-Liste zeigt eine ANBDmem-codierte Lade-Operation. Die ANB-codierte Version kann ähnlich aussehen, aber nicht die Versions-Entfernung in Zeile 5 enthalten. Die getVersion-Funktion kann die erwartete Version für eine gegebene Adresse zurückgeben. Sie kann auch codiert sein. Die Implementierung der codierten Versions-Verwaltung kann gemäß einem als solchen bekannten Verfahren erfolgen. Versions-Verwaltung mit Schnappschuss kann verwendet werden und kann gute Ergebnisse für Anwendungen mit hoher und niedriger Daten-Lokalität bereitstellen.
  • Figure 00460001
  • Wie im obigen Code gezeigt, kann Laden einen codierten Zeiger ptrc, die erwartete Signatur Bptr von ptrc, und einen Korrektur-Wert corr als Eingabe haben. Während Codierens kann der Wert Br < A für die Signatur des Ergebnisses gewählt werden. Da Bptr und A auch zur Codier-Zeit gewählt werden können, ist für jeden Aufruf des Ladens corr=A*Br+Bptr auch zur Laufzeit konstant. Falls eine falsche oder veraltete Adresse gelesen wird, wird der Rückgabe-Wert in Zeile 7 nicht die erwartete Signatur Br haben. Gemäß Ausführungsformen kann ein Speicher ähnlich implementiert werden.
  • 8 zeigt eine Datenverarbeitungsanordnung 800 gemäß einem Ausführungsbeispiel der Erfindung. Quellcode 802 kann einem Compiler 804 (beispielsweise einem Software-Codier-Compiler) zugeführt werden. Der Compiler 804 kann dann eine sichere Programmvariante 806 und erwartete Signaturen 820 erzeugen. Durch Übersetzen, beispielsweise einschließlich Linken, wird die Sichere Programmvariante 806 in ein ausführbares codiertes Programm 808 überführt, das beispielsweise auf Standard-Hardware und einem Standard-Betriebssystem 812 ausgeführt werden kann. Es kann eine codierte Ausführung 810 des ausführbaren codierten Programms 808 stattfinden. Ausgabewerte 814 des ausführbaren codierten Programms 808 können durch einen sicheren Watchdog (anders ausgedrückt einem sicheren Überprüfungs-Schaltkreis 818) verifiziert werden, dargestellt durch Pfeil und Kreis 822. Die Verifikation kann ausgeführt werden dadurch, dass die codierte Ausführung 810 akkumulierte Signaturen 816 an den sicheren Watchdog 818 sendet, und dieser die akkumulierten Signaturen 816 vergleicht mit den erwarteten Signaturen 820.
  • Stimmen die akkumulierten Signaturen nicht mit den erwarteten Signaturen überein, kann der Watchdog die Ausführung des gesicherten Programmes abbrechen.
  • Ausgaben können auch direkt durch den Watchdog laufen. Dazu müssen die codierten Ausgaben mit dem aktuellen Akkumulatorwert an den Überprüfungs-Schaltkreis gesendet werden. Der Überprüfungs-Schaltkreis prüft nun den Akkumulatorwert gegen die Referenz-Zahlen und die codierten Ausgaben. Wenn diese Werte die Prüfung bestanden haben, decodiert der Überprüfungs-Schaltkreis die Ausgaben und gibt diese decodierten Ausgaben aus.
  • Im folgenden werden Auswertungen von Verfahren und Datenverarbeitungsanordnungen gemäß Ausführungsformen unter Verwendung der folgenden Anwendungen beschrieben: md5 berechnet den md5-Hash einer Zeichenkette (englisch: string), tcas ist eine Implementierung mit öffentlichem Quellcode (englisch: open source) des Verkehrs-Warn- und Kollisions-Vermeidungs-System, welches für Flugzeuge vorgeschrieben ist, pids ist ein Proportional-Integral-Differential-Regler, abs implementiert ein Antiblockier-Brems-System, und primes implementiert das Sieb des Eratosthenes.
  • 9 zeigt ein Diagramm 900 zum Rechenzeitvergleich von Verfahren gemäß einem Ausführungsbeispiel der Erfindung. Über der Hochachse 904 sind die Werte der Verlangsamung der codierten Anwendungen über einen native (in anderen Worten: nicht-codierte), ungesicherte Anwendung gegeben. Wie in Legende 902 gezeigt, sind Werte für AN-, ANB-, und ANBDmem-Codes angegeben. Zur Erstellung des Diagramms wurde die Zeit für die gesamte Anwendung einschließlich Ein-/Ausgabe-Operationen gemessen. In 906 sind die Ergebnisse für pid dargestellt. In 908 sind die Ergebnisse für tcas dargestellt. In 910 sind die Ergebnisse für md5 dargestellt. In 912 sind die Ergebnisse für primes dargestellt. In 914 sind die Ergebnisse für abs dargestellt.
  • Für den AN-Code liegen die Verlangsamungen im Bereich von Faktor 2 (primes) bis 75 (tcas), mit anderen Worten, die Ausführung mit AN-Code dauert z. B. bei primes etwa doppelt so lange wie für den nativen Code, bei tcas etwa 75 mal so lange. Anwendungen, die teurer codierte Operationen wie Multiplikationen oder Fließkomma-Operationen verwenden, zeigen größere Verlangsamungen. Dies kann zu diesen stark variierenden Verlangsamungen führen. Beispielsweise enthält md5 eine überdurchschnittliche Anzahl von bitweise logischen Operationen, welche, in ihrer codierten Version, extensive Verwendung von teuer codierten Multiplikationen machen. Die codierte Version von tcas kann viel langsamer sein wegen der extensiven Verwendung von Fließkomma-Operationen.
  • Der ANB-Code kann im Durchschnitt 1.9 mal langsamer sein als der AN-Code, weil er codierten Kontroll- und Daten-Fluss bereitstellt und die verwendeten codierten Operationen ebenfalls die Signaturen berücksichtigen müssen.
  • Die Verlangsamung des ANBDmem-Codes verglichen mit dem ANB-Code kann im Durchschnitt 2.6 sein. Der Hauptgrund kann der zusätzlich benötigte Overhead zum sicheren Speichern und Empfangen von Versions-Information für dynamischen Speicher sein. Dieser Overhead kann abhängen von dem Grad der Lokalität der ausgeführten Speicher-Zugriffe.
  • 10 zeigt ein Diagramm 1000 zum Rechenzeitvergleich von Verfahren gemäß einem Ausführungsbeispiel der Erfindung. Es zeigt den Geschwindigkeitszuwachs (als Faktor) auf einer logarithmischen Achse 1012 von CBE gemäß Ausführungsformen verglichen mit SEP. In 1002 sind die Ergebnisse für primes dargestellt. In 1004 sind die Ergebnisse für md5 dargestellt. In 1006 sind die Ergebnisse für pid dargestellt. In 1008 sind die Ergebnisse für bubblesort dargestellt. In 1010 sind die Ergebnisse für quicksort dargestellt. Diagramm 1000 vergleicht für diese Anwendungen den Geschwindigkeitszuwachs der teuersten CBE-Variante (ANBDmem) gemäß Ausführungsformen mit SEP. tcas und abs werden von SEP nicht unterstützt aufgrund fehlender System-Aufrufe. CBE übertrifft immer klar die Leistung von SEP. Es kann beobachtet werden, dass die erhaltenen Geschwindigkeitszuwächse von dem ausgeführten Programm abhängen. Beispielsweise hat md5 kleinere Geschwindigkeitszuwächse. md5 enthält eine überdurchschnittliche Anzahl von bitweisen logischen Operationen. Jedoch ist SEP unvollständig, beispielsweise unterstützt es keine codierte Version von bitweisen logischen Operationen, Schiebe-Operationen und Typumwandlungen. Diese Operationen wird in SEP uncodiert ausgeführt, während sie in CBE gemäß Ausführungsformen codiert sind.
  • Zur Auswertung der Fehler-Erkennungs-Möglichkeiten von codierten Programmen gemäß Ausführungsformen wurde ein als solches bekannter Fehler-Injektor EIS verwendet. Er injiziert die Software-Ebenen-Symptome von möglichen Hardware-Fehlern. Es wurden die folgenden Symptome injiziert: ausgetauschte Operanden, ausgetauschte Operatoren, fehlerhafte Operationen, modifizierte Operanden, und verlorene Speicherungen. Weitere Fehler können durch Kombinationen dieser Symptome repräsentiert werden.
  • Diese Fehler wurden in drei verschiedenen Modi angewendet:
    Im deterministischen Modus (Det) wurde exakt ein Fehler pro Lauf injiziert. Es wurden ungefähr 50,000 Läufe für jede Beispielanwendung (englisch: benchmark) und Schutz-Mechanismus durchgeführt (10,000 für jedes Symptom). In jedem Lauf wurde ein anderer Fehler angetriggert. Dies testet die Möglichkeit eines Detektions-Mechanismus mit selten auftretenden Fehlern zurechtzukommen.
  • Im probabilistischen Modus (Prob) wurde ein Fehler mit einer vorgegebenen Wahrscheinlichkeit injiziert. Die gleiche Fehlerwahrscheinlichkeit wurde für alle ausgewerteten Detektions-Mechanismen verwendet. Zu jedem möglichen Punkt, an dem ein Fehler (wenn eines der Symptome vorlag) angetriggert werden konnte, wird ein Fehler mit der gegebenen Wahrscheinlichkeit injiziert. So konnte eine Ausführung von mehreren verschiedenen Fehlern getroffen werden. Mit diesem Modus wurden 6,000 Läufe für jede Beispielanwendung und pro Detektions-Mechanismus durchgeführt.
  • Im Permanent-Fehler-Modus (Per) wurden permanent fehlerhafte Operations-Fehler, die permanente Logik-Fehler in dem Prozessor simulieren, injiziert. Permanente Fehler wurden nur auf arithmetische Ganzzahl-Operationen angewendet, und auf Laden und Speichern von Ganzzahl-Werten. Es wurden ungefähr 1,700 permanente Fehler pro Beispielanwendung pro Detektions-Mechanismus injiziert, mit jeweils nur einem Fehler pro Lauf.
  • Alle Beispiel-Anwendungen sind von ähnlicher Größe, und die Injektionen wurden gleichmäßig über die Programm-Ausführung verteilt. Dadurch können mit einer festen Anzahl von Fehler-Injektions-Läufen ähnliche Abdeckungen aller Anwendungen erreicht werden. Die Anzahl der Fehler-Injektions-Läufe wurde so gewählt, dass die Experimente in einer praktikablen Zeit abgeschlossen werden konnten.
  • Die Ergebnisse der Injektions-Läufe wurden mit den Ergebnissen eines fehlerfreien Laufs verglichen, um zu ermitteln, ob der injizierte Fehler zu einem SDC geführt hat, d. h. zu einem Versagen der Fehler-Erkennung, zu einem Abbruch oder einer korrekten Ausgabe, d. h. ob der Fehler maskiert wurde.
  • 11 zeigt eine Mehrzahl 1100 von Diagrammen zum Rechenzeitvergleich von Verfahren gemäß einem Ausführungsbeispiel der Erfindung. Es sind die Anzahl von SDCs als Ergebnisse für das Experiment aller oben beschriebenen Fehler-Injektions-Läufe dargestellt. In 1102 sind die Ergebnisse für abs dargestellt. In 1104 sind die Ergebnisse für primes dargestellt. In 1106 sind die Ergebnisse für tcas dargestellt. In 1108 sind die Ergebnisse für md5 dargestellt. In 1110 sind die Ergebnisse für pid dargestellt. Die Anzahl von SDCs ist für die Auswertung so relevant, weil sie ein Versagen der Fehler-Erkennung identifizieren. Es ist anzumerken, dass die Diagramme 1100 in logarithmischer Skala dargestellt sind.
  • Aus den Diagrammen 1100 können die folgenden Beobachtungen gemacht werden: Im Gegensatz zu nativen, d. h. ungeschützten, Programmen, reduzieren die AN-codierten Versionen dramatisch die Anzahl von SDCs, d. h. unerkannten Fehlern. Jedoch haben die AN-codierten Versionen immer noch eine beträchtliche Anzahl von SDCs: im Durchschnitt 0.96%. Die höchste Rate von unerkannten Fehlern ist 7.6% für abs und det. ANB-Codierung kann die Anzahl von unerkannten Fehlern auf durchschnittlich 0.07% senken. ANBDmem-Codierung wiederum kann die Rate auf etwa 0.03% SDCs halbieren.
  • Im Gegensatz zu ungeschützten Anwendungen ist keine der codierten Versionen – unabhängig vom verwendeten Code – verwundbar durch permanente Fehler. Probabilistisch (Prob) injizierte Fehler werden ebenfalls öfter detektiert. Der Grund dafür ist, dass Programme beider Injektions-Modi öfter von mehreren Fehlern getroffen werden. Dies kann die Wahrscheinlichkeit einer Detektion erhöhen.
  • Um den Effekt von ANB und ANBDmem-Code über AN-Code zu zeigen, kann der Overhead mit der Erkennungs-Rate verglichen werden. Im Durchschnitt hat der ANB-Code eine ungefähr 14 mal höhere Fehler-Erkennungs-Rate als der AN-Code, während die Verlangsamung nur um das 1.9fach zunimmt. Der ANBDmem-Code hat eine ungefähr 32 mal höhere Erkennungs-Rate als der AN-Code, zu Kosten von etwa 5-fach höherer Verlangsamung. Sowohl der ANB- als auch der ANBDmem-Code kann die jeweils längere Rechenzeit mit einer überproportional höheren Erkennungsrate kompensieren.
  • Kontrollfluss-Überprüfung, welche in Hardware oder Software implementiert werden kann, stellt Mittel bereit zum Erkennung ungültigen Kontrollflusses für das ausgeführte Programm, d. h. Ausführung von Sequenzen von Instruktionen, die nicht erlaubt sind für das ausgeführte Binär-Programm. Im Gegensatz zu Codierung erkennt Kontrollfluss-Überprüfung nicht Fehler, die nur die verarbeiteten Daten beeinflussen. Kontrollfluss-Überprüfung kann nur durchgeführt werden für Inter-Basis-Block-Kontrollfluss. Gemäß Ausführungsformen können ANB- und ANBDmem-codierte Programme auf der Instruktions-Ebene überprüft werden.
  • Algorithmus-basierte Fehler-Toleranz und selbstüberprüfende Software nutzt Invarianten zum Überprüfen der Validität der erzeugten Ergebnisse. Es existieren oft keine passenden Invarianten, die eine gute Fehler-Erkennungs-Möglichkeit bereitstellen.
  • Andere Software-Ansätze arbeiten mit replizierter Ausführung und Vergleich (und Abstimmung) über die erhaltenen Ergebnisse arbeiten. Die geschützte Software wird während oder vor dem Compilieren geändert. Es wird dynamische Binär-Instrumentierung verwendet. Replikation wird auf verschiedene Ebenen der Abstraktion angewendet. Einige Ansätze duplizieren einzelne Instruktionen innerhalb eines Ausführungsstranges. Andere verwenden Duplikate des ganzen Programms unter Verwendung mehrerer Ausführungsstränge.
  • Anstelle von oder zusätzlich zu Duplikation werden arithmetische Codes verwendet, um Fehler zu erkennen. Das Programm und die verarbeiteten Daten werden verändert.
  • VCP und SEP verwenden beide ANBD-Code.
  • Gemäß Ausführungsformen kann Compiler-Basiertes Codieren (englisch: Compiler Based Encoding; CBE) bereitgestellt werden. Es kann Kontrollfluss-Codierung unter Verwendung von arithmetischen Codes mit Signaturen, beispielsweise ANB-Codes, ANBD-Codes, ANBDmem-Codes, Residuum-Codes, und/oder Berger-Codes, bereitgestellt werden.
  • Experimente haben gezeigt, dass diese zwei Codierungen die Anzahl von unerkannten Ausführungsfehlern weiter reduzieren können als AN-Codierung. Die Reduktion der SDCs (unerkannte Fehler) ist höher als die Erhöhung der Laufzeit, die für den fortgeschrittenen Schutz von ANB- und ANBDmem-Codierung in Kauf genommen werden kann. So können Sicherheits-Ingenieure die Fehler-Erkennungs-Abdeckung und den Leistungs-Overhead durch Wählen eines geeigneten arithmetischen Codierens gegeneinander abwägen.
  • Durchschnittlich können ANBDmem-codierte Anwendungen 108 mal schneller sein als ihre SEP-Version. Ferner kann CBE kompletter sein als SEP. Im Gegensatz zu CBE kann SEP nicht das Codieren von bitweise logischen Operationen, Typumwandlung, Schiebe-Operationen und Fließkomma-Operationen unterstützen.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • DE 10219501 B4 [0003]

Claims (25)

  1. Verfahren zur Datenverarbeitung zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, aufweisend: • Ermitteln eines Zahlenwertes basierend auf einer von einem Überprüfungs-Schaltkreis außerhalb des Programmes ermittelten Mehrzahl von Referenz-Zahlen; • Ermitteln einer Signatur mindestens einer Anweisung des Programmes mittels eines arithmetischen Codes; • Aktualisieren eines Akkumulator-Wertes basierend auf dem Zahlenwert und der Signatur; und • Übermitteln des aktualisierten Akkumulator-Wertes an den Überprüfungs-Schaltkreis zum Ermitteln, ob bei der Ausführung des Programms ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert.
  2. Verfahren gemäß Anspruch 1, wobei der arithmetische Code ein arithmetischer Code mit Signaturen ist.
  3. Verfahren gemäß Anspruch 1 oder 2, wobei der arithmetische Code aufweist mindestens einen Code aus einer Gruppe von Codes bestehend aus: • einem AN-Code; • einem ANB-Code; • einem ANBD-Code; • einem ANBDmem-Code; • einem Residuum-Code; und • einem Berger-Code.
  4. Verfahren gemäß einem der Ansprüche 1 bis 3, wobei die Mehrzahl von Referenz-Zahlen eine Mehrzahl von vorgegebenen Zufallszahlen ist.
  5. Verfahren gemäß einem der Ansprüche 1 bis 4, wobei der Zahlenwert eine Differenz zweier Referenz-Zahlen ist.
  6. Verfahren gemäß einem der Ansprüche 1 bis 5, wobei der Akkumulator-Wert aktualisiert wird basierend auf einer Subtraktion einer Signatur eines Basis-Blocks des Programms, und jeweils einer Addition der Signatur des Nachfolger-Basis-Blocks.
  7. Verfahren gemäß einem der Ansprüche 1 bis 6, wobei der Akkumulator-Wert aktualisiert wird basierend auf einer Addition des Zahlenwertes.
  8. Verfahren gemäß einem der Ansprüche 1 bis 7, ferner aufweisend: Ermitteln eines Identifikators eines Basis-Blocks des Programms.
  9. Verfahren gemäß Anspruch 8, wobei der Akkumulator-Wert aktualisiert wird ferner basierend auf dem Identifikator des Blocks.
  10. Verfahren gemäß einem der Ansprüche 1 bis 9, wobei ermittelt wird, ob ein Fehler aufgetreten ist, basierend auf einer Überprüfung, ob der übermittelte Akkumulator-Wert der Differenz zweier Referenz-Zahlen entspricht.
  11. Verfahren gemäß einem der Ansprüche 1 bis 10, wobei der Überprüfungs-Schaltkreis in sicherer Hardware implementiert ist.
  12. Verfahren zur Datenverarbeitung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, aufweisend: • Ermitteln einer Mehrzahl von Referenz-Zahlen in einem Überprüfungs-Schaltkreis außerhalb des Programmes; • Empfangen eines in einem Programm basierend auf der Mehrzahl von Referenz-Zahlen und einer mittels eines arithmetischen Codes ermittelten Signatur mindestens einer Anweisung des Programmes erzeugten Akkumulator-Wertes von einem Programm in dem Überprüfungs-Schaltkreis; und • Ermitteln in dem Überprüfungs-Schaltkreis, ob bei der Ausführung des Programms ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert.
  13. Verfahren gemäß Anspruch 12, wobei der arithmetische Code ein arithmetischer Code mit Signaturen ist.
  14. Verfahren gemäß Anspruch 12 oder 13, wobei der arithmetische Code aufweist mindestens einen Code aus einer Gruppe von Codes bestehend aus: • einem AN-Code; • einem ANB-Code; • einem ANBD-Code; • einem ANBDmem-Code; • einem Residuum-Code; und • einem Berger-Code.
  15. Verfahren gemäß einem der Ansprüche 12 bis 14, wobei der Überprüfungs-Schaltkreis in sicherer Hardware implementiert ist.
  16. Verfahren gemäß einem der Ansprüche 12 bis 15, wobei der Überprüfungs-Schaltkreis durch Redundanz abgesichert ist.
  17. Verfahren gemäß einem der Ansprüche 12 bis 16, wobei der Überprüfungs-Schaltkreis durch arithmetische Codes abgesichert ist.
  18. Verfahren zum Erzeugen von Programm-Code zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, aufweisend: • Ermitteln einer Mehrzahl von Referenz-Zahlen; • Ermitteln einer Signatur mindestens einer Anweisung eines Programmes mittels eines arithmetischen Codes; • Erzeugen eines Programm-Code-Abschnittes zum Aktualisieren eines Akkumulator-Wertes basierend auf der Mehrzahl von Referenz-Zahlen und der Signatur; und • Erzeugen eines Programm-Code-Abschnittes zum Übermitteln des aktualisierten Akkumulator-Wertes an einen Überprüfungs-Schaltkreis außerhalb des Programmes-Codes zum Ermitteln, ob bei einer Ausführung des Programm-Codes ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert.
  19. Verfahren gemäß Anspruch 18, wobei der arithmetische Code ein arithmetischer Code mit Signaturen ist.
  20. Verfahren gemäß Anspruch 18 oder 19, wobei der arithmetische Code aufweist mindestens einen Code aus einer Gruppe von Codes bestehend aus: • einem AN-Code; • einem ANB-Code; • einem ANBD-Code; • einem ANBDmem-Code; • einem Residuum-Code; und • einem Berger-Code.
  21. Datenverarbeitungsanordnung zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, aufweisend: • einen Zahlenwert-Ermittlungs-Schaltkreis, der eingerichtet ist zum Ermitteln eines Zahlenwertes basierend auf einer von einem Überprüfungs-Schaltkreis außerhalb des Programmes ermittelten Mehrzahl von Referenz-Zahlen; • einen Signatur-Ermittlungs-Schaltkreis, der eingerichtet ist zum Ermitteln einer Signatur mindestens einer Anweisung des Programmes mittels eines arithmetischen Codes; • einen Aktualisierungs-Schaltkreis, der eingerichtet ist zum Aktualisieren eines Akkumulator-Wertes basierend auf dem Zahlenwert und der Signatur; und • eine Übermittlungs-Schaltkreis, der eingerichtet ist zum Übermitteln des aktualisierten Akkumulator-Wertes an den Überprüfungs-Schaltkreis zum Ermitteln, ob bei der Ausführung des Programms ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert.
  22. Datenverarbeitungsanordnung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, aufweisend: • einen Referenz-Zahlen-Ermittlungs-Schaltkreis, der eingerichtet ist zum Ermitteln einer Mehrzahl von Referenz-Zahlen in einem Überprüfungs-Schaltkreis außerhalb des Programmes; • einen Empfangs-Schaltkreis, der eingerichtet ist zum Empfangen eines in einem Programm basierend auf der Mehrzahl von Referenz-Zahlen und einer mittels eines arithmetischen Codes ermittelten Signatur mindestens einer Anweisung des Programmes erzeugten Akkumulator-Wertes von einem Programm in dem Überprüfungs-Schaltkreis; und • einen Überprüfungs-Schaltkreis, der eingerichtet ist zum Ermitteln, ob bei der Ausführung des Programms ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert.
  23. Datenverarbeitungsanordnung zum Erzeugen von Programm-Code zum Bereitstellen eines Wertes zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist, aufweisend: • einen Referenz-Zahlen-Ermittlungs-Schaltkreis, der eingerichtet ist zum Ermitteln einer Mehrzahl von Referenz-Zahlen; • einen Signatur-Ermittlungs-Schaltkreis, der eingerichtet ist zum Ermitteln einer Signatur mindestens einer Anweisung eines Programmes mittels eines arithmetischen Codes; • einen Aktualisierungs-Programm-Code-Abschnitt-Erzeugungs-Schaltkreis, der eingerichtet ist zum Erzeugen eines Programm-Code-Abschnittes zum Aktualisieren eines Akkumulator-Wertes basierend auf der Mehrzahl von Referenz-Zahlen und der Signatur; und • einen Übermittlungs-Programm-Code-Abschnitt-Erzeugungs-Schaltkreis, der eingerichtet ist zum Erzeugen eines Programm-Code-Abschnittes zum Übermitteln des aktualisierten Akkumulator-Wertes an einen Überprüfungs-Schaltkreis außerhalb des Programmes-Codes zum Ermitteln, ob bei einer Ausführung des Programm-Codes ein Fehler aufgetreten ist, basierend auf der Mehrzahl von Referenz-Zahlen und dem Akkumulator-Wert.
  24. Computerprogrammelement, das, wenn es von einem Prozessor ausgeführt wird, bewirkt, dass der Prozessor ein Verfahren zur Datenverarbeitung gemäß einem der Ansprüche 1 bis 20 ausführt.
  25. Verfahren zur Kommunikation zweier mittels arithmetischer Codes codierter Programme, wobei die beiden Programme Werte austauschen, die mittels gleichen arithmetischer Codes codiert sind.
DE102010037457A 2010-09-10 2010-09-10 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 Active DE102010037457B4 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE102010037457A DE102010037457B4 (de) 2010-09-10 2010-09-10 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
US13/821,837 US9304872B2 (en) 2010-09-10 2011-09-09 Method for providing a value for determining whether an error has occurred in the execution of a program
EP11767393.9A EP2614438A1 (de) 2010-09-10 2011-09-09 Verfahren zum bereitstellen eines wertes zum ermitteln, ob bei einer ausführung eines programms ein fehler aufgetreten ist
PCT/EP2011/065606 WO2012032140A1 (de) 2010-09-10 2011-09-09 Verfahren zum bereitstellen eines wertes zum ermitteln, ob bei einer ausführung eines programms ein fehler aufgetreten ist
KR1020137009176A KR20130105656A (ko) 2010-09-10 2011-09-09 프로그램의 실행시 오류의 발생 여부를 결정하는 값을 제공하는 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102010037457A DE102010037457B4 (de) 2010-09-10 2010-09-10 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

Publications (2)

Publication Number Publication Date
DE102010037457A1 true DE102010037457A1 (de) 2012-03-15
DE102010037457B4 DE102010037457B4 (de) 2012-06-21

Family

ID=44774036

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102010037457A Active DE102010037457B4 (de) 2010-09-10 2010-09-10 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

Country Status (5)

Country Link
US (1) US9304872B2 (de)
EP (1) EP2614438A1 (de)
KR (1) KR20130105656A (de)
DE (1) DE102010037457B4 (de)
WO (1) WO2012032140A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016087652A1 (de) * 2014-12-05 2016-06-09 Technische Universität Dresden Verfahren zur datenverarbeitung zum ermitteln, ob bei einer ausführung eines programms ein fehler aufgetreten ist, und datenverarbeitungsanordnungen zum erzeugen von programm-code
EP3975017A1 (de) * 2020-09-29 2022-03-30 Siemens Aktiengesellschaft Verfahren zur protokollierung einer vielzahl von ereignissen in einer codierten tracer-variablen in einem sicherheitsgerichteten computerprogramm
EP3975016A1 (de) * 2020-09-29 2022-03-30 Siemens Aktiengesellschaft Verfahren und einrichtung zur sicherung von zugriffen auf codierte variablen in einem computerprogramm
EP4300221A1 (de) * 2022-07-01 2024-01-03 Siemens Aktiengesellschaft Vorrichtung und verfahren zur steuerung einer prozessanlage sowie prozesssteuerungssystem

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2631802B1 (de) * 2012-02-22 2014-11-19 Siemens Aktiengesellschaft Verfahren zur Speicherung und Propagation von Fehlerinforationen in Computer-Programmen
EP2891981B1 (de) * 2014-01-06 2018-07-18 Fujitsu Limited Verfahren und Computersystem, Verfahren zur Injektion von Hardware-Fehlern in eine Ausführungsanwendung
JP6434840B2 (ja) * 2015-03-30 2018-12-05 日立オートモティブシステムズ株式会社 電子制御装置
EP3104276A1 (de) * 2015-06-09 2016-12-14 Siemens Aktiengesellschaft Verfahren in einem computersystem, computerprogramm und datenverarbeitungsanlage
US9842045B2 (en) * 2016-02-19 2017-12-12 International Business Machines Corporation Failure recovery testing framework for microservice-based applications
CH712732B1 (de) * 2016-07-21 2021-02-15 Supercomputing Systems Ag Computerisiertes System.
US10261891B2 (en) 2016-08-05 2019-04-16 International Business Machines Corporation Automated test input generation for integration testing of microservice-based web applications
EP3442124B1 (de) * 2017-08-07 2020-02-05 Siemens Aktiengesellschaft Verfahren zum schützen der daten in einem datenspeicher vor einer unerkannten veränderung und datenverarbeitungsanlage
EP3641137A1 (de) * 2018-10-19 2020-04-22 Siemens Aktiengesellschaft Verfahren und vorrichtung zum verarbeiten von daten
CN109683085B (zh) * 2019-01-17 2021-01-12 中国人民解放军陆军工程大学 一种电子细胞自检方法
US10831595B1 (en) * 2019-05-31 2020-11-10 International Business Machines Corporation Performing error detection during deterministic program execution

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007040721A1 (de) * 2006-12-08 2008-06-19 Technische Universität Dresden Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher
DE10219501B4 (de) 2002-04-30 2010-04-01 Siemens Ag System und Verfahren zur Verbesserung von Fehlerbeherrschungsmassnahmen, insbesondere in Automatisierungssystemen
DE102009037630A1 (de) * 2009-08-14 2011-02-17 Texas Instruments Deutschland Gmbh Elektronische Vorrichtung und Verfahren zur Überprüfung der korrekten Prgrammausführung

Family Cites Families (8)

* 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
US6594761B1 (en) * 1999-06-09 2003-07-15 Cloakware Corporation Tamper resistant software encoding
US6678837B1 (en) * 2000-06-30 2004-01-13 Intel Corporation Processor control flow monitoring using a signature table for soft error detection
US7506217B2 (en) * 2005-12-30 2009-03-17 Intel Corporation Apparatus and method for software-based control flow checking for soft error detection to improve microprocessor reliability
US8904189B1 (en) * 2010-07-15 2014-12-02 The Research Foundation For The State University Of New York System and method for validating program execution at run-time using control flow signatures
FR2977342A1 (fr) * 2011-06-30 2013-01-04 Proton World Int Nv Verification d'integrite d'un programme execute par un circuit electronique
US9118351B2 (en) * 2012-02-15 2015-08-25 Infineon Technologies Ag System and method for signature-based redundancy comparison
EP2631802B1 (de) * 2012-02-22 2014-11-19 Siemens Aktiengesellschaft Verfahren zur Speicherung und Propagation von Fehlerinforationen in Computer-Programmen

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10219501B4 (de) 2002-04-30 2010-04-01 Siemens Ag System und Verfahren zur Verbesserung von Fehlerbeherrschungsmassnahmen, insbesondere in Automatisierungssystemen
DE102007040721A1 (de) * 2006-12-08 2008-06-19 Technische Universität Dresden Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher
DE102009037630A1 (de) * 2009-08-14 2011-02-17 Texas Instruments Deutschland Gmbh Elektronische Vorrichtung und Verfahren zur Überprüfung der korrekten Prgrammausführung

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Yunsi Fei u. a: Microarchitectural Support for Program Code Integrity Monitoring in Application-specific Instruction Set Processors. Design, Automation Test in Europe Conference Exhibition, 2007. S. 1 - 6 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016087652A1 (de) * 2014-12-05 2016-06-09 Technische Universität Dresden Verfahren zur datenverarbeitung zum ermitteln, ob bei einer ausführung eines programms ein fehler aufgetreten ist, und datenverarbeitungsanordnungen zum erzeugen von programm-code
EP3975017A1 (de) * 2020-09-29 2022-03-30 Siemens Aktiengesellschaft Verfahren zur protokollierung einer vielzahl von ereignissen in einer codierten tracer-variablen in einem sicherheitsgerichteten computerprogramm
EP3975016A1 (de) * 2020-09-29 2022-03-30 Siemens Aktiengesellschaft Verfahren und einrichtung zur sicherung von zugriffen auf codierte variablen in einem computerprogramm
WO2022069153A1 (de) * 2020-09-29 2022-04-07 Siemens Aktiengesellschaft Verfahren und einrichtung zur sicherung von zugriffen auf codierte variablen in einem computerprogramm
WO2022069154A1 (de) * 2020-09-29 2022-04-07 Siemens Aktiengesellschaft Verfahren zur protokollierung einer vielzahl von ereignissen in einer codierten tracer-variablen in einem sicherheitsgerichteten computerprogramm
US11914456B2 (en) 2020-09-29 2024-02-27 Siemens Aktiengesellschaft Method and device for securing access to encoded variables in a computer program
EP4300221A1 (de) * 2022-07-01 2024-01-03 Siemens Aktiengesellschaft Vorrichtung und verfahren zur steuerung einer prozessanlage sowie prozesssteuerungssystem

Also Published As

Publication number Publication date
WO2012032140A1 (de) 2012-03-15
KR20130105656A (ko) 2013-09-25
US9304872B2 (en) 2016-04-05
DE102010037457B4 (de) 2012-06-21
EP2614438A1 (de) 2013-07-17
US20130262938A1 (en) 2013-10-03

Similar Documents

Publication Publication Date Title
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
DE69818978T2 (de) Verfahren um die gültigkeit der beschreibung einer ausführbaredatei zu identifizieren
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
DE102012212343A1 (de) Verteilter Kompilierungsprozess mit Befehlssignaturunterstützung
DE102011005209A1 (de) Programmanweisungsgesteuerte Instruktionsflusskontrolle
DE112016004678T5 (de) Verfahren zum Ausführen von Programmen in einem elektronischen System für Anwendungen mit funktionaler Sicherheit umfassend mehrere Prozessoren, entsprechendes System und Computerprogrammprodukt
DE102013213314A1 (de) Hinterlegen mindestens eines berechenbaren Integritätsmesswertes in einem Speicherbereich eines Speichers
DE102004011450A1 (de) Anvisierte Fehlertoleranz durch spezielle CPU-Befehle
EP2631802B1 (de) Verfahren zur Speicherung und Propagation von Fehlerinforationen in Computer-Programmen
DE102005054587A1 (de) Programmgesteuerte Einheit und Verfahren zum Betreiben derselbigen
DE102014114157B4 (de) Verfahren zur Datenverarbeitung zum Ermitteln, ob bei einer Ausführung eines Programms ein Fehler aufgetreten ist und Datenverarbeitungsanordnungen zum Erzeugen von Programm-Code
DE102007040721B4 (de) Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher
DE102005016051B4 (de) Speicherüberprüfungsvorrichtung und Verfahren zum Überprüfen eines Speichers
DE102006036384A1 (de) Mikroprozessorsystem zur Steuerung bzw. Regelung von zumindest zum Teil sicherheitskritischen Prozessen
EP1577734A2 (de) Verfahren zum sicheren Betrieb eines tragbaren Datenträgers
DE102004001651B4 (de) Verfahren und Prozessor zur automatischen Befehls-Betriebsartumschaltung zwischen N-Bit und 2N-Bit Befehlen unter Verwendung einer Paritätsüberprüfung
DE102014003665A1 (de) Instruktion zum durchführen einer überlastprüfung
EP3876123B1 (de) Anordnung und betriebsverfahren für einen sicheren hochfahrablauf einer elektronischen einrichtung
DE102018219700B4 (de) Steuervorrichtung
AT508649A2 (de) Chipkarte mit überwachung der integrität auf softwarebasis
DE102020216072A1 (de) Vorrichtung und Verfahren zum Bearbeiten von Bitfolgen
DE102022105535A1 (de) Vorrichtung, Verfahren und System in Bezug auf Datenspeicherungselemente
WO2022189214A1 (de) Verfahren zur bestimmung der integrität einer datenverarbeitung, vorrichtung, datenverarbeitungsanlage und anlage
DE102015200212A1 (de) Verfahren zum Erzeugen eines fehlertoleranten Zielcodes
DE102004006645A1 (de) Verfahren zum sicheren Berechnen einer Prüfsumme

Legal Events

Date Code Title Description
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R082 Change of representative

Representative=s name: VIERING, JENTSCHURA & PARTNER, DE

R020 Patent grant now final

Effective date: 20120922

R081 Change of applicant/patentee

Owner name: SILISTRA SYSTEMS GMBH, DE

Free format text: FORMER OWNER: TECHNISCHE UNIVERSITAET DRESDEN, 01069 DRESDEN, DE

Effective date: 20121204

R082 Change of representative

Representative=s name: VIERING, JENTSCHURA & PARTNER MBB PATENT- UND , DE

Effective date: 20121204

Representative=s name: VIERING, JENTSCHURA & PARTNER PATENT- UND RECH, DE

Effective date: 20121204

Representative=s name: VIERING, JENTSCHURA & PARTNER, DE

Effective date: 20121204

R082 Change of representative