-
Technisches Gebiet
-
Die vorliegende Offenbarung bezieht sich auf Kontrollfluss-Integrität in Bezug auf Software.
-
Hintergrund
-
Die meisten Anfälligkeiten bzw. Schwachstellen werden dadurch ausgenutzt, dass Angreifer den normalen Kontrollfluss einer Anwendung ändern, um beliebige bösartige Aktivitäten mit Privilegien der ausgenutzten Anwendung durchzuführen. Kontrollfluss-Integrität (CFI: „Control Flow Integrity“) ist ein Sicherheitsmechanismus, der Änderungen an den ursprünglichen Kontrollflussgraphen eines kompilierten Binärcodes nicht zulässt, was es erheblich schwerer macht, derartige Angriffe durchzuführen.
-
Kurzfassung
-
Gemäß einem Ausführungsbeispiel umfasst eine Computervorrichtung einen Speicher. Die Computervorrichtung umfasst auch zumindest einen Prozessor, der konfiguriert ist zum Ausführen eines Prozesses und Verwalten des Speichers für den Prozess. Der Prozessor ist ferner konfiguriert zum Ausführen von ein oder mehr Programmanweisungen, die mit einer Anwendung in Zusammenhang stehen, Erreichen eines Kontrollflusstransfers für die ein oder mehr Programmanweisungen, Abwickeln bzw. -spulen eines Aufrufstapels, der mit dem ein oder mehr Programmanweisungen in Zusammenhang steht, in Erwiderung auf ein Scheitern bzw. Fehlschlagen, einen Zielkontrollfluss zu erfüllen bzw. einzuhalten, Identifizieren eines verletzenden bzw. verstoßenden Funktionsaufrufs, und Umschreiben des verletzenden bzw. verstoßenden Funktionsaufrufs. Der umgeschriebene Funktionsaufruf umfasst eine Speicheroperationsgrenzprüfung.
-
Gemäß einem zweiten Ausführungsbeispiel umfasst ein Verfahren zum Verwalten eines Speichers für einen Prozess, der auf einem Prozessor läuft, Ausführen von ein oder mehr Programmanweisungen, die mit einer Anwendung in Zusammenhang stehen, Erreichen eines Kontrollflusstransfers für die ein oder mehr Programmanweisungen, Abwickeln bzw. -spulen eines Aufrufstapels, der mit den ein oder mehr Programmanweisungen in Zusammenhang steht, in Erwiderung auf ein Scheitern bzw. Fehlschlagen, einen Zielkontrollfluss zu erfüllen bzw. einzuhalten, Identifizieren eines verletzenden bzw. verstoßenden Funktionsaufrufs, und Umschreiben des verletzenden bzw. verstoßenden Funktionsaufrufs, wobei der umgeschriebene Funktionsaufruf eine Speicheroperationsgrenzprüfung umfasst.
-
Gemäß einem dritten Ausführungsbeispiel umfasst eine Computervorrichtung in einem Fahrzeug einen Speicher und zumindest einen Prozessor, der konfiguriert ist zum Ausführen eines Prozesses und Verwalten des Speichers für den Prozess. Der Prozessor ist konfiguriert zum Ausführen von ein oder mehr Programmanweisungen, die mit einer Anwendung in Zusammenhang stehen. Der Prozessor ist ferner konfiguriert zum Erreichen eines Kontrollflusstransfers für die ein oder mehr Programmanweisungen, Abwickeln bzw. -spulen eines Aufrufstapels, der mit den ein oder mehr Programmanweisungen in Zusammenhang steht, in Erwiderung auf ein Scheitern bzw. Fehlschlagen, einen Zielkontrollfluss zu erfüllen bzw. einzuhalten, Identifizieren eines verletzenden bzw. verstoßenden Funktionsaufrufs und einer Datengrößenbegrenzung von Registern in einem Speicher in Zusammenhang mit dem verletzenden bzw. verstoßenden Funktionsaufruf, und Umschreiben des verletzenden bzw. verstoßenden Funktionsaufrufs, sodass er eine Speicheroperationsgrenzprüfung umfasst.
-
Figurenliste
-
- 1 ist eine Darstellung eines beispielhaften Computersystems zum Detektieren von Fehlern in einem Teil eines Speichers, der einem Prozess zugewiesen ist, gemäß einer Implementierung der vorliegenden Offenbarung.
- 2 ist ein schematisches Blockschaltbild einer beispielhaften Computervorrichtung gemäß einer Implementierung der vorliegenden Offenbarung.
- 3 ist ein Ablaufdiagramm 300 eines beispielhaften Verfahrens zur Durchsetzung von Kontrollfluss-Integrität (CFI) gemäß einer Implementierung der vorliegenden Offenbarung.
-
Ausführliche Beschreibung
-
Hierin werden Ausführungsbeispiele der vorliegenden Offenbarung beschrieben. Es ist jedoch selbstverständlich, dass die offenbarten Ausführungsbeispiele lediglich Beispiele darstellen und andere Ausführungsbeispiele diverse und alternative Formen/Ausgestaltungen annehmen können. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale können hervorgehoben oder verkleinert sein, um Einzelheiten bestimmter Komponenten zu zeigen. Daher sind spezielle strukturelle und funktionale Einzelheiten, die hierin offenbart sind, nicht als einschränkend zu interpretieren, sondern lediglich als eine repräsentative Grundlage, um einem Fachmann zu lehren, die Ausführungsbeispiele verschiedentlich einzusetzen. Wie ein Fachmann verstehen wird, können diverse Merkmale, die in irgendeiner der Figuren veranschaulicht und mit Bezug auf diese beschrieben sind, mit Merkmalen kombiniert werden, die in ein oder mehr anderen Figuren veranschaulicht sind, um Ausführungsbeispiele hervorzubringen, die nicht explizit veranschaulicht oder beschrieben sind. Die veranschaulichten Kombinationen von Merkmalen stellen repräsentative Ausführungsbeispiele für typische Anwendungen bereit. Für besondere Anwendungen oder Implementierungen können jedoch diverse Kombinationen und Modifikationen der Merkmale gewünscht sein, die mit den Lehren dieser Offenbarung konsistent sind.
-
In Computersystemen, die Software nutzen, die in maschinennahen Sprachen geschrieben ist, wie etwa zum Beispiel C oder C++, kann Speicherkorrumpierung bzw. -verfälschung auftreten. Dies ist deshalb so, da derartige Sprachen standardmäßig keine Datenvalidierungsprüfungen auf Speicherlese- oder Speicherschreibvorgänge ein-/kompilieren. Zum Beispiel kann kompilierter C-Code keinerlei Verifikationen umfassen, um zu verhindern, dass Daten außerhalb eines Speicherbereichs, der einem Datenpuffer zugewiesen ist, geschrieben werden. Ein solcher Außerhalb-von-Grenzen-Zugriff kann als ein Pufferüberlauf („buffer overflow“ oder „buffer overrun“) bezeichnet werden.
-
Wenn ein Prozess kompilierten Code ausführt, wird ein Datenstapel dem Prozess als ein Speicherblock zugewiesen. Wenn eine Funktion aufgerufen wird, indem der Code ausgeführt wird, wird ein neuer Rahmen auf diesen Stapel geschoben. Der neue Rahmen umfasst Parameter, die an die Funktion über-/weitergegeben werden, lokale Datenvariable für die Funktion und eine Rückkehradresse, von wo eine Ausführung fortzusetzen ist, sobald die Funktion abgeschlossen ist. Wenn die Funktion abgeschlossen ist, wird der Rahmen von dem Stapel weg-/ heruntergenommen, und wird die Rückkehradresse in dem Programmzähler platziert, um einen Programmfluss wiederaufzunehmen. Die Rückkehradresse ist typischerweise die Anweisung des kompilierten Codes unmittelbar nach der Stelle, wo die Funktion aufgerufen wurde.
-
Ein Stapelpufferüberlauf ist ein spezieller Typ von Pufferüberlauf, der zum Ver-/ Ändern eines Programmflusses verwendet werden kann. Zum Beispiel kann ein Angreifer einen Pufferüberlauf einer lokalen Variablen auf dem Stapel arrangieren bzw. einfädeln, der dazu ausgebildet ist, zu bewirken, dass die Rückkehradresse mit einem Sprung bzw. einer Verzweigung zu bösartigem Code überschrieben wird. Dies ist ein Beispiel dafür, wie ein Angreifer Unterlassungen bzw. Versäumnisse in Datenvalidierung, die in bestimmten Programmiersprachen inhärent sind, ausnutzen kann, um einen Kontrollfluss eines Programms, das auf dem Computersystem ausgeführt wird, zu kapern.
-
Techniken von Kontrollfluss-Integrität (CFI) können verwendet werden, um einige Arten von Speicherkorrumpierung bzw. -verfälschung zu detektieren, aber bleiben in ihrer Antwort- bzw. Ansprechfähigkeit begrenzt. CFI arbeitet, indem zunächst alle möglichen Ausführungspfade in Code oder einem Programm verfolgt bzw. aufgespürt werden, um einen Kontrollflussgraphen (CFG) zu konstruieren, und dann zur Laufzeit durchgesetzt wird, dass ein Programmfluss den Kontrollflussgraphen befolgt. CFI-Durchsetzungsprüfungen können in dem Code als eine Form von Sicherheit implementiert werden, die verhindert, dass der Kontrollfluss des Codes von dem Kontrollflussgraphen abweicht, was es erheblich schwerer macht, Angriffe durchzuführen, die einen Kontrollfluss ver-/ ändern, und beliebige bösartige Aktivitäten (z.B. Malware, Viren, trojanische Pferde, Spyware, usw.) mit Privilegien durchzuführen, die aus einer ausgenutzten Anwendung herrühren. CFI-Techniken können daher Kontroll- bzw. Steuerungstransfers und/oder Programmflüsse innerhalb einer Computerumgebung überwachen und erhalten bzw. bewahren. CFI-Techniken können einen (z.B. Inline- oder Extern-) Referenzmonitor und Funktionsübergänge von Code verwenden, die durch die Referenzmonitore geschickt werden und gegen einen Grundwahrheit-CFI-Graphen verglichen werden, um anormale bzw. ungewöhnliche oder abweichende Verhaltensweisen zu bestimmen. CFI-Techniken können Fehler bzw. Störungen identifizieren, die sich aus harmlosen oder natürlichen Gründen ergeben, einschließlich Umgebungsstrahlung (z.B. elektrischen und magnetischen Feldern, usw.), Zufallsrauschen, Signalfehlern oder Teilstörung/-ausfall. Noch wichtiger ist, dass CFI-Techniken Fehler bzw. Störungen detektieren können, die sich aus einer absichtlichen bzw. vorsätzlichen Handlung ergeben, wie etwa einem Arbeiten auf von dem Benutzer bereitgestellten bösartigen Programmeingaben. Eine typische CFI-Verstoßhandhabung führt zu einem Anhalten einer Ausführung und einer Neuausführung des Programms mit einem frischen Zustand. Ein derartiger Handhabungsmechanismus scheitert jedoch dabei, einen feindlichen Zugriff auf die Anfälligkeit bzw. Schwachstelle zu eliminieren, und verschlechtert außerdem eine Verfügbarkeit des Systems durch Zulassen einer anhaltenden Ausnutzung bzw. Ausbeutung.
-
In einer verbesserten CFI-Technik kann ein Programm weiterhin mit anfänglichen CFI-Durchsetzungsanweisungen instrumentiert bzw. ausgestattet sein. Bei Detektion eines CFI-Verstoßes kann jedoch, anstelle eines Anhaltens oder Neustartens einer Ausführung, der Programmaufrufstapel stattdessen ausgehend von dem Fehler- bzw. Störungspunkt abgewickelt werden, um die verletzende Funktion zu identifizieren, die den Verstoß verursacht hat. Die verletzende Funktion kann dann modifiziert (d.h. umgeschrieben) werden, sodass sie Anweisungen umfasst, die eine Grenzprüfung bezüglich des Zielpuffers durchführen, der in der verletzenden Funktion übergelaufen ist bzw. zum Überlaufen gebracht wurde. Dadurch, dass die verletzende Funktion umgeschrieben wird/ist, kann eine Ausführung ausgehend von einem Punkt wiederaufgenommen werden, bevor die verletzende Funktion aufgerufen wurde, wobei der vorhergehende Programmaufrufstapelzustand verwendet wird. Es ist bedeutsam, dass, da die umgeschriebene Funktion nun eine Grenzprüfung umfasst, verhindert wird, dass die missgestalteten Daten, die zu dem anfänglichen Verstoß geführt haben, einen weiteren Verstoß verursachen. Dementsprechend wird die Speicherkorrumpierung bzw. -verfälschung in der wiederaufgenommenen Ausführung verhindert, und kann der Angreifer die Überlaufanfälligkeit bzw. -schwachstelle nicht abschließen bzw. vollständig ausnutzen. Anstatt eines einfachen Anhaltens einer Ausführung und eines abrupten Stoppens einer Ausführung einer Anwendung kann die Anwendung daher modifiziert und wiederaufgenommen werden, wodurch sie sich von dem Angriff erholt, während auch zukünftige Fehler oder Probleme an diesem Punkt in der Anwendung verhindert werden.
-
Nun Bezug nehmend auf 1 umfasst ein beispielhaftes Computersystem 100 eine Computervorrichtung 110. Die Computervorrichtung 110 kann zum Beispiel eine beliebige mobile oder feste/stationäre Computervorrichtung sein, umfassend, aber nicht eingeschränkt auf, einen Desktop- oder Laptop- oder Tabletcomputer, ein Mobiltelefon, eine Spielvorrichtung, eine Gemischte-Realität- oder Virtuelle-Realität-Vorrichtung, eine Musikvorrichtung, ein Fernsehgerät, ein Navigationssystem, eine Kamera, einen Minicomputer/Organizer bzw. persönlichen digitalen Assistenten (PDA), eine handgehaltene/-geführte Vorrichtung, eine elektronische Steuereinheit, jegliche andere Computervorrichtung mit drahtgebundener und/oder drahtloser Verbindungsfähigkeit mit ein oder mehr anderen Vorrichtungen, oder jegliche andere Art von computerisierter Vorrichtung, die zum Erzeugen eines Videoausgangssignals im Stande ist.
-
Die Computervorrichtung 110 kann eine Zentralverarbeitungseinheit (CPU) 114 umfassen, die in einem Speicher 116 gespeicherte Anweisungen ausführt. Zum Beispiel kann die CPU 114 ein Betriebssystem 140 und ein oder mehr Anwendungen 130 ausführen. Das Betriebssystem 140 und die Anwendungen 130 können jeweils mit ein oder mehr Prozessen in Zusammenhang stehen, denen ein Prozessbezeichner zugeordnet und ein Teil eines Speichers 116 zugewiesen sein kann.
-
Speicher 116 kann konfiguriert sein zum Speichern von Daten und/oder computerausführbaren Anweisungen. Die computerausführbaren Anweisungen können ein Betriebssystem 140 und/oder Anwendungen 130 definieren und/oder mit diesen in Zusammenhang stehen. Die CPU 114 kann Betriebssystem 140 und/oder Anwendungen 130 ausführen. Speicher 116 kann ein oder mehr Hardwarespeichervorrichtungen darstellen, die für Computervorrichtung 110 zugänglich bzw. zugreifbar sind. Ein Beispiel eines Speichers 116 kann umfassen, ist aber nicht eingeschränkt auf, eine Art von Speicher, der durch einen Computer nutzbar ist, wie etwa Direktzugriffspeicher (RAM), Festwertspeicher (ROM), Bänder, magnetische Platten, optische Platten, flüchtiger Speicher, nichtflüchtiger Speicher, und jegliche Kombination von diesen. Speicher 116 kann lokale Versionen von Anwendungen speichern, die durch CPU 114 ausgeführt werden. In dem veranschaulichten Beispiel umfasst Speicher 116 RAM 120, einen Seitencache 122, eine Festplatte 124 und eine Netzwerkschnittstelle 126. Der RAM 120 kann eine Hardwarekomponente wie etwa ein oder mehr Dual-Inline-Speichermodule (DIMM) sein. Der Seitencache 122 kann ein Teil von dem RAM 120 sein, der zum Speichern von Seiten verwendet werden, die von einem Sekundärspeicher wie etwa der Festplatte 124 stammen. Die Festplatte 124 kann jeglichen Sekundärspeicher darstellen. Die Festplatte 124 kann eine größere Kapazität, aber eine langsamere Zugriffszeit als der RAM 120 aufweisen. Die Netzwerkschnittstelle 126 kann auch als ein Sekundärspeicher, zum Beispiel als ein Netzwerkspeicher/-laufwerk, verwendet werden.
-
Die CPU 114 kann ein oder mehr Prozessoren zum Ausführen von Anweisungen umfassen. Ein Beispiel von CPU 114 kann umfassen, aber ist nicht eingeschränkt auf, jeglichen Prozessor, der speziell programmiert ist, wie es hierin beschrieben ist, einschließlich eines Controllers, eines Mikrocontrollers, einer anwendungsspezifischen integrierten Schaltung (ASIC), eines programmierbaren Logikgatters (FPGA), einer Grafikverarbeitungseinheit (GPU), eines Systems-on-Chip bzw. Ein-Chip-Systems (SoC) oder einer anderen programmierbaren Logik oder Zustandsmaschine. Die CPU 114 kann andere Verarbeitungskomponenten umfassen, wie etwa eine arithmetische Logikeinheit (ALU), Register und eine Steuereinheit. Die CPU 114 kann mehrere Kerne umfassen und in der Lage sein, unterschiedliche Sätze von Anweisungen und/oder Daten gleichzeitig bzw. nebenläufig unter Verwendung der mehreren Kerne zu verarbeiten, um mehrere Threads auszuführen.
-
Das Betriebssystem 140 kann Anweisungen (wie etwa Anwendungen 130) umfassen, die in Speicher 116 gespeichert und durch CPU 114 ausführbar sind. Das Betriebssystem 140 kann einen Speichermanager 142 zum Zuweisen von Speicher an Prozesse umfassen. Zum Beispiel kann der Speichermanager 142 ein virtuelles Speichersystem implementieren. Der Speicher 116 kann einen begrenzten Umfang von RAM 120 umfassen. Die durch CPU 114 ausgeführten Prozesse können mehr Speicher an-/erfordern als der verfügbare Umfang von RAM 120. Ein großer Teil des ange-/erforderten Speichers kann jedoch für wesentliche Zeitumfänge leer bzw. ungenutzt bleiben. Der Speichermanager 142 kann einen virtuellen Speicher verwenden, um Speicheranforderungen/ -erfordernisse zu erfüllen, indem virtuelle Speicheradressen 146 an Prozesse zugewiesen werden. Die virtuellen Speicheradressen 146 können dann mit jeweiligen physikalischen Speicheradressen in dem RAM 120 oder Seiten in Zusammenhang gebracht werden, die in anderen logischen oder physikalischen Komponenten gespeichert sein können, wie etwa komprimiertem Speicher 164 oder Festplatte 124. In einer Implementierung kann der virtuelle Speicher eine Seitentabelle 144 umfassen, die den Ort des Speicherinhalts (z.B. einen Zeiger) für jede virtuelle Speicheradresse 146 speichert. In einer Implementierung kann die Seitentabelle 144 auch Metadaten 148 zum Detektieren und Korrigieren von Speicherfehlern oder -korrumpierung/-verfälschung speichern. Zum Beispiel kann ein Satz von Metadaten 148 mit jeder virtuellen Speicheradresse 146 in Seitentabelle 144 in Zusammenhang gebracht werden.
-
Eine Benachrichtigung-Anwendungsprogrammierschnittstelle(-API) 154 oder eine andere Art von Software kann einem Prozess ermöglichen, mit dem Speichermanager 142 zu kommunizieren, um gewisse Merkmale von Speichermanagement für den Prozess zu konfigurieren. In einer Implementierung kann der Speichermanager 142 Benachrichtigungen hinsichtlich korrumpierten bzw. verfälschten Speichers an einen Prozess oder eine Funktion bereitstellen. Zum Beispiel kann der Speichermanager 142 eine Benachrichtigung erzeugen, wenn korrumpierter bzw. verfälschter Speicher detektiert wird. Zum Beispiel kann der Speichermanager 142 eine Ausnahme auswerfen, die bezeichnet, dass korrumpierter bzw. verfälschter Speicher detektiert wurde oder ein CFI-Verstoß aufgetreten ist. Der Prozess kann darauf hinweisen, ob der Prozess die Ausnahme behandelt. Wenn der Speichermanager 142 keinen Hinweis dahingehend empfängt, dass der Prozess die Ausnahme behandelt, kann der Speichermanager 142 bestimmen, wie die Ausnahme zu behandeln ist (z.B. Wiederherstellung versuchen, Prozess beenden, System abstürzen lassen). Als ein weiteres Beispiel einer Benachrichtigung kann der Speichermanager 142 eine Benachrichtigung erzeugen, wenn korrumpierte bzw. verfälschte Daten korrigiert werden/sind. Ähnlich der Detektion von korrumpiertem bzw. verfälschtem Speicher, können einige Prozesse korrigierten Speicher in einer besonderen Art und Weise behandeln. Zum Beispiel kann der Prozess in der Lage sein, die Daten eher als Vertrauen, dass der Speichermanager 142 den korrumpierten bzw. verfälschten Speicher erfolgreich korrigiert hat, zu regenerieren. In anderen Fällen kann ein Prozess wählen, eine Benachrichtigung nicht zu empfangen, wenn korrumpierter bzw. verfälschter Speicher korrigiert wird/ist.
-
Ein Fehlerdetektor 158 kann Software oder Hardware zum Beurteilen sein, ob ein Funktionsaufruf korrumpiert bzw. verfälscht wurde. Zum Beispiel kann der Fehlerdetektor 158 Pufferfehler erkennen, indem untersucht wird, ob ein Pufferzugriff eine Pufferkapazität in Speicher 116 überschreitet. Der Fehlerdetektor 158 kann einen Hinweis an die Benachrichtigung-API 154 bereitstellen, wenn ein Fehler detektiert wird. Der Fehlerdetektor 158 kann konfiguriert sein zum Beurteilen eines Funktionsaufrufs, wenn ein Funktionsaufruf durch einen Prozess angefordert wird. Dementsprechend kann der Fehlerdetektor 158 sicherstellen, dass Prozesse validierte Daten empfangen. Außerdem oder alternativ kann der Fehlerdetektor 158 Funktionsaufrufe periodisch beurteilen, um zu bestimmen, ob die Funktionsaufrufe korrumpiert bzw. verfälscht wurden. Zum Beispiel kann der Fehlerdetektor 158 leerlaufende bzw. inaktive Prozesse verwenden, um sie auf Fehler zu prüfen, oder Funktionen auswählen, die für eine relativ lange Zeit im Speicher waren. Zum Beispiel kann er, für eine Anwendung, die im Hintergrund läuft, Anwendungen mittels ihres Typs identifizieren und eine normale Laufzeit für diese Anwendung (z.B. eine Laufzeitschwelle) bestimmen. Wenn die normale Laufzeit überschritten wird, kann der Fehlerdetektor 158 bestimmen, dass ein Fehler in der Anwendung existieren kann. Zum Beispiel, wenn erwartet wird, dass eine bestimmte Anwendung für nur eine Minute läuft, und die Anwendung für eine Zeit läuft, die eine Minute überschreitet, kann der Fehlerdetektor 158 bestimmen, dass die Funktion korrumpiert bzw. verfälscht wurde. In weiteren Beispielen kann ein Watchdog bzw. Wächter genutzt werden, um zu bestimmen, ob die Anwendung eine erwartete Antwort oder einen „Herzschlag“ bei Überwachung nicht empfängt.
-
Ein Fehlerkorrektor 159 kann versuchen, einen korrumpierten bzw. verfälschten Funktionsaufruf zu korrigieren, wenn dieser durch den Fehlerdetektor 158 detektiert wird. Der Fehlerkorrektor 159 kann Code des Funktionsaufrufs deterministisch modifizieren. Zum Beispiel kann der Fehlerkorrektor 159 Code zum Testen auf Fehler sequentiell modifizieren. Zum Beispiel kann der Fehlerkorrektor 159 jede Codezeile (oder eine Gruppierung von Codezeilen) analysieren, um sie zu modifizieren und folglich jede modifizierte Codezeile auf Fehler zu testen. Der Fehlerkorrektor 159 kann dann den Fehlerdetektor 158 verwenden, um zu beurteilen, ob der modifizierte Funktionsaufruf mit dem ursprünglichen Funktionsaufruf zusammenpasst bzw. übereinstimmt.
-
Nun Bezug nehmend auf 2 ist eine beispielhafte Computervorrichtung 110 gemäß einer Implementierung veranschaulicht, die im Vergleich zu 1 zusätzliche Komponenteneinzelheiten umfasst. In einem Beispiel kann Computervorrichtung 110 Prozessor 48 zum Durchführen von Verarbeitungsfunktionen umfassen, die mit ein oder mehr von Komponenten und Funktionen in Zusammenhang stehen, die hierin beschrieben sind. Prozessor 48 kann einen einzelnen oder mehrere Sätze von Prozessoren oder Mehrkern-Prozessoren umfassen. Außerdem kann Prozessor 48 als ein integriertes Verarbeitungssystem und/oder ein verteiltes Verarbeitungssystem implementiert sein. In einer Implementierung kann Prozessor 48 zum Beispiel CPU 114 umfassen.
-
In einem Beispiel kann Computervorrichtung 110 Speicher 50 zum Speichern von Anweisungen umfassen, die durch den Prozessor 48 zum Durchführen der hierin beschriebenen Funktionen ausführbar sind. In einer Implementierung kann zum Beispiel Speicher 50 Speicher 116 umfassen. CPU 114 kann auch spezialisierte Anweisungen zum Durchführen der beschriebenen Funktionen umfassen (z.B. Untersuchen von Funktionsaufrufen durch An-/Aufrufen dieser spezialisierten Anweisungen zum Prüfen eines Kontrollflusstransfers auf Gültigkeit/Korrektheit). Diese Prüfungen können auch durch einen Referenzmonitor, der als ein Teil von Fehlerdetektor 158 umfasst ist, und Instrumentierungen bzw. Ausstattungen, die in das Betriebssystem 140 oder Anwendungen 130 kompiliert sind, durchgeführt werden.
-
Ferner kann Computervorrichtung 110 eine Kommunikationskomponente 52 umfassen, die dafür sorgt, dass Kommunikationen mit ein oder mehr Parteien unter Verwendung von Hardware, Software und Diensten, wie sie hierin beschrieben sind, hergestellt und beibehalten werden. Kommunikationskomponente 52 kann Kommunikationen zwischen Komponenten auf Computervorrichtung 110, ebenso wie zwischen Computervorrichtung 110 und externen Vorrichtungen durchführen, wie etwa Vorrichtungen, die sich quer über ein Kommunikationsnetzwerk befinden, und/oder Vorrichtungen, die seriell oder lokal mit Computervorrichtung 110 verbunden sind. Zum Beispiel kann Kommunikationskomponente 52 ein oder mehr Busse umfassen, und kann sie ferner Sendekettenkomponenten und Empfangskettenkomponenten umfassen, die mit einem Sender und einem Empfänger in Zusammenhang stehen, die zum Bilden einer Schnittstelle mit externen Vorrichtungen betriebsfähig sind.
-
Außerdem kann Computervorrichtung 110 einen Datenspeicher 54 umfassen, der jede geeignete Kombination von Hardware und/oder Software sein kann, die eine Massenspeicherung von Informationen, Datenbanken und Programmen bereitstellt, die in Verbindung mit hierin beschriebenen Implementierungen eingesetzt werden. Zum Beispiel kann Datenspeicher 54 ein Datenbehälter bzw. -lager für Betriebssystem 140 und/oder Anwendungen 130 sein. Der Datenspeicher kann Speicher 116 umfassen.
-
Computervorrichtung 110 kann auch eine Benutzerschnittstellenkomponente 56 umfassen, die zum Empfangen von Eingaben von einem Benutzer von Computervorrichtung 110 betriebsfähig ist und ferner zum Erzeugen von Ausgaben zur Darstellung an den Benutzer betriebsfähig ist. Benutzerschnittstellenkomponente 56 kann ein oder mehr Eingabevorrichtungen umfassen, umfassend, aber nicht eingeschränkt auf, eine haptische Eingabe, eine Tastatur, ein Zahlenfeld, eine Maus, eine berührungsempfindliche Anzeige, einen Digitalisierer, eine Navigationstaste, eine Funktionstaste, ein Mikrofon, eine Spracherkennungskomponente, jeglichen anderen Mechanismus, der zum Empfangen einer Eingabe von einem Benutzer imstande ist, oder jegliche Kombination von diesen. Ferner kann Benutzerschnittstellenkomponente 56 ein oder mehr Ausgabevorrichtungen umfassen, umfassend, aber nicht eingeschränkt auf, eine Anzeige, einen Lautsprecher, einen haptischen Rückkopplungsmechanismus, einen Drucker, jeglichen anderen Mechanismus, der zum Darstellen einer Ausgabe an einen Benutzer im Stande ist, oder jegliche Kombination von diesen.
-
In einer Implementierung kann Benutzerschnittstellenkomponente 56 Nachrichten, die dem Betrieb von Betriebssystem 140 und/oder Anwendungen 130 entsprechen, senden und/oder empfangen. Außerdem kann Prozessor 48 Betriebssystem 140 und/oder Anwendungen 130 ausführen, und kann Speicher 50 oder Datenspeicher 54 diese speichern.
-
Computervorrichtung 110 kann sich in einem Fahrzeug befinden. Zum Beispiel kann Computervorrichtung 110 ein Teil eines Fahrzeugcomputersystems sein, das ein Navigationssystem, eine Audiokopfeinheit, ein Fahrzeugsicherheitssystem und weitere Fahrzeugkomponenten umfasst. In einem solchen Beispiel kann Computervorrichtung 110 mit anderen Fahrzeugkomponenten interagieren, die ein Fahrzeugkommunikationsnetzwerk nutzen, wie etwa einen Fahrzeugbus (z.B. einen Controller-Area-Network-(CAN-)Bus, usw.).
-
3 ist ein Ablaufdiagramm 300 eines beispielhaften Verfahrens einer CFI-Durchsetzung gemäß einer Implementierung des vorliegenden Ausführungsbeispiels. In einem Beispiel kann das beispielhafte Verfahren dadurch durchgeführt werden, dass die Computervorrichtung 110 eine Anwendung 130 oder andere Computercodeanweisungen zur Ausführung durch die CPU 114 in den Speicher 116 lädt.
-
In Vorgang 301 führt die Computervorrichtung 110 Programmanweisungen aus. Die Programmausweisungen können jede Art von kompiliertem Code sein, der zur Ausführung durch die CPU 114 der Computervorrichtung 110 vorgesehen ist. In einem veranschaulichenden Beispiel umfassen die Computeranweisungen Anweisungen, die aus einer maschinennahen Sprache, wie etwa C oder C++, kompiliert sind, der Datenvalidierungsprüfungen auf Speicherlesevorgänge oder -schreibvorgänge fehlen. Die Computervorrichtung 110 kann ein beliebiges vorgegebenes Programm beim Starten bzw. Hochfahren der Computervorrichtung 110 ausführen, oder wenn eine neue Anwendung geladen wird. Die Computervorrichtung 110 kann den Code basierend auf Code oder Anweisungen automatisch ausführen. In einem weiteren Beispiel kann der Code basierend darauf ausgeführt werden, dass ein Benutzer den Code manuell ablaufen lässt. Solche Beispiele umfassen ein Doppelklicken eines Programms, ein Tippen von Anweisungen zum Ausführen von Code, ein Berühren eines Anwendungssymbols auf einer Berührungsschnittstelle, ein Aktivieren eines Symbols basierend auf irgendeiner Eingabevorrichtung, ein Aktivieren von Fahrzeugfunktionen, usw. Weitere Eingabeschnittstellen können ebenfalls genutzt werden, um ein Programm auszuführen.
-
In Vorgang 303 erreicht ein Programmfluss bzw. -ablauf des Codes, der ausgeführt wird, einen Kontrollflusstransfer. Der Kontrollflusstransfer kann eine Maschinencodeanweisung der Programmanweisungen sein, die einen Kontrolle bzw. eine Steuerung des Programms von einem Codeort zu einem anderen transferiert bzw. überträgt/-führt. Beispiele solcher Anweisungen umfassen Aufrufanweisungen, die einen Programmfluss bzw. -ablauf zu einem Subroutinenort transferieren (und auch die Adresse der Anweisung, die dem Aufruf folgt, an/auf den Stapel zur späteren Verwendung durch eine Rückkehranweisung sichern), Rückkehranweisungen, die eine Ausführung zur Wiederaufnahme zurück an der gespeicherten Stelle an/auf dem Stapel bei Abschluss einer Ausführung der Subroutine ermöglichen, Bedingter-Sprung-Anweisungen, die eine Kontrolle bzw. Steuerung basierend auf Erfüllung von ein oder mehr Testbedingungen optional zu einer anderen Anweisungsstelle transferieren, und Unbedingter-Sprung-Anweisungen, die eine Kontrolle bzw. Steuerung ungeachtet einer Bedingung bedingungslos zu dem Zielort transferieren, usw.
-
In Vorgang 305 bestimmt das System, ob die Zielanweisung des Kontrollflusstransfers eine gültige Zielcodeanweisung ist. Die Zielcodeanweisung kann als gültig erachtet werden, wenn der Kontrollflusstransfer einen Transfer bzw. eine Übertragung/-führung eines Programmflusses versucht (oder veranlasst), der/die mit dem, was für das Programm erwartet wird, konsistent ist. Der Fehler bzw. die Störung kann sich aus harmlosen oder natürlichen Gründen ergeben, umfassend Umgebungsstrahlung, Zufallsrauschen, Signalfehlern, oder kann sich aus vom Menschen verursachten bzw. künstlich geschaffenen Ursachen ergeben. Oder der Fehler bzw. die Störung kann sich aus vorsätzlichen bzw. absichtlichen Handlungen ergeben, wie etwa einem Arbeiten auf von dem Benutzer bereitgestellten bösartigen Programmeingaben. Bei einem Ausführungsbeispiel kann das System, um zu identifizieren, ob das Ziel gültig ist, Hooks bzw. Haken in verschiedene Funktionsaufrufe umfassen, die einer CFI-Durchsetzung unterzogen/-worfen sind. Das System kann auch ein CFG-Modell speichern, das normale Programmflüsse bzw. -abläufe darstellt, die sich daraus ableiten, dass der Code oder die Programmanweisungen auf der Computervorrichtung 110 abgearbeitet werden. Der Fehlerdetektor 158 kann Hooks bzw. Haken nutzen, um Funktionsaufrufe abzufangen bzw. zu unterbrechen und einen Vergleich des Programmflusses bzw. -ablaufs, der aus einer Ausführung eines anhängigen Kontrollflusstransfers resultiert, mit dem normalen Programmfluss bzw. -ablauf des CFG-Modells durchzuführen. Wenn das Ziel nicht gültig ist, geht die Steuerung bzw. Verarbeitung jedoch zu Vorgang 307 über. In einem Beispiel, wenn das Ziel mit dem CFG-Modell konsistent ist, wird das Ziel als gültig erachtet, und kehrt die Steuerung bzw. Verarbeitung zu Vorgang 301 zurück, um mit einer Ausführung der Kontrollflusstransferanweisung fortzufahren. Zum Beispiel zielt sie während einer Programmausführung, immer wenn eine Maschinencodeanweisung die Kontrolle bzw. Steuerung transferiert, auf ein gültiges Ziel, wie es durch einen zuvor erzeugten CFG bestimmt wird. Wenn der Programmfluss bzw. -ablauf nicht mit dem CFG-Modell zusammenpasst bzw. übereinstimmt, kann dann der Fehlerdetektor 158 oder das System bestimmen, ob der Fehler bzw. die Störung basierend auf dem Erreichen des Kontrollflusstransfers aufgetreten ist.
-
In Vorgang 307 wickelt bzw. spult/rollt das System den Programmaufrufstapel ab. In einem Beispiel kann das System den aktuellen Stapelrahmen von dem Programmaufrufstapel weg-/herunternehmen, basierend auf einer Annahme, dass eine Programmausführung an einem konsistenten stabilen Punkt war, bevor die aktuelle verletzende Funktion aufgerufen wurde, und dass der Stapel an diesem Punkt in der Ausführung unbeschädigt ist. Es kann eine Maschinencodedisassemblierung auf der verletzenden Funktion des Programmaufrufstapels durchgeführt werden, und die Speicheroperatoren/ -operanden darin können identifiziert werden. Der Code der verletzenden Funktion kann umgeschrieben werden, um die Anfälligkeit bzw. Schwachstelle der Speicherkorrumpierung bzw. -verfälschung (d.h. Pufferüberlauf) zu eliminieren, im Gegensatz dazu, sie unberührt zu lassen und eine Wiederholung der Fehler- bzw. Störungsbedingung zu riskieren, wie es nachstehend ausführlicher erörtert ist. Zum Beispiel kann die Anwendung oder das Programm aus Maschinensprache in Assemblersprache disassembliert werden. Der Fehlerkorrektor 159 kann genutzt werden, um die Maschinensprache in die Assemblersprache zu disassemblieren. Der Fehlercode 159 kann dann die Codezeilen (z.B. individuell oder diese kollektiv gruppierend) analysieren, um eine Speicheroperation und die Datengrößenbegrenzungen für die Codezeilen zu bestimmen.
-
In Vorgang 309 analysiert das System den Code der verletzenden Funktion, um eine Datengrößenbegrenzung zu bestimmen. Zum Beispiel kann das System (z.B. der Fehlerkorrektor 158) eine Codeanalyse auf den Anweisungen durchführen, um Speicherzugriffsoperationen und -operanden zu identifizieren. Das System (z.B. der Fehlerdetektor 158) kann auch eine Codeanalyse auf den Anweisungen durchführen, um eine Instantiierung von Variablen zu identifizieren, da die Instantiierungen die Grenzen der Variablen bezeichnen können, die definiert werden. Als eine Möglichkeit kann die Datengrößenbegrenzung durch statische, dynamische oder symbolische Analyse der Programmanweisungen extrahiert werden. In einem Beispiel emuliert das System eine Programmausführung der Funktion, um den Puffer zu identifizieren, der zu einer Speicherkorrumpierung bzw. -verfälschung führt. In einem weiteren Beispiel kann das System die Programmanweisungen nach Pufferinitialisierungscode durchsuchen, der die Datengrößenbegrenzung als einen Parameter, ein Register oder einen unmittelbaren Wert umfasst. In einigen Implementierungen kann das System, um die Codeanalyse durchzuführen, den Maschinenanweisungscode der verletzenden Funktion in eine Assemblerdarstellung oder eine andere Darstellung disassemblieren, die für eine Analyse höherer Ebene geeigneter ist.
-
In einem weiteren Beispiel kann eine Maschinencodedisassemblierung auf der verletzenden Funktion ebenso wie auf den Speicheroperatoren/-operanden innerhalb der verletzenden Funktion, die identifiziert werden, durchgeführt werden. Die Operanden werden zu ihren Instantiierungen zurück-/verfolgt, wodurch ihre Datengrößenbegrenzungen bestimmt werden. Die Grenzprüfung besteht daraus, dass Maschinenanweisungen einen Größenvergleich basierend auf diesen bestimmten Datengrößenbegrenzungen implementieren. Diese Anweisungen werden in-line bezüglich der bzw. zwischen den Zeilen der bestehenden Anweisungen hinzugefügt, indem diese verschoben oder anders verlagert/-setzt werden, um Raum für die Grenzprüfungen zu schaffen. Der Grund für ein Umschreiben des Codes besteht darin, die Anfälligkeit bzw. Schwachstelle der Speicherkorrumpierung bzw. -verfälschung (d.h. Pufferüberlauf) zu eliminieren, im Gegensatz dazu, sie unberührt zu lassen und eine Wiederholung der Fehler- bzw. Störungsbedingung zu riskieren. Somit kann die Gesamtzuverlässigkeit und -verfügbarkeit in einer feinseligen Betriebsumgebung erhöht bzw. verbessert werden. In einem Beispiel kann der Fehlerkorrektor 159 genutzt werden, um den Code zum Eliminieren der Speicherkorrumpierung bzw. -verfälschung umzuschreiben.
-
In Vorgang 311 aktiviert das System eine Schreiberlaubnis auf den Speicher, der die zu modifizierenden Codeanweisungen speichert. In vielen Implementierungen sind Speichersegmente, die ausführbaren Code umfassen, durch den Speichermanager 142 als schreibgeschützt markiert, um zu erlauben, dass der Code gelesen wird, aber zu verhindern, dass der Code ver-/ändert wird. Dies ist generell vorteilhaft, da die Schreibzugriffsbeschränkungen ein zufälliges oder absichtliches bzw. beabsichtigtes Manipulieren bzw. Sabotieren oder Ver-/Ändern der Programmanweisungen verhindern, sobald sie in den Speicher geladen sind. Diese Beschränkung bezüglich Schreibzugriff auf die Codeanweisungen kann jedoch die Implementierung von Laufzeitprogrammverbesserungen be-/hindern, die durch CFI-Durchsetzungsverfahren identifiziert werden. In einem Beispiel kann das zugeordnete Erlaubnismodell Schreibzugriffsbeschränkungen durchsetzen und eine Modifikation eines Erlaubnisses während eines Computervorrichtungsbetriebs nicht zulassen. Das System kann auch den Speichermanager 142 anweisen, den Speicher, der den Code speichert, vorübergehend mit sowohl Lese- als auch Schreiberlaubnissen zu markieren, wodurch zugelassen wird, dass der Code in Szenarien umgeschrieben wird, wenn eine verletzende Funktion identifiziert wird.
-
In Vorgang 313 schreibt das System die Funktion um, sodass sie Speicheroperationsgrenzprüfungen gemäß der Datengrößenbegrenzung umfasst. Die umgeschriebene Funktion umfasst Grenzprüfungen, die sicherstellen, dass Schreiboperationen auf den Datenpuffer der Funktion auf die Größe des Puffers begrenzt bzw. beschränkt sind. Das System kann den Fehler bzw. die Störung nach-/verfolgen, um die Größe des Datenpuffers zu bestimmen. Das System kann sicherstellen, dass die Datengrößenbegrenzung für den umgeschriebenen Funktionsaufruf reduziert ist, indem sie die Datengrößenbegrenzung für einen Speicher analysiert, wie sie mit dem umgeschriebenen Funktionsaufruf in Zusammenhang steht. Um bei Erzeugung der Grenzprüfcodeanweisungen zu assistieren, kann das System (z.B. der Fehlerkorrektor 159) eine Codevorlage bzw. -schablone/-maske mit der Datengrößenbegrenzung und dem Speicheroperandenort nutzen, die eingefügt werden können, um den umgeschriebenen Code zu erzeugen. Das System kann dann den umgeschriebenen Code in den bestehenden Maschinencode einbringen/-binden, um zukünftige CFI-Fehler zu verhindern. Zum Beispiel können die neuen Anweisungen in-line bezüglich der bzw. zwischen den Zeilen der bestehenden Anweisungen hinzugefügt werden, indem der bestehende Code verschoben wird, oder indem der bestehende Code anders verlagert/-setzt wird, um Raum für die neuen Grenzprüfanweisungen zu schaffen. Durch Umschreiben des Codes kann die Anfälligkeit bzw. Schwachstelle der Speicherkorrumpierung bzw. - verfälschung (d.h. Pufferüberlauf) eliminiert werden. Dies vermeidet die Möglichkeit einer Wiederholung der Fehler- bzw. Störungsbedingung. Somit kann eine Gesamtsystemzuverlässigkeit und -verfügbarkeit erhöht bzw. verbessert werden. Die Datengrößenbegrenzung kann von dem verletzenden Funktionsaufruf bis zur Initialisierung zurück-/verfolgt werden. Zum Beispiel kann die Datengrößenbegrenzung durch statische, dynamische oder symbolische Analyse von Programmanweisungen extrahiert werden. Das System (z.B. der Fehlerdetektor 158) kann den verletzenden Funktionsaufruf bestimmen und Programmanweisungen disassemblieren oder eine Programmausführung emulieren, um den Puffer zu identifizieren, der zu einer Speicherkorrumpierung bzw. -verfälschung führt. Das System kann in einem Speicher oder Programmanweisungen nach Pufferinitialisierungscode suchen, der die Datengrößenbegrenzung als einen Parameter, ein Register oder einen unmittelbaren Wert umfasst. Die/der wiedergewonnene Datengrößenbegrenzung und Speicheroperandenort werden in eine Codevorlage bzw. -schablone/-maske eingefügt, um den modifizierten Code zu erzeugen. In einem weiteren Beispiel kann das System (z.B. der Fehlerkorrektor 159) den modifizierten Code testen, um die funktionale Äquivalenz der modifizierten Anweisungen im Vergleich zu den ursprünglichen Anweisungen zu verifizieren. Das System kann eine Vielfalt von Softwaretests (z.B. Einheitstests, Regressionstests, Integrationstests, formale Verifikationstests, Hardeware-in-the-loop-Tests, Codierungsregeltests, usw.) auf das modifizierte Programm anwenden, das modifizierte Programm mit gutartigen oder missgestalteten Eingaben unter einer Emulationsumgebung erneut ausführen, und so weiter, um das Nichtvorhandensein von Fehlern in dem modifizierten Code zu bestimmen. In Erwiderung auf irgendwelche Fehler kann das System die Modifikationen (z.B. unter Verwendung von zufälligen Mutationen, genetischen Algorithmen, usw.) ver-/ändern und ein Testen wiederholen, bis Bestehenskriterien erfüllt sind. Das System kann den verletzenden Funktionsaufruf bestimmen und Programmanweisungen disassemblieren oder eine Programmausführung emulieren, um den Puffer zu identifizieren, der zu einer Speicherkorrumpierung bzw. -verfälschung führt. Das System kann in einem Speicher oder Programmanweisungen nach Pufferinitialisierungscode suchen, der die Datengrößenbegrenzung als einen Parameter, ein Register oder einen unmittelbaren Wert umfasst. Die/der wiedergewonnene Datengrößenbegrenzung und Speicheroperandenort können in eine Codevorlage bzw. -schablone/-maske eingefügt werden, um den modifizierten Code zu erzeugen. Das System kann den Funktionsaufruf während einer Laufzeitoperation, im Gegensatz zu einer Anhalteoperation, umschreiben.
-
In Vorgang 315 deaktiviert das System Schreiberlaubnisse auf den Speicher, der die Codeanweisungen speichert. Dies nimmt die Verhinderung von Schreibzugriff auf den Code durch den Speichermanager wieder auf, wodurch erneut verhindert wird, dass auf den in den Speicher gelesenen Code versehentlich oder durch bösartige Benutzer geschrieben wird. Als solches kann die Tatsache, dass die Schreiberlaubnis deaktiviert ist, die Möglichkeit zum Modifizieren von Code durch unautorisierte Benutzer verhindern. Wenn die Erlaubnis deaktiviert ist, verhindert dies die Fähigkeit zum Modifizieren von Einträgen in dem Speicher, was Erzeugen von Dateien, Löschen von Dateien, Umbenennen von Dateien, usw. umfasst.
-
In Vorgang 317 stellt das System den Programmaufrufstapel auf den vorherigen Zustand wieder her. Zum Beispiel können der Programmstapel, der Programmzähler und andere CPU-Register und ein anderer Programmzustand auf einen Zustand rückgesetzt werden, der mit einer Ausführung der Programmanweisungen konsistent ist, bevor die verletzende Funktion ausgeführt wurde. Nach Vorgang 317 geht die Steuerung bzw. Verarbeitung zu Vorgang 301 über, um eine Ausführung des Codes wiederaufzunehmen. Dadurch, dass die verletzende Funktion umgeschrieben wird/ist, kann eine Ausführung ausgehend von einem Punkt, bevor die verletzende Funktion aufgerufen wurde, unter Verwendung des vorherigen Programmaufrufstapelzustands wiederaufgenommen werden. Da die umgeschriebene Funktion nun eine Grenzprüfung umfasst, wird verhindert, dass der Verstoß, der aufgetreten ist, einen weiteren Verstoß verursachen wird. Dementsprechend wird die Speicherkorrumpierung bzw. -verfälschung in der wiederaufgenommenen Ausführung verhindert. Anstelle eines einfachen Anhaltens einer Ausführung und eines abrupten Stoppens einer Ausführung einer Anwendung, kann somit die Anwendung modifiziert und ausgehend von dem wiederhergestellten Zustand wiederaufgenommen werden, wodurch sie sich von dem Angriff erholt, während auch zukünftige Fehler oder Probleme an diesem Punkt in der Anwendung verhindert werden. Als solches kann das Programm eine Ausführung mit der modifizierten Funktion wiederaufnehmen, die gebildet wurde, nachdem der Funktionsaufruf umgeschrieben wurde, sodass er Speicheroperationsgrenzprüfungen gemäß der Datengrößenbegrenzung umfasst. Das Programm kann dann eine Ausführung ausgehend von dem Start wiederaufnehmen, was die Grenzprüfungen zulassen kann. Eine Ausführung kann in einem wiederhergestellten Zustand erfolgen.
-
Während vorstehend beispielhafte Ausführungsbeispiele beschrieben sind, ist es nicht vorgesehen, dass diese Ausführungsbeispiele alle möglichen Ausgestaltungen beschreiben, die durch die Patentansprüche umfasst sind. Die in der Beschreibung verwendeten Begriffe sind Begriffe der Beschreibung statt der Beschränkung, und es ist selbstverständlich, dass verschiedene Änderungen vorgenommen werden können, ohne von dem Grundgedanken und dem Umfang der Offenbarung abzuweichen bzw. sich von diesen zu entfernen. Wie es vorstehend beschrieben ist, können die Merkmale verschiedener Ausführungsbeispiele kombiniert werden, um weitere Ausführungsbeispiele der Erfindung zu bilden, die nicht explizit beschrieben oder veranschaulicht sein können. Während verschiedene Ausführungsbeispiele dahingehend beschrieben worden sein können, dass sie Vorteile bereitstellen oder gegenüber anderen Ausführungsbeispielen oder Implementierungen des Stands der Technik mit Bezug auf ein oder mehr gewünschte Eigenschaften bevorzugt sind, erkennt der Fachmann, dass ein oder mehr Merkmale oder Eigenschaften kompromittiert bzw. gefährdet/beeinträchtigt sein können, um gewünschte Gesamtsystemattribute zu erzielen, die von der speziellen Anwendung und Implementierung abhängen. Diese Attribute können umfassen, sind aber nicht eingeschränkt auf, Kosten, Stärke, Haltbarkeit, Lebenszykluskosten, Marktgängigkeit, Erscheinungsbild, Ver-/Packung, Größe, Gebrauchs-/ Wartungstauglichkeit, Gewicht, Herstellbarkeit, Leichtigkeit des Zusammenbaus, usw. Als solches liegen, (bis) zu dem Grad bzw. Ausmaß, in dem irgendwelche Ausführungsbeispiele als weniger wünschenswert als andere Ausführungsbeispiele oder Implementierungen des Stands der Technik mit Bezug auf ein oder mehr Eigenschaften beschrieben sind, diese Ausführungsbeispiele nicht außerhalb des Umfangs der Offenbarung, und können diese für bestimmte Anwendungen wünschenswert bzw. vorteilhaft sein.
-
Eine Computervorrichtung (110) umfasst einen Speicher (116). Die Computervorrichtung umfasst auch zumindest einen Prozessor (114), der konfiguriert ist zum Ausführen eines Prozesses und Verwalten des Speichers für den Prozess. Der Prozessor ist ferner konfiguriert zum Ausführen von ein oder mehr Programmanweisungen, die mit einer Anwendung in Zusammenhang stehen, Erreichen eines Kontrollflusstransfers für die ein oder mehr Programmanweisungen, Abwickeln eines Aufrufstapels, der mit dem ein oder mehr Programmanweisungen in Zusammenhang steht, in Erwiderung auf ein Scheitern, einen Zielkontrollfluss zu erfüllen, Identifizieren eines verletzenden Funktionsaufrufs, und Umschreiben des verletzenden Funktionsaufrufs. Der umgeschriebene Funktionsaufruf umfasst eine Speicheroperationsgrenzprüfung.
