DE112020000280B4

DE112020000280B4 - Transparente interpretation von gastbefehlen in einer sicheren virtuellen maschinenumgebung

Info

Publication number: DE112020000280B4
Application number: DE112020000280.2T
Authority: DE
Inventors: Fadi Busaba; Lisa Heller; Jonathan Bradbury; Christian Borntraeger; Claudio Imbrenda
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2019-03-08
Filing date: 2020-02-27
Publication date: 2023-02-16
Anticipated expiration: 2040-02-28
Also published as: US20200285494A1; GB202113915D0; DE112020000280T5; JP7386882B2; JP2022522663A; CN113544678A; WO2020183278A1; GB2595428B; GB2595428A; US10956188B2

Abstract

Durch einen Computer implementiertes Verfahren, das aufweist:Ausführen (505) eines Befehlsstroms von einer virtuellen Maschine (15A; 15B; 15C; 15D; 15N), die auf einem Host-Server (10) ausgeführt wird, wobei ein Befehl aus dem Befehlsstrom zu einem Hypervisor (12) abgefangen werden muss;auf der Grundlage einer Feststellung (515), dass es sich bei der virtuellen Maschine um eine sichere virtuelle Maschine handelt, Verhindern, dass der Hypervisor direkt auf beliebige Daten der sicheren virtuellen Maschine zugreift; undDurchführen (525) durch eine sichere, durch Millicode und interne vertrauenswürdige Hardware und Firmware realisierte Schnittstellensteuerung (11) des Host-Servers:auf der Grundlage einer Feststellung (540), dass der Befehl nicht von der sicheren Schnittstellensteuerung selbst interpretierbar ist, weil die sichere Schnittstellensteuerung nicht auf die Operanden zugreifen kann:Extrahieren (555) eines oder mehrerer Parameterdatenelemente, die dem Befehl von der sicheren virtuellen Maschine zugehörig sind, durch die sichere Schnittstellensteuerung;Speichern (555) des einen oder mehrerer Parameterdatenelemente durch die sichere Schnittstellensteuerung in einem Puffer, auf den der Hypervisor Zugriff hat; undAbfangen (555) des Befehls zum Hypervisor durch die sichere Schnittstellensteuerung;auf der Grundlage einer Feststellung (540), dass der Befehl durch die sichere Schnittstellensteuerung selbst interpretierbar ist, weil die sichere Schnittstellensteuerung auf die Operanden zugreifen kann:Ausführen (545) des Befehls durch die sichere Schnittstellensteuerung; undZurückgeben der Ausführungssteuerung an die sichere virtuelle Maschine, um die Ausführung des Befehlsstroms fortzusetzen.

Description

HINTERGRUND
Die vorliegende Anwendung bezieht sich auf Computertechnologie und insbesondere auf virtuelle Maschinen.
Cloud-Computing ermöglicht es, einem Kunden einfach und schnell eine virtuelle Maschine bereitzustellen, ohne dass der Kunde Hardware kaufen oder Platz für einen physischen Server bereitstellen muss. Je nachdem, wie die Einstellungen geändert werden, kann der Kunde die virtuelle Maschine erweitern oder verkleinern. In der Regel stellt der Anbieter des Cloud-Computings die virtuelle Maschine bereit, die sich physisch im Rechenzentrum des Anbieters befindet. In dieser Umgebung wird die virtuelle Maschine des Kunden als Gast ausgeführt, und der Cloud-Anbieter verwendet Hypervisor-Code, der als Host ausgeführt wird, um die Server-Ressourcen zwischen mehreren virtuellen Maschinen zu virtualisieren, die möglicherweise zu verschiedenen Kunden gehören.
Kunden sind oft im Hinblick auf die Sicherheit der Daten in der virtuellen Maschine besorgt. Cloud-Betreibern wird möglicherweise nicht vertraut, und Kunden möchten ihre Arbeit ohne das Risiko verwenden, dass diese durch schädlichen oder fehlerhaften Code (z.B. Hypervisor) und/oder einen Systemadministrator mit böswilligen Absichten, der das Rechenzentrum betreibt, gefährdet ist. Ein Kunde kann beispielsweise verlangen, dass Cloud-Anbieter keinen Zugriff auf seine Daten haben, um die Möglichkeit zu verringern oder zu vermeiden, dass der Anbieter des Cloud-Computings, z.B. ein USamerikanisches Unternehmen, möglicherweise durch eine Vorladung gezwungen ist, vertrauliche oder geschützte Dokumente herauszugeben.
Die Druckschrift US 2016 / 0 132 345 A1 betrifft ein Verfahren zur Verarbeitung eines Gast-Ereignisses in einem von einem Hypervisor gesteuerten System, das die Schritte aufweist: (i) Durch das Gast-Ereignis Auslösen eines ersten Firmware-Dienstes, der für das Gast-Ereignis spezifisch ist, in einer Firmware, wobei das Gast-Ereignis zu einem Gast und zu einem Gast-Zustand und einem geschützten Gast-Hauptspeicher, auf den nur der Gast und die Firmware zugreifen können, sowie einem Gast-Schlüssel gehört; (ii) durch die Firmware Verarbeiten von zu dem Gast-Ereignis gehörenden Informationen, die Informationen über den Gast-Zustand und den geschützten Gast-Hauptspeicher aufweisen, und Übergeben von nur einer Teilmenge der Informationen über den Gast-Zustand und den geschützten Gast-Hauptspeicher an einen Hypervisor, wobei die Teilmenge der Informationen so ausgewählt wird, dass sie dem Hypervisor zur Verarbeitung des Gast-Ereignisses genügt; (iii) durch die Firmware Zurückhalten eines Teils der Informationen über den Gast-Zustand und den geschützten Gast-Hauptspeicher, welcher nicht an den Hypervisor gesendet wird; (iv) Verarbeiten des Gast-Ereignisses durch den Hypervisor auf der Grundlage der empfangenen Teilmenge der Informationen über den Gast-Zustand und den geschützten Gast-Hauptspeicher und Senden eines Prozessergebnisses an die Firmware, die einen zweiten Firmware-Dienst auslöst, der für das Gast-Ereignis spezifisch ist; (v) durch die Firmware Verarbeiten des empfangenen Prozessergebnisses zusammen mit dem Teil der Informationen über den Gast-Zustand und den geschützten Gast-Hauptspeicher, welcher nicht an den Hypervisor gesendet wurde, was eine Zustands- und/oder eine Hauptspeicheränderung erzeugt; (vi) Durchführen der Zustands- und/oder der Hauptspeicheränderung, die zu dem Gast-Ereignis gehört, an dem geschützten Gast-Hauptspeicher durch die Firmware.
Der Wikipedia-Eintrag „Status register“ betrifft eine Beschreibung eines Statusregisters, das ein spezielles Register im Rechenwerk eines Mikroprozessors (Status register. In: Wikipedia, the free encyclopedia. Bearbeitungsstand: 23.12.2018. URL: https://en.wikipedia.org/w/index.php?title=Status_register&oldid=875109388 [abgerufen am 06.09.2022]). Der Wikipedia-Eintrag „Interrupt“ betrifft eine Beschreibung eines Begriffs „Interrupt“ in der Informatik (Interrupt. In: Wikipedia, the free encyclopedia. Bearbeitungsstand: 26.02.2019. URL:
https://en.wikipedia.org/w/index.php?title=Interrupt&oldid=885162267 [abgerufen am 06.09.2022]).
KURZDARSTELLUNG
Die Erfindung betrifft ein durch einen Computer implementiertes Verfahren, ein System und ein Computerprogrammprodukt, deren Merkmale in den entsprechenden unabhängigen Ansprüchen angegeben sind. Bevorzugte Ausführungsformen der Erfindung sind in den abhängigen Patentansprüchen angegeben. Insbesondere umfasst ein durch einen Computer implementiertes Verfahren Ausführen eines Befehlsstroms durch eine virtuelle Maschine, die auf einem Host-Server ausgeführt wird, wobei ein Befehl aus dem Befehlsstrom zu einem Hypervisor abgefangen wird. Auf der Grundlage einer Feststellung, dass es sich bei der virtuellen Maschine um eine sichere virtuelle Maschine handelt, umfasst das Verfahren weiterhin Verhindern, dass der Hypervisor direkt auf Daten der sicheren virtuellen Maschine zugreift. Das Verfahren umfasst weiterhin Durchführen durch eine sichere Schnittstellensteuerung des Host-Servers auf der Grundlage einer Feststellung, dass der Befehl nicht durch die sichere Schnittstellensteuerung selbst interpretiert werden kann, eines Extrahierens einer oder mehrerer Parameterdatenelemente, die dem Befehl von der sicheren virtuellen Maschine zugehörig sind, und Speicherns der Parameterdatenelemente in einem Puffer, auf den der Hypervisor Zugriff hat. Der Befehl wird anschließend zum Hypervisor abgefangen.
Des Weiteren umfasst das Verfahren weiterhin Durchführen durch eine sichere Schnittstellensteuerung des Host-Servers auf der Grundlage einer Feststellung, dass der Befehl durch die sichere Schnittstellensteuerung selbst interpretiert werden kann, eines Ausführens des Befehls durch die sichere Schnittstellensteuerung und Zurückgebens der Ausführungssteuerung an die sichere virtuelle Maschine, um den Befehlsstrom weiter auszuführen.
Das Abfangen des Befehls kann umfassen: Setzen eines ersten Merkers durch die sichere Schnittstellensteuerung, der anzeigt, dass der Befehl teilweise beendet ist, und Setzen eines zweiten Merkers durch die sichere Schnittstellensteuerung, der anzeigt, dass die sichere virtuelle Maschine für die Ausführung gesperrt ist.
Das Verfahren kann weiterhin auf der Grundlage einer Feststellung durch die sichere Schnittstellensteuerung, dass der Befehl beim Ausführen eine Programmausnahmebedingung verursacht, Anzeigen der Ausnahmebedingung für die sichere virtuelle Maschine anstelle des Abfangens des Befehls zum Hypervisor umfassen.
Das Verfahren kann weiterhin nach dem Beenden der Ausführung des Befehls durch den Hypervisor Aktualisieren eines Zustands der sicheren virtuellen Maschine durch die sichere Schnittstellensteuerung mit einer Antwort vom Hypervisor umfassen, wobei mindestens ein Teil des Zustands in einem sicheren Teil des Speichers gespeichert wird, auf den der Hypervisor keinen Zugriff hat.
Außerdem kann der Hypervisor die Antwort für den Befehl in einem zweckgebundenen Puffer speichern.
Des Weiteren kann das Verfahren weiterhin nach dem Beenden der Ausführung auf der Grundlage einer Feststellung, dass die vom Hypervisor erzeugte Antwort nicht gültig ist, Abfangen einer Fehlerbedingung zum Hypervisor durch die sichere Schnittstellensteuerung umfassen.
Außerdem umfasst die sichere Schnittstellensteuerung Millicode.
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung werden die vorstehend beschriebenen Merkmale ferner mindestens von einem System, einem Computerprogrammprodukt und einer Maschine bereitgestellt.
Ein beispielhaftes durch einen Computer implementiertes Verfahren umfasst Ausführen eines Gastbefehls von einer sicheren virtuellen Maschine durch einen Hypervisor auf einer Host-Maschine, wobei der Hypervisor daran gehindert wird, direkt auf Daten der sicheren virtuellen Maschine zuzugreifen. Das Verfahren umfasst weiterhin Speichern einer Antwort auf den Gastbefehl in einem zuvor festgelegten Puffer durch den Hypervisor. Das Verfahren umfasst weiterhin Aktualisieren eines Zustandsdeskriptors der sicheren virtuellen Maschine mit der Antwort durch eine sichere Schnittstellensteuerung der Host-Maschine, indem die Antwort in ein angegebenes Register in dem Zustandsdeskriptor kopiert wird, wobei der Zustandsdeskriptor in einem sicheren Teil des Speichers gespeichert ist, auf den der Hypervisor keinen Zugriff hat.
Das bespielhafte Verfahren kann weiterhin auf der Grundlage einer Feststellung, dass die vom Hypervisor erzeugte Antwort nicht gültig ist, Abfangen einer Fehlerbedingung zum Hypervisor durch die sichere Schnittstellensteuerung umfassen.
Das beispielhafte Verfahren kann weiterhin Zurücksetzen eines ersten, der sicheren virtuellen Maschine zugehörigen Merkers durch die sichere Schnittstellensteuerung umfassen, wobei das Zurücksetzen anzeigt, dass die sichere virtuelle Maschine zugeteilt werden kann, um die Ausführung eines Befehlsstroms fortzusetzen.
Die Merkmale des vorstehenden beispielhaften Verfahrens können mindestens von einem System, einem Computerprogrammprodukt und einer Maschine bereitgestellt werden.
Die hierin beschriebenen Merkmale stellen Verbesserungen für die Computertechnologie bereit, insbesondere für Computerserver, die virtuelle Maschinen (VMs) hosten, indem sie es den Computerservern ermöglichen, sichere VMs zu hosten. Bei sicheren VMs wird der Hypervisor nicht mehr mit der Steuerung der Daten der VMs betraut, und selbst dem Hypervisor ist der Zugriff auf Speicher, Register und andere Daten verwehrt, die der sicheren VM zugehörig sind. Hierin beschriebene technische Merkmale ermöglichen es den Host-Computerservern darüber hinaus, eine Trennung der sicheren VM und des Hypervisors zu ermöglichen und damit die Sicherheit der vom Datenverarbeitungsserver gehosteten VMs zu gewährleisten.
Zusätzliche technische Merkmale und Vorteile werden durch die Techniken der vorliegenden Erfindung umgesetzt. Ausführungsformen und Aspekte der Erfindung werden hierin im Einzelnen beschrieben und als Teil des beanspruchten Gegenstands angesehen. Zu einem besseren Verständnis sei auf die Beschreibung und die Zeichnungen verwiesen.
Figurenliste
Die Besonderheiten der hierin beschriebenen ausschließlichen Rechte werden in den Ansprüchen am Ende der Beschreibung besonders hervorgehoben und ausdrücklich beansprucht. Das Vorstehende und andere Merkmale und Vorteile der Ausführungsformen der Erfindung ergeben sich aus der nachfolgenden ausführlichen Beschreibung in Verbindung mit den beigefügten Zeichnungen, in denen:

1 eine Cloud-Computing-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
2 Abstraktionsmodellschichten gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
3 ein beispielhaftes System eines Hosting-Systems gemäß einer Ausführungsform zeigt;
4 ein beispielhaftes Blockschaubild eines Hosting-Systems gemäß einer Ausführungsform zeigt;
5 einen Ablaufplan eines beispielhaften Verfahrens für eine transparente Interpretation von Gastbefehlen in einer sicheren virtuellen Maschinenumgebung gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung zeigt; und
6 einen Ablaufplan eines beispielhaften Verfahrens für eine transparente Interpretation von Gastbefehlen in einer sicheren virtuellen Maschinenumgebung gemäß einer oder mehreren Ausführungen der vorliegenden Erfindung darstellt.

AUSFÜHRLICHE BESCHREIBUNG
Verschiedene Ausführungsformen der Erfindung werden hierin mit Bezug auf die dazugehörigen Zeichnungen beschrieben. Alternative Ausführungsformen der Erfindung können entwickelt werden, ohne vom Anwendungsbereich dieser Erfindung abzuweichen. In der folgenden Beschreibung und in den Zeichnungen werden verschiedene Verbindungen und Positionsbeziehungen (z.B. über, unter, neben usw.) zwischen den Elementen dargelegt. Sofern nicht anders angegeben, können diese Verbindungen und/oder Positionsbeziehungen direkt oder indirekt sein, und die vorliegende Erfindung soll in dieser Hinsicht nicht einschränkend sein. Dementsprechend kann sich eine Verbindung von Einheiten entweder auf eine direkte oder indirekte Verbindung beziehen, und bei einer Positionsbeziehung zwischen Entitäten kann es sich um eine direkte oder indirekte Positionsbeziehung handeln. Darüber hinaus können die verschiedenen hierin beschriebenen Aufgaben und Prozessschritte in ein umfassenderes Verfahren oder einen Prozess mit zusätzlichen Schritten oder zusätzlicher Funktionalität integriert werden, die hierin nicht im Einzelnen beschrieben sind.
Für die Auslegung der Ansprüche und der Beschreibung sind folgende Begriffsbestimmungen und Abkürzungen zu verwenden. Wie hierin verwendet, sollen die Begriffe „aufweisen“, „umfassen“, „haben“, „enthalten“ oder Abwandlungen davon eine nichtausschließliche Einbeziehung umfassen. So ist beispielsweise eine Zusammensetzung, eine Mischung, ein Prozess, ein Verfahren, ein Artikel oder eine Vorrichtung, die/der/das eine Liste von Elementen aufweist, nicht unbedingt auf diese Elemente beschränkt, sondern kann auch andere Elemente enthalten, die nicht ausdrücklich aufgeführt sind oder zu einer/einem solchen Zusammensetzung, Mischung, Prozess, Verfahren, Artikel oder Vorrichtung dazugehören.
Darüber hinaus wird der Begriff „beispielhaft“ hierin in der Bedeutung „um als Beispiel, Fall oder Veranschaulichung zu dienen“ verwendet. Ausführungsformen oder Entwürfe, die hierin als „beispielhaft“ beschrieben werden, sind nicht unbedingt als bevorzugt oder vorteilhaft gegenüber anderen Ausführungsformen oder Entwürfen zu verstehen. Unter den Begriffen „mindestens eine/einer/eines“ und „ein/eine oder mehrere“ kann eine ganze Zahl verstanden werden, die größer oder gleich eins ist, d.h. eins, zwei, drei, vier usw. Unter dem Begriff „eine Mehrzahl“ kann eine ganze Zahl verstanden werden, die größer oder gleich zwei ist, d.h. zwei, drei, vier, fünf usw. Der Begriff „Verbindung“ kann eine indirekte „Verbindung“ und eine direkte „Verbindung“ umfassen.
Die Begriffe „etwa“, „im Wesentlichen“, „annähernd“ und Abwandlungen davon sollen den Grad des Fehlers umfassen, der mit der Messung der jeweiligen Menge auf der Grundlage der zum Zeitpunkt der Anmeldung vorhandenen Ausrüstung verbunden ist. Beispielsweise kann „etwa“ einen Bereich von ± 8 % oder 5 % oder 2 % eines bestimmten Wertes umfassen.
Aus Gründen der Kürze werden herkömmliche Techniken im Zusammenhang mit der Herstellung und Verwendung von Aspekten der Erfindung hierin gegebenenfalls ausführlich beschrieben werden. Insbesondere sind verschiedene Aspekte von Datenverarbeitungssystemen und spezifischen Computerprogrammen zum Implementieren der hierin beschriebenen verschiedenen technischen Merkmale bekannt. Aus Gründen der Kürze werden daher zahlreiche herkömmliche Implementierungseinzelheiten nur kurz erwähnt oder ganz weggelassen, ohne die bekannten System- und/oder Prozesseinzelheiten bereitzustellen.
Bei üblichen Cloud-Umgebungen stellt der potenziell unsichere und unerwünschte Zugriff auf Daten und Algorithmen (z.B. durch einen Cloud-Anbieter oder Cloud-Administrator) ein technisches Problem dar. Der Cloud-Anbieter führt in der Regel Hypervisor-Code als Host aus, wobei die VMs der Kunden als Gäste ausgeführt werden. Dieser Hypervisor-Code stellt die Virtualisierungsfunktion bereit, die erforderlich ist, damit mehrere VMs auf einer einzigen physischen Maschine ausgeführt werden können. In bestehenden Systemen hat der Hypervisor (und damit oft auch der Cloud-Administrator) Zugriff auf die Daten und Algorithmen der Kunden für Situationen, in denen er auf beschränkte Teile dieser Daten zugreifen muss, um eine Virtualisierungsfunktion bereitzustellen. Cloud-Anbieter können zum Beispiel einen Speicherauszug erstellen, um Leistungs- und Funktionsprobleme im System zu analysieren. Der Speicherauszug kann Kundengeheimnisse enthalten, die ein Kunde nicht preisgeben möchte. Der Systembediener kann auch den Zustand des internen Prozessorregisters anzeigen, der ebenfalls Geheimnisse enthält. Hypervisoren müssen zum Beispiel unter anderem auf Gastdaten zugreifen, um Gastbefehle zu interpretieren und E/A-Operationen im Auftrag des Gastes durchzuführen. Der Hypervisor-Zugriff auf den Gastspeicher ist erforderlich, um die funktionale Korrektheit des Gastes bereitzustellen. Bei der sicheren Ausführung, wie sie von einer oder mehreren Ausführungsformen der vorliegenden Erfindung verwendet wird, ist der Hypervisor nicht mehr vertrauenswürdig, kann jedoch weiterhin an der Interpretation von Gastbefehlen beteiligt sein. Eine oder mehrere Ausführungsformen der vorliegenden Erfindung stellen daher eine Möglichkeit bereit, dass ein nichtvertrauenswürdiger Hypervisor Gastbefehle sicher emuliert.
Eine virtuelle Maschine, die als Gast unter der Steuerung eines Host-Hypervisors ausgeführt wird, verlässt sich darauf, dass dieser Hypervisor transparent Virtualisierungsdienste für diesen Gast bereitstellt. Zu diesen Diensten können Speicherverwaltung, Befehlsemulation und Unterbrechungsverarbeitung gehören, ohne auf dies beschränkt zu sein. Eine oder mehrere Ausführungsformen der vorliegenden Erfindung können auf jede Schnittstelle zwischen einer sicheren Entität und einer anderen nichtvertrauenswürdigen Entität Anwendung finden, die in der Regel den Zugriff auf die sicheren Ressourcen durch diese andere Entität ermöglicht. Der Hypervisor liest und/oder schreibt zum Beispiel für die Unterbrechungs- und Ausnahmeinterpretation in einen Präfix-Bereich (unterer Hauptspeicherbereich) des Gastes. Der hierin verwendete Begriff „virtuelle Maschine“ oder „VM“ bezieht sich auf eine logische Darstellung einer physischen Maschine (Computereinheit, Prozessor usw.) und ihrer Verarbeitungsumgebung (Betriebssystem (BS), Software-Ressourcen usw.). Der Zustand der virtuellen Maschine wird vom Hypervisor aufrechterhalten, der auf einer zugrunde liegenden Host-Maschine (physischer Prozessor oder Satz von Prozessoren) ausgeführt wird. Aus der Sicht eines Anwenders oder einer Software-Ressource erscheint die virtuelle Maschine wie eine eigene, unabhängige physische Maschine. Die hierin verwendeten Begriffe „Hypervisor“ und „VM-Monitor (VMM)“ beziehen sich auf eine Verarbeitungsumgebung oder einen Plattformdienst, die bzw. der mehrere VMs verwaltet und es ihnen ermöglicht, unter Verwendung mehrerer (und manchmal unterschiedlicher) BS auf derselben Host-Maschine ausgeführt zu werden. Es sei darauf hingewiesen, dass ein Bereitstellen einer VM einen Installationsprozess der VM und einen Aktivierungs- (oder Start-)Prozess der VM umfasst. In einem anderen Beispiel umfasst das Bereitstellen einer VM einen Aktivierungs- (oder Start-)Prozess der VM (z.B. wenn die VM bereits installiert oder vorhanden ist).
Um sichere Gäste zu ermöglichen, besteht jedoch eine technische Herausforderung darin, dass der Datenverarbeitungsserver, z.B. der Hosting-Knoten, zusätzliche Sicherheit zwischen dem Hypervisor und den sicheren Gästen bereitstellen muss, damit der Hypervisor nicht auf Daten von der VM zugreifen kann und somit keine Dienste in der vorstehend beschriebenen Weise bereitstellen kann.
Bei den derzeit verfügbaren technischen Lösungen teilt der Hypervisor (z.B. z/VM^® von IBM^® oder Open-Source-Software Kernel Based Virtual Machine (KVM)) eine neue virtuelle CPU der VM (vCPU) auf einer physischen Verarbeitungseinheit oder einem Host-Server zu, indem er einen Start-Interpretive-Execution-Befehl (SIE-Befehl) ausgibt, der bewirkt, dass der SIE-Entry-Millicode aufgerufen wird. Bei dem Operanden des SIE-Befehls handelt es sich um einen Steuerblock, der als Zustandsbeschreibung (state description, SD) bezeichnet wird und den Gastzustand enthält. In bestehenden Implementierungen befindet sich diese Zustandsbeschreibung im Hypervisor-Speicher. Bei SIE-Entry wird dieser Gastzustand (einschließlich der allgemeinen Register und Steuerregister, der Gastbefehlsadresse und des Gast-Programmstatusworts (PSW)) per Millicode in die Hardware geladen. Dadurch kann die Gast-vCPU auf dem physischen Prozessor ausgeführt werden. Während die vCPU auf der Hardware ausgeführt wird, wird der Gastzustand in der Hardware aufrechterhalten. Ab einem bestimmten Zeitpunkt muss die Hardware/der Millicode die Steuerung wieder an den Hypervisor zurückgeben. Dies wird oft als SIE-Exit bezeichnet. Dies kann zum Beispiel erforderlich sein, wenn diese vCPU einen Befehl ausführt, der durch den Hypervisor emuliert werden muss, oder wenn die Zeitscheibe der vCPU (d.h. die Zeit, die dieser vCPU für die Ausführung auf dem physischen Prozessor zugewiesen wurde) abläuft. Da die Hardware bei SIE-Exit immer nur Ressourcen für eine einzige vCPU zu einem beliebigen Zeitpunkt zur Verfügung hat und nun den Zustand des Hypervisors in die Hardware laden muss, speichert der Millicode den aktuellen Gastzustand in der Zustandsbeschreibung. Zwar wird diese vCPU nicht zugeteilt, ihr Zustand wird aber in der Zustandsbeschreibung aufrechterhalten. Da sich diese Zustandsbeschreibung im Hypervisor-Speicher befindet, hat der Hypervisor in solchen Fällen die Steuerung über die Daten für die VM, und in einigen Fällen ist diese Steuerung erforderlich, um Befehle zu interpretieren, die auf der VM ausgeführt werden. Bestehende Hypervisoren stützen sich darauf, eine solche Schnittstelle durch den SIE-Befehl zu verwenden, um vCPUs zuzuteilen.
Der Hypervisor, der mehrere VMs verwaltet, muss darüber hinaus Gastbefehle interpretieren, d.h. Befehle, die auf einer VM ausgeführt werden. Im Rahmen dieser Interpretation hat der Hypervisor bei bestehenden Lösungen in der Regel vollen Zugriff auf die SD und andere Daten der VM, wobei die SD und die Daten in einem Speicher gespeichert werden, der Teil einer Host-Maschine ist, die den Hypervisor ausführt. Es ist zu beachten, dass nicht alle Befehle, die auf der VM ausgeführt werden, vom Hypervisor interpretiert werden müssen. Befehle, bei denen ein Zugriff auf Systemebene erforderlich ist, wie E/A-Zugriffe, benötigen in der Regel diese Hypervisor-Interpretation. Diese Gastbefehle, die eine Hypervisor-Interpretation benötigen, verursachen ein SIE-Exit-Abfangen (Unterbrechen des Gastbefehlsstroms) vom Gastmodus zum Hypervisor. Der Hypervisor prüft anschließend, welcher Befehl das Abfangen verursacht hat, und interpretiert dies, indem er entsprechende Gastdaten, die sich im Gastregister oder Gastspeicher befinden, liest und/oder schreibt. Die abgefangene VM wird in der Folge neu zugeteilt, um mit der Ausführung ihres Befehlsstroms fortzufahren.
Es ist zu beachten, dass Fälle für ein „Befehlsabfangen“ in der Regel ein Betriebssystem der VM aufweisen, das einen CPUID-Befehl ausgibt, um die Hardware-Eigenschaften zu ermitteln, und das direkt auf maschinenspezifische Register (MSRs) oder auf E/A-Anschlüsse zugreift. Wenn solche Befehle, die abgefangen werden müssen, erkannt werden, wird die Steuerung zum Weiterbearbeiten sofort an den Hypervisor 12 übertragen. Wenn die VM zum Beispiel einen Befehl zum Lesen oder Aktualisieren eines Wertes eines Steuerregisters (control register, CR) oder maschinenspezifischen Registers (MSR) ausgibt, wird diese Operation in einigen Fällen abgefangen und die Steuerung wird an den Hypervisor 12 übertragen, wo das Verhalten der VM vom Hypervisor simuliert wird, wozu auf einen oder mehrere Datenwerte von einem Zustandsdeskriptor der VM zugegriffen werden muss. Abgefangene Operationen können darüber hinaus Host-Programmausnahmebedingungen umfassen, die vom Hypervisor 12 bearbeitet werden.
Wenn dem Hypervisor die Steuerung der Daten der sicheren VM nicht mehr anvertraut wird, ist im Fall einer sicheren VM die herkömmliche Interpretation von Gastbefehlen nicht mehr möglich. Dieses technische Problem besteht, weil der Hypervisor keinen Zugriff auf Gastdaten (Register und deren Speicher) hat. Auch wenn der Hypervisor einen eingeschränkten Zugriff auf den Gastzustand erhält, kann der Hypervisor ein Verhalten der sicheren VM nicht beobachten, um Seitenkanalangriffe zu verhindern oder einzuschränken. Das technische Problem für den Hosting-Knoten besteht daher darin, es der sicheren Schnittstellensteuerung und/oder dem Hypervisor zu ermöglichen, Gastbefehle in einer sicheren VM zu interpretieren und auszuführen, wenn die VM nur begrenzte „Befugnis“ oder „Berechtigung“ hat, um auf die Systemressourcen des Hosting-Knotens zuzugreifen, zum Beispiel auf E/A-Einheiten oder Ähnliches.
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung werden technische Lösungen beschrieben, um Befehle in einer sicheren VM zu interpretieren, ohne dass dem Hypervisor Gastdaten offengelegt werden und ohne dass Gastbefehle oder das Betriebssystem neu geschrieben werden müssen. Mit anderen Worten, die Interpretation der Gastbefehle durch den Millicode und Hypervisor ist für die sichere VM selbst transparent. Bestehende Anwendungen und Betriebssysteme können somit unverändert verwendet werden, und der Hosting-Knoten und der Hypervisor, die solche sicheren VMs bereitstellen, sind mit bestehenden Produkten kompatibel. Mit anderen Worten, eine oder mehrere Ausführungsformen der vorliegenden Erfindung beseitigen technische Herausforderungen, indem sie es ermöglichen, dass die vorhandene VM, das Betriebssystem und Computeranwendungscode nicht geändert werden müssen und dass der Code in Hosting-Knoten und/oder Hypervisoren verwendet werden kann, die ebenfalls VMs auf sichere Weise zuteilen, wodurch dem Hypervisor der Zugriff auf den Zustand und/oder die Daten der sicheren VM verwehrt wird. Eine oder mehrere Ausführungsformen der vorliegenden Erfindung ermöglichen solche technischen Lösungen, indem sie eine verbesserte zugrunde liegende Implementierung der Interpretation der Gastbefehle in einer sicheren Schnittstellensteuerung (z.B. Millicode) verwenden, die die Gastbefehle für die sichere VM interpretiert.
In einem oder mehreren Beispielen kann eine solche Funktionalität durch die Verwendung von Millicode und/oder anderen Hardware-Modulen bereitgestellt werden, und in der vorliegenden Beschreibung werden die Hardware-Module und der Millicode gemeinsam als „sichere Schnittstellensteuerung“ bezeichnet. Eine oder mehrere Ausführungsformen der vorliegenden Erfindung ermöglichen es daher dem Hypervisor, Befehle in einer sicheren VM durch einen nichtvertrauenswürdigen Hypervisor sicher zu interpretieren, indem die sichere Schnittstellensteuerung (Millicode und interne vertrauenswürdige Hardware und Firmware) verwendet wird. Die sichere Schnittstellensteuerung koordiniert die Ausführung des Befehls zwischen der sicheren VM und dem nichtvertrauenswürdigen Hypervisor. Der Gastbefehl wird wie in einer nichtsicheren VM abgefangen, die Steuerung wird jedoch nicht sofort an den Hypervisor zurückgegeben, sondern zunächst an die sichere Schnittstellensteuerung, die die erforderlichen Gastdaten extrahiert und sie zusammen mit der Abfangbedingung für den Gastbefehl und zusätzlichen Kontextinformationen an den Hypervisor weiterleitet. Der Hypervisor verarbeitet die Anforderung und gibt die Antwort an die sichere Schnittstellensteuerung zurück. Anschließend aktualisiert die sichere Schnittstellensteuerung abhängig vom abgefangenen Befehl gegebenenfalls den Gastzustand. Die sichere Schnittstellensteuerung isoliert somit den Hypervisor von den Daten der sicheren VM, wodurch die Sicherheit der Daten verbessert wird, die der sicheren VM zugehörig sind.
Es folgt nun eine kurze Beschreibung der Hintergrundtechnologie, in der besondere Merkmale dargelegt werden, die von einer oder mehreren Ausführungsformen der vorliegenden Erfindung zum Einfügen von Unterbrechungen und/oder Ausnahmebedingungen in sichere VMs durch einen Hypervisor verwendet werden. Die vorliegende Offenbarung enthält zwar eine ausführliche Beschreibung von Cloud-Computing, es versteht sich jedoch von vornherein, dass die Implementierung der hier dargelegten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist. Stattdessen können Ausführungsformen der vorliegenden Erfindung gemeinsam mit beliebigen Arten von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung umgesetzt werden.
Cloud-Computing ist ein Modell zum Liefern eines Dienstes, der einen problemlosen, bedarfsorientierten Netzwerkzugang zu einem gemeinsamen Pool an konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Speicher, Anwendungen, virtuelle Maschinen und Dienste) ermöglicht, die rasch bereitgestellt und mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter eines Dienstes freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften, mindestens drei Dienstmodelle und mindestens vier Implementierungsmodelle enthalten.
Bei den Eigenschaften handelt es sich um die Folgenden:

On-Demand Self-Service (bedarfsorientierte Selbstbedienung): Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher bereitstellen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
Broad Network Access (breiter Netzzugriff): Über ein Netzwerk sind Funktionen verfügbar, auf die durch Standardmechanismen zugegriffen wird, die die Verwendung durch heterogene schlanke oder leistungsintensive Client-Plattformen unterstützen (z.B. Mobiltelefone, Laptops und PDAs).
Ressource Pooling (Ressourcen-Bündelung): Die Datenverarbeitungsressourcen des Anbieters werden gebündelt, um mehreren Nutzern unter Verwendung eines Mehrmietermodells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
Rapid Elasticity (schnelle Anpassungsfähigkeit): Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
Measured Service (messbarer Dienst): Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Die Ressourcennutzung kann überwacht, kontrolliert und protokolliert werden, wodurch Transparenz für den Anbieter und den Kunden des genutzten Dienstes bereitgestellt wird.

Es gibt folgende Dienstmodelle:

Software as a Service (Saas) (Software als Dienst): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine schlanke Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende eMail) von verschiedenen Client-Einheiten aus zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Einstellungen der Anwendungskonfiguration.
Platform as a Service (Paas) (Plattform als Dienst): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Werkzeugen erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen der Hosting-Umgebung der Anwendung.
Infrastructure as a Service (laas) (Infrastruktur als Dienst): Die dem Nutzer bereitgestellte Funktion besteht darin, Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).

Es gibt folgende Einsatzmodelle:

Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Community Cloud (Benutzergemeinschafts-Cloud): Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Anliegen hat (z.B. Aufgabe, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder fremden Räumen befinden.
Public Cloud (öffentliche Cloud): Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Branchengruppe zur Verfügung gestellt und gehört einer Organisation, die Cloud-Dienste verkauft.
Hybrid Cloud (hybride Cloud): Die Cloud-Infrastruktur besteht aus zwei oder mehr Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Entitäten bleiben, aber durch eine standardisierte oder herstellereigene Technologie miteinander verbunden sind, die eine Übertragbarkeit von Daten und Anwendungen ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).

Eine Cloud-Computing-Umgebung ist dienstorientiert und schwerpunktmäßig auf Statusunabhängigkeit, geringe Kopplung, Modularität und semantische Interoperabilität ausgerichtet. Der Kern von Cloud-Computing ist eine Infrastruktur, die ein Netzwerk aus miteinander verbundenen Knoten aufweist.
Mit Bezug nunmehr auf 1 ist eine veranschaulichende Cloud-Computing-Umgebung 50 dargestellt. Wie gezeigt, weist die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10 auf, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie der persönliche digitale Assistent (PDA) oder das Mobiltelefon 54A, der Desktop-Computer 54B, der Laptop-Computer 54C und/oder das Kraftfahrzeug-Computersystem 54N Daten austauschen können. Die Knoten 10 können miteinander Daten austauschen. Sie können physisch oder virtuell in einem oder mehreren Netzwerken wie private, benutzergemeinschaftliche, öffentliche oder hybride Clouds wie oben beschrieben oder in einer Kombination davon in Gruppen angeordnet sein (nicht dargestellt). Dies ermöglicht es der Cloud-Computing-Umgebung 50, Infrastruktur, Plattformen und/oder Software als Dienste anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es versteht sich, dass die in 1 gezeigten Arten von Datenverarbeitungseinheiten 54A bis N lediglich veranschaulichend sein sollen und die Datenverarbeitungsknoten 10 und die Cloud-Datenverarbeitungsumgebung 50 über eine beliebige Art Netzwerk und/oder über eine beliebige Art von über ein Netzwerk abrufbarer Verbindung (z.B. über einen Web-Browser) mit einer beliebigen Art von computerunterstützter Einheit Daten austauschen können.
Mit Bezug nunmehr auf 2 wird ein Satz funktionaler Abstraktionsschichten gezeigt, die von der Cloud-Datenverarbeitungsumgebung 50 (1) bereitgestellt werden. Es versteht sich im Voraus, dass die in 2 dargestellten Komponenten, Schichten und Funktionen nur veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie dargestellt, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
Die Hardware- und Software-Schicht 60 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören: die Großrechner 61; die Server 62 auf Grundlage der RISC-Architektur (RISC = Reduced Instruction Set Computer, Computer mit reduziertem Befehlssatz), die Server 63; die Blade-Server 64; die Speichereinheiten 65; sowie die Netzwerke und Netzwerkkomponenten 66. In einigen Ausführungsformen enthalten die Software-Komponenten die Netzwerkanwendungs-Serversoftware 67 und die Datenbank-Software 68.
Die Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Entitäten bereitgestellt werden können: virtuelle Server 71; virtuelle Speicher 72; virtuelle Netzwerke 73; darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
In einem Beispiel kann die Verwaltungsschicht 80 die nachfolgend beschriebenen Funktionen bereitstellen. Die Ressourcenbereitstellung 81 ermöglicht eine dynamische Bereitstellung von Datenverarbeitungsressourcen und anderen Ressourcen, die verwendet werden, um Aufgaben in der Cloud-Computing-Umgebung durchzuführen. Messen und Preisfindung 82 stellen Kostenverfolgung beim Verwenden von Ressourcen in der Cloud-Computing-Umgebung sowie Abrechnung oder Rechnungsstellung für die Inanspruchnahme dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Lizenzen für Anwendungs-Software aufweisen. Die Sicherheitsfunktion stellt eine Identitätsprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 83 stellt Nutzern und Systemadministratoren den Zugang zur Cloud-Computing-Umgebung bereit. Die Verwaltung der Dienstgüte 84 stellt Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, sodass die erforderliche Dienstgüte erreicht wird. Die Planung und Erfüllung der Dienstgütevereinbarung (Service Level Agreement, SLA) 85 stellt eine Vorabeinteilung und eine Beschaffung von Cloud-Computing-Ressourcen bereit, deren künftiger Bedarf auf der Grundlage einer Dienstgütevereinbarung vorausgesehen wird.
Die Arbeitslastschicht 90 stellt Beispiele für Funktionalitäten bereit, für die die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 91; Software-Entwicklung und Lebenszyklusverwaltung 92; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 93; Datenanalyseverarbeitung 94; Transaktionsverarbeitung 95; und Quellcode-Versionssteuerung 96. Es versteht sich, dass dies nur einige Beispiele sind und dass in anderen Ausführungsformen die Schichten andere Dienste enthalten können.
3 stellt einen beispielhaften Hosting-Knoten 10 gemäß einer oder mehreren Ausführungsform der vorliegenden Erfindung dar. Der Hosting-Knoten 10 tauscht über ein Netzwerk 165 Daten mit einer oder mehreren Client-Einheiten 20A bis 20C aus. Darüber hinaus können die Client-Einheiten 20A bis 20C direkt Daten mit dem Hosting-Knoten 10 austauschen. Bei dem Hosting-Knoten 10 kann es sich um ein Rechenzentrum oder Host-Server eines Cloud-Computing-Anbieters handeln. Der Hosting-Knoten 10 führt einen Hypervisor 12 aus, der das Bereitstellen einer oder mehrerer virtueller Maschinen 15 (15A bis 15N) ermöglicht. Der Hosting-Knoten 10 enthält ferner die sichere Schnittstellensteuerung 11, die ein oder mehrere Hardware-Module und Millicode enthält, die es dem Hypervisor 12 ermöglichen, den virtuellen Maschinen 15 einen oder mehrere Dienste bereitzustellen. Bei bestehenden technischen Lösungen findet eine Datenübertragung zwischen dem Hypervisor 12 und der sicheren Schnittstellensteuerung 11; der sicheren Schnittstellensteuerung 11 und einer oder mehreren VMs 15; dem Hypervisor 12 und der einen oder den mehreren VMs 15; und dem Hypervisor 12 zu den VMs 15 über die sichere Schnittstellensteuerung 11 statt. Um eine sichere VM-Umgebung zu ermöglichen, führt der Hosting-Knoten 10 gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung keine direkte Datenübertragung zwischen dem Hypervisor 12 und der einen oder den mehreren VMs 15 aus.
Der Hosting-Knoten 10 kann es einer Client-Einheit 20A zum Beispiel ermöglichen, eine oder mehrere der virtuellen Maschinen 15A bis 15N bereitzustellen. Die virtuellen Maschinen 15A bis 15N können auf entsprechende Anforderungen von verschiedenen Client-Einheiten 20A bis 20C bereitgestellt werden. Die virtuelle Maschine 15A kann zum Beispiel von der Client-Einheit 20A bereitgestellt werden, die virtuelle Maschine 15B kann von der Client-Einheit 20B bereitgestellt werden, und die virtuelle Maschine 15C kann von der Client-Einheit 20C bereitgestellt werden. Der Hosting-Knoten 10 kann es einem Client auch ermöglichen, einen physischen Server bereitzustellen (ohne als virtuelle Maschine ausgeführt zu werden). Die hierin beschriebenen Beispiele führen das Bereitstellen von Ressourcen im Hosting-Knoten 10 als Teil einer „virtuellen Maschine“ aus, die beschriebenen technischen Lösungen können jedoch auch angewendet werden, um die Ressourcen als Teil eines physischen Servers bereitzustellen.
In einem Beispiel können die Client-Einheiten 20A bis 20C zur selben Entität gehören, z.B. zu einer Person, einem Unternehmen, einer staatlichen Behörde, einer Abteilung in einem Unternehmen oder einer anderen Entität, und der Hosting-Knoten 10 kann als private Cloud der Entität betrieben werden. In diesem Fall hostet der Hosting-Knoten 10 nur die virtuellen Maschinen 15A bis 15N, die von den Client-Einheiten 20A bis 20C bereitgestellt werden, die zu der Entität gehören. In einem anderen Beispiel können die Client-Einheiten 20A bis 20C zu verschiedenen Entitäten gehören. Eine erste Entität kann zum Beispiel Eigentümerin der Client-Einheit 20A sein, während eine zweite Entität Eigentümerin der Client-Einheit 20B sein kann. In diesem Fall kann der Hosting-Knoten 10 als öffentliche Cloud betrieben werden, die virtuelle Maschinen von verschiedenen Entitäten hostet. Die virtuellen Maschinen 15A bis 15N können zum Beispiel verdeckt bereitgestellt werden, sodass die virtuelle Maschine 15A den Zugriff auf die virtuelle Maschine 15B nicht ermöglicht. Der Hosting-Knoten 10 kann die virtuellen Maschinen 15A bis 15N zum Beispiel unter Verwendung einer Funktionalität für eine logische Partition (LPAR) mithilfe des IBM z Systems^® Processor Resource/Systems Manager (PR/SM) verdecken. Diese Funktionalitäten wie PR/SM LPAR stellen eine Isolation zwischen den Partitionen bereit und ermöglichen es dem Hosting-Knoten 10 somit, zwei oder mehr virtuelle Maschinen 15A bis 15N für verschiedene Entitäten auf demselben physischen Hosting-Knoten 10 in verschiedenen logischen Partitionen bereitzustellen.
Bei einer Client-Einheit 20A von den Client-Einheiten 20A bis 20C handelt es sich um eine Datenübertragungsvorrichtung wie einen Computer, ein Smartphone, einen Tablet-Computer, einen Desktop-Computer, einen Laptop-Computer, einen Server-Computer oder eine andere Datenübertragungsvorrichtung, die die Bereitstellung einer virtuellen Maschine durch den Hypervisor 12 des Hosting-Knotens 10 anfordert. Die Client-Einheit 20A kann eine Anforderung über das Netzwerk 165 oder direkt senden, die vom Hypervisor empfangen wird. Bei einer virtuellen Maschine 15A von den virtuellen Maschinen 15A bis 15N handelt es sich um ein Abbild einer virtuellen Maschine, das der Hypervisor 12 auf eine Anforderung von der Client-Einheit 20A von den Client-Einheiten 20A bis 20C bereitstellt. Der Hypervisor 12 ist ein virtueller Maschinenmonitor (VMM), bei dem es sich um Software, Firmware oder Hardware handeln kann, die virtuelle Maschinen erstellt und ausführt. Der Hypervisor 12 ermöglicht es der virtuellen Maschine 15A, die Hardware-Komponenten des Hosting-Knotens 10 zu verwenden, um Programme auszuführen und/oder Daten zu speichern. Mit den entsprechenden Funktionalitäten und Änderungen kann es sich bei dem Hypervisor 12 um IBM z Systems^®, ORACLE VM SERVER™, CITRIX XENSERVER™, VMWARE ESX™, MICROSOFT HYPER-V™ oder einen anderen Hypervisor handeln. Der Hypervisor 12 kann ein nativer Hypervisor sein, der direkt auf dem Hosting-Knoten 10 ausgeführt wird, oder ein gehosteter Hypervisor, der auf einem anderen Hypervisor ausgeführt wird.
4 veranschaulicht Komponenten eines beispielhaften Hosting-Knotens gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung. Bei dem Hosting-Knoten 10 kann es sich um einen Computer handeln, z.B. einen Server-Computer, einen Desktop-Computer, einen Tablet-Computer, ein Smartphone oder einen anderen Computer, auf dem der Hypervisor 12 ausgeführt wird, der wiederum die virtuellen Maschinen 15A bis 15N bereitstellt. Der Hosting-Knoten 10 enthält Komponenten, die Hardware umfassen, z.B. elektronische Schaltungen. Der Hosting-Knoten 10 umfasst neben anderen Komponenten einen Prozessor 105, einen Speicher 110, der mit einer Speichersteuereinheit 115 verbunden ist, und eine oder mehrere Eingabeeinheiten 145 und/oder Ausgabeeinheiten 140, z.B. Peripherie- oder Steuereinheiten, die über eine lokale E/A-Steuereinheit 135 zum Zwecke der Datenübertragung verbunden sind. Diese Einheiten 140 und 145 können zum Beispiel Batteriesensoren, Positionssensoren (Höhenmesser 40, Beschleunigungsmesser 42, GPS 44), Anzeige/Kennzeichnungsleuchten und Ähnliches enthalten. Eingabeeinheiten wie eine herkömmliche Tastatur 150 und eine Maus 155 können mit der E/A-Steuereinheit 135 verbunden sein. Bei der E/A-Steuereinheit 135 kann es sich zum Beispiel um einen oder mehrere Busse oder andere drahtgebundene oder drahtlose Verbindungen handeln, wie sie in der Technik bekannt sind. Die E/A-Steuereinheit 135 kann zusätzliche Elemente enthalten, die aus Gründen der Einfachheit weggelassen wurden, wie beispielsweise Steuereinheiten, Puffer (Zwischenspeicher), Treiber, Verstärker und Empfänger, um Übertragungen von Daten zu ermöglichen.
Die E/A-Einheiten 140, 145 können des Weiteren Einheiten umfassen, die sowohl Eingaben als auch Ausgaben übertragen, z.B. Platten- und Bandspeicher, eine Netzwerkschnittstellenkarte (NIC) oder einen Modulator/Demodulator (für den Zugriff auf andere Dateien, Einheiten, Systeme oder ein Netzwerk), einen Funksendeempfänger oder anderen Sendeempfänger, eine Telefonschnittstelle, eine Bridge, einen Router und Ähnliches.
Bei dem Prozessor 105 handelt es sich um eine Hardware-Einheit zum Ausführen von Hardware-Befehlen oder Software, insbesondere um solche, die im Speicher 110 gespeichert werden. Bei dem Prozessor 105 kann es sich um einen kundenspezifischen oder handelsüblichen Prozessor handeln, eine Zentraleinheit (CPU), einen Hilfsprozessor unter mehreren Prozessoren, die dem Hosting-Knoten 10 zugehörig sind, einen in Halbleitertechnik ausgeführten Mikroprozessor (in Form eines Mikrochips oder Chipsatzes), einen Makroprozessor oder eine andere Einheit zum Ausführen von Befehlen. Der Prozessor 105 enthält - ohne auf dies beschränkt zu sein - einen Zwischenspeicher 170, der einen Befehlszwischenspeicher enthalten kann, um ein Abrufen ausführbarer Befehle zu beschleunigen, einen Datenzwischenspeicher, um ein Abrufen und Speichern von Daten zu beschleunigen, und einen Adressumsetzpuffer (translation lookaside buffer, TLB), der verwendet wird, um ein Umsetzen von einer virtuellen in eine physische Adresse für ausführbare Befehle und Daten zu beschleunigen. Der Zwischenspeicher 170 kann als Hierarchie von mehreren Zwischenspeicherebenen (L1, L2 usw.) aufgebaut sein.
Der Speicher 110 kann ein beliebiges oder eine Kombination aus flüchtigen Speicherelementen (z.B. einen Arbeitsspeicher (RAM), beispielsweise ein DRAM, SRAM, SDRAM) und nichtflüchtigen Speicherelementen (z.B. einen Flash-Speicher, ROM, löschbaren programmierbaren Nur-Lese-Speicher (EPROM), elektronischen löschbaren programmierbaren Nur-Lese-Speicher (EEPROM), programmierbaren Nur-Lese-Speicher (PROM), ein Band, einen Compact-Disc-Nur-Lese-Speicher (CD-ROM), eine Platte, Diskette, Kassette oder Ähnliches) enthalten. Des Weiteren kann der Speicher 110 elektronische, magnetische, optische oder andere Arten von Speichermedien enthalten. Hierbei ist zu beachten, dass der Speicher 110 eine verteilte Architektur aufweisen kann, bei der verschiedene Komponenten entfernt voneinander angeordnet sind, auf die der Prozessor 105 jedoch zugreifen kann.
Die Befehle im Speicher 110 können ein oder mehrere separate Programme enthalten, von denen jedes eine geordnete Auflistung von ausführbaren Befehlen zum Implementieren logischer Funktionen aufweist. In dem Beispiel von 2 enthalten die Befehle im Speicher 110 ein geeignetes Betriebssystem (BS), das den Hypervisor 12 ausführt. Das Betriebssystem kann die Ausführung anderer Computerprogramme steuern und stellt Planung, Eingangs/Ausgangs-Steuerung, Datei- und Datenverwaltung, Speicherverwaltung, Datenübertragungssteuerung und damit verbundene Dienste bereit. In einem Beispiel wie dem z System™ kann ein Hersteller des Hosting-Knotens 10 den Hypervisor 12 bereitstellen. Im Fall eines Systems mit einer anderen Struktur als z System, bei dem der Hypervisor 12 nicht vom Hersteller der Hardware bereitgestellt wird, kann das bereitgestellte Cloud-Computing einen Hypervisor 12 z.B. von VMWARE™ oder anderen Anbietern von Hypervisoren verwenden. In einem Beispiel kann der Administrator des physischen Hosting-Knotens 10 den Hypervisor 12 nicht ändern, es sei denn, dies ist erforderlich, um einen vom Hersteller bereitgestellten Dienst anzuwenden. Der Hypervisor 12 kann zum Beispiel als Teil eines „Licensed Internal Code (LIC)“ und/oder Mikrocodes für den Hosting-Knoten 10 bereitgestellt werden.
Zusätzliche Daten, z.B. Anweisungen für den Prozessor 105 oder andere abrufbare Informationen, können im Speicher 120 gespeichert werden, bei dem es sich um eine Speichereinheit wie beispielsweise ein Festplattenlaufwerk oder einen Halbleiterdatenträger handeln kann. Die im Speicher 110 oder Speicher 120 gespeicherten Befehle können solche Befehle enthalten, die den Prozessor in die Lage versetzen, einen oder mehrere Aspekte der Systeme und Verfahren dieser Offenbarung auszuführen.
Der Hosting-Knoten 10 kann ferner eine Anzeigesteuereinheit 125 enthalten, die mit einer Benutzerschnittstelle oder einer Anzeige 130 verbunden ist. In einigen Ausführungsformen kann es sich bei der Anzeige 130 um einen LCD-Bildschirm handeln. In anderen Ausführungsformen kann die Anzeige 130 eine Mehrzahl von LED-Statusleuchten enthalten. In einigen Ausführungsformen kann der Hosting-Knoten 10 weiterhin eine Netzwerkschnittstelle 160 zum Verbinden mit einem Netzwerk 165 enthalten. Bei dem Netzwerk 165 kann es sich um ein auf einem IP beruhendes Netzwerk für die Datenübertragung über eine Breitbandverbindung zwischen dem Hosting-Knoten 10 und einem externen Server, Client und Ähnlichem handeln. In einer Ausführungsform kann das Netzwerk 165 ein Satellitennetzwerk sein. Das Netzwerk 165 überträgt und empfängt Daten zwischen dem Hosting-Knoten 10 und externen Systemen. In einigen Ausführungsformen kann es sich bei dem Netzwerk 165 um ein verwaltetes IP-Netzwerk handeln, das von einem Dienstanbieter verwaltet wird. Das Netzwerk 165 kann drahtlos implementiert werden, zum Beispiel unter Verwendung von drahtlosen Protokollen und Technologien wie WLAN, WiMax, Satellit oder Anderen. Bei dem Netzwerk 165 kann es sich auch um ein paketvermitteltes Netzwerk wie ein lokales Netzwerk, ein Weitverkehrsnetzwerk, ein Metropolitan Area Network, das Internet oder eine ähnliche Art von Netzwerkumgebung handeln. Das Netzwerk 165 kann ein festes drahtloses Netzwerk, ein drahtloses lokales Netzwerk (LAN), ein drahtloses Weitverkehrsnetzwerk (WAN), ein Personal Area Network (PAN), ein virtuelles privates Netzwerk (VPN), Intranet oder ein anderes geeignetes Netzwerksystem sein und kann Ausstattung zum Empfangen und Senden von Signalen enthalten.
Die Client-Einheit 20A kann den Hypervisor 12 auffordern, die entsprechende virtuelle Maschine 15A mit Zugriff auf bestimmte Hardware- und/oder Software-Komponenten des Hosting-Knotens 10 bereitzustellen. Die Client-Einheit 20A kann zum Beispiel anfordern, dass die virtuelle Maschine 15A Zugriff auf eine zuvor festgelegte Anzahl von Prozessoren, eine zuvor festgelegte Menge an flüchtigem Speicher (wie Direktzugriffsspeicher (RAM)), eine zuvor festgelegte Menge an nichtflüchtigem Speicher (wie Speicherplatz) oder andere Hardware-Komponenten hat. Alternativ oder zusätzlich kann die Client-Einheit 20A anfordern, dass die virtuelle Maschine 15A Zugriff auf bestimmte Hardware-Komponenten wie elektronische Schaltungen hat, die von einer entsprechenden eindeutigen Kennung identifiziert werden. Die Client-Einheit 20A kann zum Beispiel anfordern, dass die virtuelle Maschine 15A Zugriff auf eine bestimmte Art eines Prozessors, einen Co-Prozessor, eine Netzwerkkarte oder einen anderen Chip oder andere elektronische Schaltung hat. In einem Beispiel kann die Client-Einheit 20A die elektronische Schaltung unter Verwendung einer Kennung identifizieren, die von einem Hersteller der elektronischen Schaltung bereitgestellt wird. In einem Beispiel kann die Kennung in Verbindung mit einer Versionskennung verwendet werden. Alternativ oder zusätzlich kann die Client-Einheit 20A anfordern, dass die virtuelle Maschine 15A Zugriff auf bestimmte Software-Komponenten wie ein Betriebssystem, eine Anwendung, ein grundlegendes Ein/Ausgabe-System (BIOS), ein Boot-Image oder eine andere Software-Komponente hat. Die angeforderten Software-Komponenten können Firmware und in den Hardware-Komponenten des Hosting-Knotens 10 eingebettete Programme umfassen. Die Client-Einheit 20A kann die angeforderten Software-Komponenten unter Verwendung der jeweiligen eindeutigen Kennungen identifizieren, die von den Entwicklern/Herstellern der jeweiligen Software-Komponenten bereitgestellt werden. In einem Beispiel können die Kennungen in Verbindung mit Versionskennungen der Software-Komponenten verwendet werden.
Damit eine virtuelle Maschine 15A eine sichere VM ist, wird allen nichtsicheren Gästen und dem Hypervisor 12 wie bereits erwähnt der Zugriff auf einen bzw. mehrere Teile des Speichers 110, des Speichers 120, der Register und auf andere Daten, die der virtuellen Maschine 15A zugehörig sind, verwehrt. In einem oder mehreren Beispielen garantiert der Hypervisor 12, dass jeder gegebenen residenten sicheren Gastseite die zugehörige absolute Host-Adresse nur über eine einzige Hypervisor-(Host-)DAT-Zuordnung zugänglich ist. Das heißt, es gibt eine einzige virtuelle Host-Adresse, die einer beliebigen gegebenen absoluten Host-Adresse zugeordnet ist, die der sicheren VM 15A zugewiesen ist. Die Hypervisor-DAT-Zuordnung (Host virtuell zu Host absolut), die einer beliebigen gegebenen sicheren Gastseite zugehörig ist, ändert sich darüber hinaus nicht, während diese eingelagert ist. Die einer sicheren Gastseite zugehörige absolute Host-Seite wird weiterhin nur einem einzigen sicheren Gast zugeordnet. Es gibt des Weiteren keine gemeinsame Nutzung von Speichern/Registern zwischen den virtuellen Maschinen 15, insbesondere im Fall der sicheren VM 15A. In einem oder mehreren Beispielen ordnet der Hypervisor 12 der sicheren Schnittstellensteuerung 11 einen sicheren Teil des Speichers 120 zu. Auf diesen sicheren Teil des Speichers 120 kann nur die sichere Schnittstellensteuerung 11 zugreifen, sobald dieser Teil zugeordnet wurde. Die virtuellen Maschinen 15 und/oder der Hypervisor 12 können nicht auf Inhalte des sicheren Teils zugreifen, nachdem dieser der sicheren Schnittstellensteuerung 11 zugeordnet wurde.
Jeder Versuch, diese Regeln zu verletzen, wird von der sicheren Schnittstellensteuerung 11 und dem Hosting-Knoten 10 verhindert und kann einen Alarm auslösen. Der Alarm kann ausgelöst werden, indem an einen oder mehrere Mitarbeiter eine Benachrichtigung gesendet wird, der Betrieb des Hosting-Knotens 10 gesperrt wird, Anforderungen von einer oder mehreren Client-Einheiten 20 gesperrt werden, der Betrieb der sicheren VM 15 (und jeder anderen sicheren VM) gesperrt wird usw.
5 stellt einen Ablaufplan eines beispielhaften Verfahrens für einen Hypervisor dar, um eine transparente Interpretation von Gastbefehlen von einer sicheren VM gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung durchzuführen. Das Verfahren kann ein Empfangen einer Anforderung zum Initiieren der sicheren VM 15A von einer Client-Einheit 20A bei 501 umfassen. In einem oder mehreren Beispielen kann die Anforderung von einer anderen Quelle empfangen werden, z.B. einer anderen VM 15B bis 15N, einer Computeranwendung, die von dem Hypervisor 12 ausgeführt wird, einem Administrator und Ähnlichem.
Das Verfahren umfasst ein Erstellen eines nichtsicheren Zustandsdeskriptors (SD) für die sichere VM 15A. In einem oder mehreren Beispielen enthält der nichtsichere SD einen Verweis auf einen sicheren SD, der in einem Teil des Speichers gespeichert ist, auf den der Hypervisor 12 oder eine andere nichtsichere Entität nicht zugreifen kann. Die sichere Schnittstellensteuerung 11 erstellt zum Beispiel den sicheren SD und fügt im nichtsicheren SD einen Verweis auf den sicheren SD hinzu. Der sichere SD kann die allgemeinen VM-Register (GRs), Zugriffsregister (ARs), Steuerregister (CRs), VM-Zeitgeber (einschließlich Uhrzeitvergleicher und CPU-Zeitgeber), das VM-Präfixregister, die virtuelle CPU-Nummer (VCN), das Programmstatuswort (PSW) und die Befehlsadresse (IA) enthalten. Der SD kann darüber hinaus Steuerinformationen wie Unterbrechungssteuerbits (IC-Bits) enthalten, um anzuzeigen, ob bestimmte Befehle (z.B. Load Program Status Word (LPSW), Invalidate Page Table Entry (IPTE) und Ähnliches) zum Host abgefangen werden müssen oder ob der VM-Adressumsetzpuffer (TLB) geleert werden muss, bevor die Ausführung von VM-Befehlen beginnen kann. Die vorstehend beschriebenen SD-Felder sind nur Beispiele und können in einer oder mehreren Ausführungsformen der vorliegenden Erfindung unterschiedlich sein, z.B. verschiedene andere Felder für andere VM-Zustände enthalten. Im Fall einer nichtsicheren VM enthält der nichtsichere SD selbst die vorstehend beschriebenen Felder/Parameter als Teil der sicheren SD im Fall einer sicheren VM.
Der Hypervisor 12 gibt einen SIE-Befehl mit dem nichtsicheren SD als Operand aus, wobei der Befehl von der sicheren Schnittstellensteuerung 11 ausgeführt wird. Der SIE-Befehl (SIE = start interpretive execution) wird verwendet, um eine VM 15 zuzuteilen und der VM 15 einen oder mehrere Prozessoren 105 und andere Datenverarbeitungsressourcen zuzuordnen. Der SIE-Befehl versetzt den Prozessor 105 in einen Emulationszustand, der im nichtsicheren SD definiert ist. Bei der sicheren VM wird auf den sicheren SD zugegriffen, um die Zuteilung der sicheren VM 15A zu initiieren. In einem oder mehreren Beispielen enthält der nichtsichere SD eine Kennung, um anzuzeigen, ob die zugeteilte VM sicher/nichtsicher ist, und entsprechend greift die sichere Schnittstellensteuerung 11 auf die Felder/Parameter von dem entsprechenden sicheren/nichtsicheren Teil des Speichers zu.
Das Verfahren umfasst bei 505 weiterhin ein Ausführen von Gastbefehlen in der sicheren VM 15A. Bis ein Befehl auftritt, der eine Abfangbedingung verursacht, kann der Befehlsstrom in der sicheren VM 15A bei 510 weiter ausgeführt werden. Sobald ein Befehl eine Abfangbedingung verursacht, ermittelt die VM mit dem abfangenden Befehl bei 510 und 515, ob die VM als sichere VM zugeteilt wird.
Wenn die VM als nichtsichere VM zugeteilt wird, bei der der Hypervisor 12 auf die Daten und/oder den Speicher zugreifen kann, die der VM zugehörig sind, erfolgt die Ausführung des abfangenden Befehls bei 520 wie bei bestehenden Lösungen. Die sichere Schnittstellensteuerung ermittelt auf der Grundlage eines im SD der VM gespeicherten Zustandsmerkers, ob sie als sichere oder nichtsichere VM zugeteilt wurde.
Ist die VM eine nichtsichere VM, wird die Ausführung des Befehlsstroms in der nichtsicheren VM angehalten, und die Steuerung geht an den Hypervisor 12 über, der den abfangenden Befehl interpretiert, indem er auf die Daten der nichtsicheren VM durch direkten Zugriff auf den SD der nichtsicheren VM zugreift. Die vom Hypervisor 12 verwendeten Daten können zum Beispiel Werte enthalten, die in den GRs, CRs, dem Gastspeicher und/oder anderen Registern der nichtsicheren VM gespeichert sind. Sobald die Interpretation des abgefangenen Befehls beendet ist, aktualisiert der Hypervisor 12 den Gastzustand entsprechend, indem er als Reaktion einen oder mehrere Werte speichert. Der Hypervisor 12 speichert zum Beispiel aktualisierte Werte direkt in dem einen oder den mehreren Registern der nichtsicheren VM, indem er diese Werte an den Speicherorten aktualisiert, an denen der SD der nichtsicheren VM gehalten wird. Der Hypervisor 12 kann auch den Gastspeicher als Teil der Befehlsinterpretation aktualisieren.
Wenn es sich bei der VM um eine sichere VM 15A handelt, wird alternativ die sichere Schnittstellensteuerung 11 aufgerufen, um den abfangenden Befehl bei 525 auszuführen. Die sichere Schnittstellensteuerung 11 ermittelt bei 530, ob der Befehl aufgrund der Ausführung eine unterdrückende oder annullierende Programmausnahmebedingung verursacht. Die sichere Schnittstellensteuerung 11 simuliert die Ausführung des abfangenden Befehls, um zu ermitteln, ob die Ausführung zu einer Programmausnahmebedingung führen würde. Der Befehl kann zum Beispiel eine Datenverarbeitungsressource anfordern, die im Hosting-Knoten 10 nicht zur Verfügung steht. Alternativ oder zusätzlich kann es sich bei dem abfangenden Befehl um einen Befehl handeln, der auf der Berechtigungsstufe nicht erlaubt ist, auf der die sichere VM 15A ausgeführt wird. Alternativ oder zusätzlich kann der abfangende Befehl eine Begrenzungsbedingung während eines Speicherzugriffs verletzen. Die sichere Schnittstellensteuerung 11 kann prüfen, ob andere Arten von Programmausnahmebedingungen vorliegen, die durch die Ausführung des abfangenden Befehls verursacht werden würden. Wenn aufgrund der Ausführung des abfangenden Befehls eine Ausnahmebedingung eintritt, zeigt die sichere Schnittstellensteuerung 11 der sicheren VM 15A bei 535 die Ausnahmebedingung an.
In einem oder mehreren Beispielen wird der Befehl je nach Art der Programmunterbrechung unterdrückt oder annulliert. Das Befehlsabfangen erreicht den Hypervisor 12 nicht, wenn eine unterdrückende oder annullierende Gastausnahmebedingung Anwendung findet, stattdessen wird die Steuerung direkt an eine Unterbrechungsroutine der sicheren VM 15A weitergegeben, um die Programmausnahmebedingung zu bearbeiten. Es gibt keinen Grund, den Befehl zum Hypervisor abzufangen, da die Programmausnahmebedingung zuerst bearbeitet werden muss. Wenn zum Beispiel der LCTLG-Befehl abgefangen werden soll und ein für den Befehl bereitgestellter Speicheroperand einen Seitenfehler aufweist, wird der sicheren VM 15A eine Programmausnahmebedingung bereitgestellt, um den Seitenfehler zuerst zu beheben. Sobald der Seitenfehler behoben ist, wird der LCTLG erneut ausgeführt, dieses Mal ohne Programmausnahmebedingung. Bei der anschließenden Ausführung wird der Befehl zum Hypervisor 12 daher unter Verwendung der hierin beschriebenen Funktionen abgefangen.
Einige Programmausnahmebedingungen beziehen sich auf den Host. In einem solchen Fall wird SIE-Exit aufgerufen, und dem Hypervisor 12 wird die Programmausnahmebedingung angezeigt. Im Fall eines Host-Seitenfehlers beispielsweise ordnet der Hypervisor 12 die Gastseite einer absoluten Host-Seite zu und teilt die VM anschließend erneut zu.
Es sei darauf hingewiesen, dass Programmausnahmebedingungen annullierend, unterdrückend und beendend sein können. Der Unterschied zwischen unterdrückend und annullierend liegt in der Art und Weise, wie die Befehlsadresse (IA) aktualisiert wird. Bei einer annullierenden Ausnahmebedingung zeigt die IA auf den Befehl, der die Ausnahmebedingung verursacht hat, während die IA bei einer unterdrückenden Ausnahmebedingung auf den nächstfolgenden Befehl nach dem Befehl mit der Ausnahmebedingung zeigt. In beiden Fällen wird der Gastzustand oder Speicher nicht aktualisiert.
Wenn der abfangende Befehl alternativ zu einer Beendigungsausnahmebedingung führt, erkennt und markiert die sichere Schnittstellensteuerung 11 bei 537 einen Beendigungsausnahmebedingungsmerker für den abfangenden Befehl. Beendigungsausnahmebedingungen wie eine Programmereignisaufzeichnung (PER) werden in der Regel nach dem Beenden des zugehörigen Befehls angezeigt. In einer nichtsicheren VM-Umgebung erkennt der Hypervisor 12 solche PER-Ausnahmebedingungen und zeigt sie der VM an, sobald der Hypervisor 12 das Interpretieren des Gastbefehls beendet hat. In der sicheren VM-Umgebung erkennt die sichere Schnittstellensteuerung 11 solche PER-Programmausnahmebedingungen, markiert sie, um sie der sicheren VM anzuzeigen, sobald die Ausführung des Gastbefehls beendet ist.
Die sichere Schnittstellensteuerung 11 prüft des Weiteren, welcher Befehl bei 540 abgefangen wird. Die sichere Schnittstellensteuerung 11 ermittelt zum Beispiel auf der Grundlage des abzufangenden Befehls und in einigen Fällen einer von mehreren Operanden des Befehls, ob der Befehl von der sicheren Schnittstellensteuerung 11 selbst interpretiert werden kann. Einige Operationen wie das Schreiben eines Gaststeuerregisters, das asynchrone Gastunterbrechungen (z.B. ein LCTLG-Befehl) aktivieren kann, werden in der Regel von der sicheren Schnittstellensteuerung beendet und anschließend zum Hypervisor 12 abgefangen, wobei der minimal erforderlich Gastzustand bereitgestellt wird, sodass der Hypervisor 12 prüfen kann, ob eine zuvor aktive, jedoch deaktivierte Gastunterbrechung aktiviert wird. Der Hypervisor 12 priorisiert anschließend die anstehenden und aktivierten Gastunterbrechungen und zeigt dem Gast die Unterbrechung mit der höchsten Priorität sicher über die sichere Schnittstellensteuerung an. Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung interpretiert die sichere Schnittstellensteuerung 11 in einer sicheren VM-Umgebung die LCTLG-Interpretation für die sichere VM. In ähnlicher Weise wird in einer oder mehreren Ausführungsformen der vorliegenden Erfindung ein „Set Prefix“-Befehl (SPX-Befehl), der zurück zum Hypervisor 12 für eine nichtsichere VM abgefangen wird, von der sicheren Schnittstellensteuerung 11 interpretiert. Wenn die sichere Schnittstellensteuerung 11 auf die Operanden zugreifen kann, kann der Befehl als von der sicheren Schnittstellensteuerung 11 interpretierbar angesehen werden. Wenn der Befehl von der sicheren Schnittstellensteuerung 11 interpretiert werden kann, wird die Ausführung des Befehls durch die sichere Schnittstellensteuerung 11 selbst beendet, und der Befehlsstrom der sicheren VM 15A wird bei 545 wieder aufgenommen.
Wenn der Befehl von der sicheren Schnittstellensteuerung 11 selbst nicht interpretiert werden kann, setzt die sichere Schnittstellensteuerung 11 bei 550 einen dem Gastbefehl zugehörigen Teilweise-Beendet-Merker auf einen ersten Zustand, z.B. Teilweise-Beendet = 1. Es versteht sich, dass der Teilweise-Beendet-Merker im vorliegenden Dokument zwar mit einem ersten Zustand = 1 und einem zweiten Zustand = 0 beschrieben wird, dass jedoch in einer oder mehreren Ausführungsformen der vorliegenden Erfindung andere Werte für die beiden Zustände verwendet werden können.
Die sichere Schnittstellensteuerung 11 setzt darüber hinaus bei 552 einen Sperr-VM-Merker, der der sicheren VM 15A zugehörig ist, die den abfangenden Befehl enthält, auf einen ersten Zustand, z.B. Sperr-VM = 1. Es versteht sich, dass der Sperr-VM-Merker im vorliegenden Dokument zwar mit einem ersten Zustand (z.B. = 1) und einem zweiten Zustand (z.B. = 0) beschrieben wird, dass jedoch in einer oder mehreren Ausführungsformen der vorliegenden Erfindung andere Werte für die beiden Zustände verwendet werden können. Der Sperr-VM-Merker zeigt an, ob die sichere VM 15A „gesperrt“ ist, das heißt, die Ausführung des Befehlsstroms wird unterbrochen und wartet auf das Beenden der Interpretation eines Befehls. Der Sperr-VM-Merker gibt ferner an, ob die Antwort des Hypervisors auf den abgefangenen Befehl bestätigt wurde, der von der sicheren Schnittstellensteuerung an die sichere VM 15A weitergeleitet wurde. In den hierin beschriebenen Beispielen wird davon ausgegangen, dass die Antwort an die sichere VM 15A im ersten Zustand (d.h. Sperr-VM = 1) bestätigt wird, und die Antwort andernfalls (d.h. Sperr-VM = 0) zu diesem Zeitpunkt nicht bestätigt werden muss. Die Sperr-VM verhindert auch, dass der Hypervisor 12 die sichere VM versehentlich oder böswillig ohne Antwort zuteilt, und verhindert ferner Versuche des Hypervisors, eine Unterbrechung in die sichere VM 15A einzufügen, bevor die Befehlsinterpretation beendet ist. Die Sperr-VM sperrt daher die sichere VM 15A, bis sie die erforderliche Antwort für den Gastbefehl erhält, der interpretiert wird.
Wenn sich die sichere VM 15A in einem gesperrten Zustand befindet, zeigt dies der sicheren Schnittstellensteuerung 11 an, dass die sichere VM 15A auf eine Antwort vom Hypervisor 12 bezüglich der Befehlsinterpretation wartet. Die sichere Schnittstellensteuerung 11 verhindert in einem solchen Fall, dass die sichere VM 15A zugeteilt wird, bevor eine gültige Antwort von der sicheren Schnittstellensteuerung empfangen wird, wobei der Zustand des Sperr-VM-Merkers in diesem Fall geändert wird.
Die sichere Schnittstellensteuerung 11 fängt des Weiteren bei 555 einen Befehl zur Ausführung für den Hypervisor 12 ab. Das Abfangen zum Hypervisor 12 umfasst, dass die sichere Schnittstellensteuerung 11 eines oder mehrere Parameterdatenelemente, die dem Befehl zugehörig sind, aus dem sicheren Teil des Speichers extrahiert und sie dem Hypervisor 12 zugänglich macht. Die sichere Schnittstellensteuerung 11 kann die Parameterdaten aus der sicheren VM 15A extrahieren, indem sie den Befehl, seinen Operanden und seine Daten prüft. Der Operand und die Daten können in Hardware-Registern und dem Speicher gespeichert werden, die der sicheren VM 15A zugehörig sind. Bei SIE-Exit wird der Gastzustand in dem sicheren SD gespeichert, und der Grund für das Abfangen (und andere auf den Hypervisor bezogene Informationen) werden in dem nichtsicheren SD gespeichert. Der physische Prozessor, auf dem die VM ausgeführt wurde, ist nun frei, und der Hypervisor kann dieselbe VM erneut zuteilen oder demselben physischen Prozessor eine neue VM zuteilen. Die Sperr-VM und andere Informationen, die sich auf den abgefangenen Gastbefehl beziehen, werden in dem sicheren SD gespeichert, sodass die VM jedem verfügbaren Prozessor zugeteilt werden kann.
Die sichere Schnittstellensteuerung 11 kann dem Hypervisor 12 die extrahierten Parameter zugänglich machen, indem ein zweckgebundener Puffer zum Ausführen dieses bestimmten Befehls erzeugt oder ein zweckgebundener Puffer verwendet wird, der zum Ausführen solcher abgefangener Gastbefehle verwendet wird. Die sichere Schnittstellensteuerung 11 speichert die Daten (die vom Hypervisor für die Befehlsinterpretation benötigt werden) von der sicheren VM 15A in den zweckgebundenen Puffer und leitet die gespeicherten Daten zum Hypervisor 12 als die Operanden/Daten weiter, die für die Interpretation des abgefangenen Gastbefehls verwendet werden.
Der Hypervisor 12 kennt oft den Befehl aus einem Befehlsstrom in der sicheren VM 15A, der das Abfangen verursacht, nicht genau - nur die spezifische Aktion, die seinerseits erforderlich ist. Nach dem Abfangen soll der Hypervisor 12 die Befehlsinterpretation ohne weiteren Kontext außerhalb des für die Interpretation erforderlichen Kontexts, z.B. die Ursache für den ausgeführten Befehl, ausführen. Der Hypervisor 12 interpretiert daher den Befehl bei 560, ohne die Quelle/Ursache des Befehls zu kennen.
6 zeigt einen Ablaufplan für ein Verfahren, um eine Antwort von einem Hypervisor an eine sichere VM zurückzugeben, nachdem gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung eine Interpretation eines abgefangenen sicheren VM-Befehls beendet wurde. Nach dem Beenden der Befehlsinterpretation teilt der Hypervisor 12 die sichere VM entweder ohne Einfügen einer Unterbrechung (562) oder mit Einfügen einer Unterbrechung (564) zu. Die Zuteilung kann mit dem hierin beschriebenen SIE-Befehl durchgeführt werden. Als Teil der Zuteilungsoperation der sicheren VM wird der Gastzustand vom sicheren SD gelesen, der der VM zugehörig ist, und in die Prozessor-Hardware (Register, Speicher usw.) geladen. Der Hypervisor 12 fügt die Unterbrechung über die sichere Schnittstellensteuerung 11 in die VM ein, indem er die Informationen im Zusammenhang mit dem Unterbrechungsparameter wie die Kennung sowie Parameter im zweckgebundenen Puffer in einem oder mehreren Beispielen speichert. Die sichere Schnittstellensteuerung 11 erhält mit dem SIE-Aufruf die Steuerung über die Ausführung.
Die sichere Schnittstellensteuerung 11 prüft bei 570, ob der Sperr-VM-Merker auf 1 gesetzt ist. Wenn die Sperr-VM = 0 (oder ungleich 1) ist, geht die sichere Schnittstellensteuerung 11 davon aus, dass eine andere VM (ohne abfangenden Befehl) durch den aufgerufenen SIE-Befehl zugeteilt wird, entsprechend wird die andere VM verwendet und bei 575 wird die Ausführung eines Befehlsstroms für diese VM initiiert.
Wenn alternativ die Sperr-VM = 1 ist, d.h., der Hypervisor 12 gibt die Ausführungssteuerung an die sichere VM 15A zurück, die den abfangenden Befehl ausgegeben hat, prüft die sichere Schnittstellensteuerung 11 bei 580, ob der Hypervisor 12 eine Antwort auf diesen Befehl empfangen hat. Die sichere Schnittstellensteuerung 11 ermittelt dies, indem sie einen festgelegten Speicherort im zweckgebundenen Puffer überprüft, der für den Hypervisor 12 eingerichtet wurde, um die Befehlsantwort bereitzustellen. Wenn keine Antwort gefunden wird, führt die sichere Schnittstellensteuerung 11 bei 582 ein Abfangen zum Hypervisor 12 mit einer Fehlerbedingung durch. Wenn im zweckgebundenen Puffer eine Antwort bereitgestellt wird, stellt die sichere Schnittstellensteuerung 11 bei 585 sicher, dass die Antwort gültig ist. Wenn die Antwort nicht gültig ist, führt die sichere Schnittstellensteuerung 11 bei 582 ein Abfangen zum Hypervisor 12 mit einer Fehlerbedingung durch.
In einem oder mehreren Beispielen stellt die sichere Schnittstellensteuerung 11 die Gültigkeit der Antwort auf der Grundlage der Art der vom Hypervisor empfangenen Antwort sicher. Zum Beispiel, dass die bereitgestellte Antwort für die Art von Befehl, der abgefangen hat, gültig ist. Für jeden der zulässigen abfangenden Befehle ermöglicht die sichere Schnittstellensteuerung 11 daher eine oder mehrere mögliche Arten von Antworten. Die sichere Schnittstellensteuerung 11 prüft zum Beispiel, dass der Datentyp der Antwort aus einer Liste von erwarteten Antwortarten für den abfangenden Befehl gültig ist. Wenn es sich bei dem abfangenden Befehl zum Beispiel um eine Anforderung für eine E/A-Operation handelt, überprüft die sichere Schnittstellensteuerung 11, dass die Antwort einen Datentyp aufweist, der für eine E/A-Operation geeignet ist.
Wenn festgestellt wird, dass die Antwort gültig ist, fährt das Verfahren damit fort, dass die sichere Schnittstellensteuerung 11 den Zustand der sicheren VM 15A auf der Grundlage der Antwort des Hypervisors 12 bei 590 aktualisiert. Das Aktualisieren des Zustands kann ein Aktualisieren der Register und des Speichers umfassen, die der sicheren VM 15A zugehörig sind. Nur die sichere Schnittstellensteuerung 11 kann auf den SD für die sichere VM 15A zugreifen, da er im sicheren Speicherteil gespeichert ist, auf den nur die sichere Schnittstellensteuerung 11 zugreifen kann. Die Antwort bleibt daher sicher, und andere VMs sowie der Hypervisor 12 können nicht darauf zugreifen.
Die sichere Schnittstellensteuerung 11 beendet bei 592 ferner die Ausführung des abfangenden Gastbefehls. Das Beenden umfasst, dass die sichere Schnittstellensteuerung 11 die Merker Teilweise-Beendet und Sperr-VM auf die zweiten Zustände aktualisiert, d.h., dass Teilweise-Beendet = 0 und Sperr-VM = 0 für die sichere VM 15A gesetzt werden. Die sichere Schnittstellensteuerung 11 ermittelt bei 595, ob dem abfangenden Befehl eine entsprechende Beendigungsausnahmebedingung zugehörig war. Wenn eine Ausnahmebedingung vorliegt, zeigt die sichere Schnittstellensteuerung 11 der sicheren VM 15A die Beendigungsausnahmebedingung an, wodurch der sicheren VM 15A angezeigt wird, den Befehlsstrom, den sie ausgeführt hat, bei 597 nach Bearbeitung der Ausnahmebedingung wieder aufzunehmen. Wenn alternativ für den abfangenden Befehl keine Programmausnahmebedingung vorliegt, gibt die sichere Schnittstellensteuerung 11 die Ausführungssteuerung an die sichere VM 15A zurück, die ihrerseits bei 598 den Befehlsstrom wieder aufnimmt.
Eine oder mehrere Ausführungsformen der vorliegenden Erfindung ermöglichen somit das Interpretieren von Gastbefehlen für eine sichere VM durch einen Hypervisor in einem Host-Knoten. Der Gastbefehl wird wie üblich abgefangen (wie in einer nichtsicheren VM), die Steuerung wird jedoch nicht sofort an den Hypervisor zurückgegeben, sondern wird stattdessen an die sichere Schnittstellensteuerung weitergegeben. Die sichere Schnittstellensteuerung extrahiert die Gastdaten und leitet sie zusammen mit dem Grund für das Abfangen an den Hypervisor weiter. Der Hypervisor verarbeitet die Anforderung und sendet die Antwort an die sichere Schnittstellensteuerung zurück.
Die sichere Schnittstellensteuerung prüft, ob eine Programmausnahmebedingung einschließlich einer Programmereignisaufzeichnung (PER) vorliegt, und markiert den Gastbefehl als teilweise beendet, bevor die Anforderung an den Hypervisor weitergeleitet wird. Bei einem annullierenden oder unterdrückenden Programmabfangen erfolgt die Benachrichtigung des Hypervisors nicht, und eine Programmausnahmebedingung wird gewählt. Die sichere Schnittstellensteuerung prüft ferner die Antwort des Hypervisors, bevor die Ergebnisse des Gastbefehls aktualisiert werden. Bei einer Programmausnahmebedingung vom Typ Beenden wie z.B. einer Programmereignisaufzeichnung (PER) kennzeichnet die sichere Schnittstellensteuerung, dass der Befehl eine Programmausnahmebedingung vom Typ Beenden aufweist, und nach der Rückkehr vom Hypervisor beendet die sichere Schnittstellensteuerung den Befehl und erzwingt die Programmunterbrechung.
Zwischen dem Zeitpunkt, an dem die sichere VM ein Abfangen zum Hypervisor durchführt, und dem Zeitpunkt der Antwort des Hypervisors verhindert die sichere Schnittstellensteuerung, dass der Hypervisor dieselbe VM einer physischen CPU zuteilt. Sie verhindert des Weiteren, dass der Hypervisor Unterbrechungen (EA, extern oder eine Maschinenprüfung) oder Ausnahmebedingungen (z.B. Programmausnahmebedingungen) in die sichere VM einfügt, bis der teilweise beendete Befehl vollständig beendet ist.
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung kann ein Computerserver sichere VMs hosten, die einem Hypervisor den Zugriff auf den Speicher, Register und andere Daten verwehren, die den sicheren VMs zugehörig sind, ohne dass der Hypervisor und/oder der Code/die Architektur der sicheren VM geändert werden muss, um Befehle zum Hypervisor abzufangen und/oder Antworten in die sicheren VMs einzufügen. Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung ermöglicht eine sichere Schnittstellensteuerung, die Millicode enthält, stattdessen, die Daten unter Verwendung einer verbesserten Struktur eines Zustandsdeskriptors und eines sicheren Teil des Speichers zu sichern. Die sichere Schnittstellensteuerung speichert darüber hinaus Daten von dem VM-Zustand, sodass für den Fall, dass dem Hypervisor einer oder mehrere Parameter zugänglich gemacht werden, die sichere Schnittstellensteuerung (Millicode) dies tun kann.
Eine oder mehrere Ausführungsformen der vorliegenden Erfindung sind in der Computertechnologie verwurzelt, insbesondere in Computerservern, die virtuelle Maschinen hosten. Eine oder mehrere Ausführungsformen der vorliegenden Erfindung ermöglichen des Weiteren eine Verbesserung des Betriebs der Datenverarbeitungstechnologie selbst, insbesondere Computerserver, die virtuelle Maschine hosten, indem sie es den Computerservern, die VMs hosten, ermöglichen, sichere VMs zu hosten, bei denen es sogar dem Hypervisor verwehrt wird, auf den Speicher, Register und andere Daten zuzugreifen, die der sicheren VM zugehörig sind. Eine oder mehrere Ausführungsformen der vorliegenden Erfindung stellen darüber hinaus wichtige Schritte zu Verbesserungen von Datenverarbeitungsservern bereit, die VM hosten, indem eine sichere Schnittstellensteuerung verwendet wird, die Millicode enthält, um eine Trennung der sicheren VM und des Hypervisors zu ermöglichen und damit die Sicherheit der von dem Datenverarbeitungsserver gehosteten VMs aufrechtzuerhalten. Die sichere Schnittstellensteuerung stellt leichte Zwischenoperationen bereit, um die Sicherheit zu verbessern, ohne dass wesentlicher Aufwand zum Sichern des VM-Zustands während der Initialisierung/des Verlassens der VMs wie hierin beschrieben hinzukommt.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jedem möglichen technischen Detaillierungsgrad der Integration handeln. Das Computerprogrammprodukt kann (ein) durch einen Computer lesbare(s) Speichermedium (oder -medien) umfassen, auf dem/denen durch einen Computer lesbare Programmanweisungen gespeichert ist/sind, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch eine Einheit zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die Folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder gehobene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. einen Lichtwellenleiter durchlaufende Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs/Verarbeitungs-Einheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Router, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs/Verarbeitungs-Einheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs/Verarbeitungs-Einheit weiter.
Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten, Konfigurationsdaten für integrierte Schaltungen oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o. ä. sowie prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, sodass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, einen Herstellungsartikel aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktion/Schritts umsetzen.
Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, sodass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung wurden zum Zwecke der Veranschaulichung vorgestellt, sollen jedoch nicht erschöpfend oder auf die Ausführungsformen beschränkt sein. Für Fachleute ist offensichtlich, dass viele Änderungen und Abwandlungen möglich sind, ohne vom Anwendungsbereich und Erfindungsgedanken der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber Technologien auf dem Markt bestmöglich zu erläutern oder es Fachleuten zu ermöglichen, die hierin beschriebenen Ausführungsformen zu verstehen.

Claims

Durch einen Computer implementiertes Verfahren, das aufweist: Ausführen (505) eines Befehlsstroms von einer virtuellen Maschine (15A; 15B; 15C; 15D; 15N), die auf einem Host-Server (10) ausgeführt wird, wobei ein Befehl aus dem Befehlsstrom zu einem Hypervisor (12) abgefangen werden muss; auf der Grundlage einer Feststellung (515), dass es sich bei der virtuellen Maschine um eine sichere virtuelle Maschine handelt, Verhindern, dass der Hypervisor direkt auf beliebige Daten der sicheren virtuellen Maschine zugreift; und Durchführen (525) durch eine sichere, durch Millicode und interne vertrauenswürdige Hardware und Firmware realisierte Schnittstellensteuerung (11) des Host-Servers: auf der Grundlage einer Feststellung (540), dass der Befehl nicht von der sicheren Schnittstellensteuerung selbst interpretierbar ist, weil die sichere Schnittstellensteuerung nicht auf die Operanden zugreifen kann: Extrahieren (555) eines oder mehrerer Parameterdatenelemente, die dem Befehl von der sicheren virtuellen Maschine zugehörig sind, durch die sichere Schnittstellensteuerung; Speichern (555) des einen oder mehrerer Parameterdatenelemente durch die sichere Schnittstellensteuerung in einem Puffer, auf den der Hypervisor Zugriff hat; und Abfangen (555) des Befehls zum Hypervisor durch die sichere Schnittstellensteuerung; auf der Grundlage einer Feststellung (540), dass der Befehl durch die sichere Schnittstellensteuerung selbst interpretierbar ist, weil die sichere Schnittstellensteuerung auf die Operanden zugreifen kann: Ausführen (545) des Befehls durch die sichere Schnittstellensteuerung; und Zurückgeben der Ausführungssteuerung an die sichere virtuelle Maschine, um die Ausführung des Befehlsstroms fortzusetzen.
Durch einen Computer implementiertes Verfahren nach Anspruch 1, wobei das Abfangen des Befehls weiterhin aufweist: Setzen (550) eines ersten Merkers durch die sichere Schnittstellensteuerung, der anzeigt, dass der Befehl teilweise beendet ist; und Setzen (552) eines zweiten Merkers durch die sichere Schnittstellensteuerung, der anzeigt, dass sich die sichere virtuelle Maschine in einem gesperrten Zustand für die Ausführung befindet.
Durch einen Computer implementiertes Verfahren nach Anspruch 2, wobei die sichere Schnittstellensteuerung Zuteilen der sicheren virtuellen Maschine im gesperrten Zustand verhindert, wobei der gesperrte Zustand anzeigt, dass die sichere virtuelle Maschine auf eine Antwort vom Hypervisor wartet.
Durch einen Computer implementiertes Verfahren nach einem der Ansprüche 1 bis 3, das weiterhin aufweist: auf der Grundlage einer Feststellung (530) durch die sichere Schnittstellensteuerung, dass der Befehl eine Programmausnahmebedingung verursacht, Anzeigen (535) der Ausnahmebedingung für die sichere virtuelle Maschine.
Durch einen Computer implementiertes Verfahren nach einem der Ansprüche 1 bis 4, das weiterhin aufweist: nach dem Beenden der Ausführung des Befehls durch den Hypervisor Aktualisieren (590) eines Zustands der sicheren virtuellen Maschine durch die sichere Schnittstellensteuerung mit einer Antwort vom Hypervisor, wobei mindestens ein Teil des Zustands in einem sicheren Teil des Speichers gespeichert wird, auf den der Hypervisor keinen Zugriff hat.
Durch einen Computer implementiertes Verfahren nach Anspruch 5, wobei der Hypervisor die Antwort für den Befehl in einem zweckgebundenen Puffer speichert.
Durch einen Computer implementiertes Verfahren nach Anspruch 5 oder 6, das weiterhin aufweist: nach dem Beenden der Ausführung Abfangen (582) einer Fehlerbedingung zum Hypervisor durch die sichere Schnittstellensteuerung auf der Grundlage einer Feststellung, dass die vom Hypervisor erzeugte Antwort nicht gültig ist.
System (10), das aufweist: einen Speicher (110); eine sichere, durch Millicode und interne vertrauenswürdige Hardware und Firmware realisierte Schnittstellensteuerung (11); und eine Verarbeitungseinheit (105), die mit dem Speicher und der sicheren Schnittstellensteuerung verbunden ist, wobei die Verarbeitungseinheit so konfiguriert ist, dass sie einen Hypervisor (12) ausführt, der eine Mehrzahl von virtuellen Maschinen (15A; 15B; 15C; 15D; 15N) hostet, wobei es dem Hypervisor verwehrt wird, direkt auf beliebige Daten einer sicheren virtuellen Maschine zuzugreifen, und wobei der Hypervisor so konfiguriert ist, dass er ein Verfahren zum Interpretieren eines oder mehrerer Gastbefehle von den virtuellen Maschinen durchführt, wobei das Verfahren aufweist: Ausführen (505) eines Befehlsstroms durch eine virtuelle Maschine, wobei ein Befehl aus dem Befehlsstrom zu einem Hypervisor abgefangen werden muss; Feststellen (515), dass es sich bei der virtuellen Maschine um eine sichere virtuelle Maschine handelt; und Durchführen (525) durch die sichere Schnittstellensteuerung: auf der Grundlage einer Feststellung (540), dass der Befehl nicht von der sicheren Schnittstellensteuerung selbst interpretierbar ist, weil die sichere Schnittstellensteuerung nicht auf die Operanden zugreifen kann: Extrahieren (555) eines oder mehrerer Parameterdatenelemente, die dem Befehl von der sicheren virtuellen Maschine zugehörig sind, durch die sichere Schnittstellensteuerung; Speichern (555) des einen oder mehrerer Parameterdatenelemente durch die sichere Schnittstellensteuerung in einem Puffer, auf den der Hypervisor Zugriff hat; und Abfangen (555) des Befehls zum Hypervisor durch die sichere Schnittstellensteuerung; auf der Grundlage einer Feststellung (540), dass der Befehl durch die sichere Schnittstellensteuerung selbst interpretierbar ist, weil die sichere Schnittstellensteuerung auf die Operanden zugreifen kann: Ausführen (545) des Befehls durch die sichere Schnittstellensteuerung; und Zurückgeben der Ausführungssteuerung an die sichere virtuelle Maschine, um die Ausführung des Befehlsstroms fortzusetzen.
System nach Anspruch 8, wobei das Abfangen des Befehls weiterhin aufweist: Setzen (550) eines ersten Merkers durch die sichere Schnittstellensteuerung, der anzeigt, dass der Befehl teilweise beendet ist; und Setzen (552) eines zweiten Merkers durch die sichere Schnittstellensteuerung, der anzeigt, dass sich die sichere virtuelle Maschine in einem gesperrten Zustand für die Ausführung befindet.
System nach Anspruch 8 oder 9, wobei das Verfahren weiterhin aufweist: auf der Grundlage einer Feststellung durch die sichere Schnittstellensteuerung, dass der Befehl eine Programmausnahmebedingung verursacht, Anzeigen der Ausnahmebedingung für die sichere virtuelle Maschine.
System nach einem der Ansprüche 8 bis 10, das weiterhin aufweist: nach dem Beenden der Ausführung des Befehls durch den Hypervisor Aktualisieren (590) eines Zustands der sicheren virtuellen Maschine durch die sichere Schnittstellensteuerung mit einer Antwort vom Hypervisor, wobei mindestens ein Teil des Zustands in einem sicheren Teil des Speichers gespeichert wird, auf den der Hypervisor keinen Zugriff hat.
System nach Anspruch 11, wobei der Hypervisor die Antwort für den Befehl in einem zweckgebundenen Puffer speichert.
System nach Anspruch 11 oder 12, wobei das Verfahren weiterhin aufweist: nach dem Beenden der Ausführung Abfangen (582) einer Fehlerbedingung zum Hypervisor durch die sichere Schnittstellensteuerung auf der Grundlage einer Feststellung, dass die vom Hypervisor erzeugte Antwort nicht gültig ist.
Computerprogrammprodukt, das ein durch einen Computer (10) lesbares Speichermedium aufweist, wobei das durch einen Computer lesbare Speichermedium durch einen Computer ausführbare Befehle aufweist, die, wenn sie von einer Verarbeitungseinheit (105) ausgeführt werden, die Verarbeitungseinheit veranlassen, ein Verfahren durchzuführen, das aufweist: Ausführen (505) eines Befehlsstroms von einer virtuellen Maschine (15A; 15B; 15C; 15D; 15N), die auf einem Host-Server (10) ausgeführt wird, wobei ein Befehl aus dem Befehlsstrom zu einem Hypervisor (12) abgefangen werden muss; Feststellen (515), dass es sich bei der virtuellen Maschine um eine sichere virtuelle Maschine handelt, wobei es dem Hypervisor verwehrt wird, direkt auf beliebige Daten der sicheren virtuellen Maschine zuzugreifen; und Durchführen (525) durch eine sichere, durch Millicode und interne vertrauenswürdige Hardware und Firmware realisierte Schnittstellensteuerung (11) des Host-Servers: auf der Grundlage einer Feststellung (540), dass der Befehl nicht von der sicheren Schnittstellensteuerung selbst interpretierbar ist, weil die sichere Schnittstellensteuerung nicht auf die Operanden zugreifen kann: Extrahieren (555) eines oder mehrerer Parameterdatenelemente, die dem Befehl von der sicheren virtuellen Maschine zugehörig sind, durch die sichere Schnittstellensteuerung; Speichern (555) des einen oder mehrerer Parameterdatenelemente durch die sichere Schnittstellensteuerung in einem Puffer, auf den der Hypervisor Zugriff hat; und Abfangen (555) des Befehls zum Hypervisor durch die sichere Schnittstellensteuerung; auf der Grundlage einer Feststellung (540), dass der Befehl durch die sichere Schnittstellensteuerung selbst interpretierbar ist, weil die sichere Schnittstellensteuerung auf die Operanden zugreifen kann: Ausführen (545) des Befehls durch die sichere Schnittstellensteuerung; und Zurückgeben der Ausführungssteuerung an die sichere virtuelle Maschine, um die Ausführung des Befehlsstroms fortzusetzen.
Computerprogrammprodukt nach Anspruch 14, wobei das Verfahren weiterhin aufweist: nach dem Beenden der Ausführung des Befehls durch den Hypervisor Aktualisieren (590) eines Zustands der sicheren virtuellen Maschine durch die sichere Schnittstellensteuerung mit einer Antwort vom Hypervisor, wobei mindestens ein Teil des Zustands in einem sicheren Teil des Speichers gespeichert wird, auf den der Hypervisor keinen Zugriff hat.
Computerprogrammprodukt nach Anspruch 15, wobei der Hypervisor die Antwort für den Befehl in einem zweckgebundenen Puffer speichert.
Computerprogrammprodukt nach Anspruch 15 oder 16, wobei das Verfahren weiterhin aufweist: nach dem Beenden der Ausführung Abfangen (582) einer Fehlerbedingung zum Hypervisor durch die sichere Schnittstellensteuerung auf der Grundlage einer Feststellung, dass die vom Hypervisor erzeugte Antwort nicht gültig ist.