DE10297273B4

DE10297273B4 - Verfahren zur Bereitstellung von Systemintegrität und Legacy-Umgebungsemulation

Info

Publication number: DE10297273B4
Application number: DE10297273T
Authority: DE
Inventors: Vincent Federal Way Zimmer
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2001-09-27
Filing date: 2002-09-27
Publication date: 2008-08-21
Anticipated expiration: 2022-09-28
Also published as: DE10297273T5; CN100533385C; JP2005528665A; WO2003027835A3; GB2397415A; US20030061497A1; WO2003027835A2; US7103529B2; GB0404784D0; KR20040037148A; AU2002343467A1; KR100692346B1; CN1585927A

Abstract

Verfahren mit den folgenden Schritten:
Implementieren eines virtuellen Maschinenmonitors (420) auf einem Computersystem (400) mit einer Native-Umgebung, die in einem physikalischen Modus ausgeführt wird, wobei das Computersystem (400) ein Extensible Firmware-Interface (EFI) mit zumindest einem zusätzlichen Codemodul aufweist;
Emulieren von Legacy-Hardwarekomponenten, die nicht in der Native-Umgebung vorhanden sind, durch den virtuellen Maschinenmonitor (420), um das Booten eines Legacy-Betriebssystems zu unterstützen; und
vor dem Booten des Legacy Betriebssystems, Aufrufen der Signatur-Logik (421) des virtuellen Maschinenmonitors (420), um eine im Codemodul enthaltene Hash-Signatur gegen eine in einem sicheren Speicher (422) des Virtuellen Maschinenmonitors (420) gespeicherte Hash-Signatur zu validieren, um dem Legacy-Betriebssystem vor der Übernahme der Kontrolle durch eine Attestprotokollierung zu versichern, daß dem Code des Codemoduls vertraut werden kann.

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft allgemein Datenverarbeitungssysteme mit erweiterbarer Firmware-Architektur und insbesondere die Verwendung eines virtuellen Maschinenüberwachers (VMM – Virtual Machine Monitor) zur Emulation von Legacy-Hardware und -Umgebung und zur Bereitstellung geschützter Speicherung und Ausführung in einem Datenverarbeitungssystem mit einer erweiterbaren Firmware-Architektur.
Allgemeiner Stand der Technik
Eine neuere Entwicklung in Computersystem-Firmware ist der Rahmen der erweiterbaren Firmware-Schnittstelle (EFI – Extensible Firmware Interface), wodurch Software-Vertreiber Betriebssystemprogramme entwickeln können, die mit vielfältigen Zentralverarbeitungseinheiten (CPUs) verwendet werden können. Es ist eine Anwendungs-Binärschnittstelle (ABI – Application Binary Interface) vorgesehen, die spezifiziert, wie Daten auf dem Stapel für einen gegebenen CPU-Typ weitergeleitet werden sollen. Durch Abstrahierung der Plattform liefert der Rahmen gegenüber Systemen, die Legacy-Architektur verwenden, viele Vorteile. Während dieses Konzept der Komponentenarchitektur voranschreitet, entsteht Systemarchitektur, die ABIS und Software-Abstraktion im Verlauf des gesamten Systeminitialisierungsprozesses verwendet. Dazu gehört nicht nur die CPU-Initialisierung, sondern auch die Chipsatz- und E/A-Geräteinitialisierung. Es wird ein Software-Rahmen bereitgestellt, der es mehreren Teilnehmern ermöglicht, kleine Codestücke zu schreiben, die abstrahieren, wie Teile des Chipsatzes oder des E/A-Komplexes arbeiten. In einem solchen Rahmen werden Produkte von verschiedenen Vertreibern miteinander arbeiten. Die Codestücke von jedem Vertreiber sind in Initialisierungsmodulen enthalten. Während einer Systeminitialisierungsphase (nach dem CPU-Rücksetzen, aber vor der Speicherinitialisierung) fertigt Kerninitialisierungscode die Initialisierungsmodule in einer sequenzierten Reihenfolge ab, um grundlegende Dienste bereitzustellen. Diese Initialisierungsphase initialisiert genug von dem System, um nachfolgende Phasen zu ermöglichen, wie zum Beispiel die Treiberausführungsphase, die für Initialisierungsprozesse verantwortlich ist, die algorithmisch komplexer sind, wie zum Beispiel das Skannen von E/A-Bussen, das Aufzählen von Betriebsmitteln und das Installieren von Treibern.
Dieses Konzept des Ermöglichens von Beiträgen von Treibern und Anwendungen von mehreren Beteiligten führt zu mehreren Besorgnissen. Die von einem einzelnen Vertreiber bereitgestellte Sicherheit der System-Firmware ist implizit von dem Vertreiber. Die Integration von Codemodulen von verschiedenen Quellen gefährdet die Systemintegrität, da keine Vorkehrungen für eine Sandbox oder für eine Validierung des Codes bestehen. Die EFI-Plattform wird im physikalischen Modus ausgeführt. Die Ausführung im physikalischen Modus bedeutet, daß alle Adressen tatsächlichen Speicherstellen entsprechen. Obwohl die Ausführung im physikalischen Modus den OS-Ladevorrichtungen vollen Zugang zu allen Plattformbetriebsmitteln gibt, schließt sie auch die Verwendung von virtuellen Speicherseitentabellen und den von ihnen beim Vorboot bereitgestellten Schutz aus. Da Boot-Firmware vollen Maschinenzugang hat, können durch Zugang durch Treiber und Anwendungen heikle Datenstruktur und Code der Kern-EFI möglicherweise verfälscht werden. Techniken wie zum Beispiel Codesignierung zur Validierung der Quelle von Treibern und Anwendungen können keine Fehlerisolation garantieren, wenn der Systemzu stand durch falschen Code korrumpiert wurde.
Eine andere Schwierigkeit ist Legacy-Codeunterstützung. Viele Jahre lang wurde Software so geschrieben, daß sie mit der PC/AT-Plattform kompatibel ist. Viele Legacy-Betriebssysteme und Options-ROMs erfordern Hardware/Software mit PC/AT-Speicherabbildung. Dieser Legacy-Code wird im Real Mode ausgeführt, der den Prozessor auf 1 Mb Speicher begrenzt und keine Speicherverwaltungs- oder Speicherschutzmerkmale bereitstellt.
US 478 70 31 offenbart ein System, bei dem der Prozessor einer Mehrzahl von Nutzern mehr als zwei Schutzringe zur Verfügung stellt, die eine Hierarchie von Schutzebenen definieren, die jeweils einem Betriebsmodus zugeordnet sind. Das System umfaßt des weiteren einen virtuellen Maschinenmonitor, der virtuelle Maschinen umfassend das tatsächliche Computersystem, bei dem der Prozessor in einem virtuellen Modus arbeitet, bereitstellt. Zwei oder mehr der Betriebsmodi des Prozessors im virtuellen Modus sind komprimiert, so daß sie als ein einzelner Modus in dem realen nicht virtuellen Modus behandelt werden, so daß (1) der am meisten privilegierte Betriebsmodus in dem realen Modus keinen entsprechenden virtuellen Betriebsmodus aufweist und der am meisten privilegierte Betriebsmodus im virtuellen Modus weniger privilegiert ist als der am meisten privilegierte Betriebsmodus im realen Modus, und (2) der am wenigsten privilegierte Betriebsmodus des virtuellen Modus zumindest so privilegiert ist, wie der am wenigsten privilegierte Betriebsmodus des realen Modus.
Der Artikel „Analysis of the Intel Pentium's ability to support a secure virtual machine monitor" von R. Scott et al. in Proceedings of the 9^th Usenix Security Symposium, Denver, USA, August 2000, S. 129–144 offenbart einen virtuellen Maschinenmonitor, der verwendet werden kann, um Betriebssystem-Software auf eine andere Version aufzurüsten, ohne die Fähigkeit zu verlieren, das ältere „Legacy"-Betriebssystem und dessen Anwendungen laufen zu lassen. Die Legacy-Software kann auf einer virtuellen Maschine genau in der gleichen Weise laufen wie zuvor auf der realen Maschine, während die neue Version des Betriebssystems auf einer separaten virtuellen Maschine läuft.
Aus der WO 00/48061 A1 ist ein Verfahren bekannt, mit dem eine Computervorrichtung, die eine Mehrzahl funktionaler Module aufweist, vor einer Modifizierung durch Überwachen der Konfiguration der funktionalen Module geschützt werden kann, wobei das Verfahren ein Speichern einer Modulkonfiguration der Computervorrichtung und Überprüfen der aktuellen Modulkonfiguration gegenüber der gespeicherten Modulkonfiguration und Unterbinden des Betriebs der Computervorrichtung, wenn die tatsächliche Modulkonfiguration nicht in zufriedenstellender Weise mit der gespeicherten Modulkonfiguration übereinstimmt, umfaßt.
Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren und ein Computersystem bereitzustellen, die einen sicheren Betrieb von Code-Modulen verschiedener Hersteller auf einem Computersystem mit einem virtuellen Maschinenmonitor zulassen.
Diese Aufgabe wird gelöst durch ein Verfahren gemäß Anspruch 1 sowie ein Computersystem gemäß Anspruch 11.
Vorteilhafte Ausführungsformen der Erfindung sind in den Unteransprüchen angegeben.
Kurze Beschreibung der Zeichnungen
Die vorliegende Erfindung wird beispielhaft veranschaulicht und soll nicht durch die Figuren der beigefügten Zeichnungen beschränkt werden, in denen gleiche Bezugszahlen ähnliche Elemente angeben. Es zeigen:
1 ein Diagramm eines beispielhaften Datenverarbeitungssystems 100 zur Implementierung des VMM der vorliegenden Erfindung;
2 Legacy-Emulation gemäß einer Ausführungsform der vorliegenden Erfindung;
3 ein. Prozeßflußdiagramm des VMM-Betriebs für einen Sandbox-Betrieb eines Programms, dem nicht vertraut wird, gemäß einer Ausführungsform der vorliegenden Erfindung; und
4 die Implementierung einer Sicherheitsanwendung durch Verwendung eines VMM gemäß einer Ausführungsform.
Ausführliche Beschreibung
Die vorliegende Erfindung schafft in einer Ausführungsform Verfahren und Vorrichtungen zur Bereitstellung der Virtualisierung des Systemzustands zum Zweck des Ausführens von Legacy-Kompatibilitätscode oder des Schüt zens von Schlüsseldaten und Codebereichen zur Sicherheit.
Ein VMM ist Simulatorsoftware, die ein effizientes Duplikat der ursprünglichen Machine, einschließlich aller CPU-Anweisungen und Systembetriebsmittel (z. B. Speicher und E/A-Geräte) liefert. Bei einer Ausführungsform wird mit dem VMM eine Vorboot-Sicherheits- und Integritätsrichtlinie für eine komponentenbasierende Architekturplattform durchgesetzt.
Ein virtueller Maschinenüberwacher (VMM) dient zur Emulation von Legacy-Hardware und -Umgebung, um Legacy-Codeunterstützung bereitzustellen. Der VMM ermöglicht eine Emulation und Ausführung von vorgeblich privilegiertem Code (z. B. BIOS-Code), ohne daß dem Code bewußt ist, daß er emuliert wird.
In der Treiberausführungsphase kann ein Treiber geladen werden, der einen VMM installiert. Legacy-Anwendungen (z. B. eine Legacy-OS-Ladevorrichtung) können dann in dem VMM ausgeführt werden. Bei einer Ausführungsform wird der VMM nur dann geladen, wenn eine Boot-Variable so gesetzt ist, daß sie angibt, daß ein Legacy-OS gebootet werden kann. Die Verwendung eines VMM kann beim Schutz von Speicher- und Systemstrukturen vor Anwendungsstörungen helfen. Der Anwendung kann Zugang zu einer Teilmenge der Systembetriebsmittel gegeben werden, und ein Zugriff auf Teile der Speicherabbildung, die nicht für Aktualisierungen gekennzeichnet sind, würde auf dem VMM einfangen (Programmunterbrechung). Ein VMM-Vorboot-Richtlinien-Agent kann dann den Zustand schützen und etwaige problematische Software entladen. Der VMM publiziert transparent eine Umgebung, die die Umgebung des physikalischen Modus zu sein scheint, aber vor illegalem Verhalten schützt; er kann sogar Speicher so abbilden, daß Software die Legacy-Speicherabbildung unterhalb einem Megabyte für Systeme sieht, die diesen physikalischen Adressenbereich tatsächlich nicht deko dieren. Diese Transparenz erhält die Kompatibilität mit Legacy-PC/AT-BIOS-Modulen, Options-ROMs, EFI-Treibern und Anwendungen aufrecht.
Bei einer Ausführungsform virtualisiert die vorliegende Erfindung die gesamte PC/AT-Umgebung, um Unterstützung für Legacy-OSe und Legacy-Hardware, wie zum Beispiel die 82XX-Serie: Timer-Zähler, serieller Port und Master/Slawe-Interrupt-Steuerung, bereitzustellen. Die VM ermöglicht es einem System mit erweiterbarer Firmware-Architektur, Vorboot-Options-ROMS oder Laufzeitumgebungen, die nicht ihre nativen Schnittstellen verwenden, zu ermöglichen. Zum Beispiel emuliert die VM die PC/AT-Umgebung, wodurch Legacy-Options-ROM ausgeführt wird und seine E/A-Dienste bewirken kann. Der VMM übersetzt die Ergebnisse dann in eine native API. Das heißt, der VMM schließt die E/A in dem semantischen Äquivalent in der nativen Umgebung ein.
Bei einer alternativen Ausführungsform kann ein VMM zum Emulieren einer nativen 32-Bit-/64-Bit-Umgebung verwendet werden, um einer Plattform, die im physikalischen Modus ausgeführt wird, geschützte Speicherung und geschützte Ausführung bereitzustellen. Die EFI-Systemarchitektur ermöglicht keine Seitentabellen und Nur-Lese-Kennzeichnungen für spezifizierte Seiten, da die OS-Ladevorrichtung möglicherweise die Seitentabellen für das Bootstrap des OS-Kerns verwendet. Die Verwendung des VMM gibt eine Möglichkeit, unter die OS-Ladevorrichtung zu kommen, um sicherheitsbezogene Informationen zu erzeugen und zu speichern, zu denen der größte Teil von Treiber- und Anwendungscode keinen Zugang hat.
1 ist ein Diagramm eines beispielhaften Datenverarbeitungssystems 100 zur Implementierung des VMM der vorliegenden Erfindung. Die Virtualisierung des Systemzustands zum Zweck des Ausführens von Legacykompatiblem Code oder des Schützens von Schlüsseldaten und Codebereichen zur Sicherheit, die hier beschrieben wird, kann in dem Datenverarbeitungssystem 100 implementiert und verwendet werden, das einen Vielzweckcomputer, einen tragbaren Computer oder ein anderes ähnliches Gerät darstellen kann. Die Komponenten des Datenverarbeitungssystems 100 sind beispielhaft, wobei ein oder mehrere Komponenten weggelassen oder hinzugefügt werden können. Zum Beispiel können ein oder mehrere Speichergeräte für das Datenverarbeitungssystem 100 verwendet werden.
Mit Bezug auf 1 enthält das Datenverarbeitungssystem 100 eine Zentralverarbeitungseinheit 102 und einen Signalprozessor 103, die über einen Bus 101 an eine Display-Schaltung 105, Hauptspeicher 104, statischen Speicher 106 und ein Massenspeichergerät 107 angekoppelt sind. Das Datenverarbeitungssystem 100 kann auch über den Bus 101 an ein Display 121, ein Tasteneingabefeld 122, Cursor-Steuerung 123, ein Druckausgabegerät 124, Eingangs-/Ausgangs-(E/A-)Geräte 125 und ein Audio-/Sprachgerät 126 angekoppelt sein.
Der Bus 101 ist ein Standardsystembus zum Übermitteln von Informationen und Signalen. Die CPU 102 und der Signalprozessor 103 sind Verarbeitungseinheiten für das Datenverarbeitungssystem 100. Die CPU 102 oder der Signalprozessor 103 oder beides können verwendet werden, um Informationen und/oder Signale für das Datenverarbeitungssystem 100 zu verarbeiten. Die CPU 102 enthält eine Steuereinheit 131, eine Arithmetik-Logik-Einheit (ALU) 132 und mehrere Register 133, mit denen Informationen und Signale verarbeitet werden. Der Signalprozessor 103 kann auch ähnliche Komponenten wie die CPU 102 enthalten.
Der Hauptspeicher 104 kann z. B. ein Direktzugriffsspeicher (RAM) oder ein anderes dynamisches Speichergerät zum Speichern von Informationen oder Anweisungen (Programmcode), die von der CPU 102 oder dem Signalprozessor 103 verwendet werden, sein. Der Hauptspeicher 104 kann temporäre Variablen oder andere Zwischeninformationen während der Ausführung von Anweisungen durch die CPU 102 oder den Signalprozessor 103 speichern. Bei dem statischen Speicher 106 kann es sich z. B. um einen Nurlesespeicher (ROM) und/oder um andere statische Speichergeräte zum Speichern von Informationen oder Anweisungen, die ebenfalls durch die CPU 102 oder den Signalprozessor 103 verwendet werden können, handeln. Das Massenspeichergerät 107 kann z. B. ein Festplatten- oder Diskettenlaufwerk oder ein optisches Plattenlaufwerk zum Speichern von Informationen oder Anweisungen für das Datenverarbeitungssystem 100 sein.
Das Display 121 kann zum Beispiel ein Kathodenstrahlröhren-(CRT-) oder Flüssigkristalldisplay (LCD) sein. Das Displaygerät 121 zeigt einem Benutzer Informationen oder Graphiken an. Das Datenverarbeitungssystem 100 kann über die Displayschaltung 105 eine Schnittstelle mit dem Display 121 aufweisen. Das Tasteneingabefeld 122 ist ein alphanumerisches Eingabegerät mit einem Analog/Digital-Umsetzer. Bei der Cursor-Steuerung 123 kann es sich z. B. um eine Maus, einen Trackball oder Cursorrichtungstasten zur Steuerung der Bewegung eines Objekts auf dem Display 121 handeln. Das Druckausgabegerät 124 kann zum Beispiel ein Laserdrucker zum Drucken von Informationen auf Papier, Film oder einem anderen ähnlichen Medium sein. An das Datenverarbeitungsystem 100 kann eine Anzahl von Eingangs-/Ausgangsgeräten 125 angekoppelt werden. Die Emulation einer Legacy-Umgebung zur Unterstützung von Legacy-Betriebssystemen und Legacy-Options-ROMS und die Emulation einer Umgebung des physikalischen Modus zur Bereitstellung geschützter Ausführung und Speicherung gemäß der vorliegenden Erfindung können durch in dem Datenverarbeitungssystem 100 enthaltene Hardware und/oder Software implementiert werden. Zum Beispiel kann die CPU 102 oder der Signalprozessor 103 Code oder Anweisungen ausführen, die in einem maschinenlesbaren Medium, z. B. im Hauptspeicher 104, gespeichert sind.
Das maschinenlesbare Medium kann einen Mechanismus enthalten, der Informationen in einer durch eine Maschine, wie zum Beispiel ein Computer oder ein digitales Verarbeitungsgerät, lesbaren Form bereitstellt (d. h. speichert und/oder überträgt). Zum Beispiel kann ein maschinenlesbares Medium einen Nurlesespeicher (ROM), Direktzugriffsspeicher (RAM), Magnetplattenspeichermedien, optische Speichermedien, Flash-Speichergeräte enthalten. Der Code bzw. die Anweisungen können durch Trägerwellensignale, Infrarotsignale, Digitalsignale oder durch andere ähnliche Signale representiert werden.
2 zeigt die Legacy-Emulation gemäß einer Ausführungsform der vorliegenden Erfindung. In der Regel wird ein PC-Motherboard Legacy-8259-Interrupt-Steuerungen unterstützen, obwohl nur die Legacy-Options-ROMs ihre Existenz voraussetzen; moderne Betriebssysteme verwenden APIC(LA32) oder SAPIC(IPF) für ihre Interrupt-Unterstützung, sodaß die Motherboard-Hardware, wie z. B. gepaarte 8259s, während einiger weniger Sekunden des Maschinen-Boot benutzbar bleiben.
Das in 2 gezeigte System 200 enthält einen EFI-Kern 205, ein Legacy-Ausführungsbild 210, EFI-Treiber 215 und den VMM 220. Das Legacy-Ausführungsbild 210 kann ein Vorboot-Options-ROM oder eine Laufzeitumgebung sein, der bzw. die die nativen EFI-Schnittstellen nicht verwendet. Bei einem Schreiben in eine Legacy-8259-Interrupt-Steuerbasis aus dem Legacy-Ausführungsbild 210 wird die Anweisung zum Beispiel auf dem VMM 220 eingefangen. Der VMM 220 kann jede beliebige Anweisung einfangen, die den Systemzustand (z. B. Interrupt-Flag) berührt oder den Schutz ändert. Wenn das System im Legacy-Modus ausgeführt wird, bildet der VMM 220 den Zugang auf die Legacy-Interrupt-(PIC-)Maske auf das zugeordnete native Interruptsteuerregister ab. Zum Beispiel kann das System versuchen, auf nicht vorhandene Legacy- Hardware zuzugreifen. Der VMM kann die E/A in das semantische äquivalent in der nativen Umgebung einschließen. An diesem Punkt kann einer der EFI-Treiber 215 mit dem relevanten Chipsatzregister kommunizieren und das Ergebnis der virtuellen Maschine zuführen. Dadurch wird ein Migrationsweg von der Legacy-Umgebung bereitgestellt.
Ein VMM kann zur Bereitstellung von Vorboot-Sicherheit durch Sandbox-Betrieb von Programmen in bezug auf Dritte verwendet werden. Das Betreiben eines Programms im Sandbox-Modus verhindert, daß das Programm Zugang zu dem Rest des Systems hat. Dem Code kann vertraut werden, da er dem Rest des Systems nicht schaden kann. Der Anwendung kann Zugang zu einer Teilmenge der Systembetriebsmittel gegeben werden, und Zugriff auf Teile der Speicherabbildung, die nicht für Aktualisierungen gekennzeichnet sind, würden auf dem VMM einschließen. Ein VMM-Vorboot-Richtlinien-Agent kann dann den Zustand schützen und problematische Software entladen.
3 ist ein Prozeßflußdiagramm des VMM-Betriebs für einen Sandbox-Betrieb eines Programms, dem nicht vertraut wird, gemaß einer Ausführungsform der vorliegenden Erfindung. Der in 3 gezeigte Prozeß 300 beginnt mit der Operation 305, in der ein Programm, dem nicht vertraut wird, einen illegalen Schreibzugriff versucht. In der Operation 310 wird die Anweisung auf dem VMM eingeschlossen. Wenn das Programm durch EFI-Kerncode gestartet wird und wenn das Programm Zugang zu den EFI-Kerndatenstrukturen hat, dann ist der Zugang legal. Andernfalls wird der Zugang in der Operation 320 verwehrt und die Steuerung an den Kern zurückgegeben.
Bei einer Ausführungsform kann der VMM den Zustand, den aus Adapterkarten und über Treiber Dritter eingeführter Code verfälschen könnte, im Sandbox-Verfahren behandeln. Der kleine Codegrundumfang einer solchen Softwaretechnik ist für kostenempfindliche, auf Flash- Speicher basierende Systeme vorteilhaft.
Der VMM wird im privilegierten Modus ausgeführt und emuliert den privilegierten Modus zur Ausführung der EFI-Umgebung bis zu dem OS-Ladevorgang. Da der VMM diesen weniger privilegierten Code abstrahiert, kann der VMM Teile des Adressenraums verbergen. Die geschützte Speicherung und Ausführung, die das Virtualisieren des geschützten Modus ermöglicht, wird Teil der Sicherheitsinfrastruktur.
4 zeigt die Implementierung einer Sicherheitsanwendung durch Verwendung eines VMM gemäß einer Ausführungsform der vorliegenden Erfindung. Das in 4 gezeigte System 400 enthält einen Vorboot-Authentisierungstreiber 405, der ein Modul 410 auswertet. Das Modul 410 kann eine digitale Signatur von dem Vertreiber enthalten. Die Signatur kann eine MD5- oder eine SHA-1-Signatur sein. Der Vorboot-Authentisierungstreiber 405 kann einen Eintrittspunkt in die Signaturlogik 421 des VMM 420 aufrufen, um die Signatur zu validieren. Der VMM 420 stellt sichere Speicherung 422 bereit, die die Signaturen gültiger Treiber und Module in einer Attest-Protokollierung enthalten kann. Die Attest-Protokollierung kann die Signaturen von Code enthalten, den das System geladen hat. In diesem Fall validiert der VMM den Code, d. h. die Plattform attestiert, den Code ablaufengelassen zu haben. Dadurch wird dem OS vor der Übernahme der Kontrolle versichert, daß dem Code vertraut werden kann.
Somit liefert der VMM Vorboot-Sicherheit (d. h. die APIs und den Rahmen) zur Implementierung einer Plattform, der vertraut wird, bis einschließlich zum OS-Laden. An diesem Punkt kann die OS-Ladevorrichtung ihre eigene Sicherheit bereitstellen.
In der obigen Spezifikation wurde die Erfindung mit Bezug auf spezifische Ausführungsbeispiele beschrieben.
Es versteht sich jedoch, daß verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne von dem allgemeineren Gedanken und Schutzumfang der Erfindung abzuweichen, die in den angefügten Ansprüchen definiert wird. Die Spezifikation und Zeichnungen sollen folglich nicht im einschränkenden, sondern im veranschaulichenden Sinne betrachtet werden.

Claims

Verfahren mit den folgenden Schritten: Implementieren eines virtuellen Maschinenmonitors (420) auf einem Computersystem (400) mit einer Native-Umgebung, die in einem physikalischen Modus ausgeführt wird, wobei das Computersystem (400) ein Extensible Firmware-Interface (EFI) mit zumindest einem zusätzlichen Codemodul aufweist; Emulieren von Legacy-Hardwarekomponenten, die nicht in der Native-Umgebung vorhanden sind, durch den virtuellen Maschinenmonitor (420), um das Booten eines Legacy-Betriebssystems zu unterstützen; und vor dem Booten des Legacy Betriebssystems, Aufrufen der Signatur-Logik (421) des virtuellen Maschinenmonitors (420), um eine im Codemodul enthaltene Hash-Signatur gegen eine in einem sicheren Speicher (422) des Virtuellen Maschinenmonitors (420) gespeicherte Hash-Signatur zu validieren, um dem Legacy-Betriebssystem vor der Übernahme der Kontrolle durch eine Attestprotokollierung zu versichern, daß dem Code des Codemoduls vertraut werden kann.
Verfahren nach Anspruch 1, wobei die Native-Umgebung eine 32-Bit-Umgebung oder eine 64-Bit-Umgebung umfaßt.
Verfahren nach Anspruch 2, wobei der virtuelle Maschinenmonitor (420) zumindest eine PC-AT-Hardwareemulation oder eine PC/AT-Umgebungsemulation bereitstellt.
Verfahren nach Anspruch 1, wobei das Verfahren des weiteren den folgenden Schritt umfaßt: Publizieren einer Umgebung, die die Umgebung des physikalischen Modus zu sein scheint für Softwareeinheiten, die auf dem virtuellen Maschinenmonitor (420) ablaufen, wobei die Umgebung des physikalischen Modus eine Speicherabbildung umfaßt, die Speicheradressen unter einem Megabyte umfaßt, wobei der virtuelle Maschinenmonitor (420) in einem Computersystem (400) implementiert ist, das keine physikalischen Adressen unter einem Megabyte dekodiert.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der virtuelle Maschinenmonitor (420) den weiteren Schritt eines Verbergens eines Teils eines Adressenraums für das Computersystem (400) umfaßt.
Verfahren nach einem der vorhergehenden, wobei das Verfahren des weiteren die folgenden Schritte umfaßt: Freigeben eines Legacy-Option-ROM, so daß er ausgeführt wird und seine Eingabe/Ausgabe-Dienste bewirken kann; und Übersetzen der Ergebnisse der Eingabe/Ausgabedienste in eine Native-Anwendungsprogrammschnittstelle.
Verfahren nach einem der vorhergehenden Ansprüche, welches des weiteren umfaßt: Entladen eines Codemoduls, das versucht auf eine zugangsbeschränkte Systemressource oder einen beschränkten Teil der Speicherabbildung zuzugreifen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei ein Authentisieren über den virtuellen Maschinenmonitor (420) des zumindest einen Codemoduls, das während der Vor-Boot-Phase geladen wurde, des weiteren umfaßt: Führen eines Attest-Protokolls über den virtuellen Maschinenmonitor (420), das Codemodule identifiziert, die durch die Signatur-Logik geladen und authentisiert wurden.
Datenträger, auf dem eine maschinenlesbare Firmware gespeichert ist, die ein Verfahren gemäß einem der vorhergehenden Ansprüche ausführt, wenn sie in einem Computer abgearbeitet wird.
Datenträger nach Anspruch 9, wobei eine Ausführung des Verfahrens die Ausführung weiterer Schritte bewirkt, welche umfassen: Ausführen von nicht vertrauenswürdigem Firmware-Modul-Code auf dem virtuellen Maschinenmonitor (420) in einem Sandbox-Mode, so daß der Code daran gehindert wird, dem Computersystem (400) zu schaden.
Computersystem (400) mit einer Native-Ausführungsumgebung, die im physikalischen Modus ausgeführt wird, a) wobei das Computersystem (400) ein Extensible Firmware-Interface (EFI) mit zumindest einem zusätzlichen Codemodul aufweist, b) wobei die Native-Ausführungsumgebung weiter einen Virtuellen Maschinenmonitor (420) aufweist zur Emulation von Legacy-Hardwarekomponenten, die in der Native-Umgebung nicht vorhanden sind, um das Booten eines Legacy-Betriebssystems zu unterstützen, c) wobei der virtuelle Maschinenmonitor (420) eine Signatur-Logik (421) und einen sicheren Speicher (422) umfaßt, d) wobei der sichere Speicher Hash-Signaturen von Codemodulen enthält; e) wobei vor dem Booten des Legacy Betriebssystems die Signatur-Logik (421) aufgerufen wird, um eine im Codemodul enthaltene Hash-Signatur gegen eine im sicheren Speicher (422) gespeicherte Hash-Signatur zu validieren, um dem Legacy-Betriebssystem vor der Übernahme der Kontrolle durch eine Attestprotokollierung zu versichern, daß dem Code des Codemoduls vertraut werden kann.
Computersystem (400) nach Anspruch 11, welches des weiteren umfaßt: Einen Vor-Boot-Authentisierungstreiber (405), der einen Eintrittspunkt in die Signaturlogik (421) aufruft, um das Codemodul zu evaluieren.
Computersystem (400) nach Anspruch 11 oder 12, wobei der virtuelle Maschinenmonitor (420) zumindest eine PC-AT-Hardwareemulation oder eine PC/AT-Umgebungsemulation bereitstellt.
Computersystem (400) nach einem der Ansprüche 11 bis 13, wobei der virtuelle Maschinenmonitor (420) weitere Schritte ausführt, welche umfassen: Freigeben eines Legacy-Option-ROMs, so daß dieser seine Eingabe/Ausgabe-Dienste ausführt und bewirkt; Einfangen von Aufrufen von Legacy-Interrupts durch den virtuellen Maschinenmonitor (420), und Abbilden der Aufrufe von Legacy-Interrupts auf entsprechende Interrupts der Native-Umgebung durch den virtuellen Maschinenmonitor (420).