DE202009019137U1

DE202009019137U1 - Apparat für die Validierung eines nicht vertrauenswürdigen Nativen Code-Moduls

Info

Publication number: DE202009019137U1
Application number: DE202009019137.0U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2008-05-08
Filing date: 2009-05-06
Publication date: 2017-01-17
Anticipated expiration: 2019-05-07
Also published as: EP2281234A4; US20200257804A1; US9361453B2; US20140359765A1; US20160283720A1; EP2281234B1; EP3401824A1; EP2281234A2; US9058483B2; US10685123B2; US9710654B2; US20180004959A1; WO2009137564A3; WO2009137564A2; US20090282477A1

Abstract

Computerlesbares Speichermedium, auf dem Befehle gespeichert sind, die bei Ausführung durch einen Computer diesen dazu bringen, ein Verfahren für die Validierung eines nativen Code-Moduls auf einem Computergerät auszuführen, wobei das native Code-Modul nicht vertrauenswürdigen Programmcode enthält, der mit einer mit dem Computergerät verbundenen Befehlssatzarchitektur ausgedrückt wird, wobei das Verfahren umfasst: das Empfangen des nativen Code-Moduls; und das Validieren, dass sich das native Code-Modul sicher ausführen lässt – durch: das Erkennen, dass ein Befehlssatz im nativen Code-Modul keine eingeschränkten Befehle beinhaltet und/oder nicht auf eingeschränkte Funktionen des Computergeräts zugreift; und das Erkennen, dass der Befehlssatz anhand von Bytegrenzen so abgestimmt wird, dass ein bestimmter Satz an Bytegrenzen stets gültige Befehle enthält und ein Satz an Steuerungsflussbefehlen im nativen Code-Modul über gültige Ziele verfügt; und

Description

HINTERGRUND
Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich generell auf Computersicherheit. Insbesondere bezieht sich die vorliegende Erfindung auf Verfahren zum Validieren und sicheren Ausführen eines nicht vertrauenswürdigen Native-Code-Moduls auf einem Computergerät. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
Verwandtes Gebiet
Einfacher Zugriff auf Computer und reichliche Netzwerkbandbreite haben das Austauschen von Informationen und Anwendungen erleichtert. Ein Benutzer kann z. B. leicht eine Anwendung installieren und ausführen, die von einer Website heruntergeladen oder von einem Freund als E-Mail-Anhang empfangen wurde. Das Installieren und Ausführen solcher Anwendungen auf einem gegebenen Computergerät erfordert jedoch ein Maß an Vertrauen. Da solche Anwendungen oft mit unzureichenden Sicherheitsmechanismen ausgeführt werden, muss ein Benutzer implizit darauf vertrauen, dass die Anwendung keinen bösartigen Code einschließt. Einige Anwendungen nutzen jedoch blindes Vertrauen aus, indem sie „Viren” einschleusen, die Informationen auf dem Computergerät beschädigen oder löschen und sich auf anderen verwundbaren Geräten im Netzwerk replizieren können.
Einige Techniken zum Mindern der negativen Auswirkungen von Viren sind entwickelt worden. Einige interpretierte Sprachen versuchen z. B. die mit dem Ausführen von unbekanntem Code verbundenen Risiken dadurch zu verringern, dass sie die Fähigkeit einer Sprache zum Vorgeben nicht sicherer Operationen begrenzen. Alternativ erleichtern Ausführungsumgebungen virtueller Maschinen das Betreiben von Gastbetriebssystemen auf vollkommen virtualisierter Hardware (die auf tatsächlicher Hardware ausgeführt wird), wodurch nicht vertrauenswürdige Anwendungen zur Verringerung des Sicherheitsrisikos auf ihren eigenen virtuellen Maschinen isoliert werden. Für solche Methoden geschriebener Code hat jedoch im Vergleich zur Ausführung nativen Codes einen Leistungsnachteil.
Was daher notwendig ist, ist ein Verfahren, das Sicherheit ohne die Leistungsbegrenzungen existierender Techniken bereitstellt.
KURZDARSTELLUNG
Eine Ausführungsform der vorliegenden Erfindung stellt ein System bereit, das ein natives Code-Modul validiert, bevor es auf einem Computergerät ausgeführt wird. Während des Betriebs empfängt das System das Native-Code-Modul, das nicht vertrauenswürdigen nativen Code umfasst, der mithilfe nativer Befehle in der mit dem Computergerät assoziierten Befehlssatzarchitektur ausgedrückt wird. Das System validiert das native Code-Modul um zu bestätigen, dass es sich sicher ausführen lässt – durch: (1) Ermittlung, dass der Befehlssatz im nativen Code-Modul keine eingeschränkten Befehle beinhaltet und/oder nicht auf eingeschränkte Funktionen auf dem Computergerät zugreift; und (2) Ermittlung, dass der Befehlssatz im nativen Code-Modul anhand solcher Bytegrenzen abgestimmt wird, dass ein Satz an Bytegrenzen stets einen gültigen Befehl enthält und ein Satz an Steuerungsflussbefehlen im nativen Code-Modul über gültige Ziele verfügt. Anschließend erlaubt das System die Ausführung gültiger (d. h. erfolgreich validierter) nativer Code-Module und weist native Code-Module, deren Validierung fehlgeschlagen ist, ab. Durch Validierung des nativen Code-Moduls erleichtert das System die sichere Ausführung des nativen Code-Moduls in der sicheren Laufzeitumgebung des Computergeräts. Dadurch lässt sich bei nicht vertrauenswürdigen Binärprogrammen ohne größere Risiken für unerwünschte Nebeneffekte native Code-Performance erreichen.
In manchen Ausführungsformen nimmt das System bei der Validierung des nativen Code-Moduls statische Binäranalysen vor.
In einigen Ausführungsformen handelt es sich bei der Befehlssatzarchitektur um die x86 Befehlssatzarchitektur.
In manchen Ausführungsformen sorgt das System dafür, dass das native Code-Modul in einem Webbrowser heruntergeladen und ausgeführt wird. Durch Validierung des nativen Code-Moduls und Ausführung des nativen Code-Moduls in der sicheren Laufzeitumgebung (im Webbrowser) isoliert das System die Ausführung des nativen Code-Moduls von anderen Programmen, die auf dem Computergerät ausgeführt werden.
In manchen Ausführungsformen ist das native Code-Modul betriebssystemneutral und kann daher Anwendungen in verschiedenen Betriebssystemen unterstützen, die sich in der Befehlssatzarchitektur des Computergeräts ausführen lassen.
In manchen Ausführungsformen weist das System das native Code-Modul ab, wenn: das native Code-Modul eingeschränkte Befehle beinhaltet und/oder eingeschränkte Funktionen auf dem Computergerät aufruft; der Befehlssatz nicht richtig abgestimmt ist; und/oder ein oder mehrere Steuerungsbefehle im nativen Code-Modul ungültige Ziele aufweisen.
In manchen Ausführungsformen generiert das System das native Code-Modul mittels eines Kompilierungsverfahrens, das dafür sorgt, dass sich das native Code-Modul erfolgreich validieren lässt.
In manchen Ausführungsformen beinhaltet das Kompilieren und/oder Validieren des nativen Code-Moduls eines oder mehrere der folgenden Elemente: Sicherstellen, dass sich ein Ziel für einen Steuerungsflussbefehl innerhalb eines angegebenen Speichersegments befindet; Sicherstellen, dass ein Befehl im native Code-Modul für einen zugehörigen Steuerungsflussbefehl richtig abgestimmt ist; Verändern eines unsicheren Befehls für das native Code-Modul in einen sichereren Befehlssatz; Ermitteln, ob eine Bytesequenz im nativen Code-Modul für eine bestimmte Hardwareimplementierung der Befehlssatzarchitektur unterstützt wird; und/oder Abweisen einer nicht unterstützten Bytesequenz im nativen Code-Modul.
KURZE BESCHREIBUNG DER
1 illustriert ein Sicherheitsmodell für ein Computergerät gemäß einer Ausführungsform der vorliegenden Erfindung.
2 illustriert die Ausführung eines nicht vertrauenswürdigen Native-Code-Moduls gemäß einer Ausführungsform der vorliegenden Erfindung.
3A illustriert mehrere exemplarische Befehlsabfolgen, die sicherstellen, dass der Steuerfluss gemäß einer Ausführungsform der vorliegenden Erfindung innerhalb eines gegebenen Native-Code-Moduls bleibt.
3B illustriert eine Speicherregion, die auf 32-Byte-Grenzen ausgerichtet ist und einen Pseudobefehl gemäß einer Ausführungsform der vorliegenden Erfindung enthält.
3C illustriert verkleinerte Pseudobefehle, die in Verbindung mit hardwaresegmentierter Speicherunterstützung gemäß einer Ausführungsform der vorliegenden Erfindung verwendet werden können.
4 illustriert das Layout eines Native-Code-Moduls, das gemäß einer Ausführungsform der vorliegenden Erfindung in ein Speichersegment geladen wurde.
5 stellt ein Flussdiagramm dar, welches das Verfahren zum Validieren eines nicht vertrauenswürdigen Native-Code-Moduls, das gemäß einer Ausführungsform der vorliegenden Erfindung auf einem Computergeräts ausgeführt werden soll, illustriert.
6 illustriert nicht vertrauenswürdige Native-Code-Module, die in einer sicheren Laufzeitumgebung in einem Webbrowser gemäß einer Ausführungsform der vorliegenden Erfindung ausgeführt werden.
7 stellt ein Flussdiagramm dar, welches das Verfahren für das sichere Ausführen eines Native-Code-Moduls auf einem Computergerät gemäß einer Ausführungsform der vorliegenden Erfindung illustriert.
8 illustriert eine exemplarische Anwendung, die mit einem ausführenden Native-Code-Modul gemäß einer Ausführungsform der vorliegenden Erfindung in Interaktion tritt.
Tabelle 1 illustriert eine exemplarische Funktion, die gemäß einer Ausführungsform der vorliegenden Erfindung einen bösartigen Funktionsaufruf ausführt.
Tabelle 2 illustriert eine exemplarische verschleierte Funktion, die gemäß einer Ausführungsform der vorliegenden Erfindung eine bösartige Funktion ausführt.
DETAILLIERTE BESCHREIBUNG
Die folgende Beschreibung soll jeden Fachmann dazu in die Lage versetzen, die Erfindung zu machen und benutzen und wird im Kontext einer bestimmten Anwendung und deren Anforderungen bereitgestellt. Dem Fachmann sind verschiedene Modifizierungen an den offengelegten Ausführungsformen offensichtlich, und die hierin definierten allgemeinen Prinzipien können auf weitere Ausführungsformen und Anwendungen angewendet werden, ohne dass vom Geist und Umfang der vorliegenden Erfindung abgewichen wird. Die vorliegende Erfindung ist daher nicht auf die gezeigten Ausführungsformen begrenzt, sondern ihr soll der weiteste Umfang zugemessen werden, der mit den hierin offengelegten Prinzipien und Merkmalen konsistent ist.
Die in dieser detaillierten Beschreibung geschilderten Datenstrukturen und -code werden normalerweise auf einem computerlesbaren Speichermedium gespeichert, bei dem es sich um jegliches Gerät oder Medium handeln kann, das Code und/oder Daten zur Verwendung durch ein Computersystem speichern kann. Das computerlesbare Speichermedium beinhaltet, ist jedoch nicht beschränkt auf, flüchtigen Speicher, nichtflüchtigen Speicher, magnetische und optische Speichervorrichtungen, wie beispielsweise Plattenlaufwerke, Magnetbänder, CDs (Compact Discs), DVDs (Digitalversatile-Discs oder digitale Videoplatten), oder andere Medien, die in der Lage sind, computerlesbare Medien zu speichern, die nun bekannt sind oder später entwickelt werden.
Die im detaillierten Beschreibungsabschnitt geschilderten Verfahren und Prozesse können als Code und/oder Daten verkörpert sein, die wie zuvor beschrieben in einem computerlesbaren Speichermedium gespeichert werden können. Wenn ein Computersystem den Code und/oder auf dem computerlesbaren Speichermedium gespeicherte Daten liest und ausführt, führt das Computersystem die Verfahren und Prozesse aus, die als Datenstrukturen und Code ihren Ausdruck finden und auf dem computerlesbaren Speichermedium sind.
Außerdem können die im Folgenden beschriebenen Verfahren und Prozesse in Hardwaremodulen eingeschlossen sein. Hardwaremodule können unter anderem ASIC-Chips (Application-Specific Integrated Circuit), FPGAs (Field-Programmable Gate Arrays) und andere programmierbare logische Schaltungen umfassen, die bereits bekannt sind oder noch entwickelt werden. Wenn die Hardwaremodule aktiviert werden, führen die Hardwaremodule die Verfahren und Prozesse aus, die in den Hardwaremodulen enthalten sind.
Probleme beim Ausführen nicht vertrauenswürdigen Codes
Einfacher Zugriff auf Computer und reichliche Netzbandbreite haben das Austauschen von Informationen und Anwendungen ermöglicht. Dies hat zahlreiche Situationen geschaffen, in denen es wünschenswert ist, in der Lage zu sein, Programme sicher ausführen zu können, die aus unbekannten Quellen stammen und nicht vollkommen vertrauenswürdig sind. Ein Benutzer kann z. B. Folgendes versuchen:

• eine als E-Mail-Anhang empfangene ausführbare Datei zu öffnen;
• eine Webseite zu öffnen, die Code in Form von Microsoft ActiveX^® Control (ActiveX^® ist eine eingetragene Handelsmarke der Microsoft Corporation) ausführen will;
• eine Webseite zu öffnen, die eine Adobe^® Flash^®-Anwendung (Adobe Flash^® ist eine Handelsmarke der Adobe Systems Incorporated) enthält;
• auf eine Reihe webbasierter Anwendungs-Frontends zuzugreifen wie z. B. E-Mail oder Dokumentenerstellungs-Tools, die mithilfe einer Script-Sprache wie JavaScript^TM (JavaScript^TM ist eine Handelsmarke der Sun Microsystems Inc.) implementiert sind; oder
• auf von Webanwendungs-Hostingdiensten bereitgestellte Apps zuzugreifen.

Da viele Benutzer unzureichende Sicherheitsvorkehrungen treffen und/oder unzureichende technische Maßnahmen zur Sicherstellung der Sicherheit anwenden, kann das Ausführen solcher nicht vertrauenswürdigen Anwendungen dazu führen, dass bösartiger Code ausgeführt wird. Eine auf einem Computergerät installierte und ausgeführte nicht vertrauenswürdige Anwendung kann zum Beispiel bösartige und/oder schädliche Aktionen ausführen, z. B. durch Ausführung eines Systemaufrufs, mit dem Benutzerdateien gelöscht werden (dargestellt in Tabelle 1 durch die Funktion DoEvil), oder durch das Sammeln und Verbreiten vertraulicher Benutzerdaten, die auf dem Computergerät gespeichert sind.
1 illustriert ein exemplarisches Sicherheitsmodell für ein Computergerät. Viele Systeme bieten (oder verwenden) nur zwei Sicherheits-Layer: (1) Kernelniveau-Sicherheit 100, die versucht, grundlegende Betriebssystemfunktionen vor dem Benutzer und/oder externen Handlungen zu schützen sowie (2) Benutzerniveau-Sicherheit 102, die es Benutzern ermöglicht, einen bestimmten Satz von Operationen auszuführen, ohne dass sie einander beeinflussen. Es ist zu beachten, dass Benutzerniveau-Sicherheit normalerweise Interaktionen zwischen von denselben Benutzern aufgerufenen Anwendungen erlaubt. Obwohl solche Systeme Benutzer voreinander schützen, kann ein Benutzer Anwendungen installieren und/oder Handlungen vornehmen, die sich schädlich auf das eigene Konto und Daten auswirken. Daher kann die Installation und Ausführung nicht vertrauenswürdiger Programme die Domäne eines Benutzers gefährden. Außerdem können solche Programme unter Umständen bekannte Sicherheitslücken ausnutzen, um die Sicherheit auf der Kernel-Ebene zu gefährden. Was daher notwendig ist, ist ein drittes Sicherheitsniveau 104, welches das Ausführen von nicht vertrauenswürdigen Programmen unterstützt, deren Auswirkungen aber auch begrenzt.
Eine Anzahl von Techniken zum Ausführen von nicht vertrauenswürdigen Programmen versuchen die Zielkonflikte bezüglich Programmierbarkeit, Sicherheit, Übertragbarkeit und Leistung zu lösen. Solche Techniken schließen z. B. ein:

• Ungeschützte native Ausführung: Vertrauen kann durch nicht-technische Mittel etabliert werden, was es einem Programm erlaubt, mit begrenztem oder ohne Schutz ausgeführt zu werden. Ein Benutzer kann z. B. eine beliebige ausführbare Datei von einem vertrauenswürdigen App-Provider herunterladen und ausführen. Auf ähnliche Weise erlauben Microsoft ActiveX^TM-Komponenten das Laden und Ausführen ausführbarer Inhalte durch einen Webbrowser, wobei anstelle technologiebasierter Schutzlösungen nicht technische Vertrauensbeziehungen verwendet werden (z. B. durch Anzeige eines Fensters, in dem der Benutzer gefragt wird: „Diese Website versucht, ein ActiveX-Programm zu laden. Möchten Sie die Ausführung des Programms zulassen?”). Weil das Etablieren von Vertrauen generell schwierig ist, wird diese Option generell für eine unzureichende Lösung gehalten. Versagen bei solchen Vertrauensbeziehungen sowie bösartige Täuschung und Ausnutzung einer solchen Beziehung können zur Verbreitung von Computerviren und sonstigen Problemen führen.
• Sichere Sprachen und Ausführungsumgebungen: Einige Versuche zum Verbessern der Sicherheit ausführbarer Inhalte verwenden interpretierte Sprachen mit damit assoziierten Ausführungsumgebungen. Interpretierte Sprachen können unerwünschte (oder bösartige) Nebenwirkungen dadurch verringern, dass die Möglichkeit von Code, einen Satz von auf dem Sprachniveau für nicht sicher gehaltene Operationen durchzuführen, begrenzt wird. Solche Sprachen können zudem in verschiedenen Betriebssystemen und/oder Computerplattformen unterstützt werden, sodass sie sich leichter portieren lassen als Anwendungen, die native Befehle (oder „nativen Code”) direkt auf der Hardware eines Computergeräts ausführen. Nicht vertrauenswürdige Programme können zum Beispiel in Sprachen geschrieben sein, die eingeschränkt worden sind (z. B. in JavaScript^TM, Java^TM (Java^TM ist eine Marke von Sun Microsystems) oder C# und anderen von Microsoft Common Language Runtime (CLR) unterstützten Sprachen), um ausschließlich „sichere” Programme ausführen zu können. Obwohl solche Sprachen (im Vergleich zur ungeschützten Ausführung nativer Befehle) die Sicherheit verbessern können, ist die Leistung solcher interpretierten Sprachen viel schlechter als nativer binärer Code. Während die Java^TM Sprache (die auf einer Java^TM Virtual Machine ausgeführt wird) z. B. Programme zwingen kann, sicher zu sein, hat die Java^TM Ausführungsumgebung ein erhebliches Leistungsoverhead und erfordert erheblichen Installationsplatz. Außerdem können mehrere miteinander konkurrierende Sicherheitstechniken bei Benutzern Verwirrung stiften und die Anstrengungen der Entwickler zersplittern.
• Virtuelle Maschinenumgebungen: Virtuelle Maschinenausführungsumgebungen (z. B. VMware^TM (VMware^TM ist eine Handelsmarke der VMware, Inc.)) können nicht vertrauenswürdige Anwendungen in einer isolierten Umgebung ausführen (z. B. auf einer virtualisierten Maschine, die auf einem Gastbetriebssystem läuft), wodurch unbeabsichtigter (oder bösartiger) Zugriff auf geschützte Ressourcen unmöglich wird, was Sicherheitsrisiken verringert. Obwohl solche Techniken manchmal wirksam sind, sind sie immer noch durch Leistungsoverhead, Installationsoverhead und Kosten begrenzt. Z. B. kann das Instanziieren eines neuen Betriebssystemkernels in einer virtuellen Maschine erhebliches Overhead erfordern und kann zum flexiblen Herunterladen von in einem Webbrowser auszuführenden Code unpraktisch sein. Außerdem kann in einer solchen Umgebung ausgeführter, nicht vertrauenswürdiger Code Ressourcen nicht flexibel mit sonstigen Software- oder Hardwareentitäten auf dem Computergerät gemeinsam benutzen.

Es ist zu beachten, dass es zum Entdecken vieler Arten bösartiger Operationen nicht ausreicht, nativen Code vor der Ausführung zu analysieren. Obwohl ein Analyse-Tool z. B. den in Tabelle 1 illustrierten bösartigen Code entdecken könnte, kann ein solcher Code in einer Form neu geschrieben werden, die den bösartigen Systemaufruf immer noch durchführt, die aber so verborgen worden ist, dass der Code bei einer solchen Analyse nicht mehr bösartig erscheint. Illustriert wird dies durch die Funktion TrustMe in Tabelle 2, die für das MacOS^TM Betriebssystem ausgewählt wird (MacOS^TM ist eine Marke von Apple Inc.). Im speziellen Fall der TrustMe-Funktion gilt die Nutzung vor allem für Architekturen mit variablen Befehlslängen (wie z. B. die x86-Architektur); eine Erkennung subtiler und/oder verschleierter Angriffe ist jedoch im Allgemeinen schwierig. Unglücklicherweise gehen Techniken zur zuverlässigen Entdeckung von bösartigen Befehlen in Programmcode über die Grenzen der gegenwärtigen Computertechnologie hinaus bzw. sind evtl. unmöglich.
Zusammenfassend sei festgehalten, dass existierende Techniken zur Ausführung von nicht vertrauenswürdigem Programmcode normalerweise einige Aspekte von Programmierbarkeit, Sicherheit, Betriebssystemübertragbarkeit und/oder Leistung opfern. Eine Ausführungsform der vorliegenden Erfindung erleichtert die sichere und unbedenkliche Ausführung eines nicht vertrauenswürdigen nativen Codemoduls auf einem substanziell ähnlichen Hardwaresatz. Diese Ausführungsform schützt das Hostverfahren und den Rest des Hostgeräts vor bösartigem Verhalten durch nicht vertrauenswürdige Module, während es eine Leistung bereitstellt, die der von nativem Code substanziell ähnelt.
Systemüberblick
Eine Ausführungsform der vorliegenden Erfindung stellt ein System bereit, das nicht vertrauenswürdigen nativen Code sicher auf einem Computergerät mit einer Leistung betreibt, die der von vertrauenswürdigem nativem Code substantiell ähnelt. Dabei verifiziert das System, dass der nicht vertrauenswürdige native Code über integere Daten und Steuerungsflüsse verfügt und in einem eingeschränkten („sicheren”) Untersatz des Befehlssatzes für das Computergerät geschrieben wurde. Diese Eigenschaften werden für das Native-Code-Modul zur Zeit der Kompilierung aktiviert und dann validiert, wenn das System das Modul in eine sichere Laufzeitumgebung lädt. Bei der Ausführung stellt diese sichere Laufzeitumgebung moderierten Zugriff auf Systemressourcen bereit und sperrt Ressourcenzugriffe des Moduls wie von einer Sicherheitsrichtlinie vorgegeben (was durch eine Organisation, ein Computergerät, eine Anwendung, einen Benutzer und/oder eine sonstige Entität bestimmt oder damit assoziiert sein kann). Das nicht vertrauenswürdige Modul kann auf gemeinsame Systemressourcen (z. B. Kommunikation mit anderen örtlichen Prozessen, dauerhafter Speicher etc.) nur über die sichere Laufzeitumgebung zugreifen. Es ist zu beachten dass, obwohl das Native-Code-Modul in einer sicheren Laufzeitumgebung ausgeführt wird, die Befehle in einem validierten Native-Code-Modul direkt auf der Hardware des Computergeräts selbst laufen und keine Emulation, Virtualisierung oder Interpretation involvieren.
2 illustriert die Ausführung eines nicht vertrauenswürdigen Native-Code-Moduls in einer Ausführungsform der vorliegenden Erfindung. Während des Betriebs greift ein Benutzer, der Operationen in Webbrowser 202 auf Computergerät 200 vornimmt, auf eine Webseite zu und ruft browserbasierte Clientanwendung 204 auf. Browserbasierte Clientanwendung 204 bewirkt, dass Browser-Plug-in 206 ein nicht vertrauenswürdiges Native-Code-Modul 208 von Netzwerkserver 210 herunterlädt. Es ist zu beachten, dass das nicht vertrauenswürdige Native-Code-Modul 208 durch Validator 212 validiert wird, während es in die sichere Laufzeitumgebung 214 geladen wird. Stellt Validator 212 fest, dass das nicht vertrauenswürdige Native-Code-Modul 208 einem Satz von Validierungsregeln nicht entspricht, wird das Modul abgelehnt (und daher nicht ausgeführt). Andernfalls kann das nicht vertrauenswürdige Native-Code-Modul 208, wenn es die Validierung besteht, in der sicheren Laufzeitumgebung 214 sicher ausgeführt werden. Während der Ausführung stellt sichere Laufzeitumgebung 214 eine sehr begrenzte Schnittstelle 216 zwischen dem nicht vertrauenswürdigen Native-Code-Modul 208 und sonstigen Softwareentitäten und Hardwareressourcen bereit, die alle externen Anforderungen vom nicht vertrauenswürdigen Native-Code-Modul 208 (sowie die Art, in der diese Anforderungen gemacht werden) moderiert.
Das in 2 führt nicht vertrauenswürdige native Code-Module in einem Webbrowser aus, sodass sich nicht vertrauenswürdiger nativer Code als Alternative (oder Ergänzung) zu einem JavaScript^TM-Front-End bei performancesensiblen Webanwendungen (z. B. Spielen mit rechenintensiver physischer Modellierung) sicher ausführen lässt. In diesem Szenario kann das System die Performance- und Funktionslücken zwischen webbasierten Anwendungen und nativen bzw. konsolenartigen Anwendungen schließen, sodass verbesserte Webanwendungen möglich werden, die eine geringere Anfälligkeit für Viren, Würmer, Spyware und andere Sicherheitsgefahren durch Software aufweisen. Beachten Sie jedoch, dass die beschriebenen Verfahren nicht auf Webbrowser begrenzt sind und sich überall dort verwenden lassen, wo für eine komplette oder Teile einer nicht vertrauenswürdigen Anwendung native Code-Performance und mehr Sicherheit benötigt werden. So können beispielsweise die beschriebenen Techniken zu Folgenden verwendet werden: Ausführen und/oder Erweitern von nicht vertrauenswürdigen eigenständigen Anwendungen, Ermöglichen von Benutzerverbesserungen spezialisierter Umgebungen wie Spiele-Konsolen, wo es wünschenswert sein kann, Benutzern die Erweiterung von Anwendungsfunktionalität auf geschützte (aber Hochleistungs-Art zu erlauben; sicheres Ausführen von E-Mail-Anhängen sowie das Verbessern von Scriptumgebungen durch sichere Verwendung von nativem Code zur Beschleunigung kritischer und/oder rechenintensiver Codeabschnitte.
In einer Ausführungsform der vorliegenden Erfindung erlaubt das System das sichere Ausführen eines nicht vertrauenswürdigen binären x86 Codemoduls auf einem Computergerät, wodurch es dem Modul ermöglicht wird, als Anwendungskomponente zu dienen, die native Leistung erreicht, strukturell aber gegen Sicherheitsprobleme wie Viren immun ist. Solche Binärmodule sind unabhängig vom Betriebssystem und lassen sich daher in verschiedene x86-Betriebssysteme portieren. Es ist zu beachten, dass das binäre Codemodul mithilfe einer Reihe populärer Programmiersprachen (wie C oder C++) implementierbar ist, im Gegensatz zu anderen Umgebungen, welche die Sprachauswahl einschränken. Es ist außerdem zu beachten dass, obwohl die folgende Beschreibung des Systems die Intel x86 Prozessorarchitektur verwendet, die in dieser Anwendung beschriebenen Techniken nicht auf diese Architektur beschränkt sind und auf eine breite Zahl von Prozessor- und/oder Hardwarearchitekturen (z. B. die PowerPC- und ARM-Architekturen) anwendbar sind.
In einer Ausführungsform der vorliegenden Erfindung stellt das System die folgenden Vorteile bereit:

• Schutz: Nicht vertrauenswürdige Module können keine unerwünschten Nebenwirkungen auf ein Hostverfahren oder jeglichen anderen Teil des Systems, einschl. anderer nicht vertrauenswürdiger Module, haben. Außerdem können nicht vertrauenswürdige Module nicht direkt mit dem Netzwerk kommunizieren. Das System verhindert, dass nicht vertrauenswürdige Module nicht-vermittelte Systemaufrufe vornehmen, wodurch solche nicht vertrauenswürdigen Module an der Verwendung solcher Systemaufrufe zur Ausnutzung von Systemverletzlichkeiten durch direktes Erzeugen oder Modifizieren von Dateien im Dateisystem, Starten von Prozessen, Vornehmen heimlicher Netzwerkkommunikation etc. gehindert werden. Das nicht vertrauenswürdige Modul ist für den Zugriff auf Systemdienste vollkommen auf die sichere Laufzeitumgebung angewiesen, wobei die sichere Laufzeitumgebung die volle Verantwortung für die Sicherheit der bereitgestellten Dienste übernimmt.
• Datenschutz: Das System stellt sicher, dass nicht vertrauenswürdige Module Daten weder lesen noch schreiben können, zu denen ihnen kein ausdrücklicher Zugriff gewährt wurde.
• Betriebssystemübertragbarkeit: Das System ermöglicht die Ausführung von nicht vertrauenswürdigen Modulen auf jedem Betriebssystem, das die sichere Laufzeitumgebung (für die x86-Architektur z. B. könnten nicht vertrauenswürdige Module im Windows^TM, MacOS^TM und Linux^TM Betriebssystem (Windows^TM ist eine Handelsmarke der Microsoft Corporation und Linux^TM ist eine Handelsmarke des Linux Mark Institute) unterstützt werden.
• Multi-Threading: Nicht vertrauenswürdige Module können multi-threaded sein.
• System-Implementierung und -Leistung: Das System ist so optimiert dass es nur eine kleine vertrauenswürdige Codebasis benötigt, wodurch Übertragbarkeit, Sicherheitsaudits und Validierung ermöglicht werden. Das System stellt Leistung für rechenintensive Module bereit, die mit ungeschützter Native-Code-Leistung vergleichbar ist, während ein mit virtuellen Maschinen- und sprachbasierten Methoden vergleichbares Sicherheitsniveau erreicht wird.
• Einfachheit der Modulimplementierung: Externe Entwickler können im System zu auszuführende Module mithilfe vertrauter Tools und Programmiertechniken leicht schreiben und debuggen.

Es ist zu beachten, dass das beschriebene System gleichzeitig sowohl Leistungs- und Übertragbarkeitsprobleme abdeckt als auch Sicherheitsrisiken eliminiert, wodurch es Entwicklern erlaubt, portable, nicht vertrauenswürdige Native-Code-Module in ihren Anwendungen zu verwenden, ohne zu verlangen, dass deren Benutzer die Sicherheit ihrer Geräte und/oder Daten riskieren.
In einer Ausführungsform der vorliegenden Erfindung beinhaltet das System: eine veränderte Kompilierungskette, die einen veränderten Compiler, Assembler und Linker umfasst, die zur Erzeugung sicherer, konformer Programmdateien verwendet werden; einen Lader/Validierer, der das Modul in einen Speicher lädt und bestätigt, dass das nicht vertrauenswürdige Modul mit einer Reihe von Anforderungen an die Code- und Steuerungsflussintegrität konform ist; und eine Laufzeitumgebung, die für Datenintegrität sorgt und steuert, ob und wie das Modul auf Ressourcen zugreifen kann. Die Kompilierungs- und Validierungsprozesse stellen sicher, dass unerwünschte Nebenwirkungen und Kommunikation für das nicht vertrauenswürdige Modul abgestellt werden, während die sichere Laufzeitumgebung eine moderierte Einrichtung bereitstellt. durch die ein begrenzter Satz erwünschter Kommunikation- und Ressourcenzugriffe sicher geschehen können. Diese Komponenten werden in den folgenden Abschnitten detaillierter beschrieben.
Kompilierung und Validierung von Native-Code-Modulen
In einer Ausführungsform der vorliegenden Erfindung stellen ergänzende Kompilierungs- und Validierungsprozesse sicher, dass nur sichere Native-Code-Module erzeugt und in das System geladen werden. Der Kompilierungsprozess involviert das Verwenden eines Compilers, eines Assemblers und eines Linkers, die gemeinsam ein systemkonformes binäres Native-Code-Modul erzeugen. Der Validator lädt dieses Native-Code-Modul in den Speicher und bestätigt, dass das Native-Code-Modul in der Tat systemkonform ist. Es ist zu beachten, dass das Validieren des kompilierten Moduls zur Ladezeit (als die letzte Handlung vor dem Ausführen) es dem System erlaubt, den Output des Compilers zu verwenden (wenn auch nicht zu trauen). Solche Validierung kann auch bösartige Handlungen feststellen, die versuchen, die Sicherheit des Native-Code-Moduls zwischen Kompilierung und Ausführung zu kompromittieren.
Es ist zu beachten, dass das System eine Kombination aus compilerbasierten Techniken und statischer binärer Analyse (z. B. Analyse von Assembler-Code während der Validierung) verwendet, um Sicherheit mit niedrigerem Ausführungsoverhead zu erreichen anstatt ausführbaren Code dynamisch zu analysieren und zur Laufzeit neu zu schreiben (wie dies gemeinhin in einigen virtuellen Maschinenumgebungen geschieht). Zusätzlich ermöglicht statische binäre Analyse das Implementieren der Validator- und Laufzeitumgebung in einer kleinen vertrauenswürdigen Codebasis, wodurch Sicherheitsverifizierung für die Codebasis ermöglicht und die Wahrscheinlichkeit von Bugs und/oder Verletzlichkeiten verringert werden. In einigen Ausführungsformen kann das System jedoch auch dynamische Analyse und Code-Neuschreib-Techniken verwenden.
In einer Ausführungsform der vorliegenden Erfindung involviert das Erzeugen eines systemkonformen Native-Code-Moduls das Befolgen eines Satzes von Sperren und oder Richtlinien, welche die Integrität und Sicherheit von Code, Steuerfluss und Daten bewahrt. Die Wahrung der Code-Integrität beinhaltet die Gewährleistung, dass das native Code-Modul ausschließlich „sichere” Befehle ausführen kann und sich zur Laufzeit durch eine Erzeugung dynamischen Codes keine unsicheren Befehle bzw. sich selbst verändernder Code einfügen lassen. Das Sperren des dem Native-Code-Modul zur Verfügung stehenden Befehlssatzes kann auch dabei behilflich sein, das Dekodieren des Native-Code-Moduls (während der Validierung) zuverlässiger zu machen. Das Bewahren von Steuerflussintegrität involviert das Sicherstellen, dass Steuerflussbefehle im Native-Code-Modul die Sicherheit nicht durch Aufrufen von Befehlen außerhalb des Native-Code-Moduls verletzen können. Die Wahrung der Datenintegrität beinhaltet die Gewährleistung, dass ein natives Code-Modul keine „wilden” Lese- oder Schreiboperationen ausführen kann (z. B. Lese- oder Schreiboperationen außerhalb einer bestimmten Datenregion, die mit dem nativen Code-Modul verknüpft ist).
In einer Ausführungsform der vorliegenden Erfindung hilft der Validierer bei der Sicherstellung von Code-, Steuerungsfluss- und Datenintegrität für ein x86-natives Code-Modul – unter anderem durch die Gewährleistung, dass bestimmte „unsichere” Befehle aus der x86-Befehlssatzarchitektur nicht in ein natives Code-Modul aufgenommen werden. So kann beispielsweise der Validator die Verwendung der folgenden Befehle und/oder Merkmale in einem Native-Code-Modul nicht erlauben:

• die Befehle syscall (system call; Systemaufruf) und int (interrupt; Unterbrechen), die versuchen, das Betriebssystem direkt aufzurufen;
• alle Befehle, die x86 Segmentstatus (einschl. LDS, FAR Aufrufe etc.) modifizieren, weil diese Befehle die Speichersegmente stören, die zur Durchsetzung von Datenintegrität dienen (siehe die Beschreibung von segmentiertem Speicher unten);
• die Befehle rdtsc (read time stamp counter) und rdmsr (read from model specific register) sowie andere Hardwareleistungsbefehle und/oder Merkmale, die von einem Native-Code-Modul dazu verwendet werden können, Seitenkanalangriffe durchzuführen (z. B. durch heimliches Ausgeben sensibler Informationen);
• verschiedene komplexe Adressiermodi, welche die Verifizierung der Steuerflussintegrität komplizieren;
• den Befehl ret (return), der eine Rücksprungadresse von einem Stapelort bestimmt und ersetzt wird durch eine Abfolge von Befehlen, die stattdessen einen durch das Register angegebenen Zielort verwenden (und daher nicht durch eine Wettlaufsituation verletzlich ist, die zulässt dass der Stapelort als Zielort für einen ersten Thread verwendet wird, der kurz vor Ausführung des Befehls „Return” bösartig (oder irrtümlich) durch einen zweiten Thread überschrieben werden soll sowie
• einige Aspekte von Ausnahme- und Signalfunktionalität – z. B. während das System C++ Ausnahmen (wie in der C++ Sprachenspezifikation definiert) unterstützen kann, unterstützt das System evtl. aufgrund von Betriebssystembegrenzungen keine Hardwareausnahmen (wie die Ausnahmen divide-by-zero (Division durch null) oder invalid memory reference (ungültige Speicherreferenz)) und kann die Ausführung eines nicht vertrauenswürdigen Native-Code-Moduls angesichts einer solchen Hardwareausnahme beenden.

Weiterhin sperrt das System zur Bereitstellung von wirksamer Codeentdeckung und Steuerintegrität auch einen Satz von Steuerungsübertragungsbefehlen. Insbesondere müssen nicht-modifizierte indirekte Steuerflussbefehle, die Ausführung an beliebige Orte im Speicher transferieren können, modifiziert werden, um zu garantieren, dass alle indirekten Steuerflussziele in Speicherregionen liegen, die für das Native-Code-Modul gültig sind. Eine Ausführungsform der vorliegenden Erfindung begrenzt indirekte Steuerflussbefehle dadurch dass: (1) die Befehle return, far call und far jump nicht erlaubt werden, (2) sichergestellt wird, dass die Befehle call und jump (jmp) nur relatives Adressieren erlauben und dergestalt in einer Befehlsabfolge kodiert sind, das der Steuerfluss innerhalb des Native-Code-Moduls bleibt; (3) sichergestellt wird, dass die indirekten Register-Befehle call und jump dergestalt in einer Befehlsabfolge kodiert sind, der Steuerfluss innerhalb des Native-Code-Moduls bleibt und auf gültige Befehlsadressen im Modul abzielt sowie (4) andere indirekte calls und jumps nicht erlaubt werden.
3A illustriert mehrere exemplarische Befehlsabfolgen, die sicherstellen, dass der Steuerfluss innerhalb eines gegebenen Native-Code-Moduls bleibt. Der Compiler kann in nativen Modulen zum Beispiel einen Pseudoaufrufbefehl 300 verwenden, der vor dem Aufruf einen logischen „and”-(and1) und einen logischen „or”-Befehl (or1) auf die Zieladresse (in Register R) anwendet, um sicherzustellen, dass die Zieladresse für den nativen Modulcode innerhalb der Grenzen eines Speichersegments maskiert ist. Ein überwiegend ähnlicher Pseudosprungbefehl 302 beinhaltet überwiegend ähnliche logische Maskierungsoperationen. Hinweis: Die tatsächlichen unmittelbaren Werte in Pseudoaufrufbefehl 300 und Pseudosprungbefehl 302 beinhalten zwei Parameter (TSAFETY_MASK und TEXT_BASE), die ausgefüllt werden müssen. Es ist zu beachten, dass diese Parameter nur durch tatsächliche Maskierungswerte zu der Zeit ausgefüllt werden können, zu der das System Codetextgröße und Speicherort kennt. So können beispielsweise die unmittelbaren Werte, die in Pseudobefehlen für ein gegebenes Native-Code-Modul verwendet werden, vom Linker zur Linkzeit oder vom Validator während des Validierungsprozesses geschrieben werden. Ein exemplarischer Pseudoaufrufbefehl mit Maskenwerten 304 steht für eine Gruppe von Werten, die das Aufrufziel auf ein mit 32 Byte angepasstes Ziel (wie von den unteren 'e0'-Bits im Befehl and1 angegeben) in einem Megabyte-Codebereich (wie von den aktivierten 'fffe'-Bits im Befehl and1 angegeben) begrenzt und dann die Basisadresse auf eine bestimmte Speicherregion (die bei Speicheradresse '0x00100000' beginnt, wie im Befehl or1 angegeben), die mit dem Code für das native Code-Modul verbunden ist, verschiebt.
Um Steuerflussintegrität sicherzustellen, begrenzen einige Ausführungsformen der vorliegenden Erfindung den Satz von Befehlen, die Steuerflussziele sein können. Beispielsweise stellt das System für die obigen Pseudobefehle sicher, dass die logischen Befehle im Pseudobefehl vor dem Befehl jump oder call ausgeführt werden. Ohne diese Garantie könnte sich ein anderer Befehlssatz bei einer gewünschten Zieladresse registrieren und dann direkt zum angegebenen Aufruf- oder Sprungbefehl abzweigen (oder den Steuerungsfluss anderweitig ändern), um die Maskierungsbefehle zu umgehen (und möglicherweise die Integrität des Steuerungsflusses zu verletzen). In einigen Ausführungsformen stellt das System sicher, dass indirekte jumps und calls nur auf einen begrenzten Adressensatz abzielen können. So kann beispielsweise es das System nur 32-Byte Grenzen erlauben, als Steuerflussziele zu dienen, und dann sicherstellen, dass die Befehle im Native-Code-Modul so ausgerichtet sind, dass alle Steuerflussziele entlang 32-Byte-Grenzen ausgerichtet sind, um diese Anforderung zu erfüllen. Das System kann die gewünschte Abstimmung zum Beispiel während des Kompilierungsverfahrens ausführen (z. B. ggf. durch Einfügen von Nulloperationen), wenn der Satz der Steuerungsflussziele in der Regel bekannt ist (zu solchen Zielen gehören z. B. oft Funktionen, Bezeichnungen, Rückkehroperationen von Funktionen und andere bekannte Ziele), und anschließend erneut bestätigen, dass das native Code-Modul im Validierer ordnungsgemäß abgestimmt wird. Es ist zu beachten, dass die Granularität der Zielausrichtung im System auf der Grundlage einer Reihe von Faktoren angepasst werden kann, wie z. B. der maximalen Befehlsgröße für eine gegebene Architektur und dem größten Satz der erforderlichen aufeinander folgenden, nicht-anvisierbaren Befehle. Für die x86 Architektur könnte das System Ziele zur Erleichterung der Maskierung z. B. entlang 16-Byte, 32-Byte, 64-Byte oder sonstigen Zweierpotenz-Grenzen ausrichten. Ausrichtungsgranularität kann auch auf der Grundlage von Schätzungen assoziierter Overheads bestimmt werden. Es ist zu beachten, dass eine größere Ausrichtungsgranularität zu unerwünschten Zunahmen in Codegröße aufgrund des gestiegenen Polsterns mit no-op führen kann.
3B illustriert eine Speicherregion, die mit 32-Byte-Grenzen ausgerichtet ist und einen Pseudobefehl enthält. Da in diesem Beispiel indirekte Sprünge und Aufrufe an jede abgestimmte 32-Byte-Adresse übertragen können, darf kein Befehl (auch keine Unterbefehle der Pseudobefehle) eine 0mod32-Grenze überlappen (z. B. Speicheradressen 0x00100120 oder 0x00100100, die beide als Abzweigungsziele dienen könnten – anders als der Aufrufbefehl bei Speicheradresse 0x0010011c). Beachten Sie außerdem, dass der Aufrufbefehl (bei Speicheradresse 0x0010011c) so abgestimmt werden muss, dass die folgende Adresse ein gültiges Ziel darstellt und der Sprungbefehl, der von der aufgerufenen Funktion zurückkehrt, zum aufrufenden Punkt zurückkehren kann.
In manchen Ausführungsformen der vorliegenden Erfindung nutzt das System Schutz durch hardwarebasierten segmentierten Speicher, um die Integrität von Daten und Steuerungsflüssen zu verbessern. Speichersegmente sind ein üblicher Mechanismus zur Implementierung von Speicherschutz, der auf Systemen wie z. B. IBM 360, CDC 6600 und auf Intel 80286-kompatiblen Systemen (z. B. den meisten x86-basierten Systemen) unterstützt wird. Speichersegmente sind mithilfe eines Satzes von Befehlen und Registern manipulierbar, die eine Basisadresse und Grenzen für ein gegebenes Speichersegment etablieren, wobei die Hardware sicherstellt, dass Speicherzugriffe während segmentierten Betriebs auf Adressen zwischens der Basisadresse und den Grenzen des Speichersegments begrenzt sind. So kann beispielsweise das System für die x86 Architektur Werte in den Segmentregistern zur Kontrolle des Datenzugriffbereichs sowie zur Art setzen, in welcher der Befehlszeiger für das Codesegment interpretiert wird (z. B. mithilfe des Codesegment(CS)-Registers) um sicherzustellen, dass: (1) Datenzugriffe für das Native-Code-Modul auf ein spezifisches Datensegment begrenzt sind, wodurch Datenintegrität sichergestellt wird sowie (2) die Codetextregion für jedes Native-Code-Modul bei einer Adresse null anfängt. Nach dem Einrichten des Segmentstatus (z. B. dem richtigen Einrichten eines Satzes von Segmentsteuerregistern) und Sicherstellen, dass nicht vertrauenswürdiger Code diesen Segmentstatus nicht ändern kann, kann es Native-Code-Modulen erlaubt werden, dieselben, von anderen Programmen benutzten Datenreferenzbefehle zu verwenden, wobei aber die Hardware aktiv sicherstellt, dass Codebefehle und Datenreferenzen abgeschirmt sind. Dabei kann das System hardwaregestützten segmentierten Speicher (wie segmentierten Speicher in der x86-Architektur) nutzen, um eine „Isolierung von Hardwarefehlern” zu ermöglichen. Eine solche Hardwarefehlerisolierung eliminiert die Notwendigkeit der Verwendung spezieller Abschirmungssequenzen für Datenreferenzen, was die Leistung zu verbessern hilft und es einfacher macht, Compiler zum Erzeugen von Native-Code-Modulen zu adaptieren. Hinweis: In manchen Ausführungsformen, bei denen keine Hardwareunterstützung für Speichersegmente nicht verfügbar oder aufrufbar ist, kann das System jedoch auf Sandboxing-Verfahren für Datenreferenzen zurückgreifen, die mit softwarebasierter Fehlerisolierung für Datenintegrität sorgen (wahrscheinlich auch mit einem zusätzlichen Performance-Overhead).
In einigen Ausführungsformen der vorliegenden Erfindung vereinfacht die Verwendung von Hardware zur segmentierten Speicherunterstützung für Native-Code-Module die für die zuvor beschriebenen Pseudobefehle notwendigen Maskierungsoperationen. Da das System hardwarebasierten segmentierten Speicher verwenden kann, um den Codetext des nativen Code-Moduls bei Adresse zero (0x00000000) zu basieren, ist kein Basis-Speicher-Offset erforderlich, und das System kann den Befehl or1 aus den Pseudobefehlen entfernen. Da nun die Ausführung von Out-of-Bound-Befehlen vom segmentierten Speicher verhindert wird, muss das System zudem die übergeordneten Bits des Befehls and1 nicht mehr maskieren. Für Befehlssätze mit Befehlen von variabler Größe (wie die x86 Architektur) kann dies ermöglichen, dass die Pseudobefehle einen einfacheren (und kleineren) Befehl and verwenden.
3C illustriert Pseudobefehle mit reduzierter Größe, die in Verbindung mit hardwaresegmentierter Speicherunterstützung verwendet werden können. Die Pseudobefehle für Aufruf 306 und Sprung 308 mit zwei Befehlen, die sich in nativen Code-Modulen nutzen lassen, benötigen nun lediglich einen weiteren Befehl, der dafür sorgt, dass das Steuerungsflussziel abgestimmt wird (in diesem Fall auf 32-Byte-Grenzen, angegeben durch den Wert 0xE0, der von der Hardware bei Ausführung des logischen Befehls „and” auf 0xFFFFFFE0 erweitert wird. 3C illustriert sowohl exemplarische Befehlssequenzen 310 für die Pseudobefehle mit zwei Befehlen als auch exemplarische x86-Bytesequenzen 312 (inkl. x86-Befehls-Opcodes und unmittelbarer Werte) für die beiden Versionen der Pseudosprungbefehle 308 und 302. Der Pseudosprungbefehl 308 mit zwei Befehlen nutzt lediglich fünf Byte (beachten Sie, dass das Prozessorsignal den Wert 0xE0 auf 0xFFFFFFE0 erweitert, sodass sich Zwei-Byte-Befehle verwenden lassen), während die Bytesequenz 312 für den vorherigen Pseudosprungbefehl 302, der in 3A dargestellt ist, 12–14 Byte nutzen kann (je nach verwendetem Befehl und Registern), wobei Oxqqrrsstt eine 4-Byte-Konstante ist, die die nächste Zweierpotenz repräsentiert, welche größer als das Textsegment minus der Abstimmung ist, und Oxuuvvwwxx die Ladeadresse des Textsegments ist. Es ist zu beachten, dass das Verringern der Bytegröße der Pseudobefehlsabfolgen die mit den zuvor beschriebenen Techniken assoziierten Codegrößezunahmen verringern kann.
In einer Ausführungsform der vorliegenden Erfindung ruft das System einen Lader auf (der in den Validator integriert werden oder als separate Komponente existieren kann), wenn ein nicht vertrauenswürdiges Native-Code-Modul empfangen wird. Der Lader liest den ausführbaren Inhalt und unterstützende Daten für das Modul und lädt das Modul unter Berücksichtigung von Faktoren wie Ausrichtungssperren und relative Position in den Speicher. (Es ist zu beachten, dass, wenn hardwareunterstützte Speichersegmente nicht unterstützt oder gemeinsam benutzte Bibliotheken benutzt werden, der Lader dann möglicherweise auf mit dem Modul assoziierte Umsetzungsdateien zugreifen muss, um Adressen auf der Grundlage der tatsächlichen Ladeadresse für die verschiedenen Modulsegmente zu aktualisieren. Beachten Sie, dass diese Ladefunktionen jenen ähneln, die oft von einem Betriebssystem verwendet werden (z. B. der Systemaufruf exec () in UNIX^® (UNIX^® ist eine eingetragene Marke von The Open Group)). Der Lader kann auch einige der Codeabfolgen im Native-Code-Modul bearbeiten, um Laufzeitdurchsetzung von Steuerflussintegrität durchzusetzen. Nach dem Laden des Moduls und der Anwendung der Umsetzungen kann das System den ausführbaren Inhalt validieren.
4 illustriert das Layout eines Native-Code-Moduls, das in ein Speichersegment geladen wurde. Wie zuvor beschrieben, kann das System Datenintegrität dadurch garantieren, dass es Segmentstatus so einrichtet, dass dem nicht vertrauenswürdigen Native-Code-Modul ein Datenzugriff nur auf eine Datenregion 400 (z. B. mithilfe von x86 Segmentregistern) erlaubt ist. Datenregion 400 des Native-Code-Moduls reicht von der Datenbasisadresse (DB) 402 bis zur Datengrenzadresse (DL) 404 und teilt Platz für die Stapel 406 jedes Threads (im Native-Code-Modul), Daten für Threads und einen anwendungsverwalteten Heap 408 sowie Datenplatz 410 für globale Variablen zu. Eine schreibgeschützte Codetextregion 412 für das Native-Code-Modul reicht von Textdatenbankadresse (TB) 414 zur Textgrenzadresse (TL), die DB 402 entspricht. Beachten Sie, dass sich Codetextregion 412 Element 418 über die tatsächliche Größe von Code 416 hinaus hinzufügen lässt (zum Beispiel durch Verwendung von 1-Byte-No-Op- und/oder 1-Byte-Halt(Hlt)-Befehlen), sodass die Größe von Textregion 412 eine gerade Zweierpotenz ist (z. B. um die Maskierung von Steuerungsflussoperationen zu vereinfachen). Zur Ermöglichung der Implementierung kann Codetextregion 412 auch bei einer Startadresse null statisch verlinkt sein (z. B. einen nullbasierten Adressbereich für das Native-Code-Modul bereitstellen). Der Validator kontrolliert, dass Befehle in Code 416 sich nur auf Daten in Datenregion 400 beziehen können. Es ist jedoch zu beachten, dass Befehle beliebig jeden Ort innerhalb der Datenregion lesen oder schreiben können und der Validator und die Laufzeitumgebung evtl. Typsicherheit oder feinkörnigere Grenzsperren nicht durchsetzt. Es ist außerdem zu beachten, dass obwohl das Laufzeitsystem die Daten des Native-Code-Moduls lesen kann, ersteres jedoch sehr vorsichtig sein muss und diesen Daten nicht trauen darf, wenn diese sich auf die Systemsicherheit auswirken können. Insbesondere garantieren der Validierer und die Laufzeitumgebung, dass das native Code-Modul sicher ist; sie garantieren jedoch nicht, dass vom nativen Code-Modul ausgeführte Operationen bzw. erzeugte Werte „richtig” sind (die vom Programmierer beabsichtigten und/oder vom Benutzer gewünschten Aktionen oder Werte richtig ausführen bzw. erzeugen).
Zur Sicherstellung von Steuerintegrität und Datenintegrität erlaubt das System nur Befehlen im Code 416, Steuerung an gültige Befehle in Textregion 412 zu übertragen. Wie zuvor erwähnt, verhindert das System Sprünge mitten in einen Befehl oder eine kritische Befehlsabfolge durch statisches Kontrollieren direkter Steuerflussübertragungen und Sicherstellen, dass indirekte Steuerübertragungen eine Steuerung nur an ausgerichtete Ziele übertragen kann (über no-op Polsterung). Das Native-Code-Modul muss jedoch eine Möglichkeit haben, Ergebnisse an externe Clients zu kommunizieren und, wie erlaubt, Anforderungen an das Laufzeitsystem zu stellen. In einer Ausführungsform der vorliegenden Erfindung bietet das System eine eingeschränkte Systemaufrufschnittstelle, die sich nur über bestimmte „Trampolinbefehle” (oder „Trampoline”) 420 in Textregion 412 aufrufen lassen. Diese Trampolinbefehle 420 schließen einen begrenzten Satz von sicheren (und ausgerichteten) Eingangspunkten in die Laufzeitumgebung bereit, die vom Lader/Validator mit vertrauenswürdigem Code initialisiert werden und Steuerung an vertrauenswürdigen Laufzeitcode und/oder -dienste 422 übertragen können. Diese Trampolinbefehle 420 sind der einzige Mechanismus, der zur Übertragung von Steuerfluss in das und aus dem nicht vertrauenswürdigen Native-Code-Modul verwendet werden können. Da diese Trampolinbefehle 420 vertrauenswürdige Befehle sind, die von der sicheren Laufzeitumgebung erzeugt werden, können sie Befehle einschließen, die andernfalls in einem nicht vertrauenswürdigen Native-Code-Modul illegal wären. So kann beispielsweise ein Satz von Trampolinbefehlen, der in den untersten Teil der Textregion 412 erzeugt und eingesetzt wird, zum Übertragen von Steuerung an andere vertrauenswürdige Routinen in der sicheren Laufzeitumgebung oder zum Senden und Empfangen von Nachrichten an die Client-Laufzeit oder sonstige Dienste verwendet werden. Es ist zu beachten dass, wenn das System hardwareunterstützte Speichersegmente verwendet, Trampolinbefehle 420 dazu verwendet werden können, Segmentierung zu deaktivieren und das System zur Ausführung von vertrauenswürdigem Code auf (vertrauenswürdige) flache Adressierung zurückzusetzen. Ähnlich kann die sichere Laufzeitumgebung, wenn der vertrauenswürdige Code die Steuerung an das Native-Code-Modul zurückgibt, den Steuerfluss an einen Satz Trampolinbefehle 420 übertragen, welche die segmentierte Speicherunterstützung wieder etablieren (und dadurch Daten-, Code- und Steuerflussintegrität wieder aktivieren). Ein Satz Trampolinbefehle kann bezüglich seiner Granularität für spezifische Native-Code-Module angepasst werden, wobei die sichere Laufzeitumgebung nur Trampolinbefehle für den Satz der erlaubten Zugriffe des gegebenen Native-Code-Moduls erzeugt. Es ist zu beachten, dass die Trampolinbefehle auf den niedrigsten Teil (z. B. die niedrigsten 8 Kbytes) von Textregion 412 beschränkt sind und überall in Textregion 412 platziert werden können. Es ist auch zu beachten, dass das System eine separate, sichere Datenregion 424 unterhalten kann, die Daten bezüglich der Laufzeit und/oder sonstiger Dienste speichert (z. B. vom Speichern des internen Browserstatus, Dateipuffer etc.).
In einer Ausführungsform der vorliegenden Erfindung führt der Validator eine binäre statische Analyse durch, die bestätigt, dass ein nicht vertrauenswürdiges Native-Code-Modul dem zuvor beschriebenen Satz von Sicherheitsbeschränkungen entspricht. Der Validator überprüft den Codeabschnitt jedes geladenen Native-Code-Moduls, decodiert alle ausführbaren Befehle mithilfe von Sequential Traversal des Befehls-Streams, der an der Lade-(Basis-)Adresse beginnt. Wie zuvor beschrieben weist der Validator ein Native-Code-Modul zurück, wenn er Mängel findet, wie z. B.: illegale/nicht erlaubte Befehle; Ausrichtungsmängel; direkte Verzweigungen mit einem ungültigen Verzweigungsziel und/oder nicht-sichere indirekte Aufrufe oder Sprünge (welche den zuvor beschriebenen Zielbereich und Ausrichtungssperren nicht befolgen). Beachten Sie, dass der Validierer den Code nicht vollständig disassemblieren muss (z. B. die Operanden von Befehlen nicht komplett auflösen oder den Befehlssatz in eine für Menschen lesbare Form reduzieren muss), sondern stattdessen die Opcodes und Längen der Befehle im Befehlsfluss decodieren können. Während des Decodierungs-Traversal erzeugt und unterhält der Validator zwei Tabellen: eine Tabelle mit gültigen Steuerflusszielen (VTT) und eine Tabelle bekannter Steuerflussziele (KTT). Jeder gültige (ausgerichtete) Befehl, der beim Traversal im schreibgeschützten Codesegment vorkommt, wird in der VTT als gültig markiert, und alle unmarkierten Befehle werden als (zu Ausrichtungszwecken) ungültig betrachtet. Beim Traversal erkennt der Validator außerdem alle Steuerflussbefehle und merkt die Bestimmungsadressen statischer Ziele in der KTT an. Für Befehle mit einem zur Laufzeit berechneten Ziel bestätigt der Validator, dass der Befehl Teil einer Mehrbefehlsabfolge mit den vom Lader gesetzten angemessenen Maskenwerten ist und markiert Zwischenbefehle in der Mehrbefehlsabfolge in der VTT als ungültig. Nach dem Decodieren des Codetextsegments (das mehrere Abschnitte einschließen kann) traversiert der Validator die KTT, um zu bestätigen, dass jedes Ziel in der VTT als gültig markiert ist. An diesem Punkt entdeckt der Validator von Maskierungsbefehlen (von einem Pseudobefehl) verursachte nicht-sichere Situationen, die eine ausgerichtete Bytegrenze überlappen (und in der VTT beim Traversal als ungültig markiert wurden). Der Validierer überprüft außerdem, ob alle indirekt zielfähigen Befehle (z. B. alle Befehle innerhalb der abgestimmten Bytegrenzen) im VTT enthalten sind (z. B. um sicherzustellen, dass alle indirekten Abzweigungsziele gültig sind). Es ist zu beachten, dass der beschriebene statische Decodierprozess mithilfe einer relativ kleinen Codemenge implementierbar ist, was die Verifizierung der Sicherheit und Richtigkeit des Validators erleichtert. Beachten Sie außerdem, dass das Codetextsegment auf „reinen Text” beschränkt sein muss und keine kleine Gruppe an problematischen Funktionen und/oder Strukturen (wie statische Daten oder Switch-Tabellen), die vom beschriebenen Decodierungsverfahren als falsche Befehle interpretiert werden können, enthalten dürfen. Obwohl das Einflechten von schreibgeschützten Daten im Befehlsstrom Leistungsvorteile haben kann, könnten solche Daten im Codetextsegment auch unerwünschte Komplexität für die Logik hinzufügen, welche Byteabfolgen von nicht vertrauenswürdigen Befehlen entdeckt.
5 zeigt ein Flussdiagramm, welches das Verfahren zum Validieren eines auf einem Computergerät auszuführenden nicht vertrauenswürdigen Native-Code-Moduls illustriert. Beim Betrieb empfängt das System ein auf einem Computergerät auszuführendes nicht vertrauenswürdiges Native-Code-Modul (Operation 500). Dieses Native-Code-Modul umfasst nicht vertrauenswürdigen nativen Programmcode, der in der mit dem Computergerät assoziierten Befehlssatzarchitektur ausgedrückt ist. Als Nächstes validiert das System das Native-Code-Modul um zu bestätigen, dass das Modul sicher ausgeführt werden kann (Operation 510). Dabei bestimmt das System zunächst, ob der Befehlssatz im Native-Code-Modul gesperrte Befehle einschließt und/oder auf gesperrte Merkmale des Computergeräts zugreift (Operation 520). Ist dies der Fall, weist das System das Native-Code-Modul zurück (Operation 550) und der Prozess wird beendet. Ist dies nicht der Fall, bestimmt das System, ob der Befehlssatz im Native-Code-Modul so mit Bytegrenzen ausgerichtet ist, dass ein vorgegebener Satz von Bytegrenzen stets einen gültigen Befehl (Operation 530) enthält. Ist dies der Fall, und wenn alle Steuerflussbefehle im Native-Code-Modul gültige Ziele haben (Operation 540), fährt das System fort und führt das erfolgreich validierte Native-Code-Modul in einer sicheren Laufzeitumgebung aus (Operation 560). Andernfalls weist das System das Native-Code-Modul zurück (Operation 550). Durch Validieren des Native-Code-Moduls ermöglicht das System das sichere Ausführen des Native-Code-Moduls in der sicheren Laufzeitumgebung auf dem Computergerät, wodurch Leistung erreicht wird, die substanziell der von vertrauenswürdigem nativem Code für nicht vertrauenswürdige Programmbinaries ähnelt, ohne erhebliches Risiko von unerwünschten Nebenwirkungen.
Ein systemkonformer Satz von Kompilierungs-Tools kann dem Validator behilflich sein durch Erzeugen richtig ausgerichteter Native-Code-Module, welche die indirekten Aufruf-/Sprung-Pseudobefehle korrekt verwenden, keine nicht erlaubten Befehle, Merkmale und/oder Befehlsabfolgen einschließen und vom Validator zuverlässig decodierbar sind. Es ist zu beachten, dass das Erzeugen von sicheren ausführbaren Programmen normalerweise involviert, dass nur eine geringe Anzahl relativ örtlicher Änderungen an bestehenden Kompilierungs-Toolketten vorgenommen wird, was den erforderlichen Modifizierungssatz für Hersteller verringert, die ausführbare Dateien erzeugen wollen, die mit dem beschriebenen System kompatibel und darin sicher ausführbar sind. Zu spezifischen Änderungen können gehören: Modifizieren eines Assemblers zum Hinzufügen der oben beschriebenen Pseudobefehlssequenzen und Durchsetzen der Abstimmung von Befehlen; und Modifizieren eines Compilers zum Ändern erzeugter Codesequenzen, um den oben beschriebenen indirekten Steuerungsfluss widerzuspiegeln und die Abstimmung zwischen Funktionen und Bezeichnungen vorzunehmen. Die vom Validator überprüften Anforderungen brauchen nicht geheim gehalten zu werden und können offen veröffentlicht werden (ohne die Sicherheit zu kompromittieren) damit jeder einen Satz Kompilierungs-Tools für das System erzeugen und/oder existierende Kompilierungs-Tools einfach modifizieren kann, um konforme Native-Code-Module zu erzeugen. Weil das System nur dem Validator und nicht dem Compiler traut, bestätigt der Validator immer, dass der Output eines gegebenen Compilers die Standards sicherer Ausführung erfüllt und weist alle Native-Code-Module zurück, die nicht konform sind und die statische binäre Analyse nicht bestehen. Die Outputs des Kompilierungsprozesses können binäre Standardformate verwenden (z. B., die Form vereinfachter, selbständiger 32-Bit x86 ELF umsetzbarer Binaries), die mithilfe herkömmlicher Debugging-Tools debuggbar sind. Daher können Programmierer, die Sprachen wie C und C++ vorziehen, weiterhin Sprachen und Kompilierungs-Tools verwenden, die substanziell dem ähneln, was sie bisher verwendet haben. Es ist zu beachten, dass fein abgestimmte, von Hand codierte Assemblerabfolgen und/oder Compiler Eigenes (z. B. manuelle Microarchitekturoptimierungen) auch für Native-Code-Module verwendbar ist, solange es die obigen Anforderungen erfüllt (z. B. die vorgegebenen Ausrichtungsanforderungen und Befehlssperren).
Es ist zu beachten, dass das beschriebene System bereits vorhandene nicht-konforme Binaries evtl. nicht ausführt und stattdessen erfordern kann, dass eine Anwendung mithilfe eines konformen Kompilierungsprozesses als konformes Native-Code-Modul neu aufgebaut wird. In einigen Ausführungsformen kann das System jedoch nicht-konforme Binaries mithilfe von Binary-Übersetzungstechniken unterstützen, die das Niveau von Sicherheitsgarantien erreichen, das zur Genehmigung durch den Validator erforderlich ist. Solche Binary-Übersetzungstechniken können in Szenarien verwendet werden, in denen es wünschenswert ist, Code aus Quellen zu inkorporieren, die ihre Kompilierungs-Toolketten nicht modifizieren können oder wollen, sodass sie konforme Native-Code-Module unterstützen. Normalerweise involviert die Verwendung einer konformen Kompilierungs-Toolkette weniger Overhead im Softwareentwicklungprozess für Native-Code-Module, weil ein Binary-Übersetzer evtl. nicht vollkommen zuverlässig sein kann und einiges Experimentieren von den Entwicklern erfordern kann, um ein Modul zu erzeugen, das erfolgreich validiert werden kann.
Weil nicht vertrauenswürdige Native-Code-Module auf der Hardware von Computergeräten nativ ausgeführt werden, ermöglichen die zuvor beschriebenen Techniken es dem System, auf sichere Weise Leistung zu erreichen, die substanziell der Leistung der Ausführung von vertrauenswürdigem nativem Code ähnelt, ohne Sicherheitsabstriche zu machen. Es ist zu beachten, dass die Codegröße von Native-Code-Modulen aufgrund zusätzlicher Befehle in Pseudobefehlsabfolgen und ausrichtungsbedingtem Polstern zunehmen kann. Jedoch ist die Auswirkung auf die Leistung normalerweise auch begrenzt, weil Befehlszwischenspeicher nun sehr groß sind und oft effizienter arbeiten, wenn indirekte Verzweigungsziele ausgerichtet sind, und die Anzahl indirekter Steuerflussbefehle normalerweise nicht groß ist. Daher stellt das System Ausführungsleistung bereit, die substanziell der Leistung ungeschützten nativen Codes ähnelt und bessere Leistung als andere existierende Methoden (wie interpretierte Sprachen und virtuelle Ausführungsumgebungen) hat.
Zusammenfassend sei festgehalten, dass der Kompilierungsprozess ein systemkonformes Native-Code-Modul erzeugt, das validiert werden kann, um zu bestätigen, dass der ausführbare Inhalt im Native-Code-Modul einen Satz gewünschter Sicherheitsanforderungen erfüllt. Überdies erlauben die von der modifizierten Kompilierungs-Toolkette, dem Lader und dem Compiler verwendeten, beschriebenen Techniken nicht vertrauenswürdige Native-Code-Module, die in einer sicheren Laufzeitumgebung sicher und mit der Leistung von nativem Code ausführbar sind. Die sichere Laufzeitumgebung, die Ausführungsüberwachung für das nicht vertrauenswürdige Native-Code-Modul durch Moderieren der Interaktionen zwischen dem Modul und anderen Software- oder Hardwareentitäten bereitstellt, wird im folgenden Abschnitt detaillierter beschrieben.
Eine sichere Laufzeitumgebung
Wie zuvor beschrieben, stellen die Kompilierungs- und Validierungsprozesse sicher, dass Native-Code-Module Systemanforderungen erfüllen und daher keine unerwünschten, sich auf die Sicherheit auswirkenden Nebenwirkungen haben. Während das Isolieren von Native-Code-Modulen gegenüber allen anderen Software- und Hardwarekomponenten die Sicherheit bewahrt, werden Softwaremodule jedoch normalerweise nicht isoliert ausgeführt und müssen Ergebnisse an eine Client-Anwendung kommunizieren und/oder auf Systemressourcen zugreifen. Ausführungsformen der vorliegenden Erfindung erlauben begrenzte Kommunikation zwischen dem Native-Code-Modul und anderen Systemkomponenten mithilfe einer sicheren Laufzeitumgebung.
In einer Ausführungsform der vorliegenden Erfindung leistet die sichere Laufzeitumgebung Folgendes:

• bietet die Möglichkeit, Native-Code-Module zu laden und zu starten;
• bietet eine Ausführungsumgebung für Native-Client-Module, die Kommunikation, Threads, Speicherverwaltung und Debugging-Unterstützung einschließt;
• regelt den Zugriff auf Systemressourcen mittels einer einfachen Zugangsrichtlinie, die sicherstellt, dass native Code-Module nicht gegen Einschränkungen beim System- und Datenschutz verstoßen;
• unterstützt mehrere voneinander isolierte Native-Code-Module und
• kann in einer kleinen Codemenge implementiert werden, der sowohl leicht auditierbar als auch übertragbar auf mehrere Betriebssysteme ist, die auf derselben Hardwarearchitektur laufen.

Die sichere Laufzeitumgebung moderiert sowohl, auf welche Ressourcen durch das Native-Code-Modul zugegriffen (und mit welchen kommuniziert) werden kann, als auch wie auf solche Ressourcen zugegriffen wird, und stellt damit sicher, dass das Native-Code-Modul zum Zugreifen auf Systemdienste vollkommen auf die sichere Laufzeitumgebung angewiesen ist und keine sensiblen Operationen ohne ausdrückliche Vermittlung ausführen kann. Zum Beispiel kann ein natives Code-Modul weder den Zustand von Dateisystemen lesen oder ändern noch Netzwerk-(bzw. Inter-Modul- oder Inter-Prozess-)Kommunikation initiieren bzw. außerhalb einer isolierten „Sandbox” Berechnungen durchführen. Hierfür benötigt es die sichere Laufzeitumgebung, die solche Interaktionen (wenn zulässig) für das Modul erledigt.
In einigen Ausführungsformen der vorliegenden Erfindung schließt die sichere Laufzeitumgebung mehrere Aspekte von Laufzeitfunktionalität ein. Die sichere Laufzeitumgebung kann z. B. Folgendes einschließen:

1. Client-Laufzeitfunktionalität, die eine Schnittstelle bereitstellt, die es Client-Anwendungen erlaubt, Dienste auf der Grundlage von nicht vertrauenswürdigen Native-Code-Modulen zu erstellen und mit solchen Diensten zu kommunizieren;
2. Service-Laufzeitfunktionalität, die als Anwendungsausführungsumgebung dient, die Native-Code-Module im Auftrag von Clients lädt und startet und Zugriff auf eine Gruppe von grundlegenden Systemdiensten bereitstellt, während die Isolierung der beabsichtigten Sicherheitsdomains sichergestellt ist;
3. IMC(inter-module communication)-Laufzeitfunktionalität, die Mechanismen für Kommunikation zwischen vertrauenswürdigen Modulen und der Service-Laufzeit bereitstellt sowie
4. Entwickler-Laufzeitfunktionalität, die während der Entwicklung mit den nicht vertrauenswürdigen Native-Code-Modulen verbunden ist, um Kommunikation mit anderen Aspekten der sicheren Laufzeitumgebung zu ermöglichen.

1. Client-Laufzeit:
Weil viele verschiedene Anwendungstypen Zugriff auf die Native-Code-Leistung der Native-Code-Module suchen können, stellt die Client-Laufzeit eine generelle externe Schnittstelle zur Interaktion mit solchen Modulen bereit. So kann beispielsweise die Client-Laufzeit: Einrichtungen zum Laden und Entladen von Native-Code-Modulen bereitstellen; Clients den Satz von Funktionen zeigen, die von einem Native-Code-Modul unterstützt werden (z. B. Offenlegen einer Liste von für das Native-Code-Modul verfügbaren externen Verfahrensaufrufen); und Hooks bereitstellen, welche die Clientumgebung zum Aufrufen solcher Funktionen verwenden kann. Wird das Native-Code-Modul in einem von einer Client-Anwendung separaten Prozess und/oder Adressenraum ausgeführt, kann die Client-Laufzeit auch für das Rangieren von Daten zwischen den beiden Entitäten verantwortlich sein.
In einigen Ausführungsformen der vorliegenden Erfindung kann das System mehrere Client-Laufzeiten involvieren, die verschiedene Client-Typen unterstützen. So kann beispielsweise in einer Browserumgebung Client-Laufzeit-Funktionalität zum Unterstützen von JavaScript^TM in einem Browser-Plug-In eingeschlossen sein, die es JavaScript^TM-Anwendungen erlaubt, Funktionen in Native-Code-Modulen zu laden, entladen und aufzurufen. So kann beispielsweise das Plug-In eine loadURL-Funktion bereitstellen, die es einer JavaScript^TM-Anwendung erlaubt, die URL (uniform resource locator) für ein gewünschtes Native-Code-Modul vorzugeben und Rückrufbenachrichtigungen zu erhalten, die anzeigen, ob das Laden erfolgreich war oder nicht. Bei erfolgreichem Laden kann die Client-Laufzeit eine Liste von mit dem Modul assoziierten, aufrufbaren Funktionen an die JavaScript^TM-Anwendung zusammen mit Informationen über die für jede Funktion verfügbaren Parameter exportieren. In einigen Ausführungsformen können die Client-Laufzeit (und Native-Code-Module) einen Typ Deskriptorkonvention unterstützen, der das Rangieren von Parameter und Rücksprunginformationen zwischen einer Client-Anwendung und einem Native-Code-Modul in Form eines Arrays von schreibgeschützten Werten ermöglicht. (Es ist zu beachten, dass aufgrund von Sicherheitsproblemen kein Hinweisadressen verwendet werden dürfen, um Parameter und Rücksprunginformationen zwischen einer Client-Anwendungen und Native-Code-Modulen weiterzugeben).
Es ist zu beachten, dass die vom Native-Code-Modul bereitgestellte Funktionalität je nach Client-Anwendung unterschiedlich verwendet und/oder darauf zugegriffen werden kann. Vom nativen Code-Modul exportierte Funktionen können zum Beispiel blockierender oder nicht blockierender Art sein, und die von verschiedenen Clientanwendungen verwendeten Eintrittspunkte in ein natives Code-Modul können variieren. Beispielsweise könnte ein Native-Code-Modul Berechnungen nur als Reaktion auf von einer Client-Anwendung aufgerufenen individuellen Funktionen durchführen oder es kann stattdessen kontinuierlich eine Message-Dispatch-Loop überwachen, die Input von einem gemeinsam benutzten Speicherpuffer (siehe unten) oder einem sonstigen Ereignisschlangenmanagement erhält.
2. Service-Laufzeit:
In einigen Ausführungsformen der vorliegenden Erfindung stellt die Service-Laufzeit Funktionalität bereit, die der eines Betriebssystems ähnelt, z. B. Laden und Starten von Modulen im Auftrag der Hostberechnung, Bereitstellen von Zugriff auf einen Satz grundlegender Systemdienste und Sicherstellen der Isolierung zwischen den separaten Sicherheitsdomains von Client-Anwendungen und nicht vertrauenswürdigen Native-Code-Modulen. Weil Native-Code-Module auf den nativen Betriebssystemkernel nicht direkt zugreifen dürfen, werden alle Kommunikations- und Systemdienstanforderungen von den Native-Code-Modulen bei der Service-Laufzeit eingereicht. Diese Mittlerrolle ermöglicht es der Service-Laufzeit, alle Kommunikation und Zugriff auf Systemressourcen zu vermitteln und eine Zugriffskontrolle durchzusetzen, die strikter ist als die des zugrunde liegenden nativen Betriebssystems.
In einer Ausführungsform der vorliegenden Erfindung nimmt die Service-Laufzeit beim Empfangen einer Anforderung von der Client-Laufzeit zum Laden eines Native-Code-Moduls Folgendes vor:

1. teilt Speicher zum Aufbewahren des Native-Code-Moduls zu;
2. lädt oder lädt das Native-Code-Modul herunter und lädt Text und Daten des Native-Code-Moduls in den Speicher;
3. Initialisiert alle benötigten statisch-initialisierten Daten und aktualisiert, falls notwendig, die Konstantenfelder in allen Maskierungsbefehlen (wie zuvor für Pseudobefehle beschrieben);
4. Fügt Laufzeitinformationen für das Native-Code-Modul hinzu (wie die zuvor beschriebenen Trampolin-Befehle, zusammen mit den korrekten Sprungadressen);
5. Betreibt den Validator am Native-Code-Modul (wie zuvor beschrieben), deaktiviert (optional) alle vom Validator entdeckten ungültigen Befehle;
6. Stellt sicher, dass die Speicherseiten für den ausführbaren Code des Native-Code-Moduls geschützt sind und dass Datenintegritätsmechanismen aktiv sind für das Datensegment des Native-Code-Moduls;
7. Errichtet den Heap für das Native-Code-Modul und
8. Errichtet, wenn vom aufrufenden Client vorgegeben, Anfangsargumente und Sprünge zu einem Eingangspunkt für das Native-Code-Modul.

Es ist zu beachten, dass das Laden des Native-Code-Moduls auch das Durchführen eines Satzes von Verlagerungen für das Native-Code-Modul involviert (z. B. wie vorgegeben in einer Verlagerungstabelle für das Native-Code-Modul), wenn gemeinsam benutzte Bibliotheken oder nicht auf null basierende Segmente verwendet werden. Alternativ ist keine Umsetzung notwendig, wenn das Native-Code-Modul so kompiliert ist, dass es fixe null-basierte Adressen einschließt.
Die Service-Laufzeit ist verantwortlich für das Bereitstellen von essentiellen Systemdiensten für Native-Client-Module, einschl. Speicherzuteilung, Threaderstellung und Kommunikation. Die Service-Laufzeit stellt außerdem eine Systemaufrufschnittstelle zu geladenen Native-Code-Modulen bereit und führt die jedem gegebenen Modul erlaubten Systemaufrufe in dessen Auftrag durch. Als Vermittler ist die Service-Laufzeit für die Bereitstellung dieser Dienste und das Sicherstellen verantwortlich, dass ein bösartiges Native-Code-Modul weder Sicherheitsprobleme (z. B. nicht erlaubte Systemaufrufe auslösen) verursachen noch Ressourcen unangemessen verwenden kann. Beispielsweise stellt die Service-Laufzeit sicher, dass ein Multi-Threaded Native-Code-Modul nicht potenziell Verletzlichkeiten aufgrund von Wettlaufsituationen in der Systemaufrufschnittstelle ausnutzen kann. Es ist zu beachten, dass Bugs in der Service-Laufzeit die Sicherheitseigenschaften des gesamten Systems gefährden können, weil die Service-Laufzeit nicht vertrauenswürdige Native-Code-Module in den Speicher lädt und mit solchen Modulen während ihrer Ausführung in direkter Interaktion ist. Daher ist das Sicherstellen der Richtigkeit und Sicherheit der System-Laufzeit und jeder von der System-Laufzeit unterstützten Schnittstelle eine hohe Priorität.
In einigen Ausführungsformen der vorliegenden Erfindung stellt das System Debugging-Unterstützung für Native-Code-Module bereit. So kann beispielsweise der Kompilierungsprozess Mechanismen zum Bauen und Verbinden eines Native-Code-Moduls mit einer anderen Laufzeitimplementierung bereitstellen, welche dieselben Schnittstellen wie die sichere Laufzeitumgebung einschließt, bei der aber die unterschiedliche Implementierung der Service-Laufzeit zusätzliche Debugging-Unterstützung und/oder Output bereitstellt. Alternativ können die Service-Laufzeit und/oder die Entwickler-Laufzeit zusätzliche Funktionen und/oder Fähigkeiten einschließen, die das Debugging von Native-Code-Modulen ermöglichen.
Zum Sicherstellen der Integrität der Ausführung des Service-Laufzeitcodes löst eine durch einen Trampolincode eines Native-Code-Moduls gemachte Serviceanforderung einen Stapelswitch aus. Dieser Stapelswitch stellt sicher, dass der zum Ausführen des Service-Laufzeitcodes verwendete Stapelspeicher keiner Modifizierung durch andere Threads im Native-Code-Modul unterliegt.
In einer Ausführungsform der vorliegenden Erfindung überwacht die Service-Laufzeitservice ein ausführendes Native-Code-Modul um sicherzustellen, dass das Modul keine Verschwendung von Ressourcen, Versuche zum Verbreiten von Systeminformationen mithilfe verborgener Kanäle oder das Ausüben anderer Streiche in Betracht zieht. Es ist zu beachten, dass, obwohl das Validieren und Sicherstellen von Code-, Steuerfluss- und Datenintegrität eines Native-Code-Moduls Sicherheit bietet und dadurch eine Gruppe von Hauptbedrohungen eliminiert, ein sich falsch verhaltendes Native-Code-Modul immer noch (entweder bösartig oder auch irrtümlich) unangemessen operieren und Systemressourcen verschwenden kann. So kann beispielsweise ein Native-Code-Modul Endlosschleifen oder Speicherlecks einschließen, versuchen mithilfe von korruptem Output Client-Anwendungen zu korrumpieren oder versuchen, Systemstatusinformationen mithilfe verborgener Kanäle an externe Parteien zu senden. Zur Entschärfung solcher Probleme kann die Service-Laufzeit eins oder mehrere der Folgenden enthalten: einen Schleifentimer, der die Ausführung eines Native-Code-Moduls stoppen kann, wenn eine Endlosschleife festgestellt oder vermutet wird; eine Speichergrenze und ein Verfolgungssystem das sicherstellt, dass das Native-Code-Modul nicht versucht, zu große Speichermengen zuzuteilen; Datenintegritätsprüfer, die sicherstellen, dass Datenoutput durch das Native-Code-Modul ein gültiges Format befolgt (was das Sicherstellen involvieren kann, dass der Datenoutput vom Native-Code-Modul ein Format hat, das praktikabel geprüft werden kann); und Techniken, die versuchen die Bandbreite eines verborgenen Kanals zu eliminieren oder sperren, z. B. indem Native-Code-Modulen nur der Zugriff auf einen Hardwaretimer mit niedriger Präzision erlaubt wird (und dadurch das Native-Code-Modul daran zu hindern, eine Gruppe verborgener Handlungen, mithilfe derer Informationen an externe Parteien gesendet werden sollen, präzise zu synchronisieren). Es ist zu beachten dass, während die vollständige Eliminierung verborgener Kanäle unmöglich sein kann, das Verringern der Bandbreite solcher Kanäle diese harmlos machen kann.
3. IMC-Laufzeit:
In einer Ausführungsform der vorliegenden Erfindung erlaubt das System Native-Code-Modulen miteinander und mit externen Anwendungen zu kommunizieren. So kann beispielsweise die IMC-Laufzeit datenintensive Kollaboration zwischen einem Native-Code-Modul und einer externen Anwendung mithilfe gemeinsam benutzter, von der Service-Laufzeit verwalteter Speicherpuffer ermöglichen. Es ist zu beachten dass je nachdem, ob die Service-Laufzeit sich im selben Prozess befindet wie die externe Anwendung, die gemeinsame Benutzung von Speicherpuffern das Übersetzen von Adressen zwischen Prozessen und Verwalten von Speicherkartendaten involvieren kann. Beachten Sie außerdem, dass das System, weil einige externe Anwendungen möglicherweise nicht vertrauenswürdig sind (z. B. eine JavaScript^TM-Anwendung, die mit einem nativen Code-Modul interagiert), eine Abstraktion für „Memory Handles” bereitstellen kann, die sich anstelle von Pointer für den Zugriff auf Shared-Memory-Puffer nutzen lassen, solange die IMC-Laufzeitumgebung Verfahren für die Übersetzung solcher Handles in Adressen unterstützt.
Weil sowohl Client-Anwendungen als auch Native-Code-Modul Multithreaded sein können, können einige Ausführungsformen der vorliegenden Erfindung das Verwenden von Mutexes involvieren, um sicheren gleichzeitigen Zugriff auf gemeinsam benutzte Speicherpuffer sicherzustellen und Datenwettläufe zu verhindern. Sicherer gleichzeitiger Zugriff auf gemeinsam benutzte Speicher kann enge Interaktion zwischen einer Client-Anwendung und einem Native-Code-Modul ermöglichen und die Anzahl der Male verringern, an denen Daten für eine Anforderung kopiert werden müssen. So kann beispielsweise das Native-Code-Modul eine Nachrichtenschleife implementieren, die Nachrichten und/oder Anforderungen von Client-Anwendungen und/oder der Service-Laufzeit empfangen, die solche gemeinsam benutzten Speicherpuffer verwenden. Alternativ kann das Native-Code-Modul Nachrichten von Client-Anwendungen (über die Service-Laufzeit) empfangen, die Handles einschließen, die sich auf gemeinsam benutzte Speicherpuffer beziehen.
Es ist auch zu beachten, dass beide Seiten der Kommunikation evtl. Fehlerkontrolle vornehmen müssen, um die Gültigkeit der gemeinsam benutzten Daten sicherzustellen. So kann beispielsweise die Client-Anwendung Daten gründlich kontrollieren müssen, die gemeinsam benutzt werden oder von einem nicht vertrauenswürdigen Native-Code-Modul empfangen wurden, um durch bösartige oder mit Bugs behaftete Module verursachte Probleme zu vermeiden. Überdies sollten Client-Anwendungen davon abgehalten werden, Datenstrukturen mit Client-Anwendung-sensiblen Daten, wie z. B. Funktion-Hinweisadressen und Hinweisadressen, die nur im Parent-Adressraum (Client-Anwendung) gültig sind, in gemeinsam benutzte Speicherpuffer zu stellen, weil ein Native-Code-Modul solche Daten potenziell modifizieren und dadurch die Client-Anwendung ausnutzen oder beeinträchtigen könnte.
In einigen Ausführungsformen können Native-Code-Module als Threads im Adressraum eines Hostprozesses laufen. In diesen Ausführungsformen schaffen vom System bereitgestellte Datenintegritätsmechanismen eine Datenschutz-Sub-Domain im Adressraum des Hostprozesses, die verhindert, dass der Thread für das Native-Code-Modul Prozessspeicher außerhalb seiner Abschirmung sieht. Weiterhin ermöglicht ein gemeinsam benutztes Speichersegment Informationsaustausch zwischen Client-Anwendungen im Hostprozess und dem Native-Code-Modul.
Es ist zu beachten, dass die IMC-Laufzeit direkten Zugriff auf sensible Strukturen in der Service-Laufzeit und potenziell auch in Client-Anwendungen hat. Daher ist, wie bei der Service-Laufzeit, das Sicherstellen der Richtigkeit und Sicherheit der IMC-Laufzeit eine hohe Priorität.
4. Entwickler-Laufzeit:
In einer Ausführungsform der vorliegenden Erfindung stellt die Entwickler-Laufzeit zusätzliche Unterstützung bereit, die zum Zugreifen auf Aspekte der Service-Laufzeit von benutzerentwickeltem Code in einem Native-Code-Modul benötigt wird. Wie zuvor beschrieben, treten Native-Code-Module mit der Service-Laufzeit in Interaktion, indem sie Aufrufe von Trampolinen im Native-Code-Modul machen, und die Service-Laufzeit vermittelt Aufrufe von Client-Anwendungen in das Native-Code-Modul. The Entwickler-Laufzeit kann einen Satz „Jacket”-Routinen einschließen, die Parameter aufbereiten, die vor dem Aufruf der Trampoline bereitgestellt werden müssen. Die Entwickler-Laufzeit kann außerdem eine Haupt-Nachrichtenverarbeitungsschleife und die Datenstrukturen bereitstellen, die zum Beschreiben der im Native-Code-Modul für Client-Anwendungen (über die Client-Laufzeit) vorhandenen Funktionen und/oder Funktionalität notwendig sind.
Die Entwickler-Laufzeit kann außerdem Bibliothekscode einschließen, der als Teil eines Softwareentwickler-Kits herausgegeben wird und entwicklertransparente Unterstützung für einen Satz gemeinsamer Funktionalität bietet. So kann beispielsweise Entwickler-Laufzeit Unterstützung für Funktionen, wie malloc, free und printf, im Kontext der sicheren Laufzeitumgebung durch Liefern von Versionen solcher Funktionen einschließen, die richtig zur Service-Runtime lotsen (über Trampoline), anstelle der Verwendung von direkten Systemaufrufen wie in existierenden Systemen. Der Bibliothekscode kann außerdem Unterstützung für die volle Zahl von Synchronisationsprimitiven und atomare Operationen (z. B. zur Unterstützung gemeinsam benutzten Speicherzugriffs wie zuvor für die IMC-Laufzeit beschrieben) bieten oder Entwickler in die Lage versetzen, zum Debugging zu stdout zu schreiben (z. B. durch Unterstützung einer modifizierten printf Funktion in der Bibliothek). Beachten Sie, dass manche traditionelle „Standardsystemfunktionen” wie fopen in der sicheren Laufzeitumgebung nicht anwendbar sind und daher nicht unterstützt werden.
Es ist zu beachten, dass obwohl die Entwickler-Laufzeit als Teil des Laufzeitsystems betrachtet wird, das dem Native-Code-Modul den Zugriff auf die Service-Laufzeit ermöglicht, der sich auf die Entwickler-Laufzeit beziehende Programmcode in das Native-Code-Modul selbst kompiliert wird und daher nicht vertrauenswürdig ist. Daher braucht solcher Programmcode nicht auf demselben Niveau auditiert zu werden wie Code in Service- und IMC-Laufzeit. In die Entwickler-Laufzeit geschobene Funktionalität kann automatisch von den Sicherheitszusicherungen profitieren, die der Validator und der Rest der sicheren Laufzeitumgebung bereitstellen. Es ist zu beachten, dass Code von der Entwickler-Laufzeit statisch in das Native-Code-Modul verlinkt ist.
6 illustriert nicht vertrauenswürdige Native-Code-Module, die in einer exemplarischen sicheren Laufzeitumgebung in einem Webbrowser ablaufen. In dieser Ausführungsform schließt Webbrowser 600 ein vertrauenswürdiges natives Modul-Plug-in 602 und ein zweites vertrauenswürdiges Plug-in 604 ein. Natives Modul-Plug-in 602 schließt Client-Laufzeit 606 und Service-Laufzeit 608 ein. Es ist zu beachten dass, obwohl Client-Laufzeit 606 und Service-Laufzeit 608 als unabhängige, gemeinsam in nativem Modul-Plug-in 602 untergebrachte Entitäten illustriert sind, sie in vielen verschiedenen Konfigurationen (z. B. integriert in ein einziges Modul oder als vollkommen separate Anwendungen) implementierbar sind. Beim Betrieb sendet eine Client-Anwendung 610 (z. B. eine JavaScript^TM-Anwendung) in Webbrowser 600 eine Anforderung an Client-Laufzeit 606 zum Herunterladen mehrerer Native-Code-Module. Client-Laufzeit 606 leitet diese Anforderung an Service-Laufzeit 608 weiter, welche die nicht vertrauenswürdige Native-Code-Module 612 herunter und in den Speicher lädt. Nach erfolgreicher Validierung, welche die Integrität von nicht vertrauenswürdigen Native-Code-Modulen 612 sicherstellt und Strukturen für selbige etabliert, benachrichtigt Service-Laufzeit 608 Client-Laufzeit 606 davon, dass nicht vertrauenswürdige Native-Code-Module 612 geladen sind und Client-Laufzeit 606 wiederum informiert Client-Anwendung 610, dass nicht vertrauenswürdige Native-Code-Module 612 verfügbar sind. Client-Anwendung 610 kann dann Client-Laufzeit 606 nach der für nicht vertrauenswürdige Native-Code-Module 612 verfügbaren Liste von Aufrufen abfragen und fordern, dass solche Aufrufe aufgerufen werden (über Client-Laufzeit 606 und Service-Laufzeit 608).
Programmcode 614 im vertrauenswürdigen Plug-in 604 kann auch versuchen, in nicht vertrauenswürdigen Native-Code-Modulen 612 verfügbare Funktionalität aufzurufen, was die Erzeugung eines gemeinsam benutzten Speichersegments im gemeinsam benutzten Speicher 618 veranlasst, der Kommunikation zwischen vertrauenswürdigem Plug-in 604 und nicht vertrauenswürdigen Native-Code-Modulen 612 (über IMC-Laufzeit 616 und Service-Laufzeit 608) erlaubt.
Es ist zu beachten, dass in 6 nur natives Modul-Plug-in 602 und vertrauenswürdiges Plug-in 604 vertrauenswürdig sind, und dass die heruntergeladene Client-Anwendung 610 und nicht vertrauenswürdiges Native-Code-Module 612 nicht vertrauenswürdig sind. Es ist außerdem zu beachten, dass sich die Entwickler-Laufzeit, obwohl sie nicht ausdrücklich illustriert ist, im Bibliothekscode und Benutzercode vom nicht vertrauenswürdige Native-Code-Module 612 ausprägt. Schließlich ist noch zu beachten, dass nicht vertrauenswürdiges Native-Code-Module 612 nicht direkt, sondern nur mit Erlaubnis von und durch Service-Laufzeit 608 miteinander in Interaktion treten können.
7 stellt ein Flussdiagramm dar, welches das Verfahren zur sicheren Ausführung eines Native-Code-Moduls auf einem Computergerät illustriert. Beim Betrieb empfängt das System ein nicht vertrauenswürdiges Native-Code-Modul, das auf einem Computergerät ausgeführt werden soll (Operation 700). Dieses Native-Code-Modul umfasst nicht vertrauenswürdigen nativen Programmcode, der in der mit dem Computergerät assoziierten Befehlssatzarchitektur ausgedrückt ist. Das System lädt das Native-Code-Modul in eine sichere Laufzeitumgebung, die Codeintegrität, Steuerflussintegrität und Datenintegrität für das Native-Code-Modul durchsetzt (Operation 710). Dann fährt das System fort mit dem Ausführen von Befehlen vom Native-Code-Modul in der sicheren Laufzeitumgebung (Operation 720). Während der Ausführung moderiert die sichere Laufzeitumgebung, auf welche Ressourcen das Native-Code-Modul zugreifen darf und wie auf diese Ressourcen zugegriffen wird. Das Ausführen des Native-Code-Moduls in der sicheren Laufzeitumgebung ermöglicht das Erreichen von Native-Code-Leistung für nicht vertrauenswürdigen Programmcode ohne erhebliches Risiko unerwünschter Nebenwirkungen.
8 illustriert eine Spieleanwendung in Webbrowser 812, die in Interaktion steht mit einem ausführenden Native-Code-Modul, das sowohl Spiellogik 800 (in JavaScript^TM implementiert) als auch Spielphysikmodul 802 umfasst, das als ein nicht vertrauenswürdiges Native-Code-Modul implementiert ist, das in der sicheren Laufzeitumgebung 814 ausgeführt wird. Einige Aspekte des Spiel brauchen evtl. keine Native-Code-Leistung. Beispielsweise braucht Spiellogik 800 evtl. keine Native-Code-Leistung zum Bestimmen und Verfolgen von Mausbewegung oder Tastatureingabe. Das Erzeugen von Grafik mit hoher Auslösung mit hohen Bildraten kann jedoch über die Leistungs- und Sprachfähigkeit von JavaScript^TM hinausgehen. Daher kann die Anwendung so strukturiert sein, dass Spiellogik 800 relevante Positionierungsinfo (bezüglich Mausaktionen) an Spielphysikmodul 802 sendet, welches einen Satz Grafik- und/oder Toninformationen mithilfe sicherer Native-Code-Leistung erzeugt. Spiellogik 800 kann Kenntnis über das Weiterleiten des Outputs von Spielphysikmodul 802 durch einen weiteren Layer (z. B. vertrauenswürdiges Browser-Plug-in 804, das ein Browsergrafik-Teilsystem bereitstellt) direkt an eine Grafik-API (Application Programmer Interface) 806 in Betriebssystem 808 und eine Grafikverarbeitungseinheit 810 in der Hardware 812 von Computergerät 200. Alternativ kann es Spielphysikmodul 802 auch erlaubt werden, Grafikdaten direkt an das vertrauenswürdige Plug-in (unter vollständiger Umgehung der JavaScript^TM Spiellogik 800) mithilfe der zuvor erwähnten Kommunikationsverfahren (wie einen gemeinsam benutzten Speicherpuffer) zu senden. Es ist zu beachten, dass die Funktionalitätsaufteilung auf Client-Anwendungen und Native-Code-Module je nach Anwendung verschieden sein kann. So können beispielsweise einige Anwendungen die Menge der in JavaScript^TM implementierten Funktionalität minimieren und zur Leistungsoptimierung so viel Funktionalität wie möglich auf Native-Code-Module verlagern. Es ist zu beachten, dass Native-Code-Module es Legacy Code erlauben können, in Client-Anwendungen benutzt zu werden, ohne dass solcher Code in einer neuen Sprache (wie JavaScript^TM) neu geschrieben werden muss. Wiederkompilierung solchen Legacy Codes zur Erzeugung eines konformen Native-Code-Moduls kann substanziell weniger Aufwand erfordern als ein komplettes Neuschreiben.
In einigen Ausführungsformen der vorliegenden Erfindung ist das Plug-in, welches das Native-Code-Modul unterstützt, so im Code einer Webseite eingebettet, dass Client-Anwendungen die im System verfügbaren Native-Code-Module entdecken und mit ihnen kommunizieren können. So können beispielsweise die Plug-in- und/oder Native-Code-Module so in Webdokumente geladen werden, dass Verbindungen für die Schnittstellen von Native-Code-Modulen zum Plug-in exportiert werden. Eine Client-Anwendung kann sich dann über das Dokumentobjektmodell mit dem Plug-in verbinden, um Verbindungsinformationen für die verfügbaren Native-Code-Module zu bestimmen.
Es ist zu beachten, dass in einigen Ausführungsformen der vorliegenden Erfindung das beschriebene System betriebssystemneutral ist, wodurch Betriebssystemübertragbarkeit gegeben ist. Compileranpassungen (und die darauf folgende Verifizierung durch den Validator) beziehen sich auf Sätze von nicht erlaubten Befehlen (z. B. durch Befehl opcode) und Steuerfluss, die betriebssystemunabhängig sind. Ähnlich können andere Systeme auch so implementiert werden, dass betriebssystemspezifische Operationen vermieden werden (z. B. weil Hardwareausnahmen oft auf betriebsspezifische Weise gehandhabt werden, kann sich das System entscheiden, Hardwareausnahmen auf einheitliche, betriebssystemneutrale Weise zu handhaben, indem Hardwareausnahmen erzeugende Native-Code-Module abgebrochen werden). Es ist zu beachten, dass es nicht notwendig ist, virtuelle Befehle/Betriebs- oder Befehlsübersetzungen für eine virtuelle Maschine im Betriebssystem durchzuführen, weil die Befehle im Native-Code-Modul bereits im nativen Assemblercode sind und daher direkt auf der Hardware des gegebenen Computergeräts ausgeführt werden können. Eine betriebssystemneutrale Methode, die leicht zwischen verschiedenen Betriebssystemen übertragbar ist, die auf einer gemeinsamen Hardwarearchitektur laufen, kann eine günstige Zwischenalternative über virtuelle Maschinenumgebungen und interpretierte Sprachen hinaus bereitstellen, die Neutralität bei Betriebssystemen und/oder Befehlssatzarchitektur bieten, aber langsamer als Native Code sind.
Zusammenfassend sei festgehalten, dass Ausführungsformen der vorliegenden Erfindung eine sichere Laufzeitumgebung einschließen, die das Erreichen von Native-Code-Leistung für nicht vertrauenswürdigen Programmcode ohne erhebliches Risiko von unerwünschten Nebenwirkungen ermöglicht. Diese sichere Laufzeitumgebung ermöglicht es Native-Code-Modulen, die ansonsten sicher von den anderen Software- und Hardwarekomponenten eines Computergeräts isoliert sind, mit anderen Systemkomponenten auf sichere, kontrollierte Weise zu kommunizieren. Die sichere Laufzeitumgebung moderiert sowohl, aufweiche Ressourcen durch das Native-Code-Modul zugegriffen (und mit welchen kommuniziert) werden kann als auch, wie auf solche Ressourcen zugegriffen wird, wodurch sichergestellt wird, dass das Native-Code-Modul zum Zugriff auf Systemdienste vollkommen auf die sichere Laufzeitumgebung angewiesen ist und ohne ausdrückliche Vermittlung keine sensiblen Operationen durchführen kann.
Variationen und Optimierungen
Obwohl das Kompilieren von Native-Code-Modulen in für einen einzigen Befehlssatz maßgeschneiderte Binaries die Befehlssatzübertragbarkeit opfert, kann die Verwendung von architekturspezifischem nativem Code auch erheblichen Nutzen bezüglich der Leistungssteigerung und Verringerung von Größe und Komplexität des Systems bieten. Für Situationen, in denen mehrere populäre Betriebssysteme dieselbe zugrundeliegende Hardwarearchitektur benutzen (wie bei der x86 Architektur), kann sich ein erheblicher Prozentsatz von Systemen evtl. ein solches Native-Code-Modul trotz des Fehlens von Befehlssatzübertragbarkeit zu Nutze machen.
Einige Ausführungsformen der vorliegenden Erfindung stellen Native-Code-Module bereit, die den nativen Code anderer Befehlssatzarchitekturen verwenden (z. B. 64-Bit x86, PowerPC- oder ARM-Architekturen). In einigen Ausführungsformen kann das System für native Code-Module „Fat-Binarys” unterstützen, die verschiedene Maschinencodeversionen umfassen, welche im gleichen nativen Code-Modulpaket einen Einsatz unterschiedlicher Befehlssatzarchitekturen erlauben. Alternativ kann das System einen Binary-Übersetzer im Lader verwenden, der Befehlssatzübertragbarkeit unterstützt. Wie zuvor beschrieben, müssen Architekturen, die keinen hardwarebasierten segmentierten Speicherschutz unterstützen, möglicherweise alternative Datenabschirmungstechniken zum Sicherstellen von Datenintegrität verwenden.
Einige Ausführungsformen der vorliegenden Erfindung können verschiedene (oder mehrere) ausführbare Formate unterstützen. So kann beispielsweise das System das gemeinhin mit ausführbaren Linux^TM Programmen verwendete ELF-Format sowie das von Windows^TM verwendete Win32-Format verwenden. Solche Optionen ermöglichen das Entwickeln von Native-Code-Modulen dadurch, dass Entwickler unter einem breiteren Angebot bevorzugter Entwickler-Tools wählen können. Einige Ausführungsformen der vorliegenden Erfindung unterstützen sowohl dynamisch geladene Bibliotheken als auch statisch verlinkte Binaries.
In einigen Ausführungsformen der vorliegenden Erfindung überprüft der Validator, ob Native-Code-Module versuchen, prozessormodellspezifische Befehlssatzerweiterungen (wie z. B. verschiedene Versionen der auf einigen Generationen von x86 Prozessoren verfügbaren SSE (Streaming SIMD Extensions)) zu verwenden. Während das Sperren der Verwendung solcher Befehle Aspekte des Validators vereinfachen kann, könnte es potenziell auch die Leistung von Native-Code-Modulen begrenzen. Für maximale Performance kann das System daher solche Erweiterungen unterstützen, indem (z. B. im Validierer) geprüft wird, ob in einem nativen Code-Modul verwendete Erweiterungen von der Hardware des Computergeräts unterstützt werden (z. B. durch Prüfung der detaillierten Produkt-, Modell- und Versionsdaten wie Modell, Modellnummer und Stepping bei aktuellen Intel-Prozessoren, um die Gruppe der unterstützten Befehle zu ermitteln). So kann beispielsweise der Validator Sicherheit für ein Native-Code-Modul dadurch durchsetzen, dass die Ausführung von Befehlen verhindert wird, für welche die verfügbare Hardware eines speziellen Computergeräts nicht definiert ist bzw. die durch diese nicht unterstützt werden. Weil das System für die Sicherheit verantwortlich ist, während der Entwickler die Richtigkeit und Leistung des eigentlichen Programms verantwortet, kann der Validator in einigen Ausführungsformen nicht unterstützte Befehle einfach mit halt Befehlen überschreiben, wodurch die Ausführung gestoppt (und Sicherheit gewahrt) wird, falls ein nicht unterstützter Befehl für ein Computergerät gefunden wird. Es ist zu beachten dass, obwohl das Verwenden des halt Befehls (der in der x86 Befehlssatzarchitektur 1 Byte groß ist) die Implementierung solcher Befehlsersatztechniken vereinfachen kann, andere Single-Byte- und/oder Multi-Byte-Befehle auch mit ähnlicher Wirkung verwendbar sind.
Zusammenfassend sei festgehalten, dass existierende Techniken zur Ausführung von nicht vertrauenswürdigem Programmcode normalerweise einige Aspekte von Programmierbarkeit, Sicherheit, Betriebssystemübertragbarkeit und/oder Leistung opfern. Ausführungsformen der vorliegenden Erfindung verwenden Hardware- und Softwarefehlerisolierungstechniken, um das sichere Ausführen eines nicht vertrauenswürdigen Native-Code-Moduls auf einem gegebenen Hardwaresatz zu ermöglichen, wodurch ein Hostprozess und der Rest des Hostgeräts vor bösartigem Verhalten des nicht vertrauenswürdigen Moduls geschützt werden, während eine Leistung bereitgestellt wird, die substanziell der Leistung von nativem Code ähnelt. Sichere Ausführung des Native-Code-Moduls wird erreicht durch Ladezeitvalidierung und eine sichere Laufzeitumgebung, wobei der Validator sicherstellt, dass ein Native-Code-Modul konform ist mit einem Satz von Befehlssperren und Ausrichtungsanforderungen, und die sichere Laufzeitumgebung sowohl moderiert, auf welche Ressourcen durch das Native-Code-Modul zugegriffen (und mit welchen kommuniziert) werden kann und wie auf solche Ressourcen zugegriffen wird. In einer Anwendung dieser Techniken können die beschriebenen Techniken verwendende, webbasierte Anwendungen mit nativer Leistung laufen, während die Sicherheits- und Übertragbarkeitsprobleme existierender Technik gelöst werden.
Die obigen Beschreibungen der Ausführungsformen der vorliegenden Erfindung wurden nur zum Zweck der Illustration und Beschreibung dargestellt. Sie sind nicht als erschöpfend zu verstehen und begrenzen die vorliegende Erfindung auch nicht auf die offengelegten Formen. Dementsprechend sind viele Modifikationen und Variationen für Fachleute offensichtlich. Zusätzlich soll die obige Offenlegung die vorliegende Erfindung auch nicht begrenzen. Der Geltungsbereich der vorliegenden Erfindung wird definiert durch die angehängten Patentansprüche.

Claims

Computerlesbares Speichermedium, auf dem Befehle gespeichert sind, die bei Ausführung durch einen Computer diesen dazu bringen, ein Verfahren für die Validierung eines nativen Code-Moduls auf einem Computergerät auszuführen, wobei das native Code-Modul nicht vertrauenswürdigen Programmcode enthält, der mit einer mit dem Computergerät verbundenen Befehlssatzarchitektur ausgedrückt wird, wobei das Verfahren umfasst: das Empfangen des nativen Code-Moduls; und das Validieren, dass sich das native Code-Modul sicher ausführen lässt – durch: das Erkennen, dass ein Befehlssatz im nativen Code-Modul keine eingeschränkten Befehle beinhaltet und/oder nicht auf eingeschränkte Funktionen des Computergeräts zugreift; und das Erkennen, dass der Befehlssatz anhand von Bytegrenzen so abgestimmt wird, dass ein bestimmter Satz an Bytegrenzen stets gültige Befehle enthält und ein Satz an Steuerungsflussbefehlen im nativen Code-Modul über gültige Ziele verfügt; und
Computerlesbares Speichermedium nach Anspruch 1, worin das Verfahren des Weiteren die Ausführung des validierten nativen Code-Moduls in einer sicheren Laufzeitumgebung umfasst.
Computerlesbares Speichermedium nach Anspruch 2, worin die Validierung des nativen Code-Moduls das sichere Ausführen des nativen Code-Moduls in der sicheren Laufzeitumgebung auf dem Computergerät erleichtert, sodass sich bei nicht vertrauenswürdigen Binärprogrammen ohne größere Anfälligkeit für unerwünschte Nebeneffekte native Code-Performance erreichen lässt.
Computerlesbares Speichermedium nach Anspruch 1, worin das Validieren des nativen Code-Moduls die Durchführung statischer Binäranalysen im nativen Code-Modul beinhaltet.
Computerlesbares Speichermedium nach Anspruch 1, worin die Befehlssatzarchitektur die x86-Befehlssatzarchitektur ist.
Computerlesbares Speichermedium nach Anspruch 1, worin das Verfahren des Weiteren das Herunterladen und Ausführen des nativen Code-Moduls in einem Webbrowser umfasst; und worin das Validieren des nativen Code-Moduls und das Ausführen des nativen Code-Moduls in der sicheren Laufzeitumgebung das native Code-Modul von anderen Programmen, die auf dem Computergerät ausgeführt werden, isolieren.
Computerlesbares Speichermedium nach Anspruch 4, worin das native Code-Modul betriebssystemneutral ist und Anwendungen in verschiedenen Betriebssystemen unterstützen kann, die sich in der Befehlssatzarchitektur des Computergeräts ausführen lassen.
Computerlesbares Speichermedium nach Anspruch 1, worin das Verfahren außerdem die Abweisung des nativen Code-Moduls beinhaltet, wenn: das native Code-Modul eingeschränkte Befehle beinhaltet und/oder auf eingeschränkte Funktionen des Computergeräts zugreift; der Befehlssatz nicht richtig abgestimmt ist; und/oder ein oder mehrere Steuerungsbefehle im nativen Code-Modul ungültige Ziele aufweisen.
Computerlesbares Speichermedium nach Anspruch 1, worin die Kompilierung und/oder Validierung des nativen Code-Moduls außerdem eines oder mehrere der folgenden Elemente beinhalten: das Sicherstellen, dass sich ein Ziel für einen Steuerungsflussbefehl innerhalb des angegebenen Speichersegments befindet; das Sicherstellen, dass ein Befehl im nativen Code-Modul für einen zugehörigen Steuerungsflussbefehl richtig abgestimmt wird; das Ändern eines unsicheren Befehls für das native Code-Modul in einen sichereren Befehlssatz; das Ermitteln, ob eine Bytesequenz im nativen Code-Modul mit einer bestimmten Hardwareimplementierung der Befehlssatzarchitektur unterstützt wird; und/oder das Abweisen einer nicht unterstützten Bytesequenz im nativen Code-Modul.
Apparat für die Validierung eines nativen Code-Moduls, das auf einem Computergerät ausgeführt werden soll, wobei das native Code-Modul nicht vertrauenswürdigen Programmcode enthält, der mit einer mit dem Computergerät verbundenen Befehlssatzarchitektur ausgedrückt wird, umfassend: einen Empfangsprozess, der für den Empfang des nativen Code-Moduls konfiguriert wurde; und einen Validierungsprozess, der per Konfiguration validiert, ob das native Code-Modul sicher ausgeführt wird – durch: das Erkennen, dass ein Befehlssatz im nativen Code-Modul keine eingeschränkten Befehle beinhaltet und/oder nicht auf eingeschränkte Funktionen des Computergeräts zugreift; und das Erkennen, dass der Befehlssatz anhand von Bytegrenzen so abgestimmt wird, dass ein bestimmter Satz an Bytegrenzen stets gültige Befehle enthält und ein Satz an Steuerungsflussbefehlen im nativen Code-Modul über gültige Ziele verfügt.