[go: up one dir, main page]

DE102011006000B4 - Signaturaktualisierung durch Codetransformation - Google Patents

Signaturaktualisierung durch Codetransformation Download PDF

Info

Publication number
DE102011006000B4
DE102011006000B4 DE102011006000.6A DE102011006000A DE102011006000B4 DE 102011006000 B4 DE102011006000 B4 DE 102011006000B4 DE 102011006000 A DE102011006000 A DE 102011006000A DE 102011006000 B4 DE102011006000 B4 DE 102011006000B4
Authority
DE
Germany
Prior art keywords
program
instruction sequence
modification
signature
initial
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102011006000.6A
Other languages
English (en)
Other versions
DE102011006000A1 (de
Inventor
Dr. Mangard Stefan
Dr. Gammel Berndt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Infineon Technologies AG
Original Assignee
Infineon Technologies AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies AG filed Critical Infineon Technologies AG
Priority to DE102011006000.6A priority Critical patent/DE102011006000B4/de
Priority to FR1200807A priority patent/FR2973130B1/fr
Priority to CN201210080828.3A priority patent/CN102722422B/zh
Priority to US13/428,589 priority patent/US9323604B2/en
Publication of DE102011006000A1 publication Critical patent/DE102011006000A1/de
Application granted granted Critical
Publication of DE102011006000B4 publication Critical patent/DE102011006000B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; 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/10Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/28Error detection; Error correction; Monitoring by checking the correct order of processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Executing Machine-Instructions (AREA)
  • Storage Device Security (AREA)
  • Programmable Controllers (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Verfahren zur Erzeugung einer Instruktionsfolge (404') für eine Recheneinheit, die von einem zumindest die Instruktionsfolge umfassenden Programm gesteuert werden kann, wobei zur Laufzeit des Programms Signaturwerte (SIG'P2) als Instruktionssignaturen durch Aufsummieren der ausgeführten Instruktionen (I1', I2', In') in eine Prüfsumme berechnet und mit Referenzwerten verglichen werden, das Verfahren umfassend: Bestimmen eines Zielsignaturwerts (SIGP1) für eine Zielsignatur an einem Programmpunkt (P); Bestimmen einer initialen Instruktionsfolge (404) für einen zu dem Programmpunkt (P) führenden Programmabschnitt, Prüfen, ob das Ausführen der initialen Instruktionsfolge (404) ausgehend von einem Anfangssignaturwert die Berechnung eines initialen Signaturwerts (SIGP2) für die Zielsignatur zur Folge hätte, der von dem Zielsignaturwert (SIGP1) verschieden wäre; und falls der initiale Signaturwert (SIGP2) von dem Zielsignaturwert (SIGP1) verschieden wäre: Bestimmen einer Modifikation der initialen Instruktionsfolge (404) zur Erlangung einer modifizierten Instruktionsfolge (404'), so dass das Ausführen der modifizierten Instruktionsfolge (404') die Berechnung eines Signaturwerts (SIG'P2) zur Folge hat, der dem Zielsignaturwert (SIGP1) entspricht, und ein Ergebnis einer Verarbeitung von Nutzdaten durch die modifizierte Instruktionsfolge (404') einem Ergebnis einer Verarbeitung der Nutzdaten durch die initiale Instruktionsfolge (404) an dem Programmpunkt (P) entspricht, wobei alle Instruktionen der modifizierten Instruktionsfolge nach dem gleichen Verfahren in die Signaturberechnung eingehen.

Description

  • Ausführungsbeispiele der vorliegenden Erfindung schaffen ein Verfahren zur Erzeugung einer Instruktionsfolge für eine Recheneinheit, die von einem zumindest die Instruktionsfolge umfassenden Programm gesteuert werden kann. Ausführungsbeispiele der vorliegenden Erfindung schaffen weiterhin ein Verfahren zum Ausführen eines Programms auf einer programmgesteuerten Recheneinheit, wobei das Programm zumindest eine Instruktionsfolge umfasst, die von dem zuerst genannten Verfahren erzeugt wurde. Weitere Ausführungsbeispiele der vorliegenden Erfindung schaffen ein Computerprogramm mit einem Programmcode zur Durchführung des erstgenannten Verfahrens und einen Kompilierer zum Erstellen eines Computerprogramms, der das Verfahren zur Erzeugung einer Instruktionsfolge anwendet.
  • Das Grundprinzip von Instruktionssignaturen ist, zur Laufzeit eines Programms die ausgeführten Instruktionen in einer Prüfsumme (Signatur) aufzusummieren und an vorgegebenen Stellen gegen Referenzwerte zu prüfen. Kommt es im Programmflussgraph, der als grafische Abbildung des Programmablaufs angesehen werden, zu Verzweigungen, können Signaturaktualisierungen eingesetzt werden, um die Signaturen in zwei oder mehr parallelen Pfaden des Programmflussgraphen zu vereinheitlichen.
  • Wenn ein Programm (Software) auf einer Recheneinheit (Hardware) ausgeführt wird, so wird in der Regel erwartet, dass das Programm auch tatsächlich so ausgeführt wird, wie es vom Kompilierer zur Kompilierzeit vorgesehen war. In der Realität kann die Ausführung eines Programms bzw. eines Codes jedoch von dem ursprünglich geplanten Programmablauf abweichen. Verantwortlich hierfür sind beispielsweise Fehler in der Hardware, Störsignale oder auch gezielte, mutwillige Manipulationen an der Recheneinheit. Fehler in der Hardware können beispielsweise auf ungewollte Leitungskurzschlüsse, Leitungsunterbrechungen oder hängende Schaltelemente (sog. „stuck-at faults”) zurückgeführt werden, um einige häufig auftretende Arten von Hardwarefehlern zu nennen. Störsignale können während des Betriebs der Recheneinheit beispielsweise durch elektromagnetische Felder oder auch in Form von extremen Temperaturen, die außerhalb des für die Recheneinheit vorgesehenen Temperaturbereichs liegen, auftreten. Mutwillige Manipulationen der Hardware können beispielsweise durch Kurzschließen von ausgewählten Kontakten, Leitungsunterbrechungen oder Laserbestrahlung der Recheneinheit und/oder eines an die Recheneinheit angeschlossenen Speichers erfolgen. Die genannten Fehlerarten können beispielsweise innerhalb der Recheneinheit selbst, innerhalb eines Speichers, in dem das Programm gespeichert ist, innerhalb weiterer Komponenten eines Systems, welches die Recheneinheit umfasst, oder in elektrischen Verbindungen zwischen den Komponenten des Rechnersystems auftreten. Um derartige Fehler während der Ausführung des Programms zu detektieren, kann eine Instruktionsflusskontrolle durchgeführt werden.
  • Für die Zwecke der Instruktionsflusskontrolle wird in der Regel während der Programmerstellung ein Prüfwert (die Signatur) berechnet, der sich aus den Instruktionen des Programms an die Recheneinheit ergibt. Beispielsweise können die Operationscodes (Opcodes) der Instruktionen aufaddiert werden, um auf diese Weise eine Prüfsumme zu bilden. Bei einem linearen Programm, welches in der Regel vom Programmbeginn bis Programmende einschließlich aller dazwischenliegenden Instruktionen ausgeführt wird, kann somit eine einzige Prüfsumme (bzw. allgemeiner: Prüfwert) berechnet werden, die am Programmende oder nach dem Programmende geprüft werden kann. Für diese Überprüfung wird parallel zur Ausführung einer jeden Instruktion durch die Recheneinheit der Wert dieser Instruktion (beispielsweise in Form des als Bitmuster vorliegenden Opcodes) mit dem Inhalt eines speziellen Registers verrechnet, z. B. zu dem Registerinhalt addiert oder mit dem Registerinhalt bitweise Exklusiv-Oder (XOR) verknüpft. Sobald alle Instruktionswerte auf diese Weise in dem speziellen Register berücksichtigt wurden, kann der sich ergebende Wert des speziellen Registers mit einem Referenz-Prüfwert verglichen werden, um festzustellen, ob eine Übereinstimmung zwischen beiden Werten vorliegt. Sofern eine Übereinstimmung vorliegt, kann in der Regel von einer ordnungsgemäßen Ausführung des Programms ausgegangen werden, d. h. das Programm wurde tatsächlich so ausgeführt, wie es zum Zeitpunkt der Programmerstellung geplant war. Der Referenz-Prüfwert kann beispielsweise als Konstante im Programmcode abgelegt sein. Je nachdem, auf welche Weise und mit welcher Programmiersprache das Programm erstellt wurde, kann der Referenz-Prüfwert von einem Kompilierer („Compiler”) berechnet und in den Programmcode hineingeschrieben werden. Der wissenschaftlichen Artikel „Control Flow Checking by Software Signatures” von Nahmsuk Oh u. a. (Technical Report of the Center for Reliable Computing, Stanford University, CRC TR 00-04, Apr. 2000) beschreibt z. B. ein Software-Verfahren, das den Kontrollfluss eines Programms mittels zugewiesener Signaturen prüft. Der wissenschaftliche Artikel „Control Flow Monitoring for a Time-Triggered Communication Controller” von Thomas Galla u. a. (10th European Workshop an Dependable Computing (EWDC-10), Mai 1999) beschreibt z. B. ein Kontrollfluss-Überwachungsschema für die Architektur einer Protokollkontrolleinheit eines zeitgetriggerten Kommunikationssystems.
  • Häufig weisen Programme Verzweigungen im Programmfluss auf, die auch als „bedingte Sprünge” angesehen werden können. Nach einer Verzweigung kann das Programm auf zumindest zwei Pfaden fortgesetzt werden, wobei sich die Entscheidung darüber, welcher der zwei oder mehr möglichen Pfade gewählt wird, erst zur Laufzeit des Programms durch die Auswertung einer Bedingung ergibt. Man beachte, dass sich Verzweigungspunkte mit mehr als zwei möglichen Verzweigungspfaden in der Regel in elementare Verzweigungspunkte zerlegen lassen, d. h. in Verzweigungspunkte, die jeweils nur zwei mögliche Verzweigungspfade aufweisen. Für den Wert, der während der Laufzeit des Programms berechnet wird, bedeutet dies, dass er davon abhängt, welche Pfade wie oft durchlaufen wurden. Damit beispielsweise gegen Ende des Programms oder an einem anderen Punkt innerhalb des Programmablaufs ein Vergleich zwischen dem aktuellen Prüfwert und einem für diesen Punkt definierten Referenz-Prüfwert durchgeführt werden kann, besteht die Möglichkeit, den Prüfwert innerhalb der verschiedenen Pfade, die durchlaufen werden können, aneinander auszurichten. Dies kann in der Form erfolgen, dass der Kompilierer in einen Pfad eine oder mehrere für den Programmablauf an sich überflüssige Instruktion(en) einbaut, die den Prüfwert derart verändern, dass der besagte Pfad an einem Zusammenführungspunkt mit einem anderen Pfad den gleichen Prüfwert wie dieser andere Pfad hat. Typischerweise ist dabei vorgesehen, dass spezielle Aktualisierungen anhand bestimmter Bitmuster erkannt und aus dem normalen Instruktionsfluss herausgefiltert werden, um auf spezielle Weise zur Aktualisierung verwendet zu werden.
  • Die hierin offenbarte technische Lehre betrifft gemäß dem zuvor Gesagten ein Verfahren zur Durchführung von Impliziten Signaturaktualisierungen mittels Codetransformation für Instruktionssignaturverfahren.
  • Ausführungsbeispiele der hierin offenbarten technischen Lehre schaffen ein Verfahren zur Erzeugung einer Instruktionsfolge für eine Recheneinheit, die von einem zumindest die Instruktionsfolge umfassenden Programm gesteuert werden kann. Dabei werden zur Laufzeit des Programms z. B. durch ein Signaturmodul Signaturwerte als Instruktionssignaturen durch Aufsummieren der von der Recheneinheit ausgeführten Instruktionen in eine Prüfsumme berechnet und mit Referenzwerten verglichen werden. Das Verfahren umfasst: Bestimmen eines Zielsignaturwerts für eine Zielsignatur an einem Programmpunkt; Bestimmen einer initialen Instruktionsfolge für einen zu dem Programmpunkt führenden Programmabschnitt; Prüfen, ob das Ausführen der initialen Instruktionsfolge ausgehend von einem Anfangssignaturwert die Berechnung eines initialen Signaturwerts zur Folge hätte, der von dem Zielsignaturwert verschieden wäre; und, falls der initiale Signaturwert von dem Zielsignaturwert verschieden wäre: Bestimmen einer Modifikation der initialen Instruktionsfolge zur Erlangung einer modifizierten Instruktionsfolge. Durch das Bestimmen der modifizierten Instruktionsfolge wird erreicht, dass das Ausführen der modifizierten Instruktionsfolge die Berechnung des Zielsignaturwerts zur Folge hat. Ein Ergebnis einer Verarbeitung von Nutzdaten durch die modifizierte Instruktionsfolge entspricht einem Ergebnis einer Verarbeitung der Nutzdaten durch die initiale Instruktionsfolge an dem Programmpunkt, wobei alle Instruktionen der modifizierten Instruktionsfolge nach dem gleichen Verfahren in die Signaturberechnung eingehen.
  • Gemäß dem Verfahren nach der offenbarten technischen Lehre kann somit auf explizite Instruktionen zur Signaturaktualisierung verzichtet werden, da die Signaturaktualisierung inhärent von der modifizierten Instruktionsfolge durchgeführt wird. Im Zusammenhang mit einem Signaturmodul kann somit auf explizite Schreibzugriffe auf das Signaturregister des Signaturmoduls verzichtet werden, welche bei einigen Instruktionssignaturverfahren verwendet werden, um die Signatur in einem Programmpfad an die Signatur in einem parallelen Programmpfad anzugleichen. Die Signaturberechnung zur Laufzeit behandelt alle Instruktionen gleich, d. h. alle Instruktionen gehen nach dem gleichen Verfahren bzw. der gleichen Berechnungsvorschrift in die Signaturberechnung ein. Somit müssen die für die Signaturaktualisierung vorgesehenen Instruktionen zur Laufzeit nicht herausgefiltert werden. Ohnehin übernehmen zumindest einige Instruktionen der modifizierten Instruktionsfolge eine Doppelfunktion, nämlich die Verarbeitung der Nutzdaten und die Aktualisierung der Signatur in der vorgesehenen Weise, so dass für diese Instruktionen keine Unterscheidung nach normalen Instruktionen und Aktualisierungsinstruktionen sinnvoll wäre. Explizite Instruktionen zur Signaturaktualisierung sind gemäß der hierin offenbarten Lehre nicht notwendig, obwohl diese nichtsdestotrotz weiterhin möglich sind.
  • Die vorgeschlagene Art der Signaturaktualisierung unterscheidet sich somit von anderen Methoden der Signaturaktualisierung, bei denen ein Aktualisierungsbefehl auf andere Weise in die Signaturberechnung eingeht, z. B. durch explizites Addieren eines bestimmten Werts zu dem gegenwärtigen Signaturwert. Zu diesem Zweck weisen Signaturmodule, die derartige andere Methoden der Signaturaktualisierung unterstützen, typischerweise zumindest zwei Schnittstellen auf: Über eine erste Schnittstelle werden dem Signaturmodul die Operationscodes von normalen Instruktionen zugeführt, die somit in die normale Signaturberechnung eingehen. Über eine zweite Schnittstelle werden die expliziten Aktualisierungsanweisungen an das Signaturmodul übermittelt. Diese expliziten Aktualisierungsanweisungen werden typischerweise nicht mit in die Hashsumme eingerechnet, gehen also nicht in die normale Signaturberechnung ein. Gemäß der offenbarten technischen Lehre muss ein Signaturmodul die zweite Schnittstelle nicht unbedingt aufweisen. Ebenso ist es nicht erforderlich, dass das Signaturmodul zwischen „normalen” Instruktionen und Aktualisierungsinstruktionen unterscheidet.
  • Gemäß der offenbarten Lehre können z. B. alle Instruktionen oder Werte im Rahmen einer Hashwertberechnung berücksichtigt („mitgehasht”) werden oder ein ganzer Befehl wird addiert (anstelle nur des Arguments, das in einem Additionsbefehl spezifiziert ist).
  • Der Anfangssignaturwert ist einem Punkt am Anfang oder vor der Instruktionsfolge zugeordnet. Durch die Signaturberechnung wird dieser Anfangssignaturwert umgeformt zu einem Endsignaturwert, der einem Punkt am Ende der Instruktionsfolge oder einem Punkt nach dieser zugeordnet ist. Der initiale Signaturwert ist der Wert am Ende der initialen Instruktionsfolge (oder an einem Punkt danach), der sich aus der initialen Instruktionsfolge ergibt. Der Zielsignaturwert ist der Wert am Ende der modifizierten Instruktionsfolge.
  • Das Modifizieren der Instruktionsfolge kann z. B. auch darin bestehen, dass nicht benutzte Bits in einem Befehl geändert werden, um die Signatur zu ändern. Auf diese Weise können gezielt Bits in der Signatur geändert werden.
  • In Ausführungsbeispielen kann das Bestimmen der Modifikation eine Änderung der Reihenfolge von zwei oder mehr Instruktionen umfassen, eine Einfügung einer Instruktion umfassen, eine Ersetzung einer Instruktion umfassen und/oder eine Aufteilung einer Instruktion in zwei oder mehr Teilinstruktionen umfasst.
  • In weiteren Ausführungsbeispielen kann das Bestimmen der Modifikation eine Zuweisung eines konstanten Werts auf ein Register oder ein Speicherelement (Speicheraddresse) der Recheneinheit umfasst, ohne dass der konstante Wert nach der Zuweisung für die Verarbeitung der Nutzdaten verwendet wird. Typischerweise ist das Register oder das Speicherelement, an der konstante Wert geschrieben wird, nicht das Signaturregister, sondern ein für Nutzdaten vorgesehenes Register bzw. Speicherelement.
  • Weiterhin kann das Bestimmen der Modifikation umfassen: Vergleichen der Differenz mit zumindest einem Signaturmodifizierungswert für zumindest eine Modifizierungsoption; Auswählen einer Modifizierungsoption; Bestimmen einer Restdifferenz; und, falls die Restdifferenz ungleich Null ist: Wiederholen der Schritte des Vergleichens, des Auswählens und des Bestimmens der Restdifferenz. Durch eine iterative Durchführung von mehreren Modifizierungen der initialen Instruktionsfolge können auch Zielsignaturwerte für die Signatur erreicht werden, die nicht mit einer einzigen Modifizierung erzeugt werden können. Die initiale Instruktionsfolge kann unter Umständen wenige Freiheitsgrade aufweisen, so dass eine geeignete Modifizierung möglicherweise schwierig zu finden ist.
  • Gemäß weiterer Ausführungsbeispiele kann das Bestimmen der Modifizierung eine Auswahl einer gewählten Modifizierungsoption aus einer Vielzahl von Modifizierungsoptionen umfassen, wobei die gemäß der gewählten Modifizierungsoption modifizierte Instruktionsfolge einen geringeren Verarbeitungsmehraufwand gegenüber der initialen Instruktionsfolge aufweist, als andere Modifizierungsoptionen. Durch eine Auswertung einer Kostenfunktion bezüglich des Rechenaufwands können Modifizierungsoptionen herausgefiltert werden, die die gewünschte Signaturaktualisierung mit möglichst geringem zusätzlichem Rechenaufwand für die Recheneinheit erreichen.
  • Die Auswahl der gewählten Modifizierungsoption kann weiterhin eine Abfrage einer Datenbank umfassen, in der Modifizierungsvorschriften für die Vielzahl der Modifizierungsoptionen gespeichert sind, mittels der die Vielzahl der Modifizierungsoptionen für den Programmabschnitt ermittelt werden können. Die Modifizierungsvorschriften können auch zu erfüllende Bedingungen spezifizieren, die angeben, ob und auf welche Weise eine bestimmte Instruktion oder Instruktionsgruppe modifiziert werden kann. In diese Auswertung kann insbesondere eine Datenabhängigkeitsanalyse eingehen.
  • Gemäß weiteren Ausführungsbeispielen kann das Bestimmen des Zielinstruktionswerts das Ermitteln eines Instruktionswerts für einen gegenüber dem Programmabschnitt alternativen Programmpfad zu dem Programmpunkt umfassen.
  • Das Bestimmen der Modifikation kann ferner umfassen: ein Identifizieren einer aufteilbaren Instruktion in dem Programmabschnitt, ein Zerlegen eines Arguments der aufteilbaren Instruktion in zumindest zwei Teilargumente und ein Ersetzen der aufteilbaren Instruktion durch zumindest zwei Teilinstruktionen mit jeweils einem der zumindest zwei Teilargumente.
  • Nach weiteren Ausführungsbeispielen kann beim Bestimmen der Modifikation der initialen Instruktionsfolge versucht werden, eine Modifikation zu bewirken, die keine Verlängerung der Instruktionsfolge bewirkt. Wenn eine solche Modifikation (mit vertretbarem Aufwand) nicht gefunden werden kann, kann das Verfahren zumindest eine der folgenden Aktionen aufweisen:
    Bestimmen einer Modifikation, die eine Verlängerung der Instruktionsfolge bewirkt;
    Einfügen einer Anweisung für eine explizite Codeaktualisierung; und
    Ändern des Zielsignaturwerts und/oder der initialen Signatur.
  • Hinsichtlich der Option „Ändern des Zielsignaturwerts und/oder der initialen Signatur” sei darauf hingewiesen, dass die gewünschte Zielsignatur sozusagen eine zusätzliche Randbedingung bei der Optimierung darstellen kann. Die Möglichkeit, den Zielsignaturwert und/oder die initiale Signatur zu ändern, bietet einen zusätzlichen Freiheitsgrad für die Modifizierung. Eine Änderung des Zielsignaturwerts und/oder der initialen Signatur kann unter Umständen bedeuten, dass auch in einem parallelen Programmpfad die Instruktionsfolge modifiziert werden muss.
  • Alternative Ausführungsbeispiele der Erfindung schaffen ein Verfahren zum Ausführen eines Programms auf einer programmgesteuerten Recheneinheit, wobei das Programm zumindest eine Instruktionsfolge umfasst, die von dem Verfahren zur Erzeugung einer Instruktionsfolge für eine Recheneinheit erzeugt wurde. Während der Ausführung des Programms kommt zur typischerweise zu einer Signaturberechnung für jede von der Recheneinheit ausgeführten Signatur und, an dafür vorgesehen Stellen im Programmfluss des Programms, zu einer Überprüfung des zur Laufzeit berechneten Signaturwerts mit einem Referenzwert. Da es keine expliziten Instruktionen für das Aktualisieren des Signaturregisters bzw. -werts gibt, sind beispielsweise mutwillige Manipulationen an dem Signaturregister für einen potentiellen Angreifer schwieriger durchzuführen.
  • Ein weiteres Ausführungsbeispiel der offenbarten technischen Lehre schafft ein Computerprogramm mit einem Programmcode zur Durchführung des oben beschriebenen Verfahrens zur Erzeugung einer Instruktionsfolge, wenn das Computerprogramm auf einem Computer abläuft.
  • Ein weiteres Ausführungsbeispiel der offenbarten technischen Lehre schafft einen Kompilierer zum Erstellen eines solchen Computerprogramms.
  • Ein weiteres Ausführungsbeispiel schafft eine Vorrichtung zur Erzeugung einer Instruktionsfolge für eine Recheneinheit, die von einem zumindest die Instruktionsfolge umfassenden Programm gesteuert werden kann. Zur Laufzeit des Programms werden Signaturwerte als Instruktionssignaturen durch Aufsummieren der ausgeführten Instruktionen in eine Prüfsumme berechnet und mit Referenzwerten verglichen. Die Vorrichtung umfasst: eine Zielsignaturbestimmung zum Bestimmen eines Zielsignaturwerts an einem Programmpunkt; eine Instruktionsfolgebestimmung zum Bestimmen einer initialen Instruktionsfolge für einen zu dem Programmpunkt führenden Programmabschnitt; eine Signaturermittlung zum Ermitteln eines initialen Signaturwerts, der dem Programmpunkt zugeordnet ist, auf der Basis der initialen Instruktionsfolge; und eine Modifikationsbestimmung zum Bestimmen einer Modifikation der initialen Instruktionsfolge, falls der initiale Signaturwert von dem Zielsignaturwert verschieden ist, zur Erlangung einer modifizierten Instruktionsfolge auf der Grundlage des Zielsignaturwerts und des initialen Signaturwerts. Das Ausführen der modifizierten Instruktionsfolge hat die Berechnung des Zielsignaturwerts zur Folge, und ein Ergebnis einer Verarbeitung von Nutzdaten durch die modifizierte Instruktionsfolge einem Ergebnis einer Verarbeitung der Nutzdaten durch die initiale Instruktionsfolge an dem Programmpunkt entspricht, wobei die Modifikation der initialen Instruktionsfolge zu einer unterschiedlichen zeitlichen Abfolge der Abarbeitung von Instruktionen, die Nutzdaten betreffen, innerhalb des Programmabschnitts führt.
  • Bei bisherigen Instruktionssignaturverfahren werden die Signaturaktualisierungen oder „Updates” durch explizite Instruktionen oder explizite Speicherzugriffe durchgeführt. Dies bringt einen Mehraufwand bei der Abarbeitung des Programms mit sich. Unter Umständen sind auch architekturelle Änderungen im System notwendig für die Unterstützung expliziter Aktualisierungs-Instruktionen bzw. von expliziten Registern.
  • Gemäß der offenbarten technischen Lehre kann der Programmcode so transformiert werden, dass durch eine Codetransformation eine gezielte (vorgegebene) Aktualisierung der Instruktionssignatur durchgeführt werden kann.
  • Ausführungsbeispiele der vorliegenden Erfindung werden im Folgenden anhand der beiliegenden Figuren näher beschrieben.
  • Es zeigen:
  • 1 eine Veranschaulichung einer Codetransformation mittels Transposition;
  • 2 eine Veranschaulichung einer Codetransformation mittels Einfügung;
  • 3 eine Veranschaulichung eine Codetransformation mittels Ersetzung;
  • 4 einen Ausschnitt aus einem schematischen Flussdiagramm einer initialen Instruktionsfolge und einer modifizierten Instruktionsfolge, welche die initiale Instruktionsfolge ersetzen kann;
  • 5 ein Flussdiagram eines Verfahrens zur Erzeugung einer Instruktionsfolge gemäß einem Ausführungsbeispiel der hierin offenbarten technischen Lehre;
  • 6 ein Flussdiagram eines Details des Verfahrens zur Erzeugung einer Instruktionsfolge gemäß einem weiteren Ausführungsbeispiel der hierein offenbarten technischen Lehre; und
  • 7 ein schematisches Blockschaltbild einer Vorrichtung zur Erzeugung einer Instruktionsfolge für eine Recheneinheit gemäß einem Ausführungsbeispiel der hierin offenbarten technischen Lehre.
  • Bevor im Folgenden Ausführungsbeispiele anhand der beiliegenden Figuren erläutert werden, wird darauf hingewiesen, dass gleiche Elemente oder Elemente gleicher Funktion mit denselben oder ähnlichen Bezugszeichen versehen sind und dass auf eine wiederholte Beschreibung dieser Elemente verzichtet wird. Beschreibungen von Elementen mit gleichen oder ähnlichen Bezugszeichen sind daher untereinander austauschbar.
  • In bisherigen Instruktionssignaturverfahren werden die Aktualisierungen der Signatur durch explizite Instruktionen oder Speicherzugriffe durchgeführt. Die Aktualisierungen können jedoch auch ohne Änderung der Hardwarestruktur effizient durch Codetransformationen durchgeführt werden. Um eine gewisse Funktion auf einem Prozessor zu implementieren gibt es meist mehrere Möglichkeiten. Insbesondere wenn man bereit ist, zumindest eine Zusatzinstruktion (es können auch mehrere sein) im Vergleich zum optimalen Code zu erlauben, gibt es eine Vielzahl von Möglichkeiten, den Code zu schreiben. Diese Vielzahl kann genutzt werden, um durch geeignete Wahl des Programmcodes implizit eine Aktualisierung durchzuführen.
  • Durch eine Änderung des Programmcodes, die das Ergebnis des Programms nicht ändert, kann die Signatur an einem anderen Punkt als dem, an dem die Änderung stattfindet, auf einen gewünschten Zielsignaturwert gebracht werden.
  • Das Auffinden von Codetransformationen, die die logische Funktion eines Programms unangetastet lassen, ist Fachleuten gut bekannt und bedarf hierin keiner weiteren Erläuterung. Bei Ausführungsbeispielen wird bei einem Kontrollflusssignaturverfahren gezielt eine invariante Transformation aus der riesigen Menge möglicher Transformationen ausgewählt, so dass die Signatur auf einen vorgegebenen Wert transformiert wird.
  • Letztendlich erzeugt jeder Compiler unterschiedliche Codetransformationen, wobei bei unterschiedlichen Optimierungsstufen unterschiedlicher, aber funktional identischer Code erzeugt wird. Bei Ausführungsbeispielen der Erfindung wird eine der Transformationen genutzt, die eine gewünschte Signatur zur Folge hat.
  • Bei Ausführungsbeispielen der Erfindung können Transformationen des Codes, die auf die gewünschte Zielsignatur führen, von dem gewählten vorgegebenen Signaturalgorithmus abhängen, wobei für unterschiedliche Signaturalgorithmen unterschiedliche Transformationen zur Zielsignatur führen können.
  • Bei Ausführungsbeispielen der Erfindung ist eine Anfangs- und eine Zielsignatur vorgegeben und es wird eine entsprechende Code-Transformation gesucht. Für den Fall, dass Instruktionen eingefügt werden, kann es auch mehrere Lösungen geben. Bei Ausführungsbeispielen der Erfindung werden jedoch keine Instruktionen eingefügt, sondern vorhandene Instruktionen vertauscht, um den Code-Overhead gering zu halten.
  • Ausführungsbeispiele der Erfindung können ein Ändern der Anfangssignatur oder Zielsignatur aufweisen, wenn die zur Verfügung stehenden Freiheitsgrade der Transformation nicht ausreichen, um eine mit gegebenen Randbedingungen (z. B. gegebene Codelänge) verträgliche Transformation zu finden.
  • Bei Ausführungsbeispielen der Erfindung wird versucht, eine solche Transformation durchzuführen, dass der transformierte Programmcode, z. B. pro Elementarblock (basic block), nicht länger wird, z. B. durch reines Vertauschen von Instruktionen. Falls eine solche Lösung nicht gefunden wird, kann bei Ausführungsbeispielen entweder a) eine Anweisung zur expliziten Signaturaktualisierung eingefügt werden, b) eine zusätzliche Operation eingefügt werden, wie z. B. zwei Additionen statt einer Addition, oder c) eine Änderung von Anfangssignatur und/oder Zielsignatur vorgenommen werden.
  • Bei Ausführungsbeispielen der Erfindung kann eine Modifikation der initialen Instruktionsfolge eine oder mehrere der folgenden Transformationen aufweisen, wobei dies jedoch keine abschließende Liste darstellt:
    • – Änderung einer Reihenfolge von zwei oder mehr Instruktionen;
    • – Einfügung einer oder mehrerer Instruktionen;
    • – Ersetzen einer oder mehrerer Instruktionen;
    • – Aufteilung einer Instruktion in zwei oder mehr Teilinstruktionen;
    • – Zuweisung eines konstanten Werts auf ein Register oder ein Speicherelement der Recheneinheit, ohne dass der konstante Wert nach der Zuweisung für die Verarbeitung der Nutzdaten verwendet wird;
    • – Durchführen einer Registerpermutation, beispielsweise durch Vertauschen der benutzten Prozessorregister (wie z. B. von R1, R2, R3 in R2, R1, R3 oder R3, R2, R1. Hierbei muss berücksichtigt werden, dass die Register in abhängigen bzw. nachfolgenden Basisblöcken auch die richtigen Werte haben, d. h. es muss eine globale Anpassung über den Elementarblock hinaus erfolgen;
    • – Benutzung freier Register, wobei wiederum eine gobale Analyse und Anpassungen über den Elementarblock hinaus erforderlich sind;
    • – Füllen von ungenutzten Feldern in Instruktionen mit frei gewählten Bits; und
    • – Durchführen von Vorzeichenänderungen von Operanden bei einer Addition oder Subtraktion und entsprechendes Vertauschen von Addition und Subtraktion.
  • Es ist für Fachleute jedoch offensichtlich, dass neben den genannten auch andere Modifikationen bzw. Transformationen möglich sind, die zu einer Zielsignatur führen.
  • 1 zeigt eine erste Option für eine Codetransformation, die darin besteht, die Reihenfolge von zwei oder mehr Instruktionen zu modifizieren, d. h. die Veränderung von Signaturwerten durch Verschiebung von Instruktionen. Diese Option der Modifizierung wird im Rahmen dieser Beschreibung „Transposition” genannt. Die linke Spalte in 1 zeigt den ursprünglichen Code, in welchem die Instruktionen in der Reihenfolge Instr1, Instr2, Instr3, Instr4, ... InstrN ausgeführt werden. Diese Reihenfolge wurde beispielsweise durch einen Kompilierer oder einen Code-Optimierer festgelegt und bewirkt, Nutzdaten auf eine vorgesehene Weise von den Instruktionen verarbeitet werden. Die rechte Spalte zeigt das Ergebnis von zwei durchgeführten Transpositionen. Eine erste Transposition besteht darin, dass die Instruktionen Instr1 und Instr3 die Plätze getauscht haben. Eine zweite Transposition führte zu einem Vertauschen der Plätze der Instruktionen Instr4 und InstrN. In der Regel wird gefordert, dass die Modifizierung eines Programmabschnitts transparent gegenüber der Verarbeitung der Nutzdaten ist. Dies bedeutet, dass nach Ausführung eines modifizierten Programmabschnitts die Nutzdaten im Ergebnis auf identische Weise verarbeitet worden sind, wie es von dem ursprünglichen Programmabschnitt bewirkt worden wäre. Innerhalb des modifizierten Programmabschnitts kann die Verarbeitung der Nutzdaten dagegen von der Verarbeitung abweichen, die im Rahmen des ursprünglichen Programmabschnitts durchgeführt wird. Bei der Transposition wird beispielsweise ausgenutzt, dass die Reihenfolge bestimmter Instruktionen verändert werden kann, ohne die Verarbeitung der Nutzdaten im Ergebnis (d. h. am Ende des modifizierten Programmabschnitts) zu verändern.
  • Die Codetransformation mittels Transposition kann angewendet werden, wenn die Signaturberechnung nicht kommutativ ist, so dass eine Vertauschung der Reihenfolge der Instruktionen zu unterschiedlichen Signaturwerten führt, wenn also gilt:
    Signatur(Instr1, Instr2) ≠ Signatur(Instr2, Instr1).
  • Hinsichtlich der Nutzdaten sind die Instruktionen Instr1 und Instr2 dagegen typischerweise kommutativ. Auf diese Weise kann die Signatur durch Veränderung der Reihenfolge der Instruktionen beeinflusst werden. Wenn hinsichtlich der Nutzdaten eine große Anzahl von Permutationen der Reihenfolge der Instruktionen möglich ist, hat die Transposition von Instruktionen eine große Anzahl von Freiheitsgraden, so dass die Signatur an viele gewünschte Zielsignaturwerte angepasst werden kann.
  • 2 zeigt eine zweite Option für eine Codetransformation, die darin besteht, eine oder mehrere Instruktionen einzufügen, die in dem ursprünglichen Programmcode nicht enthalten waren. In 2 wird zwischen den Instruktionen Instr2 und Instr3 der ursprünglichen Programmcodes eine zusätzliche Instruktion InstrX eingefügt. Weiterhin wird nachfolgend auf die Instruktion Instr4 eine weitere zusätzliche Instruktion InstrY eingefügt. Die eingefügten Instruktionen InstrX und InstrY können zum Beispiel Instruktion sein, die die Nutzdaten nicht verändern. Denkbar sind hier eine Addition des Wertes Null, das Wiederholen eines Speicherlese- oder -schreibvorgangs (so dass derselbe Wert zweimal gelesen oder geschrieben wird) oder das Laden eines bestimmten Werts in ein zu diesem Zeitpunkt unbenutzes Register des Prozessors.
  • 3 zeigt eine dritte Option für eine Codetransformation, die darin besteht, eine ursprüngliche Instruktion zu ersetzen. In 3 wird die ursprüngliche Instruktion Instr2 durch zwei Instruktionen InstrX und InstrY ersetzt. Es wird eine Zerlegung des Arguments durchgeführt, so dass das Resultat gleich bleibt, aber die Signatur den gewünschten Zielwert erhält. Wie im unteren Teil von 3 dargestellt, kann die Instruktion Instr2 zum Beispiel eine Addition des konstanten Werts 2468 zu dem aktuellen Inhalt im Register R3 sein. Diese Addition kann aufgeteilt werden in zwei Teiladdition, wobei im Rahmen der ersten Teiladdition (InstrX) zunächst der Wert 1330 addiert wird und im Rahmen der zweiten Teiladdition (InstrY) der Wert 1138 addiert wird. Im Ergebnis enthält das Register R3 nach Ausführung der zwei Instruktionen InstrX und InstrY damit den gegenüber seinem vorherigen Inhalt um 2468 erhöhten Wert. Anstelle von zwei Additionen können auch zwei Subtraktionen, mehrere Teiladdition, mehrere Teilsubtraktionen oder eine Kombination von Addition(en) und Subtraktion(en) durchgeführt werden. Diese Option der Codetransformation eröffnet weitreichende und/oder flexible Möglichkeiten, da sich konstante Werte durch viele verschiedene Additions- und Subtraktionskombinationen darstellen lassen. Zum Beispiel kann durch eine Addition eines konstanten Werts und eine nachfolgende Subtraktion desselben Werts im Ergebnis der Wert Null zu einem Register hinzuaddiert werden, was sich im Ergebnis der Nutzdatenverarbeitung nicht auswirkt. Auf die Signaturberechnung hat eine derartige Instruktionskombination dagegen einen Einfluss, der bei gezielter Wahl des konstanten Werts so justiert werden kann, dass eine Signaturaktualisierung erzielt werden kann, die die Signatur an einem bestimmten Programmpunkt auf einen Zielsignaturtwert bringt, sofern im Zusammenhang mit der Recheneinheit während der Laufzeit des Programms kein Fehler bei der Verarbeitung der Instruktionen auftritt, die in die Signaturberechnung eingehen.
  • 3 veranschaulicht somit ein Beispiel für eine Codetransformation, bei der eine Addition in zwei statt in nur einem Schritt berechnet wird. Durch die Wahl der Aufteilung der zwei Schritte kann die Instruktionssignatur so verändert (aktualisiert) werden, dass genau die Funktionalität einer expliziten Signaturaktualisierungsinstruktion implementiert wird.
  • Als Alternative zu einer Aufteilung der Verarbeitung eines konstanten Werts, wie in 3 gezeigt, kann auch ein Registerwert oder eine Variable in zwei oder mehr Schritten verarbeitet werden. Wenn zum Beispiel der Inhalt eines ersten Registers R1 zu dem Inhalt eines zweiten Registers R2 hinzuaddiert werden soll, so kann zunächst das niedrigstwertige Bit von R1 zum Inhalt von R2 hinzuaddiert werden, dann der Inhalt des ersten Registers R1 durch zwei geteilt werden (allgemein: durch n), z. B. mittels Rechtsverschiebung („right shift”) und anschließend zweimal (allgemein: n-mal) zum zweiten Register hinzuaddiert werden.
  • Die in 1 bis 3 als Beispiel angegebenen Modifizierungsoptionen sind geeignet, die Signatur gezielt zu beeinflussen, ohne auf den Inhalt eines Signaturregisters der Recheneinheit oder eines verbundenen Signaturmoduls direkt Einfluss zu nehmen, bzw. ohne eine oder mehrere auf den Inhalt des Signaturregisters Einfluss nehmende Instruktion. Andere Beispiele sind die Zuweisung von Konstanten auf Register, die vom Prozessor zumindest zeitweilig nicht genutzt werden.
  • 4 stellt einen Ausschnitt eines Programmablaufplans dar. An einem Programmpunkt P werden zwei Programmpfade bzw. Instruktionsfolgen 402 und 404 wieder vereinigt, die von einem Verzweigungspunkt (nicht gezeigt) ausgehen. Am Ende der Instruktionsfolge 402 hat die Signatur bei korrekter Ausführung der Instruktionen den Wert SIGP1. Eine initiale Version der zweiten Instruktionsfolge 404 führt dagegen zu einem Signaturwert SIGP2, der im Allgemeinen unterschiedlich zum Signaturwert SIGP1 ist um eine Differenz ΔSIG = SIGP1 – SIGP2. Bevor die zwei Instruktionsfolgen 402 und 404 am Punkt P vereinigt werden, ist es in der Regel erwünscht, dass die Signaturen in den verschiedenen sich vereinigenden Instruktionsfolgen 402 und 404 denselben Signaturwert aufweisen, sofern ein fehlerfreie Ausführung der Instruktionen in den Instruktionsfolgen erfolgt ist. Zu diesem Zweck wird die Signatur in einer der beiden Instruktionsfolgen 404, 402 an die Signatur der anderen Instruktionsfolge 402, 404 angepasst. In 4 wird die zweite Instruktionsfolge 404 angepasst, so dass aus der initialen Instruktionsfolge 404 eine modifizierte Instruktionsfolge 404' entsteht. Die modifizierte Instruktionsfolge 404' weist am Programmpunkt P einen modifizierten Signaturwert SIGP2' auf, welcher mit dem Signaturwert SIGP1 der ersten Instruktionsfolge 402 übereinstimmt. Es gilt: SIGP2' = SIGP2 + ΔSIG = SIGP1. Auf diese Weise kann die Signaturberechnung und -überprüfung nach der Vereinigung der Instruktionsfolgen 402, 404' bei Programmpunkt P fortgesetzt werden, ohne dass es für die Signaturberechnung eine Bedeutung hat, ob die erste Instruktionsfolge 402 oder die (modifizierte) zweite Instruktionsfolge 404' von der Recheneinheit abgearbeitet wurde.
  • Im Rahmen der modifizierten Instruktionsfolge 404' ist es möglich, die Signatur durch eine explizite Signaturaktualisierung an die Signatur der Instruktionsfolge 402 anzupassen. Gemäß der hierin offenbarten technischen Lehre wird jedoch eine Modifikation der Instruktionsfolge 404 durchgeführt, so dass zumindest einige der ursprünglichen Instruktionen I1, I2, und In modifiziert werden. Die modifizierte Instruktionsfolge 404' weist somit zum Beispiel modifizierte Instruktionen I1', I2' und In' auf. Die Modifizierung der Instruktionen kann in einem Verschieben, Weglassen, Hinzufügen, Ersetzen oder Ändern von Instruktionen bestehen. Insbesondere unterscheidet sich die zeitliche Abfolge der Verarbeitung von Daten innerhalb der initialen Instruktionsfolge 404 von der, die innerhalb der modifizierten Instruktionsfolge 404' durchgeführt wird. Ein Unterschied in der zeitlichen Abfolge wird auch dadurch verursacht, dass z. B. eine Null-Addition an einer bestimmten Stelle der modifizierten Instruktionsfolge 404' eingefügt wird, da dadurch die nachfolgenden Instruktionen mindestens einen Taktzyklus später ausgeführt werden.
  • Zu den Nutzdaten eines Programms oder eines Programmabschnitts sind typischerweise zumindest solche Daten zu zählen, die eine Eingangs-, Ausgangs- oder Hilfsvariable des Programms bzw. Programmabschnitts darstellen, d. h. Daten, die eine Ausgabe oder ein Ergebnis des Programms bzw. Programmabschnitts beeinflussen. Je nach Definition können weiterhin auch Daten zu den Nutzdaten gehören, die von dem Prozessor verarbeitet werden, die Ausgabe des Programms bzw. Programmabschnitts jedoch nicht beeinflussen. Letztere Daten können zum Beispiel Daten sein, die in ein Register der Recheneinheit geschrieben werden oder aus diesem ausgelesen werden, jedoch nicht mit Eingabevariablen, Hilfsvariablen und/oder Ausgabevariablen des Programms bzw. Programmabschnitts interagieren.
  • 5 zeigt ein schematisches Flussdiagramm eines Verfahrens zur Erzeugung einer Instruktionsfolge für eine Recheneinheit gemäß einem Ausführungsbeispiel der hierin offenbarten technischen Lehre.
  • Bei Aktion 502 wird ein Zielsignaturwert für einen Programmpunkt P bestimmt. Der Zielsignaturwert kann sich zum Beispiel aus der standardmäßig berechneten Referenzsignatur eines anderen Programmpfads ergeben, der zum Programmpunkt P führt.
  • Bei 504 wird eine initiale Instruktionsfolge für einen Programmabschnitt bestimmt, der zu dem Programmpunkt P führt. Meist mündet der Programmabschnitt in den Programmpunkt P, obwohl Abweichungen hiervon möglich sind, d. h. der Programmabschnitt endet schon vor dem Programmpunkt P. Die Bestimmung der initialen Instruktionsfolge kann zum Beispiel durch einen Kompilierer erfolgen. Im Rahmen des hierin offenbarten Verfahrens zur Erzeugung einer Instruktionsfolge kann die initiale Instruktionsfolge auch z. B. aus einer Datei oder einem Datenträger ausgelesen werden.
  • Als optionale Aktion kann bei 506 ein initialer Signaturwert auf der Grundlage der Instruktionen der initialen Instruktionsfolge ermittelt werden. Ebenfalls optional ist die Bestimmung einer Differenz zwischen dem Zielsignaturwert und dem initialen Signaturwert bei 508. Durch die Bestimmung der Differenz kann unter Umständen eine Suche nach möglichen Modifizierungsoptionen erleichtert werden. Die Differenz kann zum Beispiel als Argument in eine Funktion eingehen, mit der ein konstanter Wert berechnet wird, welcher in ein gegenwärtig unbenutztes Register der Recheneinheit geschrieben wird. Diese Registerschreiboperation kann dann eine Änderung der Signatur bewirken, die genau der benötigten Differenz der Signatur entspricht.
  • Im Rahmen der Aktion 510 wird darin eine Modifikation der initialen Instruktionsfolge 404 bestimmt, die zur modifizierten Instruktionsfolge 404' führt.
  • In 6 ist ein schematisches Flussdiagramm abgebildet, das einen Aspekt eines Verfahrens zur Erzeugung einer Instruktionsfolge zeigt. Ausgehend von der Aktion 508, in welcher die Differenz zwischen dem Zielsignaturwert und dem initialen Signaturwert bestimmt wird, wird bei 608 die Differenz mit zumindest einem Signaturmodifizierungswert für eine Modifizierungsoption verglichen. Bei 610 wird eine Modifizierungsoption ausgewählt und die entsprechende Modifizierung der Instruktionsfolge durchgeführt. Wenn der Signaturmodifizierungswert für die gewählte Modifizierungsoption mit der festgestellten Differenz übereinstimmt, ist das Ziel der Modifizierung erreicht. Dies wird dadurch festgestellt, dass bei 612 eine Restdifferenz bestimmt wird und diese Restdifferenz bei 614 mit Null verglichen wird. Wenn die Restdifferenz gleich Null ist, endet das Verfahren mit der Ausgabe der modifizierten Instruktionsfolge 616. Wenn dagegen die Restdifferenz ungleich Null ist, springt das Verfahren von der Abfrage 614 zurück zur Aktion 608, wo die Restdifferenz mit den Signaturmodifizierungswerten für eine oder mehrere Modifizierungsoptionen verglichen wird. Auf diese Weise können mehrere Iterationen durchlaufen werden, bis die Restdifferenz gleich Null ist. Bei jeder Iteration wird eine weitere Modifizierungsoption durchgeführt, die jedoch für die Verarbeitung der Nutzdaten im Ergebnis unerheblich, also „transparent” ist.
  • In der Regel wird für das Verfahren angestrebt werden, mit möglichst wenigen Modifizierungen der initialen Instruktionsfolge auszukommen, da auf diese Weise der durch die Modifizierung häufig verursachte Mehraufwand für die Recheneinheit im Rahmen gehalten werden kann. Während bei Transpositionen, wie sie in 1 gezeigt sind, unter Umständen überhaupt keine Erhöhung des Rechenaufwands entsteht, können Einfügungen von Instruktionen den Rechenaufwand erhöhen. Unterschiedliche Modifizierungsoptionen sind also mit unterschiedlichen Auswirkungen auf den Rechenaufwand verbunden. Diese Information kann zusammen mit den Modifizierungsoptionen gespeichert sein, so dass die Entscheidung für eine spezielle Modifizierungsoption eine eventuelle Erhöhung des Rechenaufwands in Betracht ziehen kann. Eine mögliche Strategie für die Wahl der Modifizierungsoption(en) könnte somit sein, zunächst mögliche Transpositionen von Instruktionen zu prüfen. Erst wenn sich herausstellt, dass der Zielsignaturwert der Signatur ausschließlich mit Transpositionen nicht erreicht werden kann, könnte auf andere Modifizierungsoptionen wie Einfügungen und/oder Ersetzungen ausgewichen werden.
  • 7 zeigt ein schematisches Blockschaltbild einer Vorrichtung 100 zur Erzeugung einer Instruktionsfolge für eine Recheneinheit gemäß der hierin offenbarten technischen Lehre. Die Vorrichtung 100 empfängt beispielsweise von einem Kompilierer Instruktionen als Eingabegröße. Diese Instruktionen liegen meist in Form einer initialen Instruktionsfolge vor. Die Vorrichtung 100 umfasst eine Instruktionsfolgebestimmung 104, die die initiale Instruktionsfolge bestimmt bzw. durch Auslesen einer Datei oder vergleichbare Aktionen der Vorrichtung 100 zur Verfügung stellt.
  • Die Vorrichtung 100 umfasst ferner eine Zielsignaturwertbestimmung 102. Die Zielsignaturwertbestimmung 102 kann zum Beispiel ausgelegt sein, Programmpunkte zu identifizieren, an denen zwei oder mehrere parallele Programmpfade wieder zusammengeführt werden. An diesen Programmpunkten ist typischerweise vorgesehen, dass in einigen der Programmpfade eine Signaturaktualisierung durchgeführt wird, damit an besagtem Programmpunkt die Signaturen in den verschiedenen Signaturpfaden einander entsprechen. Die Zielsignaturwertbestimmung 102 kann einen der Programmpfade festlegen, der als Referenzpfad für die Zwecke der Signaturbestimmung dienen kann. In dem Referenzpfad wird typischerweise keine Signaturaktualisierung durchgeführt, obwohl dies nicht ausgeschlossen ist. In dem anderen Programmpfad oder den anderen Programmpfaden ist dagegen typischerweise eine Signaturaktualisierung vorgesehen.
  • Eine Signaturermittlung 106 ist ausgelegt, eine initiale Signatur für die und auf der Grundlage der initialen Instruktionsfolge zu ermitteln. Die ermittelte initiale Signatur wird an eine Differenzbestimmung 108 übermittelt, die als weitere Eingabevariable den Zielsignaturwert empfängt. Eine ermittelte Differenz zwischen dem Zielsignaturwert und der initialen Signatur wird an eine Modifizierungsbestimmung 110 weitergeleitet, die auch die initiale Instruktionsfolge von der Instruktionsfolgebestimmung 104 empfängt. Die Modifizierungsbestimmung 110 gibt eine modifizierte Instruktionsfolge aus, welche auch eine Ausgabe der Vorrichtung zur Erzeugung der Instruktionsfolge darstellt.
  • Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, sodass ein Block oder ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden Blocks oder Details oder Merkmals einer entsprechenden Vorrichtung dar. Einige oder alle der Verfahrensschritte können durch einen Hardware-Apparat (oder unter Verwendung eines Hardware-Apparats), wie zum Beispiel einen Mikroprozessor, einen programmierbaren Computer oder eine elektronische Schaltung ausgeführt werden. Bei einigen Ausführungsbeispielen können einige oder mehrere der wichtigsten Verfahrensschritte durch einen solchen Apparat ausgeführt werden.
  • Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einem programmierbaren Computersystem derart zusammenwirken können oder zusammenwirken, dass das jeweilige Verfahren durchgeführt wird. Deshalb kann das digitale Speichermedium computerlesbar sein.
  • Manche Ausführungsbeispiele gemäß der Erfindung umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird.
  • Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Computerprogrammprodukt mit einem Programmcode implementiert sein, wobei der Programmcode dahin gehend wirksam ist, eines der Verfahren durchzuführen, wenn das Computerprogrammprodukt auf einem Computer abläuft.
  • Der Programmcode kann beispielsweise auch auf einem maschinenlesbaren Träger gespeichert sein.
  • Andere Ausführungsbeispiele umfassen das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren, wobei das Computerprogramm auf einem maschinenlesbaren Träger gespeichert ist.
  • Mit anderen Worten ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens somit ein Computerprogramm, das einen Programmcode zum Durchführen eines der hierin beschriebenen Verfahren aufweist, wenn das Computerprogramm auf einem Computer abläuft.
  • Ein weiteres Ausführungsbeispiel der erfindungsgemäßen Verfahren ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.
  • Ein weiteres Ausführungsbeispiel des erfindungsgemäßen Verfahrens ist somit ein Datenstrom oder eine Sequenz von Signalen, der bzw. die das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom oder die Sequenz von Signalen kann bzw. können beispielsweise dahin gehend konfiguriert sein, über eine Datenkommunikationsverbindung, beispielsweise über das Internet, transferiert zu werden.
  • Ein weiteres Ausführungsbeispiel umfasst eine Verarbeitungseinrichtung, beispielsweise einen Computer oder ein programmierbares Logikbauelement, die dahin gehend konfiguriert oder angepasst ist, eines der hierin beschriebenen Verfahren durchzuführen.
  • Ein weiteres Ausführungsbeispiel umfasst einen Computer, auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren installiert ist.
  • Ein weiteres Ausführungsbeispiel gemäß der Erfindung umfasst eine Vorrichtung oder ein System, die bzw. das ausgelegt ist, um ein Computerprogramm zur Durchführung zumindest eines der hierin beschriebenen Verfahren zu einem Empfänger zu übertragen. Die Übertragung kann beispielsweise elektronisch oder optisch erfolgen. Der Empfänger kann beispielsweise ein Computer, ein Mobilgerät, ein Speichergerät oder eine ähnliche Vorrichtung sein. Die Vorrichtung oder das System kann beispielsweise einen Datei-Server zur Übertragung des Computerprogramms zu dem Empfänger umfassen.
  • Bei manchen Ausführungsbeispielen kann ein programmierbares Logikbauelement (beispielsweise ein feldprogrammierbares Gatterarray, ein FPGA) dazu verwendet werden, manche oder alle Funktionalitäten der hierin beschriebenen Verfahren durchzuführen. Bei manchen Ausführungsbeispielen kann ein feldprogrammierbares Gatterarray mit einem Mikroprozessor zusammenwirken, um eines der hierin beschriebenen Verfahren durchzuführen. Allgemein werden die Verfahren bei einigen Ausführungsbeispielen seitens einer beliebigen Hardwarevorrichtung durchgeführt. Diese kann eine universell einsetzbare Hardware wie ein Computerprozessor (CPU) sein oder für das Verfahren spezifische Hardware, wie beispielsweise ein ASIC.
  • Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.

Claims (16)

  1. Verfahren zur Erzeugung einer Instruktionsfolge (404') für eine Recheneinheit, die von einem zumindest die Instruktionsfolge umfassenden Programm gesteuert werden kann, wobei zur Laufzeit des Programms Signaturwerte (SIG'P2) als Instruktionssignaturen durch Aufsummieren der ausgeführten Instruktionen (I1', I2', In') in eine Prüfsumme berechnet und mit Referenzwerten verglichen werden, das Verfahren umfassend: Bestimmen eines Zielsignaturwerts (SIGP1) für eine Zielsignatur an einem Programmpunkt (P); Bestimmen einer initialen Instruktionsfolge (404) für einen zu dem Programmpunkt (P) führenden Programmabschnitt, Prüfen, ob das Ausführen der initialen Instruktionsfolge (404) ausgehend von einem Anfangssignaturwert die Berechnung eines initialen Signaturwerts (SIGP2) für die Zielsignatur zur Folge hätte, der von dem Zielsignaturwert (SIGP1) verschieden wäre; und falls der initiale Signaturwert (SIGP2) von dem Zielsignaturwert (SIGP1) verschieden wäre: Bestimmen einer Modifikation der initialen Instruktionsfolge (404) zur Erlangung einer modifizierten Instruktionsfolge (404'), so dass das Ausführen der modifizierten Instruktionsfolge (404') die Berechnung eines Signaturwerts (SIG'P2) zur Folge hat, der dem Zielsignaturwert (SIGP1) entspricht, und ein Ergebnis einer Verarbeitung von Nutzdaten durch die modifizierte Instruktionsfolge (404') einem Ergebnis einer Verarbeitung der Nutzdaten durch die initiale Instruktionsfolge (404) an dem Programmpunkt (P) entspricht, wobei alle Instruktionen der modifizierten Instruktionsfolge nach dem gleichen Verfahren in die Signaturberechnung eingehen.
  2. Verfahren nach Anspruch 1, wobei das Bestimmen der Modifikation eine Änderung der Reihenfolge von zwei oder mehr Instruktionen (I1, I2, In) umfasst.
  3. Verfahren nach Anspruch 1 oder 2, wobei das Bestimmen der Modifikation eine Einfügung einer Instruktion (I1', I2', In') umfasst.
  4. Verfahren nach einem der Ansprüche 1 bis 3, wobei das Bestimmen der Modifikation eine Ersetzung einer Instruktion (I1, I2, In) umfasst.
  5. Verfahren nach einem der Ansprüche 1 bis 4, wobei das Bestimmen der Modifikation eine Aufteilung einer Instruktion (I1, I2, In) in zwei oder mehr Teilinstruktionen umfasst.
  6. Verfahren nach einem der Ansprüche 1 bis 5, wobei das Bestimmen der Modifikation eine Zuweisung eines konstanten Werts auf ein Register oder ein Speicherelement der Recheneinheit umfasst, ohne dass der konstante Wert nach der Zuweisung für die Verarbeitung der Nutzdaten verwendet wird.
  7. Verfahren nach einem der Ansprüche 1 bis 6, wobei das Bestimmen der Modifikation umfasst: Bestimmen einer Differenz zwischen dem Zielsignaturwert und dem initialen Signaturwert; Vergleichen der Differenz bzw. Restdifferenz mit zumindest einem Signaturmodifizierungswert für zumindest eine Modifizierungsoption; Auswählen einer Modifizierungsoption; Bestimmen einer Restdifferenz; und, falls die Restdifferenz ungleich Null ist: Wiederholen der Schritte des Vergleichens, des Auswählens und des Bestimmens der Restdifferenz.
  8. Verfahren nach einem der Ansprüche 1 bis 7, wobei das Bestimmen der Modifizierung eine Auswahl einer gewählten Modifizierungsoption aus einer Vielzahl von Modifizierungsoptionen umfasst, wobei die gemäß der gewählten Modifizierungsoption modifizierte Instruktionsfolge (404') einen geringeren Verarbeitungsmehraufwand gegenüber der initialen Instruktionsfolge (404) aufweist, als andere Modifizierungsoptionen.
  9. Verfahren nach Anspruch 8, wobei die Auswahl der gewählten Modifizierungsoption eine Abfrage einer Datenbank umfasst, in der Modifizierungsvorschriften für die Vielzahl der Modifizierungsoptionen gespeichert sind, mittels der die Vielzahl der Modifizierungsoptionen für den Programmabschnitt ermittelt werden können.
  10. Verfahren nach einem der Ansprüche 1 bis 9, wobei das Bestimmen des Zielsignaturwerts (SIGP1) das Ermitteln eines Signaturwerts für einen gegenüber dem Programmabschnitt alternativen Programmpfad (402) zu dem Programmpunkt (P) umfasst.
  11. Verfahren nach einem der Ansprüche 1 bis 10, wobei das Bestimmen der Modifikation umfasst: ein Identifizieren einer aufteilbaren Instruktion in dem Programmabschnitt, ein Zerlegen eines Arguments der aufteilbaren Instruktion in zumindest zwei Teilargumente und ein Ersetzen der aufteilbaren Instruktion durch zumindest zwei Teilinstruktionen mit jeweils einem der zumindest zwei Teilargumente.
  12. Verfahren nach einem der Ansprüche 1 bis 11, wobei beim Schritt des Bestimmens einer Modifikation der initialen Instruktionsfolge (404) versucht wird, eine Modifikation zu bestimmen, die keine Verlängerung der Instruktionsfolge bewirkt, wobei, wenn eine solche Modifikation nicht gefunden wird, das Verfahren zumindest einen der folgenden Schritte aufweist: – Bestimmen einer Modifikation, die eine Verlängerung der Instruktionsfolge (404) bewirkt; – Einfügen einer Anweisung für eine explizite Codeaktualisierung; und – Ändern des Zielsignaturwerts (SIGP1) und/oder der initialen Signatur.
  13. Verfahren zum Ausführen eines Programms auf einer programmgesteuerten Recheneinheit, wobei das Programm zumindest eine modifizierte Instruktionsfolge (404') umfasst, die von einem Verfahren nach einem der Ansprüche 1 bis 12 erzeugt wurde.
  14. Computerprogramm mit einem Programmcode zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 12, wenn das Computerprogramm auf einem Computer abläuft.
  15. Kompilierer zum Erstellen eines Computerprogramms, der das Verfahren nach einem der Ansprüche 1 bis 12 anwendet.
  16. Vorrichtung zur Erzeugung einer Instruktionsfolge (404') für eine Recheneinheit, die von einem zumindest die Instruktionsfolge (404') umfassenden Programm gesteuert werden kann, wobei zur Laufzeit des Programms Signaturwerte (SIG'P2) als Instruktionssignaturen durch Aufsummieren der ausgeführten Instruktionen (I1', I2', In') in eine Prüfsumme berechnet und mit Referenzwerten verglichen werden, die Vorrichtung umfassend: eine Zielsignaturbestimmung (102) zum Bestimmen eines Zielsignaturwerts (SIGP1) an einem Programmpunkt (P); eine Instruktionsfolgebestimmung (104) zum Bestimmen einer initialen Instruktionsfolge (404) für einen zu dem Programmpunkt (P) führenden Programmabschnitt; eine Signaturermittlung (106) zum Ermitteln eines initialen Signaturwerts (SIGP2), der dem Programmpunkt (P) zugeordnet ist, auf der Basis der initialen Instruktionsfolge (404); und eine Modifikationsbestimmung (110) zum Bestimmen einer Modifikation der initialen Instruktionsfolge (404), falls der initiale Signaturwert (SIGP2) von dem Zielsignaturwert (SIGP1) verschieden ist, zur Erlangung einer modifizierten Instruktionsfolge (404') auf der Grundlage des Zielsignaturwerts (SIGP1) und des initialen Signaturwerts (SIGP2), so dass das Ausführen der modifizierten Instruktionsfolge (404') die Berechnung des Zielsignaturwerts (SIGP1) zur Folge hat, und ein Ergebnis einer Verarbeitung von Nutzdaten durch die modifizierte Instruktionsfolge (404') einem Ergebnis einer Verarbeitung der Nutzdaten durch die initiale Instruktionsfolge (404) an dem Programmpunkt (P) entspricht, wobei alle Instruktionen (I1', I2', In') der modifizierten Instruktionsfolge (404') nach dem gleichen Verfahren in die Signaturberechnung eingehen.
DE102011006000.6A 2011-03-23 2011-03-23 Signaturaktualisierung durch Codetransformation Active DE102011006000B4 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE102011006000.6A DE102011006000B4 (de) 2011-03-23 2011-03-23 Signaturaktualisierung durch Codetransformation
FR1200807A FR2973130B1 (fr) 2011-03-23 2012-03-16 Mise a jour de signature par transformation de code
CN201210080828.3A CN102722422B (zh) 2011-03-23 2012-03-23 通过代码转换更新签名
US13/428,589 US9323604B2 (en) 2011-03-23 2012-03-23 Signature update by code transformation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102011006000.6A DE102011006000B4 (de) 2011-03-23 2011-03-23 Signaturaktualisierung durch Codetransformation

Publications (2)

Publication Number Publication Date
DE102011006000A1 DE102011006000A1 (de) 2012-09-27
DE102011006000B4 true DE102011006000B4 (de) 2015-01-15

Family

ID=46801819

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102011006000.6A Active DE102011006000B4 (de) 2011-03-23 2011-03-23 Signaturaktualisierung durch Codetransformation

Country Status (4)

Country Link
US (1) US9323604B2 (de)
CN (1) CN102722422B (de)
DE (1) DE102011006000B4 (de)
FR (1) FR2973130B1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10289808B2 (en) 2013-12-20 2019-05-14 Infineon Technologies Ag Method and system for secure data processing
US10223507B2 (en) * 2016-10-28 2019-03-05 Infineon Technologies Ag Deterministic code fingerprinting for program flow monitoring
US10536168B2 (en) 2016-11-07 2020-01-14 Infineon Technologies Ag Program flow monitoring for deterministic firmware functions
EP3579072A1 (de) * 2018-06-06 2019-12-11 Siemens Aktiengesellschaft Verfahren zur automatischen erzeugung gelabelter signaturen

Family Cites Families (12)

* 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
IL128007A (en) 1999-01-11 2003-02-12 Milsys Ltd Enhancements on compact logic devices and also for accelerating and securing computations in modular arithmetic especially for use in public key cryptographic co-processors designed for elliptic curve and rsa type computations
FR2790844B1 (fr) * 1999-03-09 2001-05-25 Gemplus Card Int Procede et dispositif de surveillance du deroulement d'un programme, dispositif programme permettant la surveillance de son programme
US7308096B2 (en) 2000-05-30 2007-12-11 Hitachi, Ltd. Elliptic scalar multiplication system
FR2828304B1 (fr) 2001-07-31 2010-09-03 Validy Procede pour proteger un logiciel a l'aide d'un principe dit de "dissociation temporelle" contre son utilisation non autorisee
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
DE102006014353B4 (de) 2006-03-28 2007-11-22 Siemens Ag Verfahren zum sicheren Ermitteln von Daten
US8243919B2 (en) 2007-03-07 2012-08-14 Research In Motion Limited Method and apparatus for performing elliptic curve scalar multiplication in a manner that counters power analysis attacks
DE102007038763A1 (de) * 2007-08-16 2009-02-19 Siemens Ag Verfahren und Vorrichtung zur Sicherung eines Programms gegen eine Kontrollflussmanipulation und gegen einen fehlerhaften Programmablauf
JP2009104589A (ja) * 2007-10-05 2009-05-14 Canon Inc 情報処理装置及びその方法、プログラム、記録媒体
US8261247B2 (en) * 2008-10-01 2012-09-04 Oracle International Corporation Method of modifying code of a running computer program based on symbol values discovered from comparison of running code to corresponding object code
FR2942560B1 (fr) 2009-02-24 2015-06-26 Oberthur Technologies Procede de traitement de donnees impliquant une exponentiation et un dispositif associe.

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GALLA, T. u.a.: Control Flow Monitoring for a Time-Triggered Communication Controller. 10th European Workshop on Dependable Computing (EWDC-10). Mai 1999 *
NAHMSUK O. u.a.: Control Flow Checking by Software Signatures. Technical Report. Center for Reliable Computing, Stanford University. April 2000 [recherchiert am 01.08.2012]. Im Internet: *
NAHMSUK O. u.a.: Control Flow Checking by Software Signatures. Technical Report. Center for Reliable Computing, Stanford University. April 2000 [recherchiert am 01.08.2012]. Im Internet: <URL: http://crc.stanford.edu/crc_papers/CRC-TR-00-4.pdf>

Also Published As

Publication number Publication date
US9323604B2 (en) 2016-04-26
DE102011006000A1 (de) 2012-09-27
CN102722422A (zh) 2012-10-10
CN102722422B (zh) 2015-08-26
FR2973130B1 (fr) 2018-04-06
US20120246452A1 (en) 2012-09-27
FR2973130A1 (fr) 2012-09-28

Similar Documents

Publication Publication Date Title
DE60313652T2 (de) Verfahren und gerät zur kontrolle der umwandlung von programm-kodes
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
DE102012212343A1 (de) Verteilter Kompilierungsprozess mit Befehlssignaturunterstützung
EP2799983B1 (de) Flexible Aufteilung der I/O Kanäle einer Hardware Komponente
EP3001313A1 (de) Verfahren zur Simulation eines Anwendungsprogramms eines elektronischen Steuergeräts auf einem Computer
DE102011006000B4 (de) Signaturaktualisierung durch Codetransformation
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
EP3614268B1 (de) Verfahren und vorrichtung zum verarbeiten von daten mittels codierter operationen
DE202016008006U1 (de) Generierung von Integrationstests im Kleinen
EP3320431A1 (de) Computerimplementiertes verfahren zur bearbeitung von datenobjektvarianten
DE102019008598A1 (de) Identifikation und Visualisierung von Assoziationen zwischen Code, der von einem Modell generiert ist, und Quellen, welche die Codegeneration beeinflussen
DE102005032944A1 (de) Verfahren und Softwaresystem zur Konfiguration eines modularen Systems
EP3830687A1 (de) Verfahren zum analysieren von quelltexten
EP1738257B1 (de) Verfahren zum vermeiden von dateninkonsistenz zwischen zugriffen verschiedener funktionen einer anwendung auf eine globale variable in einer datenverarbeitungsanlage
DE102012010102A1 (de) Verfahren und Vorrichtung zur Datenverarbeitung
WO2016050857A1 (de) Verfahren zur datenverarbeitung zum ermitteln, ob bei einer ausführung eines programms ein fehler aufgetreten ist und datenverarbeitungsanordnungen zum erzeugen von programm-code
DE102007040721A1 (de) Datenverarbeitungsanordnung, Verfahren zur Datenverarbeitung, Computerprogrammelement und Überprüfungsanordnung für einen Speicher
DE10325513B4 (de) Verfahren und Vorrichtung zum Erstellen eines Verhaltensaspekts einer Schaltung zur formalen Verifikation
EP4055473B1 (de) Verfahren zum aktualisieren eines steuerprogramms eines automatisierungssystems mit datenmigration eines programmzustands des steuerprogramms
DE102010014720A1 (de) Verfahren zum Verifizieren eines aus einem Quellmodell generierten Zielprogramms
DE102008044808A1 (de) Verfahren zur Generierung von Programmcode in einem Betriebssystemspeicher und einem Applikationsspeicher eines Datenträgers
DE10300541A1 (de) Erzeugen einer ausführbaren Datei
DE102005006832B4 (de) Schaltungsanordnung und Verfahren zur gesicherten Datenverarbeitung und deren Verwendung
DE102021005309A1 (de) Verfahren zur Bewilligung der Einbringung von Programmcode aus einem Programmcode-Freigabepaket in eine Anwendungsumgebung und informationstechnisches System
DE102004020873A1 (de) System und Verfahren zum Bestimmen von anwendbaren Konfigurationsinformationen zur Verwendung bei einer Analyse eines computergestützten Entwurfs

Legal Events

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