DE112020000303T5

DE112020000303T5 - Testen von speicherschutz-hardware in einer umgebung einer sicheren virtuellen maschine

Info

Publication number: DE112020000303T5
Application number: DE112020000303.5T
Authority: DE
Inventors: Lisa Heller; Fadi Basuba
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2019-03-08
Filing date: 2020-03-06
Publication date: 2021-09-30
Also published as: CN113544645B; US11455398B2; CN113544645A; GB2598222B; GB202113842D0; JP7373578B2; WO2020183317A1; GB2598222A; US20200285493A1; JP2022523787A

Abstract

Ein Verfahren zum Testen von Speicherschutz-Hardware umfasst ein Empfangen, von einer nicht vertrauenswürdigen Entität, die auf einem Host-Server ausgeführt wird, einer Anforderung zum Zuteilen einer sicheren Entität. Durch eine sichere Schnittstellensteuerung des Host-Servers wird bestimmt, ob sich der Host-Server in einem sicheren Hilfs- (AS) Debug-Modus zum Testen einer AS-Entität befindet. Auf Grundlage des Bestimmens, dass sich der Host-Server in dem AS-Debug-Modus befindet, wird ein sicherer Gast-Entitätszustand aus einem Zustandsdeskriptor für die sichere Entität in einen AS-Entitätszustand in Hardware geladen, um nach Zuteilung der sicheren Entität Zugriffe auf Seiten in einem Arbeitsspeicher zu testen, die als „Sicher“ und als der AS-Entität zugehörig registriert sind.

Description

HINTERGRUND
Die vorliegende Erfindung betrifft allgemein Computertechnologie und insbesondere einen Modus zum Testen von Speicherschutz-Hardware, die von einer sicheren Schnittstellensteuerung in einer Umgebung einer sicheren virtuellen Maschine (VM) verwendet wird.
Cloud Computing und Cloud Storage stellen für Nutzer Möglichkeiten zum Speichern und Verarbeiten ihrer Daten in Rechenzentren von Drittparteien bereit. Cloud Computing vereinfacht die Fähigkeit zum schnellen und einfachen Bereitstellen einer VM für einen Kunden, wobei der Kunde weder Hardware erwerben noch Stellfläche für einen physischen Server bereitstellen muss. Der Kunde kann die VM entsprechend einer Änderung von Voreinstellungen oder Anforderungen des Kunden problemlos erweitern oder verkleinern. In der Regel stellt ein Anbieter von Cloud Computing die VM bereit, die sich physisch auf einem Server im Rechenzentrum des Anbieters befindet. Kunden sind oft hinsichtlich der Sicherheit von Daten in der VM besorgt, vor allem, weil Computing-Anbieter häufig Daten von mehr als einem Kunden auf demselben Server speichern. Kunden können Sicherheit zwischen ihrem eigenen Code/den eigenen Daten und dem Code/den Daten des Cloud-Computing-Anbieters sowie zwischen ihrem eigenen Code/den eigenen Daten und demjenigen bzw. denjenigen von anderen VMs verlangen, die am Standort des Anbieters ausgeführt werden. Außerdem kann der Kunde Sicherheit von den Administratoren des Anbieters sowie in Bezug auf mögliche Sicherheitsverletzungen durch anderen Code verlangen, der auf der Maschine ausgeführt wird.
Um derartige heikle Situationen zu meistern, können Anbieter von Cloud-Diensten Sicherheitskontrollen umsetzen, um eine einwandfreie Datenisolation und logische Speichertrennung sicherzustellen. Der ausgedehnte Einsatz von Virtualisierung beim Umsetzen einer Cloud-Infrastruktur führt zu einzigartigen Sicherheitsproblemen für Kunden von Cloud-Diensten, da eine Virtualisierung die Beziehung zwischen einem Betriebssystem (OS) und der zugrunde liegenden Hardware verändert, sei es Hardware für Datenverarbeitung, Speicher oder sogar Vernetzung. Damit wird die Virtualisierung als eine zusätzliche Schicht eingeführt, die selbst einwandfrei konfiguriert, verwaltet und gesichert werden muss.
Im Allgemeinen hängt eine VM, die als Gast unter der Steuerung eines Host-Hypervisors ausgeführt wird, von diesem Hypervisor ab, um Virtualisierungsdienste für diesen Gast transparent bereitzustellen. Diese Dienste umfassen Arbeitsspeicherverwaltung, Anweisungsemulation und Interrupt-Verarbeitung.
Im Fall einer Arbeitsspeicherverwaltung kann die VM ihre Daten von einer Platte verschieben (page-in (einlagern)), um sie in einem Arbeitsspeicher abzulegen, und die VM kann ihre Daten auch wieder auf die Platte zurückverschieben (page-out (auslagern)). Während sich die Seite im Arbeitsspeicher befindet, verwendet die VM (Gast) eine dynamische Adressübersetzung (DAT), um die Seiten im Arbeitsspeicher von einer virtuellen Gast-Adresse einer absoluten Gast-Adresse zuzuordnen. Außerdem hat der Host-Hypervisor seine eigene DAT-Zuordnung (von virtueller Host-Adresse zu absoluter Host-Adresse) für die Gast-Seiten im Arbeitsspeicher und kann die Gast-Seiten unabhängig und transparent für den Gast in den Arbeitsspeicher ein- oder aus diesem auslagern. Der Hypervisor stellt über die DAT-Tabellen des Hosts eine Arbeitsspeicherisolation oder gemeinsame Nutzung von Gast-Arbeitsspeicher zwischen zwei getrennten Gast-VMs bereit. Der Host ist auch fähig, auf den Gast-Arbeitsspeicher zuzugreifen, um gegebenenfalls Gast-Operationen für den Gast zu simulieren.
KURZDARSTELLUNG DER ERFINDUNG
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung umfasst ein nicht einschränkendes beispielhaftes Verfahren ein Empfangen, von einer nicht vertrauenswürdigen Entität, die auf einem Host-Server ausgeführt wird, einer Anforderung zum Zuteilen einer sicheren Entität. Durch eine sichere Schnittstellensteuerung des Host-Servers wird bestimmt, ob sich der Host-Server in einem sicheren Hilfs- (AS) Debug-Modus zum Testen einer AS-Entität befindet. Auf Grundlage des Bestimmens, dass sich der Host-Server in dem AS-Debug-Modus befindet, wird ein sicherer Gast-Entitätszustand aus einem Zustandsdeskriptor für die sichere Entität in einen AS-Entitätszustand in Hardware geladen, um nach Zuteilung der sicheren Entität Zugriffe auf Seiten in einem Arbeitsspeicher zu testen, die als „Sicher“ und als der AS-Entität zugehörig registriert sind. Technische Effekte und Vorteile können die Fähigkeit umfassen, von der sicheren Schnittstellensteuerung verwendete Hardware zu testen, ohne zu erfordern, dass die Infrastruktur der sicheren Schnittstellensteuerung während des Testens betriebsbereit sein muss. Dies kann zu einem früheren und umfassenderen Testen der Hardware führen.
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung wird die sichere Entität zugeteilt. Technische Effekte und Vorteile können ein Ausführen des Testens der Hardware umfassen.
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung umfasst der AS-Entitätszustand eine Domäne und ein Modus-Bit.
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung beruht das Bestimmen auf einem oder mehreren Hardware-Bits
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung wird auf Grundlage des Bestimmens, dass sich der Host-Server nicht in dem AS-Debug-Modus befindet, der sichere Gast-Entitätszustand aus dem Zustandsdeskriptor für die sichere Entität in einen sicheren Gast-Entitätszustand in Hardware geladen, um nach Zuteilung der sicheren Entität Zugriffe auf Seiten in einem Arbeitsspeicher zu testen, die als „Sicher“ registriert sind. Technische Effekte und Vorteile können die Fähigkeit umfassen, die von dem sicheren Gast verwendete Hardware zu testen.
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung ist die nicht vertrauenswürdige Entität ein Hypervisor, und die sichere Entität ist eine sichere virtuelle Maschine (VM).
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung ist die sichere Entität ein Testfall.
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung umfasst ein nicht einschränkendes beispielhaftes Verfahren ein Empfangen, von einer nicht vertrauenswürdigen Entität, die auf einem Host-Server ausgeführt wird, einer Anforderung zum Zuteilen einer sicheren Entität. Durch eine sichere Schnittstellensteuerung des Host-Servers wird bestimmt, ob sich die sichere Entität in einem sicheren Hilfs- (AS) Modus zum Testen einer AS-Entität befindet. Auf Grundlage des Bestimmens, dass sich die sichere Entität im AS-Debug-Modus befindet, wird ein AS-Entitätszustand aus einem Zustandsdeskriptor für die sichere Entität in einen AS-Entitätszustand in Hardware geladen, um nach Zuteilung der sicheren Entität Zugriff auf Seiten in einem Arbeitsspeicher zu testen, die als „Sicher“ und als der AS-Entität zugehörig registriert sind. Technische Effekte und Vorteile können die Fähigkeit umfassen, von der sicheren Schnittstellensteuerung verwendete Hardware zu testen, ohne zu erfordern, dass die Infrastruktur der sicheren Schnittstellensteuerung während des Testens betriebsbereit sein muss. Dies kann zu einem früheren und umfassenderen Testen der Hardware führen.
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung wird auf Grundlage eines Bestimmens, dass sich die sichere Entität in einem AS-Debug-Modus befindet, durch die sichere Schnittstellensteuerung des Host-Servers bestimmt, ob sich die sichere Gast-Entität auch in einem sicheren Gast-Modus befindet. Auf Grundlage des Bestimmens, dass sich die sichere Entität ebenfalls in dem sicheren Gast-Modus befindet, wird ein sicherer Gast-Entitätszustand aus dem Zustandsdeskriptor für die sichere Entität in einen sicheren Gast-Entitätszustand in Hardware geladen, um nach Zuteilung der sicheren Entität Zugriffe auf Seiten in einem Arbeitsspeicher zu testen, die als „Sicher“ registriert sind. Technische Effekte und Vorteile können die Fähigkeit umfassen, sowohl die AS-Entität als auch die sichere Gast-Entität zu testen.
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung wird die sichere Entität zugeteilt. Technische Effekte und Vorteile können ein Ausführen des Testens der Hardware umfassen.
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung weist der sichere Gast-Entitätszustand eine Domäne und ein Modus-Bit auf.
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung weist der AS-Entitätszustand eine Domäne und ein Modus-Bit auf.
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung beruht das Bestimmen auf einem Bit in dem Zustandsdeskriptor der sicheren Entität.
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung ist die nicht vertrauenswürdige Entität ein Hypervisor, und die sichere Entität ist eine sichere virtuelle Maschine (VM).
Gemäß zusätzlichen oder alternativen Ausführungsformen der vorliegenden Erfindung ist die sichere Entität ein Testfall.
Andere Ausführungsformen der vorliegenden Erfindung setzen die Merkmale der oben beschriebenen Verfahren in Computersystemen und in Computerprogrammprodukten um.
Weitere Merkmale und Vorteile werden durch die Techniken der vorliegenden Offenbarung verwirklicht. Andere Ausführungsformen und Aspekte der Erfindung werden hierin ausführlich beschrieben und werden als Bestandteil der Erfindung betrachtet. Zum besseren Verständnis der Erfindung mit den Vorteilen und den Merkmalen wird auf die Beschreibung und auf die Zeichnungen verwiesen.
Figurenliste
Die hierin beschriebenen Details der ausschließlichen Rechte werden insbesondere in den Ansprüchen am Ende der Patentschrift dargelegt und eindeutig beansprucht. Die vorgenannten und andere Merkmale und Vorteile der Ausführungsformen der Erfindung werden aus der folgenden ausführlichen Beschreibung in Verbindung mit den begleitenden Zeichnungen offenkundig, wobei:

1 eine Tabelle für Zonensicherheit gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
2 virtuelle und absolute Adressräume zum Ausführen von DAT gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
3 eine verschachtelte mehrteilige dynamische Adressübersetzung (DAT) zum Unterstützen einer virtuellen Maschine (VM), die unter einem Hypervisor ausgeführt wird, gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
4 eine Zuordnung von sicherem Gast-Speicher gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
5 einen Systemschemaplan einer DAT-Operation gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
6 einen Systemschemaplan eines Arbeitsspeichers einer sicheren Schnittstellensteuerung gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
7 einen Prozessablauf einer Importoperation gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
8 einen Prozessablauf einer Importoperation gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
9 einen Prozess einer Operation eines überlassenen Arbeitsspeichers gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
10 einen Prozessablauf eines Übergangs von nicht sicheren Hypervisor-Seiten zu sicheren Seiten einer sicheren Schnittstellensteuerung gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
11 einen Prozessablauf eines durch die sichere Schnittstellensteuerung ausgeführten sicheren Speicherzugriffs gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
12 einen Prozessablauf einer Zugriffskennzeichnung durch die sichere Schnittstellensteuerung und durch Hardware gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
13 einen Prozessablauf von Übersetzungen zum Unterstützen von sicheren und nicht sicheren Zugriffen durch das Programm und durch die sichere Schnittstellensteuerung gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
14 einen Prozessablauf einer DAT mit sicherem Speicherschutz durch das Programm und durch sichere Schnittstellensteuerung gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
15 einen Prozessablauf eines Testfalls zum Initiieren einer sicheren VM gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
16 ein Beispiel für einen Zustandsdeskriptor gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
17 einen Prozessablauf eines Testfalls zum Initiieren einer sicheren VM gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
18 eine Cloud-Computing-Umgebung gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung veranschaulicht;
19 Abstraktionsmodellschichten gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
20 ein System gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt; und
21 ein Verarbeitungssystem gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt.

Die hierin dargestellten Abbildungen dienen zur Veranschaulichung. Viele Variationen der Darstellungen oder der hierin beschriebenen Operationen sind möglich, ohne vom Erfindungsgedanken der Erfindung abzuweichen. Die Aktionen können zum Beispiel in einer anderen Reihenfolge ausgeführt werden, oder Aktionen können hinzugefügt, gelöscht oder modifiziert werden. Der Begriff „verbunden“ und Variationen davon beschreiben des Weiteren einen Datenübertragungspfad zwischen zwei Elementen und implizieren keine direkte Verbindung zwischen den Elementen ohne dazwischen liegende Elemente/Verbindungen. Alle dieser Variationen werden als Teil der Patentschrift betrachtet.
AUSFÜHRLICHE BESCHREIBUNG
Eine oder mehrere Ausführungsformen der vorliegenden Erfindung überprüfen, dass die von einer sicheren Schnittstellensteuerung verwendete Hardware einwandfrei funktioniert, um nicht genehmigte Zugriffe auf Datenstrukturen zu verhindern, die von der sicheren Schnittstellensteuerung verwendet werden. Wie ferner hierin beschrieben, stellt die sichere Schnittstellensteuerung eine sichere Umgebung für virtuelle Maschinen (VMs) bereit, die auf einem Computersystem ausgeführt werden. Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung wird die Überprüfung der Hardware ausgeführt, indem die Hardware in einen speziellen Test-Modus versetzt wird, der hierin als „sicherer Hilfs-Modus“ oder „AS-Debug-Modus“ bezeichnet wird, der nicht erfordert, dass die Infrastruktur der sicheren Schnittstellensteuerung während des Testens betriebsbereit sein muss. Außerdem wird aufgrund der Ähnlichkeit der Hardware, die zum Zugreifen auf Arbeitsspeicher-Speicherorte verwendet wird, die als „Sicher“ markiert sind, und der Hardware, die zum Zugreifen auf Arbeitsspeicher-Speicherorte verwendet wird, die Daten der sicheren Schnittstellensteuerung enthalten (z.B. Datenstrukturen), die Erstellung von komplizierten Testfällen vermieden, die die Infrastruktur der sicheren Schnittstellensteuerung manipulieren. Stattdessen können dieselben Testfälle, die zum Testen von Datenzugriffen auf sicheren Gast-Speicher verwendet werden, wenn er sich in einem sicheren Gast-Modus befindet, auf ein Testen von Datenzugriffen auf sicheren Schnittstellensteuerungs-Speicher angewendet werden, wenn er sich im AS-Debug-Modus befindet. Diese Testfälle können zum vollständigen Anwenden der Hardware während des Testens verwendet werden.
Eine virtuelle Maschine (VM), die als Gast unter der Steuerung eines Host-Hypervisors ausgeführt wird, ist von diesem Hypervisor abhängig, um Virtualisierungsdienste für diesen Gast transparent bereitzustellen. Diese Dienste können auf jede Schnittstelle zwischen einer sicheren Entität und einer weiteren nicht vertrauenswürdigen Entität angewendet werden, die herkömmlicherweise Zugriff auf die sicheren Ressourcen durch diese andere Entität gestattet. Wie vorher erwähnt, können diese Dienste Arbeitsspeicherverwaltung, Anweisungsemulation und Interruptverarbeitung umfassen, sie sind aber nicht darauf beschränkt. Zum Beispiel liest und/oder schreibt der Hypervisor für Interrupt und Ausnahmeinjektion in der Regel in einem Präfixbereich (Low Core) des Gastes. Der Begriff „virtuelle Maschine“ oder „VM“, wie hierin verwendet, bezieht sich auf eine logische Darstellung einer physischen Maschine (Datenverarbeitungseinheit, Prozessor usw.) und deren Verarbeitungsumgebung (Betriebssystem (OS), Software-Ressourcen usw.). Die VM wird als Software verwaltet, die auf einer zugrundeliegenden Host-Maschine (physischer Prozessor oder Gruppe von Prozessoren) ausgeführt wird. Aus der Perspektive eines Benutzers oder einer Software-Ressource scheint die VM ihre eigene unabhängige physische Maschine zu sein. Die Begriffe „Hypervisor“ und „VM-Monitor (VMM)“, wie hierin verwendet, beziehen sich auf eine Verarbeitungsumgebung oder einen Plattformdienst, der mehrere VMs verwaltet und diesen gestattet, mehrere (und manchmal verschiedene) Betriebssysteme auf ein und derselben Host-Maschine auszuführen. Es sollte klar sein, dass ein Verwenden einer VM einen Installationsprozess der VM und einen Aktivierungs- (oder Start-) Prozess der VM umfasst. In einem weiteren Beispiel umfasst ein Verwenden einer VM einen Aktivierungs- (oder Start-) Prozess der VM (z.B. wenn die VM vorher installiert wurde oder bereits vorhanden ist).
Um sichere Gäste zu ermöglichen und zu unterstützen, besteht eine technische Herausforderung in Fällen, in denen zusätzliche Sicherheit zwischen dem Hypervisor und den sicheren Gästen unabhängig vom Hypervisor erforderlich ist, sodass der Hypervisor nicht auf Daten von der VM zugreifen und daher keine Dienste auf die oben beschriebene Weise bereitstellen kann.
Die hierin beschriebene sichere Ausführung stellt einen Hardware-Mechanismus zum Sicherstellen einer Isolation zwischen sicherem Speicher und nicht sicherem Speicher sowie zwischen sicherem Speicher bereit, der zu verschiedenen sicheren Benutzern gehört. Für sichere Gäste wird zusätzliche Sicherheit zwischen dem „nicht vertrauenswürdigen“, nicht sicheren Hypervisor und den sicheren Gästen bereitgestellt. Dazu müssen viele der Funktionen, die der Hypervisor in der Regel für die Gäste ausführt, in die Maschine integriert werden. Eine neue sichere Schnittstellensteuerung, auf die hierin auch als „UV“ Bezug genommen wird, wird hierin beschrieben, um eine sichere Schnittstelle zwischen dem Hypervisor und den sicheren Gästen bereitzustellen. Die Begriffe „sichere Schnittstellensteuerung“ und „UV“ werden hierin austauschbar verwendet. Die sichere Schnittstellensteuerung arbeitet mit der Hardware zusammen, um diese zusätzliche Sicherheit bereitzustellen. Außerdem kann ein Hypervisor einer niedrigeren Ebene eine Virtualisierung für diesen nicht vertrauenswürdigen Hypervisor bereitstellen, und wenn der Hypervisor niedrigerer Ebene in vertrauenswürdigem Code umgesetzt wird, kann er auch Teil der sicheren Schnittstellensteuerung sein.
Die sichere Schnittstellensteuerung wird in einem Beispiel in interner, sicherer und vertrauenswürdiger Hardware und/oder Firmware umgesetzt. Diese vertrauenswürdige Firmware kann zum Beispiel Prozessor-Millicode oder logischen PR/SM-Partitionierungscode umfassen. Für einen sicheren Gast bzw. eine sichere Entität stellt die sichere Schnittstellensteuerung die Initialisierung und Verwaltung der sicheren Umgebung sowie die Koordinierung der Zuteilung dieser sicheren Entitäten auf der Hardware bereit. Wenn der sichere Gast Daten aktiv verwendet und diese im Host-Speicher abgelegt sind, werden sie in sicherem Speicher „deaktiviert“ gehalten Auf den sicheren Gast-Speicher kann von diesem einzelnen sicheren Gast zugegriffen werden - wobei dies strikt durch die Hardware durchgesetzt wird. Das heißt, die Hardware hindert jede nicht sichere Entität (darunter den Hypervisor oder andere nicht sichere Gäste) oder verschiedene sichere Gäste daran, auf diese Daten zuzugreifen. In diesem Beispiel wird die sichere Schnittstellensteuerung als ein vertrauenswürdiger Teil der untersten Firmware-Ebenen ausgeführt. Die unterste Ebene bzw. der Millicode ist eigentlich eine Erweiterung der Hardware und wird zum Umsetzen der komplexen Anweisungen und Funktionen verwendet, die zum Beispiel in zArchitecture^® von IBM definiert sind. Der Millicode hat Zugriff auf alle Teile des Speichers, der im Kontext einer sicheren Ausführung seinen eigenen sicheren UV-Speicher, nicht sicheren Hypervisor-Speicher, sicheren Gast-Speicher und gemeinsam genutzten Speicher umfasst. Somit kann er jede Funktion bereitstellen, die von dem sicheren Gast oder dem Hypervisor zum Unterstützen dieses Gastes benötigt werden. Die sichere Schnittstellensteuerung hat direkten Zugriff auf die Hardware, wodurch es der Hardware möglich ist, Sicherheitsüberprüfungen effizient unter der Kontrolle von Bedingungen bereitzustellen, die durch die sichere Schnittstellensteuerung erstellt wurden.
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung wird ein sicheres Speicher-Bit in der Hardware zum Markieren einer sicheren Seite bereitgestellt. Wenn dieses Bit gesetzt ist, hindert die Hardware jeden nicht sicheren Gast oder Hypervisor daran, auf diese Seite zuzugreifen. Außerdem wird jede sichere oder gemeinsam genutzte Seite in einer Zonensicherheitstabelle registriert und wird mit einer Kennung (ID) „Sichere Gast-Domäne“ gekennzeichnet. Wenn die Seite nicht sicher ist, wird sie als solche in der Zonensicherheitstabelle markiert. Diese Zonensicherheitstabelle wird von der sicheren Schnittstellensteuerung pro Partition oder Zone verwaltet und ist ein Beispiel für eine Datenstruktur, die von der sicheren Schnittstellensteuerung verwendet und getestet wird, wenn sich das System im sicheren Hilfs-Modus befindet. Pro absoluter Host-Seite ist ein Eintrag vorhanden, der von der Hardware auf jeder DAT-Übersetzung, die durch eine sichere Entität vorgenommen wird, verwendet wird, um sicherzustellen, dass auf die Seite nur von dem sicheren Gast oder der zugehörigen Entität zugegriffen wird.
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung hat die sichere Schnittstellensteuerung ihren eigenen sicheren UV-Speicher, auf den nur von der sicheren Schnittstellensteuerung selbst zugegriffen werden kann. Dieser Speicher wird von der sicheren Schnittstellensteuerung und der Hardware verwendet, um die nötige Sicherheit für die sicheren Gäste bereitzustellen. Die sichere Schnittstellensteuerung verwendet diesen sicheren Speicher, um Informationen über sich selbst, die Zone, die zum Ausführen sicherer Gäste aktiviert ist, die sicheren Gäste und die sicheren virtuellen CPUs zu speichern. Speicher der sicheren Schnittstellensteuerung wird ähnlich wie sicherer Gast-Speicher auch als sichere Seite markiert, um Zugriff durch eine nicht sichere Entität zu verhindern. Außerdem hat der Speicher der sicheren Schnittstellensteuerung seine eigenen sicheren Domänen-IDs, die verwendet werden, um alle anderen sicheren Entitäten daran zu hindern, auf Speicher der sicheren Schnittstellensteuerung zuzugreifen.
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung verwendet die Software eine Anweisung „UV-Aufruf“ (UVC) (UV Call), um die sichere Schnittstellensteuerung aufzufordern, eine bestimmte Aktion auszuführen. Zum Beispiel kann die UCV-Anweisung von dem Hypervisor zum Initialisieren der sicheren Schnittstellensteuerung, Erstellen der sicheren Gast-Domäne (z.B. sichere Gast-Konfiguration) und Erstellen der virtuellen CPUs in dieser sicheren Konfiguration verwendet werden. Sie kann auch zum Importieren (Entschlüsseln und Zuweisen zu sicherer Gast-Domäne) und Exportieren (Verschlüsseln und Zulassen von Host-Zugriff) einer sicheren Gast-Seite als Teil der Einlagerungs- oder Auslagerungs-Operationen des Hypervisors verwendet werden. Außerdem hat der sichere Gast die Möglichkeit, mit dem Hypervisor gemeinsam genutzten Speicher zu definieren, sicheren Speicher gemeinsam nutzbar zu machen und gemeinsam genutzten Speicher sicher zu machen.
Diese UVC-Befehle können durch die Maschinen-Firmware ähnlich wie viele andere architekturgebundene Anweisungen ausgeführt werden. Die Maschine tritt nicht in einen Modus einer sicheren Schnittstellensteuerung ein, sondern stattdessen führt die Maschine Funktionen der sicheren Schnittstellensteuerung in dem Modus aus, in dem sie aktuell ausgeführt wird. Die Hardware verwaltet die Zustände sowohl der Firmware als auch der Software, sodass kein Wechsel von Kontexten erfolgt, um diese Operationen zu bearbeiten. Diese geringe Systembelastung ermöglicht eine enge Zusammenarbeit zwischen den verschiedenen Schichten der Software, vertrauenswürdiger Firmware und Hardware auf eine Weise, die eine Komplexität in der sicheren Schnittstellensteuerung minimiert und reduziert, aber immer noch das notwendige Sicherheitsniveau bereitstellt.
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung überlässt der Hypervisor der sicheren Schnittstellensteuerung während der Initialisierung der sicheren Gast-Umgebung Speicher zum Unterstützen der Steuerblockstrukturen, die von der sicheren Schnittstellensteuerung und der Hardware benötigt werden, um den sicheren Gast und unterstützende Hypervisor-Umgebungen entsprechend zu verwalten. Daraufhin gibt der Hypervisor in Vorbereitung eines 1) Initialisierens einer Zone zum Ausführen von sicheren Gästen, 2) Erstellens von sicheren Gast-Domänen und 3) Erstellens der sicheren CPUs, die in jeder der Domänen ausgeführt werden, eine UVC-Abfrageanweisung aus, um unter anderem die für die Überlassung benötigte Speichermenge zu bestimmen. Wenn der Speicher überlassen worden ist, wird er als „Sicher“ gekennzeichnet und als der sicheren Schnittstellensteuerung zugehörig registriert; und ein Zugriff durch jede nicht sichere oder sichere Gast-Entität wird unterbunden. Dies bleibt bis zu dem Zeitpunkt der Fall, an dem die zugehörige Entität (z.B. die sichere Gast-CPU, sichere Gast-Domäne oder Zone) zerstört wird.
In einem Beispiel wird der erste Abschnitt von UV-Speicher zum Unterstützen der zonenspezifischen UV-Steuerblöcke der sicheren Schnittstellensteuerung als Teil des UVC „Initialisieren“ überlassen und wird in dem hierin als UV2 bezeichneten Speicher abgelegt. Der zweite und der dritte Abschnitt des UV-Speichers werden zum Unterstützen der Basis- und variablen Steuerblöcke für sichere Gast-Konfiguration (für jede sichere Gast-Domäne) als Teil des UVC „Sichere Gastkonfiguration erstellen“ (create-secure-guest-configuration UVC) überlassen und werden jeweils im UVS- und UVV-Speicher abgelegt. Der vierte und letzte Abschnitt des UV-Speichers wird zum Unterstützen der sicheren CPU-Steuerblöcke ebenfalls im UVS-Raum abgelegt und wird als Teil des UVC „Sichere Gast-CPU erstellen“ (create-secure-guest-CPU UVC) überlassen. Beim Überlassen jedes dieser Bereiche werden sie von der sicheren Schnittstellensteuerung als „Sicher“ gekennzeichnet (um zu verhindern, dass auf sie von einer nicht sicheren Entität zugegriffen wird), und sie werden auch in der Zonensicherheitstabelle als der sicheren Schnittstellensteuerung zugehörig registriert (um zu verhindern, dass auf sie von irgendwelchen sicheren Gast-Entitäten zugegriffen wird). Um eine weitere Isolation im UV-Raum bereitzustellen, wird auch der UV2-Raum (der keiner spezifischen sicheren Gast-Domäne zugehörig ist) mit einer eindeutigen sicheren UV2-Domäne markiert, während sowohl der UVS- als auch der UVV-Raum mit der zugehörigen spezifischen sicheren Gast-Domäne markiert werden. In diesem Beispiel befindet sich der UVV-Raum in virtuellem Host-Raum und kann daher ferner mit einer Zuordnung von virtuellem Host zu absolutem Host identifiziert werden.
Obwohl die sichere Schnittstellensteuerung auf sämtlichen Speicher Zugriff hat (nicht sicherer Speicher, sicherer Gast-Speicher und UV-Speicher), stellt bzw. stellen eine oder mehrere Ausführungsformen der vorliegenden Erfindung Mechanismen bereit, die es der sicheren Schnittstellensteuerung ermöglichen, sehr spezifisch auf den UV-Speicher zuzugreifen. Unter Verwendung derselben Hardware-Mechanismen, die eine Isolation zwischen sicheren Gast-Domänen bereitstellen, können Ausführungsformen der vorliegenden Erfindung eine ähnliche Isolation in dem UV-Speicher bereitstellen. Damit wird sichergestellt, dass die sichere Schnittstellensteuerung nur auf UV-Speicher zugreift, wenn dies beabsichtigt und spezifiziert ist; nur auf sicheren Gast-Speicher für den gewünschten spezifizierten sicheren Gast zugreift; und nur auf nicht sicheren Speicher zugreift, wenn dies spezifiziert ist. Das heißt, die sichere Schnittstellensteuerung kann sehr explizit den Speicher spezifizieren, auf den sie zuzugreifen beabsichtigt, sodass die Hardware sicherstellen kann, dass sie tatsächlich auf diesen Speicher zugreift. Außerdem kann sie ferner spezifizieren, dass sie beabsichtigt, nur auf den UV-Speicher zuzugreifen, der der spezifizierten sicheren Gast-Domäne zugehörig ist.
Dieser Ansatz stellt zusätzliche Sicherheit bereit, wenn die sichere Schnittstellensteuerung auf Speicher der sicheren Schnittstellensteuerung oder UV zugreift. Ein durch diesen Ansatz eingebrachter Nachteil ist jedoch, dass die relativ komplexe UV-Aufruf-Infrastruktur erforderlich ist, um den Schutz der UV-Arbeitsspeicher-Hardware zu testen. Um das Risiko eines Ausfalls der Hardware, der UV oder sicheren Schnittstellensteuerung zu vermindern, ist gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung die Speicherschutz-Hardware der Speicherschutz-Hardware des sicheren Gastes sehr ähnlich (und in manchen Fällen dieselbe). Dies ermöglicht, dass ein Großteil des Testens, das zum Überprüfen des Schutzes des sicheren Gast-Speichers ausgeführt wird, auch auf ein Testen der Schutz-Hardware für den sicheren UV-Speicher anwendbar ist. Um ein noch besseres Testen in Testumgebungen, die nicht die Software umfassen, die die vorausgesetzte UV-Aufruf-Infrastruktur bereitstellt, und in umfassenderen Testumgebungen zu ermöglichen, bevor die Infrastruktur verfügbar ist, wird ein AS-Debug-Modus definiert. Dieser alternative Modus ermöglicht, dass sichere Gast-Testfälle im Wesentlichen unverändert bleiben, wenn sie zum Ausführen des UV-Speicherschutzabschnitts der Hardware verwendet werden. Dieser alternative Modus kann anschließend für ein ausführlicheres Testen verwendet werden, bei dem die Testfälle zwischen sicherem Gast und AS-Debug-Modus umschalten und sicherstellen, dass zwischen beiden eine ausreichende Isolation besteht. Dieses Testen kann insgesamt unabhängig ohne Einschränkungen erfolgen, die eine einzelne Umsetzung erzwingen könnte.
Wenn der Hypervisor die sicheren Gast-Daten transparent einlagert und auslagert, stellt die sichere Schnittstellensteuerung, die mit der Hardware arbeitet, zum Bereitstellen von Sicherheit die Entschlüsselung und Verschlüsselung der Daten bereit und sicher. Zu diesem Zweck muss der Hypervisor beim Einlagern und Auslagern der sicheren Gast-Daten neue UVCs ausgeben. Die Hardware stellt auf Grundlage von Kontrollen sicher, die durch die sichere Schnittstellensteuerung während dieser neuen UVCs eingerichtet werden, dass diese UVCs tatsächlich durch den Hypervisor ausgegeben werden.
Bei jedem Auslagern einer sicheren Seite durch den Hypervisor muss er in dieser neuen sicheren Umgebung einen neuen UVC „Aus sicherem Speicher umwandeln“ (Export) (new convert from secure storage (export) UVC) ausgeben. In Reaktion auf diesen Export-UVC wird von der sicheren Schnittstellensteuerung 1) angegeben, dass die Seite durch die UV „gesperrt“ ist, 2) die Seite verschlüsselt wird, 3) die Seite auf „Nicht sicher“ festgelegt wird und 4) die UV-Sperre zurückgesetzt wird. Wenn der Export-UVC abgeschlossen ist, kann der Hypervisor ein Auslagern der verschlüsselten Gast-Seite vornehmen.
Bei jedem Einlagern einer sicheren Seite durch den Hypervisor muss er außerdem einen neuem UVC „In sicheren Speicher umwandeln“ (Import) (convert to secure storage (import) UVC) ausgeben. In Reaktion auf diesen Import-UVC kennzeichnet die UV oder sichere Schnittstellensteuerung 1) die Seite in der Hardware als „Sicher“, 2) gibt an, dass die Seite durch die UV „gesperrt“ ist, 3) entschlüsselt die Seite, 4) legt eine Berechtigung für eine bestimmte sichere Gast-Domäne fest und 5) setzt die UV-Sperre zurück. Bei jedem Zugriff durch eine sichere Entität führt die Hardware während einer Übersetzung an dieser Seite Berechtigungsüberprüfungen aus. Diese Überprüfungen umfassen 1) eine Überprüfung zum Sicherstellen, dass die Seite wirklich zu der sicheren Gast-Domäne gehört, auf die sie zuzugreifen versucht, und 2) eine Überprüfung zum Sicherstellen, dass der Hypervisor die Host-Zuordnung dieser Seite nicht geändert hat, während diese Seite im Gast-Arbeitsspeicher abgelegt war. Wenn eine Seite als „Sicher“ markiert ist, verhindert die Hardware den Zugriff auf jede sichere Seite entweder durch den Hypervisor oder durch eine nicht sichere Gast-VM. Die zusätzlichen Übersetzungsschritte verhindern den Zugriff durch eine weitere sichere VM und verhindern eine Neuzuordnung durch den Hypervisor.
Unter folgender Bezugnahme auf 1 wird allgemein eine Tabelle 100 für Zonensicherheit gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. Die in 1 gezeigte Zonensicherheitstabelle 100 wird durch die sichere Schnittstellensteuerung (im Speicher der sicheren Schnittstellensteuerung) verwaltet und von der sicheren Schnittstellensteuerung und der Hardware zum Sicherstellen von sicherem Zugriff auf jede Seite verwendet, auf die von einer sicheren Entität zugegriffen wird. Die Zonensicherheitstabelle 100 wird durch die absolute Host-Adresse 110 indexiert. Das heißt, dass es für jede Seite von absolutem Host-Speicher einen Eintrag gibt. Jeder Eintrag umfasst Informationen, die verwendet werden, um zu überprüfen, dass der Eintrag zu der sicheren Entität gehört, die den Zugriff vornimmt.
Wie ferner in 1 gezeigt, umfasst die Zonensicherheitstabelle 100 eine sichere Domänen-ID 120 (sie identifiziert die dieser Seite zugehörige sichere Domäne); ein UV-Bit 130 (es gibt an, dass diese Seite der sicheren Schnittstellensteuerung überlassen wurde und Eigentum der sicheren Schnittstellensteuerung ist); ein Adressenvergleich-Deaktivierungs-(DA) Bit 140 (es wird zum Deaktivieren des Host-Adressenpaarvergleichs unter bestimmten Umständen verwendet, wie zum Beispiel, wenn eine sichere Schnittstellensteuerungsseite, die als absoluter Host definiert ist, keine zugehörige virtuelle Host-Adresse hat); ein gemeinsam genutztes (SH) Bit 150 (es gibt an, dass die Seite gemeinsam mit dem nicht sicheren Hypervisor genutzt wird) und eine virtuelle Host-Adresse 160 (sie gibt die virtuelle Host-Adresse an, die für diese absolute Host-Adresse registriert ist, auf die als das Host-Adressenpaar verwiesen wird). Zu beachten ist, dass ein Host-Adressenpaar einen absoluten Host und eine zugehörige registrierte virtuelle Host-Adresse angibt. Das Host-Adressenpaar stellt die Zuordnung dieser Seite dar, nachdem sie durch den Hypervisor importiert worden ist, und der Vergleich stellt sicher, dass der Host diese Seite nicht neu zuordnet, während sie von dem Gast verwendet wird.
Die dynamische Adressübersetzung (DAT) wird zum Zuordnen von virtuellem Speicher zu realem Speicher verwendet. Wenn eine Gast-VM als ein ein/auslagerungsfähiger Gast unter der Steuerung eines Hypervisors ausgeführt wird, verwendet der Gast die DAT zum Verwalten von Seiten, die in seinem Arbeitsspeicher abgelegt sind. Außerdem verwendet der Host die DAT, um diese Gast-Seiten (zusammen mit seinen eigenen Seiten) unabhängig zu verwalten, wenn die Seiten in seinem Arbeitsspeicher abgelegt sind. Der Hypervisor verwendet die DAT zum Bereitstellen von Isolation und/oder gemeinsamen Nutzen von Speicher zwischen verschiedenen VMs sowie zum Verhindern eines Gast-Zugriffs auf Hypervisor-Speicher. Der Hypervisor hat Zugriff auf den gesamten Speicher der Gäste, wenn Gäste in einem nicht sicheren Modus ausgeführt werden.
Die DAT ermöglicht die Isolation einer Anwendung von einer anderen, gestattet aber immer noch, dass sie allgemeine Ressourcen gemeinsam nutzen. Außerdem gestattet sie die Umsetzung von VMs, was in der Auslegung und beim Testen von neuen Versionen von Betriebssystemen zusammen mit der Parallelverarbeitung von Anwendungsprogrammen verwendet werden kann. Eine virtuelle Adresse identifiziert einen Speicherort im virtuellen Speicher. Ein Adressraum ist eine zusammenhängende Abfolge von virtuellen Adressen zusammen mit den spezifischen Transformationsparametern (einschließlich DAT-Tabellen), die ermöglichen, dass jede virtuelle Adresse in eine zugehörige absolute Adresse übersetzt werden kann, die diese Adresse mit einem Byte-Speicherort im Speicher identifiziert.
Die DAT verwendet eine Lookup-Tabelle mit mehreren Tabellen, um die virtuelle Adresse in die zugehörige absolute Adresse zu übersetzen. Diese Tabellenstruktur wird in der Regel durch einen Speichermanager definiert und verwaltet. Dieser Speichermanager nutzt den absoluten Speicher in transparenter Weise gemeinsam zwischen mehreren Programmen, zum Beispiel durch Auslagern einer Seite, um eine weitere Seite einzuführen. Wenn die Seite ausgelagert wird, setzt der Speichermanager zum Beispiel ein ungültiges Bit in der zugehörigen Seitentabelle. Wenn ein Programm versucht, auf eine ausgelagerte Seite zuzugreifen, meldet die Hardware für den Speichermanager eine Programmunterbrechung, auf die oft als Seitenfehler verwiesen wird. In Reaktion darauf nimmt der Speichermanager ein Einlagern der angeforderten Seite vor und setzt das ungültige Bit zurück. Alles wird für das Programm transparent ausgeführt und ermöglicht dem Speichermanager, den Speicher zu virtualisieren und zwischen verschiedenen unterschiedlichen Benutzern gemeinsam zu nutzen.
Wenn eine virtuelle Adresse von einer CPU verwendet wird, um auf den Hauptspeicher zuzugreifen, wird sie zuerst mithilfe einer DAT in eine reale Adresse und anschließend mittels Voranstellen in eine absolute Adresse umgewandelt. Die Bezeichnung (Ursprung und Länge) der Tabelle höchster Ebene für einen spezifischen Adressraum wird als Adressraum-Kontrollelement (ASCE) (address-space-control element) bezeichnet und definiert den zugehörigen Adressraum.
Unter folgender Bezugnahme auf 2 werden allgemein virtuelle Adressräume 202 und 204 und ein absoluter Adressraum 206 zum Ausführen einer DAT gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. In dem in 2 gezeigten Beispiel sind zwei virtuelle Adressräume vorhanden: der virtuelle Adressraum 202 (definiert durch ein Adressraum-Kontrollelement (ASCE) A 208) und der virtuelle Adressraum 204 (definiert durch ASCE B 210). Virtuelle Seiten A1.V 212a1, A2.V 212a2 und A3.V 212a3 werden durch den Speichermanager in einer Lookup-Tabelle mit mehreren Tabellen (Segment 230 und Seitentabellen 232a, 232b) unter Verwendung von ASCE A 208 absoluten Seiten A1.A 2320a1, A2.A 2320a1 und A3.A 2320a1 zugeordnet. Auf ähnliche Weise werden virtuelle Seiten B1.V 214b1 und B2.V 214b2 in einer Lookup-Tabelle mit zwei Tabellen 234 und 236 unter Verwendung von ASCE B 210 jeweils absoluten Seiten B1.A 222b1 und B2.A 222b2 zugeordnet.
Unter folgender Bezugnahme auf 3 wird allgemein ein Beispiel für eine verschachtelte mehrteilige DAT-Übersetzung zum Unterstützen einer VM, die unter einem Hypervisor ausgeführt wird, gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. In dem in 3 gezeigten Beispiel befinden sich sowohl ein virtueller Adressraum eines Gastes A 302 (definiert durch das ASCE eines Gastes (GASCE) A 304) als auch ein virtueller Adressraum eines Gastes B 306 (definiert durch GASCEB 308) in einem gemeinsam genutzten virtuellen Adressraum 325 eines Hosts (Hypervisors). Wie gezeigt, werden virtuelle Seiten A1.GV 310a1, A2.GV 310a2 und A3.GV 310a3, die zum Gast A gehören, durch den Speichermanager des Gastes A unter Verwendung von GASCEA 304 jeweils absoluten Gast-Seiten A1.HV 340a1, A2.HV 340a2, und A3.HV 340a3 zugeordnet; die virtuellen Seiten B1.GV 320b1 und B2.GV 320b2, die zum Gast B gehören, werden unabhängig durch den Speichermanager des Gastes B unter Verwendung von GASCEB 308 jeweils absoluten Gast-Seiten B1.HV 360b1 und B2.HV 360b2 zugeordnet. In diesem Beispiel werden diese absoluten Gast-Seiten direkt in den gemeinsam genutzten virtuellen Host-Adressraum 325 zugeordnet und anschließend einer zusätzlichen Host-DAT-Übersetzung in einen absoluten Host-Adressraum 330 unterzogen. Wie gezeigt, werden virtuelle Host-Adressen A1.HV 340a1, A3.HV 340a3 und B1.HV 360b1 durch den Host-Speichermanager unter Verwendung eines Host-ASCE (HASCE) 350 zu A1.HA 370a1, A3.HA 370a3 und B1.HA 370b1 zugeordnet. Eine virtuelle Host-Adresse A2.HV 340a2, die zum Gast A gehört, und B2.HV 360b2, die zum Gast B gehört, werden beide derselben absoluten Host-Seite AB2.HA 380 zugeordnet. Damit wird eine gemeinsame Nutzung von Daten zwischen diesen beiden Gästen ermöglicht. Während der Gast-DAT-Übersetzung wird jede der Gast-Tabellenadressen als ein absoluter Gast behandelt und einer zusätzlichen verschachtelten Host-DAT-Übersetzung unterzogen.
Hierin beschriebene Ausführungsformen der vorliegenden Erfindung stellen einen sicheren Gast- und UV-Speicherschutz bereit. Der Zugriff auf sicheren Speicher durch nicht sichere Gäste und den Hypervisor wird unterbunden. Der Hypervisor sieht für eine bestimmte residente sichere Gast-Seite vor, dass Folgendes eintritt. Auf die zugehörige absolute Host-Adresse kann nur über eine einzelne Hypervisor- (Host-) DAT-Zuordnung zugegriffen werden. Das heißt, dass eine einzelne virtuelle Host-Adresse vorhanden ist, die jeder beliebigen absoluten Host-Adresse zugeordnet ist, die einem sicheren Gast zugewiesen ist. Die Hypervisor-DAT-Zuordnung (virtueller Host zu absolutem Host), die einer bestimmten sicheren Gast-Seite zugehörig ist, ändert sich beim Einlagern nicht. Die absolute Host-Seite, die einer sicheren Gast-Seite zugehörig ist, wird für einen einzelnen sicheren Gast zugeordnet.
Eine gemeinsame Nutzung von Speicher zwischen sicheren Gästen wird gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung ebenfalls unterbunden. Der Speicher wird zwischen einem einzelnen sicheren Gast und dem Hypervisor unter Kontrolle des sicheren Gastes gemeinsam genutzt. Der UV-Speicher ist ein sicherer Speicher und durch die sichere Schnittstellensteuerung zugreifbar, nicht jedoch die Gäste/Hosts. Der Speicher wird der sicheren Schnittstellensteuerung durch den Hypervisor zugewiesen. Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung wird jede versuchte Verletzung dieser Regeln durch die Hardware und sichere Schnittstellensteuerung unterbunden.
Unter folgender Bezugnahme auf 4 wird allgemein ein Beispiel für eine Zuordnung von sicherem Gast-Speicher gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. 4 ähnelt 3 mit Ausnahme dessen, dass das Beispiel von 4 keine gemeinsame Nutzung von Speicher zwischen dem sicheren Gast A und dem sicheren Gast B zulässt. In dem nicht sicheren Beispiel von 3 werden sowohl die virtuelle Host-Adresse A2.HV 340a2, die zum Gast A gehört, als auch B2.HV 360b2, die zum Gast B gehört, derselben absoluten Host-Seite AB2.HA 380 zugeordnet. In dem Beispiel für sicheren Gast-Speicher von 4 wird die virtuelle Host-Adresse A2.HV 340a2, die zum Gast A gehört, der absoluten Host-Adresse A2.HA 490a zugeordnet, wogegen B2.HV 360b2, die zum Gast B, gehört, ihrer eigenen B2.HA 490b zugeordnet wird. In diesem Beispiel ist keine gemeinsame Nutzung zwischen sicheren Gästen vorhanden.
Die sichere Gast-Seite wird verschlüsselt, während sie sich auf einer Festplatte befindet. Wenn der Hypervisor eine sichere Gast-Seite einlagert, gibt er einen UV-Aufruf (UVC) aus, der die sichere Schnittstellensteuerung veranlasst, die Seite als „Sicher“ zu markieren (es sei denn, sie wird gemeinsam genutzt), sie zu entschlüsseln (es sei denn, sie wird gemeinsam genutzt) und sie (in der Zonensicherheitstabelle) als dem entsprechenden sicheren Gast zugehörig (zum Beispiel Gast A) zu registrieren. Außerdem registriert er die zugehörige virtuelle Host-Adresse (zum Beispiel A3.HV 340a3) für diese absolute Host-Seite (auf die als Host-Adressenpaar verwiesen wird). Wenn es dem Hypervisor nicht gelingt, den korrekten UVC auszugeben, empfängt er eine Ausnahme, wenn er versucht, auf die sichere Gast-Seite zuzugreifen. Wenn der Hypervisor eine Gast-Seite auslagert, wird ein ähnlicher UVC ausgegeben, der die Gast-Seite verschlüsselt (es sei denn, sie wird gemeinsam genutzt), bevor die Gast-Seite als „Nicht sicher“ markiert und in der Zonensicherheitstabelle als „Nicht sicher“ registriert wird.
In einem Beispiel mit fünf vorgegebenen absoluten Host-Seiten K, P, L, M und N wird jede der absoluten Host-Seiten durch die sichere Schnittstellensteuerung als „Sicher“ markiert, wenn der Hypervisor sie einlagert. Dies hindert nicht sichere Gäste und den Hypervisor daran, auf sie zuzugreifen. Die absoluten Host-Seiten K, P und M werden als dem Gast A zugehörig registriert, wenn der Hypervisor sie einlagert; die absoluten Host-Seiten L und N werden für den Gast B registriert, wenn sie durch den Hypervisor eingelagert werden. Gemeinsam genutzte Seiten, Seiten, die zwischen einem einzelnen sicheren Gast und dem Hypervisor gemeinsam genutzt werden, werden während eines Einlagerns/Auslagerns weder verschlüsselt noch entschlüsselt. Sie werden nicht als „Sicher“ markiert (Zugriff durch den Hypervisor zulässig), sondern werden mit einer einzelnen sicheren Gast-Domäne in der Zonensicherheitstabelle registriert.
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung empfängt der Hypervisor eine Ausnahme für sicheren Speicherzugriff (PIC3D), wenn ein nicht sicherer Gast oder der Hypervisor versucht auf eine Seite zuzugreifen, die Eigentum eines sicheren Gastes ist. Für diese Bestimmung ist kein weiterer Übersetzungsschritt erforderlich.
Gemäß einer oder mehreren Ausführungsformen führt die Hardware, wenn eine sichere Entität auf eine Seite zuzugreifen versucht, eine zusätzliche Übersetzungsüberprüfung aus, die überprüft, dass der Speicher tatsächlich zu diesem bestimmten sicheren Gast gehört. Ist dies nicht der Fall, wird dem Hypervisor eine Ausnahme für nicht sicheren Zugriff (PIC3E) gemeldet. Wenn außerdem die virtuelle Host-Adresse, die übersetzt wird, nicht mit der virtuellen Host-Adresse aus dem registrierten Host-Adressenpaar in der Zonensicherheitstabelle übereinstimmt, wird eine Ausnahme für eine Verletzung des sicheren Speichers (,3F‘x) erkannt. Um eine gemeinsame Nutzung mit dem Hypervisor zu ermöglichen, kann ein sicherer Gast auf Speicher zugreifen, der nicht als „Sicher“ markiert ist, vorausgesetzt die Übersetzungsüberprüfungen lassen Zugriff zu.
Unter folgender Bezugnahme auf 5 wird allgemein ein Systemschemaplan 500 einer DAT-Operation gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. Der Systemschemaplan 500 umfasst einen primären virtuellen Host-Adressraum 510 und einen virtuellen Host-Home-Adressraum 520, aus denen Seiten in einen absoluten Hypervisor- (Host-) Adressraum 530 übersetzt werden (z.B. siehe Host-DAT-Übersetzung 525; zu beachten ist, dass die gepunkteten Linien eine Zuordnung durch die DAT-Übersetzung 525 darstellen). Zum Beispiel veranschaulicht 5 die gemeinsame Nutzung eines absoluten Host-Speichers durch zwei verschiedene virtuelle Host-Adressräume und auch die gemeinsame Nutzung von einer dieser virtuellen Host-Adressen nicht nur zwischen zwei Gästen, sondern außerdem mit dem Host selbst. In dieser Hinsicht sind der primäre virtuelle Host-Adressraum 510 und der virtuelle Host-Home-Adressraum 520 Beispiele für zwei virtuelle Host-Adressräume, von denen jeder durch ein separates ASCE, jeweils das primäre Host-ASCE (HPASCE) 591 und das Host-Home-ASCE (HHASCE) 592 adressiert wird. Zu beachten ist, dass der gesamte Speicher der sicheren Schnittstellensteuerung (sowohl virtuell als auch real) durch den Hypervisor überlassen und als „Sicher“ markiert wird. Nach dem Überlassen kann auf den Speicher der sicheren Schnittstellensteuerung nur von der sicheren Schnittstellensteuerung zugegriffen werden, solange eine zugehörige sichere Entität existiert.
Wie veranschaulicht, umfasst der primäre virtuelle Host-Adressraum 510 eine absolute Seite A1.HV des Gastes A, eine absolute Seite A2.HV des Gastes A, eine absolute Seite B1.HV des Gastes B und eine virtuelle Host-Seite H3.HV. Der virtuelle Host-Home-Adressraum 520 umfasst eine virtuelle Seite U1.HV der sicheren Schnittstellensteuerung, eine virtuelle Host-Seite H1.HV und eine virtuelle Host-Seite H2.HV.
Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung wird der gesamte sichere Gast-Speicher (z.B. des sicheren Gastes A und des sicheren Gastes B) in der hierin beschriebenen Zonensicherheitstabelle als einer sicheren Gast-Konfiguration zugehörig registriert, und die zugehörige virtuelle Host-Adresse (z.B. A1.HV, A2.HV, B1.HV) wird ebenfalls als Teil eines Host-Adressenpaars registriert. In einer oder mehreren Ausführungsformen wird der gesamte sichere Gast-Speicher in dem primären virtuellen Host-Adressraum zugeordnet. Außerdem wird der gesamte sichere Speicher der Schnittstellensteuerung auch in der Zonensicherheitstabelle als der sicheren Schnittstellensteuerung zugehörig registriert und kann des Weiteren in der Zonensicherheitstabelle auf Grundlage der zugehörigen sicheren Gast-Domäne differenziert werden. Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung wird der virtuelle UV-Speicher im virtuellen Host-Home-Adressraum zugeordnet, und die zugehörige virtuelle Host-Adresse wird als Teil des Host-Adressenpaars registriert. Gemäß einer oder mehreren Ausführungsformen weist der reale UV-Speicher keine zugehörige virtuelle Host-Zuordnung auf, und das DA-Bit in der Zonensicherheitstabelle (das angibt, dass der virtuelle Adressenvergleich deaktiviert ist) wird gesetzt, um dies anzugeben. Der Host-Speicher wird als „Nicht sicher“ markiert und wird auch in der Zonensicherheitstabelle als „Nicht sicher“ registriert.
In dem Fall, in dem ,absoluter Gast = virtueller Host‘ ist, übersetzen die primären Hypervisor- (Host-) DAT-Tabellen (definiert durch das HPASCE 591) somit die Seiten des primären virtuellen Host-Adressraums 510 wie folgt: die absolute Seite A1.HV des Gastes A wird einem absoluten Host A1.HA zugeordnet, der zum sicheren Gast A gehört; die absolute Seite A2.HV des Gastes A wird einem absoluten Host A2.HA zugeordnet, der zum sicheren Gast A gehört; die absolute Seite B1.HV des Gastes B wird einem absoluten Host B1.HA zugeordnet, der zum sicheren Gast B gehört; und die virtuelle Host-Seite H3.HV wird einer absoluten Host-Seite H3.HA eines nicht sicheren Hosts zugeordnet (und es gibt kein Host-Adressenpaar, da es nicht sicher ist). Ferner übersetzen die Hypervisor- (Host-) Home-DAT-Tabellen (definiert durch das HHASCE 592) die Seiten des virtuellen Host-Home-Adressraums 520 wie folgt: die virtuelle Seite der Schnittstellensteuerung U1.HV wird einer absoluten Host-Seite U1.HA zugeordnet, die als virtuelle sichere UV definiert ist; die virtuelle Host-Seite H1.HV wird einer absoluten Host-Seite H1.HA zugeordnet, die als „Nicht sicher“ definiert ist; und die virtuelle Host-Seite H2.HV wird einer absoluten Host-Seite H2.HA zugeordnet, die als „Nicht sicher“ definiert ist. Ein Host-Adressenpaar ist weder H1.HA noch H2.HA zugehörig, da sie nicht sicher sind.
Wenn ein sicherer Gast im Betrieb versucht, auf eine sichere Seite zuzugreifen, die der sicheren Schnittstellensteuerung zugewiesen ist, wird dem Hypervisor durch die Hardware eine Ausnahme für Verletzung von sicherem Speicher (‚3F‘X) gemeldet. Wenn ein nicht sicherer Gast oder der Hypervisor versucht, auf irgendeine sichere Seite (einschließlich denjenigen, die der sicheren Schnittstellensteuerung zugewiesen sind) zuzugreifen, wird dem Hypervisor durch die Hardware eine Ausnahme für Zugriff auf sicheren Speicher (‚3D‘X) gemeldet. Alternativ kann für versuchte Zugriffe auf einen sicheren Schnittstellensteuerungsraum eine Fehlerbedingung gemeldet werden. Wenn die Hardware eine fehlende Übereinstimmung in der sicheren Zuweisung bei einem Zugriff auf die sichere Schnittstellensteuerung erkennt (z.B. ist der Speicher in der Zonensicherheitstabelle als einem sicheren Gast statt der sicheren Schnittstellensteuerung zugehörig registriert, oder es liegt eine fehlende Übereinstimmung im Host-Adressenpaar vor, das für das registrierte Paar verwendet wird), wird eine Überprüfung angegeben.
Mit anderen Worten, der primäre virtuelle Host-Adressraum 510 umfasst die virtuellen Host-Seiten A1.HV und A2.HV (die zum sicheren Gast A gehören) und B1.HV (die zum sicheren Gast B gehört), die jeweils dem absoluten Host A1.HA, A2.HA und B1.HA zugeordnet sind. Außerdem umfasst der primäre virtuelle Adressraum 510 die Host-(Hypervisor-) Seite H3.HV, die dem absoluten Host H3.HA zugeordnet ist. Der virtuelle Host-Home-Adressraum 520 umfasst zwei virtuelle Host-Seiten H1.HV und H2.HV, die den absoluten Host-Seiten H1.HA und H2.HA zugeordnet sind. Sowohl der primäre virtuelle Host-Adressraum 510 als auch der virtuelle Host-Home-Adressraum 520 sind dem einzelnen absoluten Host 530 zugeordnet. Die dem sicheren Gast A und sicheren Gast B zugehörigen Speicherseiten werden als „Sicher“ markiert und in der in 1 gezeigten Zonensicherheitstabelle 100 mit ihren sicheren Domänen und zugehörigen virtuellen Host-Adressen registriert. Der Host-Speicher wird andererseits als „Nicht sicher“ markiert. Wenn der Hypervisor die sicheren Gäste definiert, muss er der sicheren Schnittstellensteuerung Host-Speicher überlassen, der für benötigte sichere Steuerblöcke zum Unterstützen dieser sicheren Gäste verwendet wird. Dieser Speicher kann entweder im absoluten Host- oder virtuellen Host-Adressraum und in einem Beispiel speziell im virtuellen Host-Home-Adressraum definiert werden. Unter erneuter Bezugnahme auf 5 sind die absoluten Host-Seiten U1.HA und U2.HA der sicheren absoluten UV ein Speicher der sicheren Schnittstellensteuerung, der als absoluter Host-Speicher definiert ist. Als Ergebnis dessen werden diese Seiten als „Sicher“ markiert und in der in 1 gezeigten Zonensicherheitstabelle 100 als der sicheren Schnittstellensteuerung zugehörig und mit einer zugehörigen sicheren Domäne registriert. Da die Seiten als absolute-Host-Adressen definiert sind, ist keine zugehörige virtuelle Host-Adresse vorhanden, sodass das DA-Bit in der Zonensicherheitstabelle 100 festgelegt wird.
Ein Beispiel für den absoluten Hypervisor- (Host-) Adressraum 530 nach der Übersetzung ist in 6 zu finden. Die 6, ein Systemschemaplan 600 in Bezug auf einen Arbeitsspeicher einer sicheren Schnittstellensteuerung, wird gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung dargestellt. Der Systemschemaplan 600 veranschaulicht einen absoluten Hypervisor- (Host-) Adressraum 630, der eine absolute Host-Seite A2.HA des sicheren Gastes A (für A2.HV); eine absolute Host-Seite B1.HA des sicheren Gastes B (für B1.HV); eine absolute nicht sichere Host-Seite H1.HA (Host); eine absolute nicht sichere Host-Seite H2.HA (Host); eine absolute Host-Seite U3.HA der sicheren realen UV (keine HV-Zuordnung); eine absolute Host-Seite U1.HA der sicheren virtuellen UV (für U1.HV); und eine absolute Host-Seite A1.HA für den sicheren Gast A (für A1.HV) umfasst.
Unter folgender Bezugnahme auf 7 wird allgemein ein Prozessablauf 700 für eine Importoperation gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. Wenn ein sicherer Gast auf eine Seite zugreift, die vom Hypervisor ausgelagert wurde, tritt eine Folge von Ereignissen wie diejenigen auf, die im Prozessablauf 700 gezeigt werden, um diese Seite wieder sicher einzulagern. Der Prozessablauf 700 beginnt an einem Block 705, in dem der sichere Gast auf die virtuelle Gast-Seite zugreift. Da die Seite zum Beispiel ungültig ist, meldet die Hardware einen Host-Seitenfehler, der dem Hypervisor durch einen Programmunterbrechungs-Code 11 (PIC11) angegeben wird (siehe Block 715). Der Hypervisor identifiziert seinerseits eine verfügbare nicht sichere absolute Host-Seite für diese Gast-Seite (siehe Block 720) und lagert die verschlüsselte Gast-Seite in die identifizierte absolute Host-Seite ein (siehe Block 725).
An einem Block 730 wird die absolute Host-Seite anschließend in den entsprechenden Host-DAT-Tabellen (auf Grundlage der virtuellen Host-Adresse) zugeordnet. An einem Block 735 teilt der Hypervisor-Host anschließend den sicheren Gast erneut zu. An einem Block 740 greift der sichere Gast erneut auf die sichere Gast-Seite zu. Der Seitenfehler ist nicht mehr vorhanden, aber da dies ein Zugriff eines sicheren Gastes ist, und die Seite in der Zonensicherheitstabelle 100 von 1 nicht als „Sicher“ markiert ist, meldet die Hardware an einem Block 745 eine Ausnahme für nicht sicheren Speicher (PIC3E) an den Hypervisor. Diese PIC3E verhindert Zugriff auf diese sichere Seite durch den Gast, bis der notwendige Import ausgegeben wurde. Als Nächstes fährt der Prozessablauf 700 mit „A“ fort, das mit 8 verbunden ist.
Unter folgender Bezugnahme auf 8 wird allgemein ein Prozessablauf 800 zum Ausführen einer Importoperation gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. Ein sich wohlverhaltender Hypervisor (der z.B. in erwarteter Weise ohne Fehler ausgeführt wird) gibt in Reaktion auf die PIC3E einen Import-UVC aus (siehe Block 805) An dieser Stelle ist zu beachten, dass eine zu importierende Seite als „Nicht sicher“ markiert wird und auf sie nur durch den Hypervisor, andere nicht sichere Entitäten und die sichere Schnittstellensteuerung zugegriffen werden kann. Auf sie kann von sicheren Gästen nicht zugegriffen werden.
Als Teil des Import-UVC überprüft die vertrauenswürdige Firmware, die als die sichere Schnittstellensteuerung agiert, ob diese Seite bereits durch die sichere Schnittstellensteuerung gesperrt worden ist (siehe Entscheidungsblock 810). Ist dies der Fall, fährt der Prozessablauf 800 mit einem Block 820 fort. Am Block 820 wird ein Rückgabe-Code „Belegt“ an den Hypervisor zurückgegeben, der in Reaktion darauf den Import-UVC verzögert (siehe Block 825) und erneut ausgibt (der Prozessablauf 800 kehrt zum Block 805 zurück). Wenn die Seite nicht bereits gesperrt ist, fährt der Prozessablauf 800 anschließend mit einem Entscheidungsblock 822 fort.
Am Entscheidungsblock 822 überprüft die sichere Schnittstellensteuerung, ob die Seite eine Seite ist, die gemeinsam mit dem nicht sicheren Hypervisor genutzt wird. Wenn sie gemeinsam genutzt wird (der Prozessablauf 800 fährt mit einem Entscheidungsblock 824 fort), registriert die sichere Schnittstellensteuerung die absolute Host-Adresse in der Zonensicherheitstabelle mit der zugehörigen sicheren Gast-Domäne, virtuellen Host-Adresse und als „Gemeinsam genutzt“. Diese Seite bleibt weiterhin als „Nicht sicher“ markiert. Damit ist der Import-UVC abgeschlossen, und die Seite steht nun für den Zugriff durch den Gast zur Verfügung. Die Verarbeitung wird damit fortgesetzt, dass der Hypervisor den Gast erneut zuteilt (Block 830) und der sichere Gast erfolgreich auf die Seite zugreift (Block 835).
Wenn die zu importierende virtuelle Host-Seite nicht gemeinsam mit dem Hypervisor genutzt wird (der Prozessablauf 800 fährt mit einem Block 840 fort), markiert die sichere Schnittstellensteuerung die Seite als „Sicher“, sodass der Hypervisor nicht mehr auf die Seite zugreifen kann. An einem Block 845 sperrt die sichere Schnittstellensteuerung die Seite, sodass kein anderer UVC den Seitenzustand modifizieren kann. Nachdem die Sperre gesetzt ist (an einem Block 850), überprüft die sichere Schnittstellensteuerung, dass sich die Inhalte der Gast-Seite während der Verschlüsselung nicht geändert haben. Wenn sie sich geändert haben, wird ein Fehler-Rückgabecode an den Hypervisor zurückgegeben, andernfalls entschlüsselt die sichere Schnittstellensteuerung die sichere Seite.
An einem Block 855 entsperrt die sichere Schnittstellensteuerung die Seite, lässt Zugriff durch andere UVCs zu, registriert die Seite in der Zonensicherheitstabelle als „Sicher“ und als der entsprechenden Gast-Domäne und virtuellen Host-Adresse zugehörig, um das Host-Adressenpaar HV->HA zu vervollständigen. Damit wird ein Zugriff durch den Gast zulässig und der UVC wird abgeschlossen.
Unter folgender Bezugnahme auf 9 wird allgemein ein Prozessablauf 900 in Bezug auf eine Operation für überlassenen Arbeitsspeicher gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. Der Prozessablauf 900 beginnt an einem Block 905, an dem ein Hypervisor einen Abfrage-UVC an die sichere Schnittstellensteuerung ausgibt. An einem Block 910 gibt die sichere Schnittstellensteuerung Daten zurück (z.B. Abfrage-UVC). Diese Daten können eine erforderliche Menge von grundlegendem zonenspezifischem absolutem Host-Speicher; eine erforderliche Menge von grundlegendem domänenspezifischem absolutem Host-Speicher eines sicheren Gastes; eine pro MB erforderliche Menge von variablem domänenspezifischem virtuellem Host-Speicher eines sicheren Gastes; und/oder eine erforderliche Menge von grundlegendem CPUspezifischem absolutem Host-Speicher eines sicheren Gastes umfassen.
An einem Block 915 reserviert der Hypervisor grundlegenden zonenspezifischen absoluten Host-Speicher (z.B. auf Grundlage einer von der Abfrage-UVC zurückgegebenen Größe). An einem Block 920 gibt der Hypervisor eine Initialisierung an die sichere Schnittstellensteuerung aus. In diesem Zusammenhang kann der Hypervisor einen UVC „Initialisieren“ ausgeben, der überlassenen Speicher für die UV-Steuerblöcke bereitstellt, die zum Koordinieren zwischen den sicheren Gast-Konfigurationen für die gesamte Zone benötigt werden. Der UVC „Initialisieren“ gibt eine grundlegende zonenspezifische Speicherherkunft an.
An einem Block 925 setzt die sichere Schnittstellensteuerung die Initialisierung um (z.B. UVC „Initialisieren“), indem ein der UV überlassener Speicher registriert und als „Sicher“ markiert wird. Für den UVC „Initialisieren“ kann die sichere Schnittstellensteuerung überlassenen Speicher als „Sicher“ markieren; einen Teil dieses überlassenen Speichers für die Zonensicherheitstabelle zuweisen; und den überlassenen Speicher in der Zonensicherheitstabelle zur UV-Verwendung mit einer eindeutigen sicheren Domäne registrieren, jedoch ohne zugehörige sichere Gast-Domäne und ohne zugehöriges virtuelles Host-Adressenpaar.
An einem Block 930 reserviert der Hypervisor Speicher (z.B. grundlegenden und variablen domänenspezifischen Speicher für sicheren Gast). Zum Beispiel reserviert der Hypervisor (z.B. auf Grundlage einer Größe von Speicher einer sicheren Gast-Domäne) grundlegenden und variablen domänenspezifischen Speicher für einen sicheren Gast (z.B. eine von dem Abfrage-UVC zurückgegebene Größe). An einem Block 935 gibt der Hypervisor ein „Konfiguration erstellen“ an die sichere Schnittstellensteuerung aus. In diesem Zusammenhang kann der Hypervisor einen UVC „Sichere Gast-Konfiguration erstellen“ (create-secure-guest-config UVC) ausgeben, der eine Herkunft von grundlegendem und variablem domänenspezifischem Speicher für eine sichere Gast-Domäne angibt. Ferner stellt der UVC „Sichere Gast-Konfiguration erstellen“ überlassenen Speicher für die UV-Steuerblöcke bereit, die zum Unterstützen dieser sicheren Gast-Konfiguration benötigt werden.
An einem Block 940 setzt die sichere Schnittstellensteuerung das „Konfiguration erstellen“ um (z.B. UVC „Sichere Gast-Konfiguration erstellen“). Für den UVC „Sichere Gast-Konfiguration erstellen“ kann die sichere Schnittstellensteuerung überlassenen Speicher als „Sicher“ markieren; den überlassenen Speicher in der Zonensicherheitstabelle zur UV-Verwendung registrieren; und den überlassenen Speicher mit der zugehörigen sicheren Gast-Domäne registrieren. Der überlassene grundlegende (absolute Host-) Speicher wird ohne zugehöriges virtuelles Host-Adressenpaar registriert. Der überlassene variable (virtuelle Host-) Speicher wird mit dem zugehörige virtuellen Host-Adressenpaar registriert.
An einem Block 945 reserviert der Hypervisor grundlegenden CPU-spezifischen Speicher eines sicheren Gastes (z.B. eine von der Abfrage-UV zurückgegebene Größe). An einem Block 950 spezifiziert der Hypervisor eine Speicherherkunft. Zum Beispiel gibt der Hypervisor an die UV „Sichere Gast-CPU erstellen“ aus, wodurch eine grundlegende CPUspezifische Speicherherkunft für einen sicheren Gast spezifiziert wird. An einem Block 955 setzt die sichere Schnittstellensteuerung das „CPU erstellen“ um (z.B. UVC „CPU für sicheren Gast erstellen“) (create-secure-guest-CPU UVC). Für den UVC „CPU für sicheren Gast erstellen“ kann die sichere Schnittstellensteuerung überlassenen Speicher als „Sicher“ markieren und überlassenen Speicher in der Zonensicherheitstabelle zur UV-Verwendung registrieren, jedoch ohne zugehörige sichere Gast-Domäne und ohne zugehöriges virtuelles Host-Adressenpaar.
Auf die (nicht sicheren) Hypervisor-Seiten A, B und C kann von einer nicht sicheren Entität aus (einschließlich des Hypervisors) zugegriffen werden. Ferner werden die (nicht sicheren) Hypervisor-Seiten A, B und C als „Nicht sicher“ (NS) markiert sowie in einer Zonensicherheitstabelle (z.B. die in 1 gezeigte Zonensicherheitstabelle 100) als „Nicht sicher“ und „Nicht gemeinsam genutzt“ registriert. An einem Pfeil 1005 wird ein UVC „Initialisieren“ ausgegeben, der die Gast-Seite A in eine reale Speicherseite 1010 der sicheren Schnittstellensteuerung überführt, die einer ganzen Zone (UV2) zugehörig ist. Der reale Speicher 1010 der sicheren Schnittstellensteuerung kann als „Sicher“ markiert sowie in einer Zonensicherheitstabelle (z.B. die Zonensicherheitstabelle 100, die in 1 gezeigt wird) als UV ohne sichere Gast-Domäne und ohne Zuordnung von Hypervisor zu absolutem Host (HV->HA) registriert werden. Stattdessen wird sie mit einer eindeutigen sicheren UV2-Domäne registriert, und das DA-Bit wird auf 1 gesetzt. Zu beachten ist, dass auf den realen Speicher 1010 der sicheren Schnittstellensteuerung durch die sichere Schnittstellensteuerung als „Real“ zugegriffen werden kann.
Von der (nicht sicheren) Hypervisor-Seite B aus wird an einem Pfeil 1025 ein UVC „SG-Konfiguration erstellen“ (create-SG-config) oder „SG-CPU erstellen“ (create-SG-CPU) ausgegeben, der diese Seite in einen realen Speicher 1030 einer sicheren Schnittstellensteuerung überführt, der einer sicheren Gast-Domäne (UVS) zugehörig ist. Der reale Speicher 1030 der sicheren Schnittstellensteuerung kann als „Sicher“ markiert sowie in einer Zonensicherheitstabelle (z.B. die in 1 gezeigte Zonensicherheitstabelle 100) als UV mit einer zugehörigen sicheren Gast-Domäne und ohne Zuordnung von Hypervisor zu absolutem Host (HV->HA) registriert werden (z.B. DA-Bit = 1). Zu beachten ist, dass auf den realen Speicher 1010 der sicheren Schnittstellensteuerung durch die sichere Schnittstellensteuerung als „Real“ für eine sichere Gast-Domäne zugegriffen werden kann.
Von der (nicht sicheren) Hypervisor-Seite C aus wird an einem Pfeil 1045 ein UVC „SG-Konfiguration erstellen“ ausgegeben, der diese Seite in einen virtuellen Speicher 1050 der sicheren Schnittstellensteuerung überführt, der einer sicheren Gast-Domäne (UVV) zugehörig ist. Der virtuelle Speicher 1050 der sicheren Schnittstellensteuerung kann als „Sicher“ markiert sowie in einer Zonensicherheitstabelle (z.B. die in 1 gezeigte Zonensicherheitstabelle 100) als UV mit einer sicheren Gast-Domäne und Zuordnung von Hypervisor zu absolutem Host (HV->HA) registriert werden. Zu beachten ist, dass auf den virtuellen Speicher 1050 der sicheren Schnittstellensteuerung als virtuelle UV für eine sichere Gast-Domäne zugegriffen werden kann.
Unter folgender Bezugnahme auf 11 wird ein Prozessablauf 1100 hinsichtlich eines sicheren Speicherzugriffs, der durch das Programm oder die sichere Schnittstellensteuerung vorgenommen wird, gemäß einer oder mehreren Ausführungsformen dargestellt. Damit wird die Situation dargestellt, in der die sichere Schnittstellensteuerung gerade auf Gast-Speicher oder Speicher der sicheren Schnittstellensteuerung zugreift und den Zugriff korrekt kennzeichnen muss, um der Hardware zu erlauben, die Sicherheit dieses Zugriffs zu überprüfen. 1100 beschreibt dieses Kennzeichnen von Speicherzugriffen durch die sichere Schnittstellensteuerung. Der Prozessablauf 1100 beginnt an einem Block 1110, an dem die sichere Schnittstellensteuerung bestimmt, ob sie auf einen Speicher einer sicheren Schnittstellensteuerung zugreift.
Wenn es sich nicht um einen Zugriff auf den Speicher der sicheren Schnittstellensteuerung handelt, fährt der Prozessablauf 1100 mit einem Entscheidungsblock 1112 fort (wie durch den NEIN-Pfeil gezeigt). Am Entscheidungsblock 1112 bestimmt die sichere Schnittstellensteuerung, ob auf einen sicheren Gast-Speicher zugegriffen wird. Wenn es sich nicht um einen Zugriff auf den sicheren Gast-Speicher handelt, fährt der Prozessablauf 1100 mit „B“ fort (das mit einem Prozessablauf 1200 von 12 verbunden ist), das die Standardeinstellung für nicht sichere Zugriffe verwendet. Wenn es sich hier um einen Zugriff auf den sicheren Gast-Speicher handelt, fährt der Prozessablauf 1100 anschließend mit einem Entscheidungsblock 1113 fort, in dem die sichere Schnittstellensteuerung bestimmt, ob eine standardmäßige sichere Gast-Domäne verwendet wird. Ist dies der Fall, fährt der Prozessablauf 1100 mit „B“ fort (das mit dem Prozessablauf 1200 von 12 verbunden ist), das die Standardeinstellung für sichere Gast-Zugriffe verwendet. Ist dies nicht der Fall, fährt der Prozessablauf 1100 mit einem Block 1114 fort. Am Block 1114 wird eine entsprechende sichere Gast-Domäne in ein SG-Register einer sicheren Domäne geladen (und fährt mit „B“ fort, das mit dem Prozessablauf 1200 von 12 verbunden ist).
Wenn es sich hier um einen Zugriff auf den Speicher der Schnittstellensteuerung handelt, fährt der Prozessablauf 1100 mit einem Block 1120 fort (wie durch den JA-Pfeil gezeigt). Am Block 1120 wird der Zugriff als sichere UV gekennzeichnet (z.B. wird das UV-Register der sicheren Domäne verwendet).
Der Prozessablauf 1100 fährt anschließend mit einem Entscheidungsblock 1130 fort, an dem die sichere Schnittstellensteuerung bestimmt, ob es sich um einen Zugriff auf einen UVV-Raum handelt (z.B. „SG-Konfigurationsvariablentabelle“) (SG-Config Variable Table). Wenn ein Zugriff auf einen UVV-Raum vorliegt, fährt der Prozessablauf 1100 mit einem Block 1134 fort (wie durch den JA-Pfeil gezeigt). Am Block 1134 wird der Zugriff als virtuell gekennzeichnet. An einem Block 1136 wird eine anwendbare sichere Gast-Domäne in das UV-Register der sicheren Domäne geladen. An einem Block 1138 sind DAT-Übersetzung und Zugriffsspeicher bereit zu beginnen. Wenn es sich bei erneuter Bezugnahme auf den Entscheidungsblock 1130 nicht um einen Zugriff auf einen UVV-Raum handelt, fährt der Prozessablauf 1100 mit einem Block 1140 fort (wie durch den NEIN-Pfeil gezeigt). Am Block 1140 wird der Zugriff als „Real“ gekennzeichnet.
An einem Entscheidungsblock 1150 bestimmt die sichere Schnittstellensteuerung, ob es sich hier um einen Zugriff auf einen UVS-Raum handelt (z.B. SG-Konfiguration oder CPU-Tabelle). Wenn es sich hier um einen Zugriff auf den UVS-Raum handelt, fährt der Prozessablauf 1100 mit dem Block 1136 fort (wie durch den JA-Pfeil gezeigt). Wenn es sich hier nicht um einen Zugriff auf den UVS-Raum handelt, fährt der Prozessablauf 1100 mit einem Block 1170 fort (wie durch den NEIN-Pfeil gezeigt). Dieser Zugriff wäre dann ein Zugriff auf einen UV2-Raum (z.B. eine Zonensicherheitstabelle). Am Block 1170 wird eine eindeutige sichere UV2-Domäne in das UV-Register der sicheren Domäne geladen.
12 stellt einen Prozessablauf 1200 gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung dar. Wenn ein Gast zugeteilt wird, kann SIE-Eingabe-Firmware für die Hardware angeben, dass ein Gast ausgeführt wird (z.B. Gast-Modus aktiv) und kann angeben, ob der Gast sicher ist. Wenn der Gast sicher ist, kann die zugehörige sichere Gast-Domäne in die Hardware geladen werden (z.B. in das SG-Register der sicheren Domäne). Wenn ein Programm auf einen Speicher zugreift, kann die Hardware den Zugriff auf Grundlage des aktuellen Zustands des Programms zum Zeitpunkt des Zugriffs kennzeichnen. 12 veranschaulicht ein Beispiel dieses Prozesses im Prozessablauf 1200. An einem Block 1205 kann die Hardware bestimmen, ob die Maschine aktuell im Gast-Modus ausgeführt wird, und wenn dies nicht der Fall ist, den Zugriff an einem Block 1210 als einen Host-Zugriff und an einem Block 1215 als einen nicht sicheren Zugriff kennzeichnen. Wenn die Maschine am Block 1205 im Gast-Modus ausgeführt wird, kann der Zugriff an einem Block 1220 als ein Gast-Zugriff gekennzeichnet werden und an einem Block 1225 ferner bestimmen, ob der aktuelle Gast ein sicherer Gast ist. Wenn der Gast nicht sicher ist, kann der Zugriff am Block 1215 als „Nicht sicher“ gekennzeichnet werden. Wenn der Gast sicher ist, kann die Hardware den Gast an einem Block 1230 als „Sicher“ kennzeichnen, wodurch der sichere Gast dem SG-Register der sicheren Domäne zugeordnet werden kann, das beim Zuteilen des sicheren Gastes geladen wurde. Sowohl für nicht sichere als auch sichere Gäste kann an einem Block 1235 ein DAT-Zustand überprüft werden. Der Zugriff kann an einem Block 1240 als „Real“ gekennzeichnet werden, wenn die DAT ausgeschaltet ist. Der Zugriff kann an einem Block 1245 als „Virtuell“ gekennzeichnet werden, wenn die DAT eingeschaltet ist. Wenn der Zugriff am Block 1240 bei ausgeschalteter DAT als „Real“ oder am Block 1245 bei eingeschalteter DAT als „Virtuell“ gekennzeichnet wird, ist die Hardware an einem Block 1250 bereit, mit der Übersetzung zu beginnen und auf Speicher zuzugreifen, wie ferner in 13 beschrieben wird.
13 stellt ein Beispiel für eine durch die Hardware ausgeführte Übersetzung dar, um sowohl sichere als auch nicht sichere Zugriffe in einem Prozessablauf 1300 gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung zu unterstützen. An einem Block 1305 kann die Hardware bestimmen, ob der Zugriff als eine Gast-Übersetzung gekennzeichnet ist, und wenn dies der Fall ist und der Zugriff an einem Block 1310 virtuell erfolgt, kann die Gast-DAT an einem Block 1315 ausgeführt werden. Während der Gast-DAT-Übersetzung können verschachtelte zwischengeschaltete Abrufe für Gast-DAT-Tabellen vorhanden sein. Die Tabellenabrufe können als „Real“ für den Gast und als „Sicher“ gekennzeichnet werden, wenn die ursprüngliche Übersetzung als „Sicher“ gekennzeichnet wurde. Die Tabellenabrufe können auch auf den Übersetzungsprozess des Prozessablaufs 1300 folgen. Nachdem die Gast-DAT am Block 1315 für einen Zugriff ausgeführt worden ist, der als virtueller Gast gekennzeichnet wurde, und am Block 1310 (virtuell = Nein) für jeden Zugriff als realer Gast gekennzeichnet worden ist, können an einem Block 1320 Gast-Präfix und Gast-Arbeitsspeicherversatz angewendet werden. Bei Abschluss des Gast-Übersetzungsprozesses kann die sich daraus ergebende Adresse als virtueller Host und als „Sicher“ gekennzeichnet werden, wenn die ursprüngliche Gast-Übersetzung an einem Block 1325 als „Sicher“ gekennzeichnet wurde. Der Prozess 1300 kann wie gezeigt für jeden Zugriff fortfahren, der als virtueller Host gekennzeichnet ist. Wenn der ursprüngliche Zugriff am Block 1305 ein Host-Zugriff (Gast = Nein) und an einem Block 1330 virtuell ist, kann die Host-DAT an einem Block 1335 ausgeführt werden. Host-Tabellenabrufe können am Block 1335 als „Nicht sicher“ markiert werden. Nachdem eine Host-DAT am Block 1335 ausgeführt worden ist, oder wenn der ursprüngliche Host-Zugriff am Block 1330 als „Real“ (virtuell = Nein) gekennzeichnet wurde, kann an einem Block 1340 ein Host-Präfix angewendet werden. Die sich daraus ergebende Adresse kann an einem Block 1345 eine absolute Host-Adresse sein.
14 stellt ein Beispiel für eine DAT-Übersetzung mit sicherem Speicherschutz dar, die durch die Hardware in einem Prozessablauf 1400 gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung ausgeführt werden kann. Wenn bei einer Fortsetzung von Block 1345 von 13 ein sicherer UV-Zugriff an einem Block 1405 identifiziert wird, kann die Hardware an einem Block 1410 überprüfen, ob der Speicher als sicherer UV-Speicher registriert ist, und wenn dies nicht der Fall ist, wird an einem Block 1415 ein Fehler gemeldet. Ein sicherer UV-Zugriff kann beim Zugreifen auf UV-Speicher durch die sichere Schnittstellensteuerung erfolgen. Wenn der Speicher am Block 1410 als sicherer UV-Speicher registriert ist, können Schutzüberprüfungen wie für jeden sicheren Zugriff weiter durchgeführt werden, mit Ausnahme dessen, dass das UV-Register der sicheren Domäne (eingerichtet durch die sichere Schnittstellensteuerung vor einem Zugriff auf eine sichere UV) als die spezifizierte sichere Domäne für die Domänenüberprüfung an einem Block 1420 verwendet werden kann, an dem die Verarbeitung fortgesetzt wird. Außerdem kann jede Verletzung, die für einen UV-Zugriff an einem Block 1425 erkannt wird (Eintrittspunkt D), an einem Block 1430 als ein Fehler statt eine Ausnahme für den Hypervisor an einem Block 1435 gemeldet werden, wie dies bei einer Verletzung eines sicheren Gastes am Block 1425 (sichere UV = Nein) erfolgt.
Für Zugriffe, die am Block 1405 nicht als sichere UV-Zugriffe gekennzeichnet sind, bestimmt die Hardware an einem Block 1440, ob der Zugriff ein sicherer Gast-Zugriff ist, und wenn dies nicht der Fall ist und die Seite an einem Block 1445 als „Sicher“ markiert ist, kann dem Hypervisor am Block 1435 eine Ausnahme gemeldet werden. Wenn der Zugriff andererseits am Block 1440 kein sicherer Gast-Zugriff und die Seite an einem Block 1445 nicht als „Sicher“ markiert ist, ist anschließend die Übersetzung an einem Block 1450 erfolgreich.
Wenn der Zugriff am Block 1440 ein sicherer Gast-Zugriff oder ein sicherer UV-Zugriff auf Speicher ist, der am Block 1410 als sicherer UV-Speicher registriert wurde, kann die Hardware am Block 1420 eine Prüfung vornehmen, um sicherzustellen, dass der Speicher für die sichere Entität registriert ist, die dem Zugriff zugehörig ist. Wenn es sich hier um einen sicheren UV-Zugriff handelt, kann die spezifizierte sichere Domäne aus dem UV-Register der sicheren Domäne erhalten werden (geladen von der sicheren Schnittstellensteuerung auf Grundlage von sicherem UV-Speicher, auf den zugegriffen wird), und für einen sicheren Gast-Zugriff wird die spezifizierte sichere Domäne von dem SG-Register der sicheren Domäne erhalten (geladen, wenn die sichere Entität zugeteilt wird). Wenn der Speicher, auf den zugegriffen wird, am Block 1420 nicht für die spezifizierte sichere Domäne registriert ist, wird für sichere UV-Zugriffe am Block 1425 ein Fehler am Block 1430 angegeben, und für sichere Gast-Zugriffe am Block 1425 (sichere UV = Nein) wird dem Hypervisor am Block 1435 eine Ausnahme gemeldet.
Für sichere Zugriffe auf Speicher am Block 1440 und Block 1410, die am Block 1420 für die spezifizierte sichere Domäne registriert sind, wenn die virtuelle Adressüberprüfung deaktiviert ist, d.h. das DA-Bit = 1 an einem Block 1455 und der Zugriff ist an einem Block 1460 real, ist die Übersetzung an einem Block 1450 abgeschlossen. Wenn am Block 1455 jedoch das DA-Bit = 1 ist, der Zugriff an einem Block 1460 aber virtuell ist (real = Nein), wird für sichere UV-Zugriffe am Block 1425 ein Fehler am Block 1430 angegeben, und für sichere Gast-Zugriffe am Block 1425 (sichere UV = Nein) wird dem Hypervisor am Block 1435 eine Ausnahme gemeldet. Wenn am Block 1455 das DA-Bit = 0 ist und der Zugriff an einem Block 1475 ein virtueller Zugriff ist, kann die Hardware bestimmen, ob die Zuordnung des Zugriffs von virtuellem Host zu absolutem Host mit derjenigen übereinstimmt, die für diese absolute-Host-Adresse an einem Block 1470 registriert wurde. Ist dies der Fall, wird die Übersetzung am Block 1450 erfolgreich abgeschlossen. Wenn die Zuordnung am Block 1470 nicht übereinstimmt, wird für sichere UV-Zugriffe am Block 1425 ein Fehler am Block 1430 angegeben, und für sichere Gast-Zugriffe am Block 1425 (sichere UV = Nein) wird dem Hypervisor am Block 1435 eine Ausnahme gemeldet. Wenn das DA-Bit = 0 ist und der Zugriff an einem Block 1475 ein realer Zugriff ist (virtuell = Nein), wird für sichere UV-Zugriffe am Block 1425 ein Fehler am Block 1430 angegeben, und für sichere Gast-Zugriffe am Block 1425 (sichere UV = Nein) wird dem Hypervisor am Block 1435 eine Ausnahme gemeldet; alternativ kann die Übersetzung am Block 1450 erfolgreich abgeschlossen werden. Jeder Zugriff durch das E/A-Subsystem an einem Block 1480 kann überprüfen, ob die Seite am Block 1445 als „Sicher“ markiert ist, und wenn die Seite sicher ist, kann dem Hypervisor am Block 1435 eine Ausnahme gemeldet werden; wenn die Seite nicht als „Sicher“ markiert ist, ist die Übersetzung am Block 1450 erfolgreich.
Verschiedene Überprüfungen von Speicherregistrierung und -zuordnung können gemeinsam über eine Zonensicherheitstabellen-Schnittstelle 1485 verwaltet werden. Zum Beispiel können die Blöcke 1410, 1420, 1455, 1470 und 1475 eine Schnittstelle mit einer Zonensicherheitstabelle bilden, die einer selben Zone zugehörig ist, um verschiedene Zugriffe zu verwalten.
15 bis 17 und der begleitende Text beschreiben ein Testen von Speicherschutz-Hardware gemäß Ausführungsformen der vorliegenden Erfindung. Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung, gezeigt in 15, wird ein internes sicheres Hilfs- (AS) Debug-Bit in der Hardware gesetzt, um anzugeben, dass die Testfälle im AS-Debug-Modus auszuführen sind. Außerdem wird in 17 eine Ausführungsform gezeigt, in der die Testfälle explizit spezifizieren, dass der Gast im AS-Modus ausgeführt wird. Im AS-Modus wird eine AS-Entität und zugehörige Hardware getestet. Wie hierin verwendet, verweist der Begriff „sichere Hilfs-“ oder „AS-Entität“ auf ein AS-Modus-Bit und den zugehörigen AS-Domänenwert, und der Begriff „sichere Gast-“ oder „SG-Entität“ verweist auf ein SG-Modus-Bit und den zugehörigen SG-Domänenwert. Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gibt ein vorhandener Testfall eine Anweisung „Interpretative Ausführung starten“ (SIE) (Start Interpretive Execution) aus, um einen sicheren Gast zuzuteilen. Wenn das AS-Debug-Bit ausgeschaltet ist, tritt die sichere Schnittstellensteuerung in den sicheren Gast-Modus als Teil einer SIE-Eingabe ein, und wenn das AS-Debug-Bit eingeschaltet ist, tritt die sichere Schnittstellensteuerung stattdessen in den AS-Debug-Modus ein. An dem vorhandenen Testfall ist keine Änderung erforderlich. In einer oder mehreren Ausführungsformen wird statt einer Verwendung des internen Hardware-AS-Debug-Bits (welches das sichere Gast-Modus-Bit in dem Zustandsdeskriptor als Angabe für den AS-Modus behandelt) ein unabhängiges AS-Modus-Feld, das nur zum Debuggen verwendet wird, in dem Zustandsdeskriptor definiert, wodurch ein leicht modifizierter Testfall angeben kann, dass sich der sichere Gast im AS-Debug-Modus befindet. In diesem Fall hat der Testfall die Fähigkeit, zwischen sicherem Gast-Modus und AS-Modus umzuschalten und kann die Isolation zwischen den beiden Speichertypen besser testen. Sowohl die AS-Entität als auch die SG-Entität sind in der Hardware vorhanden. Im AS-Debug-Modus (dargestellt in 15) ist nur die SG-Entität in dem Zustandsdeskriptor vorhanden, wird aber in die AS-Entität in der Hardware geladen. Wenn sie sich nicht im AS-Debug-Modus befinden, aber Unterstützung für spezielles AS-Modus-Testen bereitgestellt wird (dargestellt in 17), sind sowohl die AS-Entität (die in die Hardware der AS-Entität geladen ist) als auch die SG-Entität (die in die Hardware der SG-Entität geladen ist) in dem Zustandsdeskriptor vorhanden.
Wenn im sicheren Gast-Modus ein sicherer Gast zugeteilt wird, wird das SG-Modus-Bit in der Hardware gesetzt, um anzugeben, dass das sichere Gast-Domänen- (SG-Domäne) Register, das beim Zuteilen eines sicheren Gastes von der sicheren Schnittstellensteuerung aus dem Zustandsdeskriptor ebenfalls in die Hardware geladen wird, für Zugriffe als die sichere Domänen-ID verwendet werden soll. Auf das SG-Modus-Bit und das SG-Domänenregister kann als der sichere Gast-Entitätszustand eines sicheren Gastes verwiesen werden Dies steht im Gegensatz zum AS-Debug-Modus, in dem, wenn ein sicherer Gast zugeteilt wird, das AS-Modus-Bit (statt des SG-Modus-Bits) in der Hardware gesetzt wird, um anzugeben, dass das AS-Domänenregister, das beim Zuteilen eines sicheren Gastes von der sicheren Schnittstellensteuerung aus dem SG-Domänen-Feld in dem Zustandsdeskriptor in die Hardware geladen wird, für den Zugriff als die sichere Domänen-ID verwendet werden soll. Auf das AS-Modus-Bit und das AS-Domänenregister kann als der AS-Entitätszustand verwiesen werden Das SG-Domänen- und das AS-Domänen-Register sind in der Hardware vorhanden und unterscheiden sich voneinander. Die durch den Zugriff angegebene spezifizierte sichere Domänen-ID wird mit der sicheren Kennung der Domäne verglichen, die für die Seite registriert ist, auf die zugegriffen wird, um den autorisierten Zugriff auf die Seite zu überprüfen. Während einer normalen Operation eines sicheren Gastes im sicheren Gast-Modus wird die SG-Domäne (und zugehörige Hardware) für Speicherzugriffe verwendet. Die AS-Domäne (und zugehörige Hardware) kann nur durch die sichere Schnittstellensteuerung spezifiziert werden und wird dann nur in sehr eingeschränkten Situationen verwendet (z.B. während spezifischer UVC-Anweisungen nur beim Zugreifen auf UV-Speicher). Dieser neue Test-Modus ermöglicht ein umfangreicheres Testen von AS-Zugriffen in einer größeren Vielfalt von Situationen. Dies wird in 15 dargestellt.
Unter folgender Bezugnahme auf 15 wird allgemein ein Ablaufplan 1500 eines beispielhaften Verfahrens für einen Testfall, der als Hypervisor wirkt, zum Initiieren einer sicheren VM gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. 15 stellt eine Ausführungsform dar, in der ein Bit zum Angeben verwendet wird, ob der Host-Server, in dem der Hypervisor ausgeführt wird, sich in dem AS-Debug-Modus befindet Wie in dem beispielhaften Verfahren von FIG, 15 gezeigt, wird ein Zustandsdeskriptor (SD) als ein Operand einer SIE-Anweisung an einem Block 1505 erstellt. Der SD umfasst Felder, die den zu emulierenden Hardware-Zustand auf dem bzw. den Prozessoren definieren, der bzw. die der sicheren VM zugewiesen sind.
Unter folgender Bezugnahme auf 16 wird allgemein eine beispielhafte Struktur eines SD 1600 gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. In einem oder mehreren Beispielen wird dasselbe SD-Format sowohl für sichere als auch nicht sichere VMs verwendet. Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung umfasst der SD 1600 ein Feld „Moduskontrolle“ 1602, das zum Angeben verwendet wird, ob die VM, die zugeteilt wird, sicher oder nicht sicher ist. Das Feld „Moduskontrolle“ 1602 kann in einem oder mehreren Beispielen ein Bit sein. Wenn das Feld „Moduskontrolle“ 1602 ferner angibt, dass der SD 1600 für eine sichere VM ist, stellt eine eindeutige Identifizierungskennung 1604 eine sichere Gast-Domänen-ID für die spezielle sichere VM bereit, die gerade zugeteilt wird. Für eine nicht sichere VM wird die eindeutige Identifizierungskennung 1604 nicht verwendet und kann einen Standardwert wie beispielsweise 0 umfassen (oder jeden anderen Wert, der angibt, dass das Feld nicht verwendet wird). Wie in 16 gezeigt, umfasst der SD 1600 auch ein oder mehrere SD-Felder 1606 zum Definieren des Gast-Zustands.
Unter erneuter Bezugnahme auf 15 gibt der Hypervisor die SIE-Anweisung mit dem SD 1600 als Operanden aus, wobei die Ausführung der Anweisung von der sicheren Schnittstellensteuerung vorgenommen wird. Die SIE-Anweisung wird zum Initiieren einer VM und zum Zuweisen von einem bzw. mehreren Prozessoren und anderen Ressourcen zu der VM verwendet. An einem Block 510 bestimmt die sichere Schnittstellensteuerung, ob die zuzuteilende VM auf Grundlage des Felds „Moduskontrolle“ 1602 in dem SD 600 sicher ist. Wenn eine nicht sichere VM zugeteilt werden soll, fährt die Verarbeitung mit einem Zuteilen einer nicht sicheren VM an einem Block 1515 fort.
Wenn an einem Block 1510 bestimmt wird, dass eine sichere VM zugeteilt werden soll, fährt die Verarbeitung an einem Block 1520 damit fort, dass die sichere Schnittstellensteuerung die Richtigkeit des Zustands validiert. An einem Block 1540 wird bestimmt, ob sich das System im AS-Debug-Modus befindet. Wenn sich das System im AS-Debug-Modus befindet, fährt die Verarbeitung an einem Block 1535 damit fort, dass die sichere Schnittstellensteuerung ein AS-Modus-Bit in der Hardware setzt (um die Datenverarbeitungsressourcen als der VM in einem AS-Debug-Modus zugewiesen zu konfigurieren). Die Verarbeitung fährt an einem Block 1545 damit fort, dass die sichere Schnittstellensteuerung die sichere Gast-Domänen-ID 1604 aus dem SD 1600 in das AS-Domänenregister lädt. Die Verarbeitung wird an einem Block 1550 fortgesetzt.
Wenn am Block 1540 bestimmt wird, dass sich das System nicht im AS-Debug-Modus befindet, fährt die Verarbeitung an einem Block 1525 damit fort, dass die sichere Schnittstellensteuerung ein SG-Modus-Bit in der Hardware setzt, um die Datenverarbeitungsressourcen als der VM in einem sicheren Gast-Modus zugewiesen zu konfigurieren. An einem Block 1530 wird die sichere Gast-Domänen-ID 1604 in das SG-Domänenregister geladen. Die Verarbeitung wird am Block 1550 fortgesetzt.
Im Block 1550 wird der Gast-Zustand aus den SD-Feldern 1606 in die Hardware geladen. Die zugeteilte VM wird dann ausgeführt, 1560, bis eine Beendigungsbedingung erreicht ist, 1565. Die Beendigungsbedingung kann eine Anweisungs- oder Abbruchinterpretation, eine Benutzeranforderung, die VM zu verlassen und dergleichen umfassen.
Unter folgender Bezugnahme auf 17 wird allgemein ein Ablaufplan 1700 eines beispielhaften Verfahrens für einen Testfall, der als Hypervisor wirkt, zum Initiieren einer sicheren VM gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. 17 stellt eine Ausführungsform dar, in der ein Bit in dem Zustandsdeskriptor zum Angeben verwendet wird, ob sich die sichere VM in dem AS-Modus befindet. In der in 17 gezeigten Ausführungsform kann sich die sichere VM auch in einem doppelten sicheren Modus befinden, der sowohl den AS-Modus als auch den SG-Modus umfasst. Wie in dem beispielhaften Verfahren von 17 gezeigt, wird ein SD als ein Operand einer SIE-Anweisung an einem Block 1705 erstellt. Der SD, wie beispielsweise der SD 1600 von 16, umfasst Felder, die den zu emulierenden Hardware-Zustand auf dem bzw. den Prozessoren definieren, der bzw. die der sicheren VM zugewiesen sind. Unter erneuter Bezugnahme auf 16 umfasst das Feld „Moduskontrolle“ 1602 in einer Ausführungsform zwei Bits, eines zum Angeben von sicherem Gast-Modus und das andere zum Angeben des sicheren Hilfs-Modus. Diese Bits können in jeder der vier möglichen Kombinationen spezifiziert werden: beide Bits ausgeschaltet, um eine nicht sichere VM anzugeben, ein einzelnes Bit eingeschaltet, um entweder sicheren Gast-Modus oder AS-Modus anzugeben, oder beide Bits eingeschaltet, um „doppelt sicheren“ Modus anzugeben (d.h. sowohl sicherer Gast- als auch AS-Modus). In diesem Fall wären zwei eindeutige Identifizierungskennungen 1604 vorhanden, eine, die die sichere Gast-Domäne darstellt (sie wird verwendet, wenn der sichere Gast-Modus spezifiziert ist) und die andere, die die AS-Domäne darstellt (sie wird verwendet, wenn der sichere Hilfs-Modus spezifiziert ist).
Unter erneuter Bezugnahme auf 17 gibt der Hypervisor die SIE-Anweisung mit dem SD als Operanden aus, wobei die Ausführung der Anweisung von der sicheren Schnittstellensteuerung vorgenommen wird. Die SIE-Anweisung wird zum Initiieren einer VM und zum Zuweisen von einem bzw. mehreren Prozessoren und anderen Ressourcen zu der VM verwendet. An einem Block 1710 bestimmt die sichere Schnittstellensteuerung, ob die VM sicher ist, die zugeteilt werden soll. Wenn eine nicht sichere VM zugeteilt werden soll, fährt die Verarbeitung mit einem Zuteilen einer nicht sicheren VM an einem Block 1715 fort.
Wenn am Block 1710 bestimmt wird, dass eine sichere VM zugeteilt werden soll, fährt die Verarbeitung an einem Block 1720 damit fort, dass die sichere Schnittstellensteuerung die Richtigkeit des Zustands der VM validiert. An einem Block 1740 wird bestimmt, ob sich die sichere VM im sicheren Hilfs- (AS) Modus befindet (z.B. auf Grundlage von Bits in dem SD der sicheren VM). Wenn sich die sichere VM nicht im AS-Modus befindet, fährt die Verarbeitung an einem Block 1748 fort. Wenn sich andererseits die sichere VM im AS-Modus befindet, fährt die Verarbeitung an einem Block 1735 damit fort, dass die sichere Schnittstellensteuerung ein AS-Modus-Bit in der Hardware setzt (um die Datenverarbeitungsressourcen als der VM in einem AS-Modus zugewiesen zu konfigurieren). Die Verarbeitung fährt an einem Block 1745 damit fort, dass die sichere Schnittstellensteuerung die sichere Gast-Domänen-ID der sicheren VM aus dem SD in das AS-Domänenregister lädt. Die Verarbeitung wird an einem Block 1748 fortgesetzt.
Am Block 1748 wird bestimmt, ob sich die sichere VM im sicheren Gast- (SG) Modus befindet. Wenn sich die sichere VM nicht im SG-Modus befindet, fährt die Verarbeitung an einem Block 1750 fort. Wenn sich andererseits die sichere VM im SG-Modus befindet, fährt die Verarbeitung an einem Block 1725 damit fort, dass die sichere Schnittstellensteuerung das SG-Modus-Bit in der Hardware setzt, um die Datenverarbeitungsressourcen als der VM in einem sicheren Gast-Modus zugewiesen zu konfigurieren. An einem Block 1730 wird die sichere Gast-Domänen-ID der sicheren VM in das SG-Domänenregister geladen. Die Verarbeitung wird am Block 1750 fortgesetzt.
Am Block 1750 wird der Gast-Zustand aus den SD-Feldern des SD in die Hardware geladen. Die zugeteilte VM wird dann ausgeführt, 1760, bis eine Beendigungsbedingung erreicht ist, 1765. Die Beendigungsbedingung kann eine Anweisungs- oder Abbruchinterpretation, eine Benutzeranforderung, die VM zu verlassen und dergleichen umfassen.
Obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud Computing enthält, sollte klar sein, dass die Umsetzung der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist. Stattdessen können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jedem beliebigen Typ von jetzt bekannter oder später entwickelter Datenverarbeitungsumgebung umgesetzt werden.
Cloud Computing ist ein Dienstbereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Arbeitsspeicher, Speicher, Anwendungen, VMs und Dienste), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften, mindestens drei Dienstmodelle und mindestens vier Nutzungsmodelle umfassen.
Die Eigenschaften sind wie folgt:

On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter des Dienstes erforderlich ist.

Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
Resource-Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells 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: 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: 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). Der Ressourcen-Verbrauch kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.
Die Dienstmodelle sind wie folgt:
Software as a Service (SaaS): Die für den Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur ausgeführten Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. eine auf dem Web beruhende eMail) von verschiedenen Client-Einheiten her 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 Anwendungskonfigurationseinstellungen.
Platform as a Service (PaaS): 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 Tools 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 des Application Hosting Environment.
Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Funktion besteht darin, Verarbeitung, 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 eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
Die Nutzungsmodelle sind wie folgt:
Private Cloud: Die Cloud-Infrastruktur wird ausschließlich für eine Organisation betrieben. Sie kann von der Organisation oder einer Drittpartei verwaltet werden und kann innerhalb oder außerhalb von Geschäftsräumen vorhanden sein.
Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine bestimmte Community, die gemeinsame Problemstellungen hat (z.B. Berücksichtigung von Zielsetzung, Sicherheitsanforderungen, Richtlinien und Konformität). Sie kann von den Organisationen oder einer Drittpartei verwaltet werden und kann innerhalb oder außerhalb der Geschäftsräume vorhanden sein.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und gehört einer Organisation, die Cloud-Dienste verkauft.
Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die eine Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastausgleich zwischen Clouds).
Eine Cloud-Computing-Umgebung ist dienstorientiert, wobei der Schwerpunkt auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität liegt. Im Mittelpunkt von Cloud Computing steht eine Infrastruktur, die ein Netzwerk von miteinander verbundenen Knoten enthält.
Unter folgender Bezugnahme auf 18 wird eine veranschaulichende Cloud-Computing-Umgebung 50 dargestellt. Wie gezeigt, enthält die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10, mit denen lokale Datenverarbeitungseinheiten, die von Nutzern der Cloud verwendet werden, wie beispielsweise Personal Digital Assistant (PDA) oder Mobiltelefon 54A, Desktop-Computer 54B, Laptop-Computer 54C und/oder Fahrzeug-Computersystem 54N, Daten austauschen können. Die Knoten 10 können untereinander Daten austauschen. Sie können physisch oder virtuell in einem oder mehreren Netzwerken gruppiert sein (nicht gezeigt), wie beispielsweise Private, Community, Public oder Hybrid Cloud, wie hierin oben beschrieben, oder in einer Kombination davon. Damit hat die Cloud-Computing-Umgebung 50 die Möglichkeit, eine Infrastruktur, Plattformen und/oder Software als Dienste anzubieten, für die ein Cloud-Nutzer keinerlei Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sollte klar sein, dass die in 18 gezeigten Typen von Datenverarbeitungseinheiten 54A bis N nur zur Veranschaulichung dienen sollen, und dass die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 mit jedem Typ einer computerisierten Einheit über jeden Typ von Netzwerk und/oder eine über ein Netzwerk adressierbare Verbindung (z.B. unter Verwendung eines Web-Browsers) Daten austauschen können.
Unter folgender Bezugnahme auf 19 wird ein Satz von funktionalen Abstraktionsschichten gezeigt, die von der Cloud Computing-Umgebung 50 (18) bereitgestellt werden. Dabei sollte von Anfang an klar sein, dass die in 19 gezeigten Komponenten, Schichten und Funktionen lediglich zur Veranschaulichung dienen sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie dargestellt, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
Eine Hardware- und Software-Schicht 60 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten zählen: Mainframes 61; Server auf Grundlage einer RISC- (Reduced Instruction Set Computer) Architektur 62; Server 63; Blade-Server 64; Speichereinheiten 65; und Netzwerke und vernetzte Komponenten 66. In einigen Ausführungsformen enthalten Software-Komponenten Software für Netzwerkanwendungsserver 67 und Datenbank-Software 68.
Eine Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, von der aus die folgenden beispielhaften virtuellen Entitäten bereitgestellt werden können: virtuelle Server 71; virtueller Speicher 72; virtuelle Netzwerke 73, einschließlich virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
In einem Beispiel kann eine Verwaltungsschicht 80 die im Folgenden beschriebenen Funktionen bereitstellen. Eine Ressourcenbereitstellung 81 sorgt für eine dynamische Beschaffung von Datenverarbeitungsressourcen und weiteren Ressourcen, die zum Ausführen von Aufgaben innerhalb der Cloud-Computing-Umgebung eingesetzt werden. Messung und Preisbestimmung 82 ermöglichen beim Einsatz von Ressourcen innerhalb der Cloud-Computing-Umgebung eine Kostenverfolgung und eine Abrechnung oder Rechnungsstellung für die Inanspruchnahme dieser Ressourcen. In einem Beispiel können diese Ressourcen Lizenzen für Anwendungssoftware umfassen. Eine Sicherheitsfunktion stellt eine Identitätsprüfung für Cloud-Nutzer und -Aufgaben sowie einen Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 83 stellt den Zugang zur Cloud-Computing-Umgebung für Nutzer und Systemadministratoren bereit. Eine Service-Level- (Dienstgüte) Verwaltung 84 sorgt für Zuweisung und Verwaltung von Cloud-Computing-Ressourcen, sodass erforderliche Service-Levels eingehalten werden. Planung und Vertragserfüllung des Service Level Agreement (SLA) (Dienstgütevereinbarung) 85 stellen eine Vorab-Vereinbarung für und Beschaffung von Cloud-Computing-Ressourcen bereit, für die gemäß eines SLA eine zukünftige Anforderung erwartet wird.
Eine Arbeitslastschicht 90 stellt Beispiele für eine Funktionalität bereit, für welche die Cloud-Computing-Umgebung genutzt werden kann. Zu Beispielen von Arbeitslasten und Funktionen, die von dieser Schicht aus bereitgestellt werden können, zählen: Zuordnung und Navigation 91; Software-Entwicklung und Lifecycle-Management 92; Bereitstellung von virtuellen Schulungen 93; Datenanalyseverarbeitung 94; Transaktionsverarbeitung 95; und Kontrollieren des Zugriffs auf einen sicheren Speicher einer virtuellen Maschine 96. Es sollte klar sein, dass es sich hier nur um einige Beispiele handelt, und dass die Schichten in anderen Ausführungsformen verschiedene Dienste enthalten können.
Unter folgender Bezugnahme auf 20 wird ein System 2000 gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung dargestellt. Das System 2000 umfasst einen Beispielknoten 10 (z.B. einen Host-Knoten), der in direktem oder indirekten Datenaustausch mit einer oder mehreren Client-Einheiten 20A bis 20E steht, wie zum Beispiel über ein Netzwerk 165. Der Knoten 10 kann ein Rechenzentrum oder ein Host-Server eines Cloud-Computing-Anbieters sein. Der Knoten 10 führt einen Hypervisor 12 aus, der den Einsatz von einer oder mehreren VMs 15 (15A bis 15N) ermöglicht. Der Knoten 10 umfasst ferner eine Hardware/Firmware-Schicht 11, die eine direkte Unterstützung für Funktionen bereitstellt, die für die VMs 15A bis 15N und einen Hypervisor 12 erforderlich sind, und dem Hypervisor 12 außerdem ermöglicht, einen oder mehrere Dienste für die VMs 15 bereitzustellen. In gegenwärtigen Umsetzungen wird ein Datenaustausch zwischen der Hardware/Firmware-Schicht 11 und dem Hypervisor 12, zwischen der Hardware/Firmware-Schicht 11 und den VMs 15, zwischen dem Hypervisor 12 und den VMs 15 und zwischen dem Hypervisor 12 und den VMs 15 über die Hardware/Firmware-Schicht 11 bereitgestellt. Gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung wird eine sichere Schnittstellensteuerung in der Hardware/Firmware-Schicht 11 bereitgestellt, und der direkte Datenaustausch zwischen dem Hypervisor 12 und den VMs 15 wird ausgeschlossen.
Zum Beispiel kann der Knoten 10 einer Client-Einheit 20A die Verwendung von einer oder mehreren der VMs 15A bis 15N ermöglichen. Die VMs 15A bis 15N können in Reaktion auf jeweilige Anforderungen von verschiedenen Client-Einheiten 20A bis 20E verwendet werden. Zum Beispiel kann die VM 15A von der Client-Einheit 20A verwendet werden, die VM 15B kann von der Client-Einheit 20B verwendet werden, und die VM 15C kann von der Client-Einheit 20C verwendet werden. Der Knoten 10 kann einem Client auch ein Bereitstellen eines physischen Servers ermöglichen (ohne als eine VM ausgeführt zu werden). Die hierin beschriebenen Beispiele verkörpern die Bereitstellung von Ressourcen in dem Knoten 10 als Teil einer VM, 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 20E zu derselben Entität gehören, wie zum Beispiel eine Person, ein Geschäft, eine Regierungsbehörde, eine Abteilung in einer Firma oder eine beliebige andere Entität, und der Knoten 10 kann als private Cloud der Entität ausgeführt werden. In diesem Fall hostet der Knoten 10 nur die VMs 15A bis 15N, die von den Client-Einheiten 20A bis 20E verwendet werden, die zu der Entität gehören. In einem weiteren Beispiel können die Client-Einheiten 20A bis 20E zu verschiedenen Entitäten gehören. Zum Beispiel kann eine erste Entität die Client-Einheit 20A besitzen, während eine zweite Entität die Client-Einheit 20B besitzen kann. In diesem Fall kann der Knoten 10 als eine öffentliche Cloud ausgeführt werden, die VMs von verschiedenen Entitäten hostet. Zum Beispiel können die VMs 15A bis 15N in verschleierter Weise verwendet werden, in der die VM 15A den Zugriff auf VM 15B nicht ermöglicht. Zum Beispiel kann der Knoten 10 die VMs 15A bis 15N unter Verwenden einer Funktion „Logische Partition“ (LPAR) eines IBM z Systems^® Processor Resource/Systems Manager (PR/SM) verschleiern. Diese Funktionen, wie zum Beispiel PR/SM LPAR, stellen eine Isolation zwischen Partitionen bereit, und ermöglichen dem Knoten 10 damit, zwei oder mehrere VMs 15A bis 15N für verschiedene Entitäten auf demselben physischen Knoten 10 in verschiedenen logischen Partitionen zu verwenden. Der PR/SM-LPAR-Hypervisor wird in vertrauenswürdiger interner Firmware mit spezieller Hardware umgesetzt, um diese Isolation bereitzustellen.
Eine Client-Einheit 20A von den Client-Einheiten 20A bis 20E ist eine Datenübertragungsvorrichtung wie zum Beispiel ein Computer, ein Smartphone, ein Tablet-Computer, ein Desktop-Computer, ein Laptop-Computer, ein Server-Computer oder jede andere Datenübertragungsvorrichtung, die einen Einsatz einer VM durch den Hypervisor 12 des Knotens 10 erfordert. Die Client-Einheit 20A kann eine Anforderung für ein Empfangen durch den Hypervisor über das Netzwerk 165 senden. Eine VM 15A von den VMs 15A bis 15N ist eine VM-Abbildung, die der Hypervisor 12 in Reaktion auf eine Anforderung von der Client-Einheit 20A von den Client-Einheiten 20A bis 20E verwendet. Der Hypervisor 12 ist ein VM-Monitor (VMM), der Software, Firmware oder Hardware sein kann, die VMs erstellt und ausführt. Der Hypervisor 12 ermöglicht es der VM 15A, die Hardware-Komponenten des Knotens 10 zum Ausführen von Programmen und/oder Speichern von Daten zu verwenden. Mit den entsprechenden Merkmalen und Modifizierungen kann der Hypervisor 12 IBM z Systems^®, ein VM-Server von Oracle, ein XenServer von Citrix, ESX von VMware, Hyper-V-Hypervisor von Microsoft oder jeder andere Hypervisor sein. Der Hypervisor 12 kann ein nativer Hypervisor sein, der direkt auf dem Knoten 10 ausgeführt wird, oder ein gehosteter Hypervisor sein, der auf einem weiteren Hypervisor ausgeführt wird.
Unter folgender Bezugnahme auf 21 wird ein Knoten 10 zum Umsetzen der Lehren hierin gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung gezeigt. Der Knoten 10 kann ein elektronisches Computer-Framework sein, das unter Einsatz von verschiedenen Datenübertragungstechnologien eine beliebige Anzahl und Kombination von Datenverarbeitungseinheiten und Netzwerken aufweist und/oder verwendet, wie hierin beschrieben. Der Knoten 10 ist problemlos skalierbar, erweiterbar und ist modular mit der Fähigkeit, zu verschiedenen Diensten zu wechseln oder einige Funktionen unabhängig von anderen neu zu konfigurieren.
In dieser Ausführungsform hat der Knoten 10 einen Prozessor 2101, der eine oder mehrere Zentraleinheiten (CPUs) 2101a, 2101b, 2101c usw. umfassen kann. Der Prozessor 2101, auf den auch als Verarbeitungseinheit, Mikroprozessor, Datenverarbeitungseinheit verwiesen wird, ist über einen Systembus 2102 mit einem Systemarbeitsspeicher 2103 und verschiedenen anderen Komponenten verbunden. Der Systemarbeitsspeicher 2103 umfasst einen Nur-Lese-Speicher (ROM) 2104 und einen Direktzugriffspeicher (RAM) 2105. Der ROM 2104 ist mit dem Systembus 2102 verbunden und kann ein grundlegendes Eingabe/Ausgabe-System (BIOS) umfassen, das bestimmte grundlegende Funktionen des Knotens 10 steuert. Der RAM ist ein Lese-Schreib-Speicher, der mit dem Systembus 2102 zur Verwendung durch den Prozessor 2101 verbunden ist.
Der Knoten 10 von 21 umfasst eine Festplatte 2107, die ein Beispiel für ein konkretes Speichermedium ist, das durch den Prozessor 2101 lesbar und ausführbar ist. Die Festplatte 2107 speichert Software 2108 und Daten 2109. Die Software 2108 ist als Anweisungen für die Ausführung auf dem Knoten 10 durch den Prozessor 2101 gespeichert (um einen Prozess auszuführen wie beispielsweise die Prozesse, die in Bezug auf 1 bis 20 beschrieben wurden). Die Daten 2109 umfassen ein Werteset von qualitativen oder quantitativen Variablen, die in verschiedenen Datenstrukturen zum Unterstützen und Verwenden durch Operationen der Software 2108 organisiert sind.
Der Knoten 10 von 21 umfasst einen oder mehrere Adapter (z.B. Festplatten-Controller, Netzwerkadapter, Grafikadapter usw.), die Datenübertragungen zwischen dem Prozessor 2101, dem Systemarbeitsspeicher 2103, der Festplatte 2107 und anderen Komponenten des Knotens 10 miteinander verbinden und unterstützen (z.B. Peripherie- und externe Einheiten). In einer oder mehreren Ausführungsformen der vorliegenden Erfindung kann bzw. können der eine oder die mehreren Adapter mit einem oder mehreren E/A-Bussen verbunden werden, die mit dem Systembus 2102 über eine dazwischenliegende Busbrücke verbunden sind, und der eine oder die mehreren E/A-Busse kann bzw. können gemeinsame Protokolle nutzen wie zum Beispiel die Peripheriekomponentenverbindung (PCI) (Peripheral Component Interconnect).
Wie gezeigt, umfasst der Knoten 10 einen Schnittstellenadapter 2120, der eine Tastatur 2121, eine Maus 2122, einen Lautsprecher 2123 und ein Mikrofon 2124 mit dem Systembus 2102 verbindet. Der Knoten 10 umfasst einen Anzeigeadapter 2130, der den Systembus 2102 mit einer Anzeige 2131 verbindet. Der Anzeigeadapter 2130 (und/oder der Prozessor 2101) kann einen Grafik-Controller umfassen, um eine Grafikleistung wie zum Beispiel eine Anzeige und Verwaltung einer GUI 2132 bereitzustellen. Ein Datenübertragungsadapter 2141 verbindet den Systembus 2102 mit einem Netzwerk 2150, was dem Knoten 10 ermöglicht, mit anderen Systemen, Einheiten, Daten und Software, wie beispielsweise einem Server 2151 und einer Datenbank 2152 Daten auszutauschen. In einer oder mehreren Ausführungsformen der vorliegenden Erfindung können die Operationen der Software 2108 und die Daten 2109 auf dem Netzwerk 2150 durch den Server 2151 und die Datenbank 2152 umgesetzt werden. Zum Beispiel können das Netzwerk 2150, der Server 2151 und die Datenbank 2152 kombiniert werden, um interne Wiederholungen der Software 2108 und der Daten 2109 als Platform as a Service, Software as a Service und/oder Infrastructure as a Service (z.B. als Web-Anwendung in einem verteilten System) bereitzustellen.
Hierin beschriebene Ausführungsformen sind notwendigerweise in Computertechnologie verankert und insbesondere in Computer-Servern, die VMs hosten. Ferner vereinfacht bzw. vereinfachen eine oder mehreren Ausführungsformen der vorliegenden Erfindung eine Verbesserung der Funktionsweise der Datenverarbeitungstechnologie selbst, insbesondere von Computer-Servern, die VMs hosten, indem den Computer-Servern, die VMs hosten, ermöglicht wird, sichere VMs zu hosten, in denen selbst dem Hypervisor ein Zugreifen auf Arbeitsspeicher, Register und andere derartige Daten untersagt ist, die der sicheren VM zugehörig sind. Außerdem stellt eine bzw. stellen mehrere Ausführungsformen der vorliegenden Erfindung wesentliche Schritte hinsichtlich der Verbesserungen der Datenverarbeitungsserver, die die VM hosten, durch Verwenden einer sicheren Schnittstellensteuerung (auf die hierin auch als „UV“ verwiesen wird) bereit, die Hardware, Firmware (z.B. Millicode) oder eine Kombination davon umfasst, um eine Trennung der sicheren VM und des Hypervisors zu vereinfachen und somit eine Sicherheit der VMs aufrecht zu erhalten, die durch den DatenverarbeitungsServer gehostet werden. Die sichere Schnittstellensteuerung stellt kompakte zwischengeschaltete Operationen bereit, um die Sicherheit zu ermöglichen ohne erheblichen Mehraufwand beim Schützen des VM-Zustands während einer Initialisierung/Beendigung von VMs wie hierin beschrieben hinzuzufügen.
Hierin offenbarte Ausführungsformen der Erfindung können ein System, ein Verfahren und/oder ein Computerprogrammprodukt (hierin ein System) umfassen, die den Zugriff auf sicheren Speicher einer VM kontrollieren. Zu beachten ist, dass für jede Erklärung Kennungen für Elemente für andere ähnliche Elemente von verschiedenen Figuren erneut verwendet werden.
Verschiedene Ausführungsformen der Erfindung werden hierin unter Bezugnahme auf die zugehörigen Zeichnungen beschrieben. Alternative Ausführungsformen der Erfindung sind denkbar, ohne von dem Schutzumfang dieser Erfindung abzuweichen. Verschiedene Verbindungen und positionsbezogene Beziehungen (z.B. über, unter, neben usw.) zwischen Elementen werden in der folgenden Beschreibung und in den Zeichnungen dargelegt. Diese Verbindungen und/oder positionsbezogenen Beziehungen können, sofern nicht anders spezifiziert, direkt oder indirekt sein, und die vorliegende Erfindung ist in dieser Hinsicht keinesfalls als einschränkend zu verstehen. Dementsprechend kann eine Verbindung von Entitäten entweder auf eine direkte oder eine indirekte Verbindung verweisen, und eine positionsbezogene Beziehung zwischen Entitäten kann eine direkte oder indirekte positionsbezogene Beziehung sein. Des Weiteren können die hierin beschriebenen verschiedenen Aufgaben und Prozessschritte in eine umfassendere Prozedur oder einen umfassenderen Prozess mit zusätzlichen Schritten oder zusätzlicher Funktionalität integriert werden, die hierin nicht im Detail beschrieben werden.
Die folgenden Definitionen und Abkürzungen sind für die Auslegung der Ansprüche und der Patentschrift zu verwenden. Wie hierin verwendet, sollen die Begriffe „weist auf“, „aufweisend“, „umfasst“, „umfassend“, „besitzt“, „besitzend“, „enthält“ oder „enthaltend“ oder irgendeine Variation davon eine nicht ausschließende Einbeziehung abdecken. Zum Beispiel ist eine Zusammensetzung, ein Gemisch, ein Prozess, ein Verfahren, ein Artikel oder eine Vorrichtung, die eine Liste von Elementen umfasst, nicht notwendigerweise auf nur diese Elemente beschränkt, sondern kann andere Elemente umfassen, die nicht ausdrücklich aufgelistet oder derartigen Zusammensetzungen, Gemischen, Prozessen, Verfahren, Artikeln oder Vorrichtungen eigen sind.
Außerdem bedeutet der hierin verwendete Begriff „beispielhaft“, dass „etwas als Beispiel, Variante oder zur Veranschaulichung dient“. Jede hierin als „beispielhaft“ beschriebene Ausführungsform oder Auslegung muss nicht notwendigerweise als gegenüber anderen Ausführungsformen oder Auslegungen bevorzugt oder vorteilhaft aufgefasst werden. Der Begriff „mindestens ein/eine“ und „ein/e oder mehrere“ ist als jede ganzzahlige Anzahl größer oder gleich eins zu verstehen, d.h. eins, zwei, drei, vier usw. Der Begriff „eine Mehrzahl“ ist als ganzzahlige Anzahl größer oder gleich zwei zu verstehen, d.h. zwei, drei, vier, fünf usw. Der Begriff „Verbindung“ kann sowohl eine indirekte „Verbindung“ als auch eine direkte „Verbindung“ umfassen.
Die Begriffe „über“, „im Wesentlichen“, „ungefähr“ und Variationen davon sollen das Fehlermaß angeben, das einer Messung der bestimmten Menge auf Grundlage des Zeitpunkts der Anmeldungseinreichung auf der verfügbaren Ausrüstung zugehörig ist. Zum Beispiel kann „über“ einen Bereich von ±8 % oder 5 % oder 2 % eines bestimmten Werts umfassen.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jeder möglichen technischen Detailintegrationsebene handeln. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) enthalten, auf dem durch einen Computer lesbare Programmanweisungen gespeichert 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 zum Ausführen von Anweisungen beibehalten und speichern kann. Das durch einen Computer lesbare Speichermedium kann zum Beispiel eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiter-Speichereinheit oder jede geeignete Kombination aus dem Vorgenannten sein, es ist aber nicht darauf beschränkt. Zu einer nicht erschöpfenden Liste von spezifischeren Beispielen 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 CD-ROM, eine DVD, ein Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination des Vorgenannten. Ein durch einen Computer lesbares Speichermedium soll, wie hierin verwendet, 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 andere Übertragungsmedien ausbreiten (z.B. durch ein Lichtwellenleiterkabel geleitete 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-/Verarbeitungseinheiten 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, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit 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-/Verarbeitungseinheit 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 sind, 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 dem letzteren Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch jeden Typ von Netzwerk verbunden werden, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann zu 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, feldprogrammierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die computerlesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der computerlesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Veranschaulichungen von Ablaufplänen und/oder Blockschaubildern von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es sollte klar sein, dass jeder Block der Ablaufplanveranschaulichungen und/oder der Blockschaubilder und Kombinationen von Blöcken in den Ablaufplanveranschaulichungen und/oder den Blockschaubildern mittels durch einen Computer lesbare Programmanweisungen umgesetzt 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. eine andere programmierbare Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegebenen 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, ein Herstellungsprodukt aufweist, darunter Anweisungen, die Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaubilder 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 Arbeitsschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen durch einen Computer umgesetzten 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 Blockschaubilder angegebenen Funktionen/Schritte umsetzen.
Die Ablaufpläne und Blockschaubilder 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 den Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zum Umsetzen der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Umsetzungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt auftreten. Zum Beispiel können zwei nacheinander gezeigte Blöcke tatsächlich im Wesentlichen parallel ausgeführt werden, oder die Blöcke können manchmal in der umgekehrten Reihenfolge ausgeführt werden, was von der beteiligten Funktionalität abhängt. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder der Ablaufplandarstellungen sowie Kombinationen von Blöcken in den Blockschaubildern und/oder der Ablaufplandarstellung durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die angegebenen Funktionen oder Handlungen durchführen oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
Die hierin verwendete Terminologie dient nur zum Zweck der Beschreibung von bestimmten Ausführungsformen und soll keinesfalls einschränkend sein. Die hierin verwendeten Singularformen „ein“, „eine“ und „der/die/das“ sollen auch die Pluralformen mit einschließen, es sei denn, der Kontext gibt eindeutig anderes vor. Es versteht sich des Weiteren, dass die Begriffe „weist auf“ und/oder „aufweisend“ bei Verwendung in dieser Patentschrift das Vorhandensein ausgewiesener Merkmale, Ganzzahlen, Schritte, Vorgänge, Elemente und/oder Komponenten angeben, das Vorhandensein oder die Hinzufügung von einem oder mehreren anderen Merkmalen, Ganzzahlen, Schritten, Vorgängen, Elementen, Komponenten und/oder Gruppen davon aber nicht ausschließen.
Die Beschreibungen der verschiedenen Ausführungsformen hierin wurden zum Zweck einer Veranschaulichung erstellt, sie sollen aber keineswegs erschöpfend oder auf die offenbarten Ausführungsformen eingeschränkt sein. Für Fachleute sind viele Modifizierungen und Variationen offenkundig, die nicht von dem Schutzumfang und Erfindungsgedanken der beschriebenen Ausführungsformen abweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber auf dem Markt gefundenen Technologien bestmöglich zu erklären oder anderen Fachleuten das Verständnis der hierin offenbarten Ausführungsformen zu ermöglichen.

Claims

Verfahren, aufweisend: Empfangen, von einer nicht vertrauenswürdigen Entität, die auf einem Host-Server ausgeführt wird, einer Anforderung zum Zuteilen einer sicheren Entität; Bestimmen, durch eine sichere Schnittstellensteuerung des Host-Servers, ob sich der Host-Server in einem sicheren Hilfs- (AS) (auxiliary-secure) Debug-Modus zum Testen einer AS-Entität befindet; und auf Grundlage des Bestimmens, dass sich der Host-Server in dem AS-Debug-Modus befindet, Laden eines sicheren Gast-Entitätszustands aus einem Zustandsdeskriptor für die sichere Entität in einen AS-Entitätszustand in Hardware zum Testen, nach Zuteilung der sicheren Entität, von Zugriffen auf Seiten in einem Arbeitsspeicher, die als „Sicher“ und als der AS-Entität zugehörig registriert sind.
Verfahren nach Anspruch 1, das ferner ein Zuteilen der sicheren Entität aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der AS-Entitätszustand eine Domäne und ein Modus-Bit aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Bestimmen auf einem oder mehreren Hardware-Bits beruht.
Verfahren nach einem der vorhergehenden Ansprüche, das ferner aufweist: auf Grundlage des Bestimmens, dass sich der Host-Server nicht in dem AS-Debug-Modus befindet, Laden des sicheren Gast-Entitätszustands aus dem Zustandsdeskriptor für die sichere Entität in einen sicheren Gast-Entitätszustand in Hardware zum Testen, nach Zuteilung der sicheren Entität, von Zugriffen auf Seiten in einem Arbeitsspeicher, die als „Sicher“ registriert sind.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die nicht vertrauenswürdige Entität ein Hypervisor ist und die sichere Entität eine sichere virtuelle Maschine (VM) ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die sichere Entität ein Testfall ist.
System, aufweisend: einen Arbeitsspeicher; eine sichere Schnittstellensteuerung; und einen Host-Server, der mit dem Arbeitsspeicher und der sicheren Schnittstellensteuerung verbunden ist, wobei das System zum Ausführen von Operationen konfiguriert ist, die Folgendes aufweisen: Empfangen, von einer nicht vertrauenswürdigen Entität, die auf dem Host-Server ausgeführt wird, einer Anforderung zum Zuteilen einer sicheren Entität; Bestimmen, durch die sichere Schnittstellensteuerung, ob sich der Host-Server in einem sicheren Hilfs- (AS) Debug-Modus zum Testen einer AS-Entität befindet; und auf Grundlage des Bestimmens, dass sich der Host-Server in dem AS-Debug-Modus befindet, Laden eines sicheren Gast-Entitätszustands aus einem Zustandsdeskriptor für die sichere Entität in einen AS-Entitätszustand in Hardware zum Testen, nach Zuteilung der sicheren Entität, von Zugriffen auf Seiten in einem Arbeitsspeicher, die als „Sicher“ und als der AS-Entität zugehörig registriert sind.
System nach Anspruch 8, wobei die Operationen ferner ein Zuteilen der sicheren Entität aufweisen.
System nach einem der Ansprüche 8 oder 9, wobei der AS-Entitätszustand eine Domäne und ein Modus-Bit aufweist.
System nach einem der Ansprüche 8 bis 10, wobei das Bestimmen auf einem oder mehreren Hardware-Bits beruht.
System nach einem der Ansprüche 8 bis 11, wobei die Operationen ferner aufweisen: auf Grundlage des Bestimmens, dass sich der Host-Server nicht in dem AS-Debug-Modus befindet, Laden des sicheren Gast-Entitätszustands aus dem Zustandsdeskriptor für die sichere Entität in einen sicheren Gast-Entitätszustand in Hardware zum Testen, nach Zuteilung der sicheren Entität, von Zugriffen auf Seiten in einem Arbeitsspeicher, die als „Sicher“ registriert sind.
System nach einem der Ansprüche 8 bis 12, wobei die nicht vertrauenswürdige Entität ein Hypervisor ist und die sichere Entität eine sichere virtuelle Maschine (VM) ist.
System nach einem der Ansprüche 8 bis 13, wobei die sichere Entität ein Testfall ist
Computerprogrammprodukt, aufweisend ein durch einen Computer lesbares Speichermedium, wobei das durch einen Computer lesbare Speichermedium durch einen Computer ausführbare Anweisungen aufweist, die bei Ausführung durch eine Verarbeitungseinheit die Verarbeitungseinheit veranlassen, ein Verfahren auszuführen, das aufweist: Empfangen, von einer nicht vertrauenswürdigen Entität, die auf einem Host-Server ausgeführt wird, einer Anforderung zum Zuteilen einer sicheren Entität; Bestimmen, durch eine sichere Schnittstellensteuerung des Host-Servers, ob sich der Host-Server in einem sicheren Hilfs- (AS) Debug-Modus zum Testen einer AS-Entität befindet; und auf Grundlage des Bestimmens, dass sich der Host-Server in dem AS-Debug-Modus befindet, Laden eines sicheren Gast-Entitätszustands aus einem Zustandsdeskriptor für die sichere Entität in einen AS-Entitätszustand in Hardware zum Testen, nach Zuteilung der sicheren Entität, von Zugriffen auf Seiten in einem Arbeitsspeicher, die als „Sicher“ und als der AS-Entität zugehörig registriert sind.
Verfahren, aufweisend: Empfangen, von einer nicht vertrauenswürdigen Entität, die auf einem Host-Server ausgeführt wird, einer Anforderung zum Zuteilen einer sicheren Entität; Bestimmen, durch eine sichere Schnittstellensteuerung des Host-Servers, ob sich die sichere Entität in einem sicheren Hilfs- (AS) Debug-Modus zum Testen einer AS-Entität befindet, auf Grundlage des Bestimmens, dass sich die sichere Entität im AS-Debug-Modus befindet, Laden eines AS-Entitätszustands aus einem Zustandsdeskriptor für die sichere Entität in einen AS-Entitätszustand in Hardware zum Testen, nach Zuteilung der sicheren Entität, von Zugriffen auf Seiten in einem Arbeitsspeicher, die als „Sicher“ und als einer AS-Entität zugehörig registriert sind.
Verfahren nach Anspruch 16, das ferner auf Grundlage des Bestimmens, dass sich die sichere Entität in einem AS-Modus befindet, Folgendes aufweist: Bestimmen, durch die sichere Schnittstellensteuerung des Host-Servers, ob sich die sichere Gast-Entität ebenfalls in einem sicheren Gast-Modus befindet; und auf Grundlage des Bestimmens, dass sich die sichere Entität ebenfalls in dem sicheren Gast-Modus befindet, Laden eines sicheren Gast-Entitätszustands aus dem Zustandsdeskriptor für die sichere Entität in einen sicheren Gast-Entitätszustand in Hardware zum Testen, nach Zuteilung der sicheren Entität, von Zugriffen auf Seiten in einem Arbeitsspeicher, die als „Sicher“ registriert sind.
Verfahren nach einem der Ansprüche 16 oder 17, wobei das Verfahren ferner ein Zuteilen der sicheren Entität aufweist.
Verfahren nach einem der Ansprüche 16 bis 18, wobei der sichere Gast-Entitätszustand eine Domäne und ein Modus-Bit aufweist.
Verfahren nach einem der Ansprüche 16 bis 19, wobei der AS-Entitätszustand eine Domäne und ein Modus-Bit aufweist.
Verfahren nach einem der Ansprüche 16 bis 20, wobei das Bestimmen auf einem Bit in dem Zustandsdeskriptor der sicheren Entität beruht.
Verfahren nach einem der Ansprüche 16 bis 21, wobei die nicht vertrauenswürdige Entität ein Hypervisor ist und die sichere Entität eine sichere virtuelle Maschine (VM) ist.
Verfahren nach einem der Ansprüche 16 bis 22, wobei die sichere Entität ein Testfall ist
System, aufweisend: einen Arbeitsspeicher; eine sichere Schnittstellensteuerung; und einen Host-Server, der mit dem Arbeitsspeicher und der sicheren Schnittstellensteuerung verbunden ist, wobei das System zum Ausführen von Operationen konfiguriert ist, die Folgendes aufweisen: Empfangen, von einer nicht vertrauenswürdigen Entität, die auf einem Host-Server ausgeführt wird, einer Anforderung zum Zuteilen einer sicheren Entität; Bestimmen, durch eine sichere Schnittstellensteuerung des Host-Servers, ob sich die sichere Entität in einem sicheren Hilfs- (AS) Modus zum Testen einer AS-Entität befindet; auf Grundlage des Bestimmens, dass sich die sichere Entität im AS-Debug-Modus befindet, Laden eines AS-Entitätszustands aus einem Zustandsdeskriptor für die sichere Entität in einen AS-Entitätszustand in Hardware zum Testen, nach Zuteilung der sicheren Entität, von Zugriffen auf Seiten in einem Arbeitsspeicher, die als „Sicher“ und als einer AS-Entität zugehörig registriert sind.
System nach Anspruch 24, wobei die Operationen ferner auf Grundlage des Bestimmens, dass sich die sichere Entität in einem AS-Modus befindet, Folgendes aufweisen: Bestimmen, durch die sichere Schnittstellensteuerung des Host-Servers, ob sich die sichere Gast-Entität ebenfalls in einem sicheren Gast-Modus befindet; und auf Grundlage des Bestimmens, dass sich die sichere Entität ebenfalls in dem sicheren Gast-Modus befindet, Laden eines sicheren Gast-Entitätszustands aus dem Zustandsdeskriptor für die sichere Entität in einen sicheren Gast-Entitätszustand in Hardware zum Testen, nach Zuteilung der sicheren Entität, von Zugriffen auf Seiten in einem Arbeitsspeicher, die als „Sicher“ registriert sind.