DE102020128050A1 - Tdx-inseln mit in sich abgeschlossenem geltungsbereich, wodurch eine tdx-schlüsselkennungsskalierung ermöglicht wird - Google Patents

Tdx-inseln mit in sich abgeschlossenem geltungsbereich, wodurch eine tdx-schlüsselkennungsskalierung ermöglicht wird Download PDF

Info

Publication number
DE102020128050A1
DE102020128050A1 DE102020128050.5A DE102020128050A DE102020128050A1 DE 102020128050 A1 DE102020128050 A1 DE 102020128050A1 DE 102020128050 A DE102020128050 A DE 102020128050A DE 102020128050 A1 DE102020128050 A1 DE 102020128050A1
Authority
DE
Germany
Prior art keywords
memory
island
tdi
tdirm
sockets
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020128050.5A
Other languages
English (en)
Inventor
Gideon Gerzon
Hormuzd M. Khosravi
Vincent Von Bokern
Barry E. Huntley
Dror Caspi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102020128050A1 publication Critical patent/DE102020128050A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/145—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being virtual, e.g. for virtual blocks or segments before a translation mechanism
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1466—Key-lock mechanism
    • G06F12/1475—Key-lock mechanism in a virtual system, e.g. with translation means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Mathematical Physics (AREA)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)

Abstract

Offenbarte Ausführungsformen betreffen vertrauenswürdige Domänen-Inseln innerhalb eines in sich abgeschlossenen Geltungsbereichs. Bei einem Beispiel weist ein System mehrere Sockets auf, die jeweils mehrere Kerne, mehrere Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TME)-Schaltungen, mehrere Speichersteuereinrichtungen und einen Vertrauenswürdige-Domänen-Insel-Ressourcenmanager (TDIRM) aufweisen, um Folgendes auszuführen: Initialisieren einer Vertrauenswürdige-Domänen-Insel-Steuerstruktur (TDICS) in Zusammenhang mit einer TD-Insel, Initialisieren eines geschützten TD-Insel-Speichers (TDIPM) in Zusammenhang mit der TD-Insel, Identifizieren einer Host-Schlüsselkennung (HKID) in einer Schlüsseleigentümerschaftstabelle (KOT), Zuweisen der HKID zu einem kryptographischen Schlüssel in einer MK-TME-Schaltung und Speichern der HKID in der TDICS, Assoziieren eines ersten der mehreren Kerne mit der TD-Insel, Hinzufügen einer Speicherseite von einem Adressraum des ersten Kerns zum TDIPM und Übertragen der Ausführungssteuerung auf den ersten Kern zur Ausführung der TDI, wobei die Anzahl der im System verfügbaren HKIDs vergrößert wird, wenn der auf die TD-Insel abgebildete Speicher verringert wird.

Description

  • GEBIET DER ERFINDUNG
  • Das Gebiet der Erfindung betrifft allgemein eine Computerprozessorarchitektur und insbesondere Vertrauenswürdige-Domänen-Insel-Erweiterungs(TDIX)-Inseln mit einem in sich abgeschlossenen Geltungsbereich zur Ermöglichung einer TDIX-Schlüsselkennungsskalierung.
  • HINTERGRUND
  • Moderne Verarbeitungsvorrichtungen verwenden eine Plattenverschlüsselung für den Schutz von Daten in Ruhe. Daten im Speicher liegen jedoch als Klartext vor und sind für Angriffe verwundbar. Angreifer können eine Vielzahl von Techniken einschließlich eines Software- und hardwarebasierten Bus-Scannens, Speicher-Scannens, einer Hardware-Prüfung usw. verwenden, um Daten aus dem Speicher abzurufen. Diese Daten aus dem Speicher könnten sensitive Daten einschließlich privatheitssensitiver Daten, IP-sensitiver Daten und auch Schlüssel, die für Dateiverschlüsselung oder Kommunikation verwendet werden, einschließen. Die Offenlegung von Daten wird durch den aktuellen Trend des Verschiebens von Daten und Unternehmensarbeitslasten in die Cloud unter Verwendung virtualisierungsbasierter Hosting-Dienste, die von Cloud-Dienstanbietern bereitgestellt werden, weiter verschärft.
  • Figurenliste
  • Die vorliegende Erfindung wird in den Figuren der anliegenden Zeichnungen beispielhaft und nicht einschränkend erläutert, wobei gleiche Bezüge ähnliche Elemente angeben.
  • Es zeigen:
    • 1 ein Blockdiagramm von Verarbeitungskomponenten zur Ausführung von Befehlen gemäß einigen Ausführungsformen,
    • 2A ein Blockdiagramm einer Ausführungsform eines Mehr-Socket-Rechensystems, das eine Isolation in virtualisierten Systemen unter Verwendung auf Sockets abgebildeter vertrauenswürdiger Domänen-Inseln (TDI) bereitstellt,
    • 2B ein Blockdiagramm einer Ausführungsform eines Mehr-Socket-Rechensystems, das eine Isolation in virtualisierten Systemen unter Verwendung auf Speichersteuereinrichtungen abgebildeter vertrauenswürdiger Domänen-Inseln (TDI) bereitstellt,
    • 3 eine Ausführungsform einer Speicherkarte eines Rechensystems, wodurch eine Isolation in virtualisierten Systemen unter Verwendung vertrauenswürdiger Domänen-Inseln (TDIs) bereitgestellt wird,
    • 4 ein Flussdiagramm eines Verfahrens zum Erzeugen einer vertrauenswürdigen Domänen-Insel (TDI) gemäß einer Ausführungsform einer TDI-Architektur,
    • 5 ein Blockdiagramm einer Ausführungsform eines Rechensystems, das eine Isolation in virtualisierten Systemen unter Verwendung vertrauenswürdiger Domänen-Inseln (TDIs) bereitstellt,
    • 6 ein Blockdiagramm einer anderen Ausführungsform eines Rechensystems, das eine Isolation in virtualisierten Systemen unter Verwendung vertrauenswürdiger Domänen-Inseln (TDIs) bereitstellt,
    • 7 ein Blockdiagramm einer anderen Ausführungsform eines Rechensystems, das eine Isolation in virtualisierten Systemen unter Verwendung von TDIs bereitstellt,
    • 8 ein Blockdiagramm einer Ausführungsform einer TDI-Architektur,
    • 9 ein Flussdiagramm eines Verfahrens zum Erzeugen einer TDI gemäß Ausführungsformen der vorliegenden Offenbarung,
    • 10 ein Flussdiagramm eines Verfahrens zum Initialisieren einer Vertrauenswürdige-Domänen-Insel-Steuerstruktur (TDICS) und eines geschützten Vertrauenswürdige-Domänen-Insel-Speichers (TDIPM) gemäß Ausführungsformen der vorliegenden Offenbarung,
    • 11 ein Flussdiagramm eines Verfahrens zum Assoziieren eines logischen Prozessors mit einer TDI gemäß Ausführungsformen der vorliegenden Offenbarung,
    • 12 ein Flussdiagramm eines Verfahrens zum Hinzufügen einer Speicherseite von einem Adressraum eines logischen Prozessors zu einem TDIPM gemäß Ausführungsformen der vorliegenden Offenbarung,
    • 13 ein Flussdiagramm eines Verfahrens zum Übertragen der Ausführungssteuerung auf einen logischen Prozessor zur Ausführung einer TDI gemäß Ausführungsformen der vorliegenden Offenbarung,
    • 14 ein Flussdiagramm eines Verfahrens zum Zerstören einer TDI gemäß Ausführungsformen der vorliegenden Offenbarung,
    • 15 ein Flussdiagramm eines Verfahrens zum Verhindern, dass eine TDI auf einem logischen Prozessor ausführt, gemäß Ausführungsformen der vorliegenden Offenbarung,
    • 16 ein Flussdiagramm eines Verfahrens zum Entfernen einer Speicherseite aus einem TDIPM in Zusammenhang mit einer TDI gemäß Ausführungsformen der vorliegenden Offenbarung,
    • die 17A - 17B Blockdiagramme eines generischen vektorfreundlichen Befehlsformats und von Befehlsschablonen davon gemäß einigen Ausführungsformen der Erfindung,
    • 17A ein Blockdiagramm eines generischen vektorfreundlichen Befehlsformats und von Klasse-A-Befehlsschablonen davon gemäß einigen Ausführungsformen der Erfindung,
    • 17B ein Blockdiagramm des generischen vektorfreundlichen Befehlsformats und von Klasse-B-Befehlsschablonen davon gemäß einigen Ausführungsformen der Erfindung,
    • 18A ein Blockdiagramm eines beispielhaften spezifischen vektorfreundlichen Befehlsformats gemäß einigen Ausführungsformen der Erfindung,
    • 18B ein Blockdiagramm der Felder des spezifischen vektorfreundlichen Befehlsformats, welche das vollständige Operationscodefeld bilden, gemäß einer Ausführungsform,
    • 18C ein Blockdiagramm der Felder des spezifischen vektorfreundlichen Befehlsformats, welche das Registerindexfeld bilden, gemäß einer Ausführungsform,
    • 18D ein Blockdiagramm der Felder des spezifischen vektorfreundlichen Befehlsformats, welche das Erweiterungsoperationsfeld bilden, gemäß einer Ausführungsform,
    • 19 ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform,
    • 20A ein Blockdiagramm, das sowohl eine als Beispiel dienende In-der-Reihenfolge-Pipeline als auch eine als Beispiel dienende Register-umbenennende Außerhalbder-Reihenfolge-Ausgabe/Ausführung-Pipeline gemäß einigen Ausführungsformen zeigt,
    • 20B ein Blockdiagramm, das sowohl eine als Beispiel dienende Ausführungsform eines In-der-Reihenfolge-Architekturkerns als auch eines als Beispiel dienenden Register-umbenennenden Außerhalb-der-Reihenfolge-Ausgabe/Ausführung-Architekturkerns, der in einen Prozessor gemäß Ausführungsformen aufzunehmen ist, zeigt,
    • Die 21A-B ein Blockdiagramm einer spezifischeren als Beispiel dienenden In-der-Reihenfolge-Kernarchitektur, wobei der Kern einer von mehreren Logikblöcken (einschließlich anderer Kerne desselben Typs und/oder anderer Typen) in einem Chip wäre,
    • 21A ein Blockdiagramm eines Einzelprozessorkerns zusammen mit seiner Verbindung zum auf dem Chip liegenden Zwischenverbindungsnetz und mit seiner lokalen Untermenge des Level-2(L2)-Cache gemäß einigen Ausführungsformen,
    • 21B eine erweiterte Ansicht eines Teils des Prozessorkerns aus 21A gemäß einigen Ausführungsformen,
    • 22 ein Blockdiagramm eines Prozessors, der mehr als einen Kern aufweisen kann, eine integrierte Speichersteuereinrichtung aufweisen kann und eine integrierte Graphik aufweisen kann, gemäß einigen Ausführungsformen,
    • die 23 - 26 Blockdiagramme als Beispiel dienender Computerarchitekturen,
    • 23 ein Blockdiagramm eines Systems gemäß einigen Ausführungsformen,
    • 24 ein Blockdiagramm eines ersten spezifischeren als Beispiel dienenden Systems gemäß einer Ausführungsform,
    • 25 ein Blockdiagramm eines zweiten spezifischeren als Beispiel dienenden Systems gemäß einigen Ausführungsformen,
    • 26 ein Blockdiagramm eines System-auf-einem-Chip (SoC) gemäß einigen Ausführungsformen,
    • 27 ein Blockdiagramm, das die Verwendung eines Softwarebefehlswandlers zur Umwandlung binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz zeigt, gemäß einigen Ausführungsformen der Erfindung.
  • DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
  • In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt. Es ist jedoch zu verstehen, dass einige Ausführungsformen ohne diese spezifischen Einzelheiten verwirklicht werden können. In anderen Fällen wurden wohlbekannte Schaltungen, Strukturen und Techniken nicht detailliert dargestellt, um das Verständnis dieser Beschreibung nicht zu behindern.
  • In dieser Patentschrift auftretende Bezüge auf „eine einzige Ausführungsform“, „eine Ausführungsform“, „eine beispielhafte Ausführungsform“ usw. geben an, dass die beschriebene Ausführungsform ein Merkmal, eine Struktur oder eine Eigenschaft aufweist, wobei jedoch nicht notwendigerweise jede Ausführungsform das Merkmal, die Struktur oder die Eigenschaft aufzuweisen braucht. Überdies beziehen sich solche Ausdrücke nicht notwendigerweise auf dieselbe Ausführungsform. Ferner wird, wenn ein Merkmal, eine Struktur oder eine Eigenschaft in Bezug auf eine Ausführungsform beschrieben wird, angenommen, dass es innerhalb des Wissens von Fachleuten liegt, dieses Merkmal, diese Struktur oder diese Eigenschaft auf andere Ausführungsformen anzuwenden, falls explizit beschrieben.
  • Hier werden Ausführungsformen einer auf einer Vertrauenswürdige-Domänen-Insel-Erweiterung(TDIX)-Architektur aufbauenden Erfindung offenbart. Die TDIX-Architektur ermöglicht 1) eine Gesamtspeicherverschlüsselung, 2) eine Mehrschlüssel-Speicherverschlüsselung und 3) vertrauenswürdige Domänen-Inseln auf der Grundlage von Verwendungs- und Sicherheitsanforderungen.
  • Bei Implementationen dieser Offenbarung ist eine TDI-Architektur- und Befehlssatzarchitektur(ISA)-Erweiterungen(hier als Vertrauenswürdige-Domänen-Insel-Erweiterung (TDIX) bezeichnet)-Architektur vorgesehen. Die hier offenbarte TDIX-Architektur wird manchmal einfach als Vertrauenswürdige-Domänen-Erweiterung(TDX)-Architektur bezeichnet, wobei eine vertrauenswürdige Domäne viele der gleichen Merkmale als eine vertrauenswürdige Domänen-Insel teilt, jedoch den Geltungsbereich von Host-Schlüssel-Kennungen nicht auf eine „Insel“ beschränkt.
  • VERTRAUENSWÜRDIGE DOMÄNEN-INSELN/VERTRAUENSWÜRDIGE DOMÄNEN
  • TDX und TDIX weisen beide bestimmte Vorteile auf: Sie ermöglichen mehrere sichere TDIs (oder TDs) entsprechend verschiedenen Client-Maschinen (beispielsweise VMs), Gastbetriebssystemen, Host-Betriebssystemen, Hypervisoren oder dergleichen. Zusätzlich können verschiedene Anwendungen, die vom selben Client innerhalb desselben Gast-OS ausgeführt werden, sicher unter Verwendung mehrerer TDIs (oder TDs) ausgeführt werden. Jede TDI (oder TD) kann einen oder mehrere private Schlüssel verwenden, die Software, welche außerhalb der vertrauenswürdigen Domäne ausgeführt wird, nicht verfügbar sind. Gemäß einigen Ausführungsformen hat in einer TDI (oder TD) ausgeführte Software Zugang zu privaten Schlüsseln, die für diese bestimmte vertrauenswürdige Domänen-Insel spezifisch sind, und zu geteilten Schlüsseln, die von mehreren TDIs verwendet werden können. Beispielsweise kann ein Softwareprogramm, das innerhalb einer TDI ausgeführt wird, einen privaten Schlüssel für seine sichere Ausführung (beispielsweise Lese-, Schreib-, Ausführungsoperationen) verwenden und kann dieselbe Software einen geteilten Schlüssel für den Zugriff auf Strukturen oder Vorrichtungen, die mit anderen TDIs geteilt werden (beispielsweise Drucker, Tastatur, Maus, Bildschirm, Netzadapter, Router usw.), verwenden.
  • Eine TDI kann sogar vor privilegierten Benutzern gesichert werden, wie dem OS (entweder Host oder Gast), dem VMM, Grund-Ein-/Ausgabesystem(BIOS)-Firmware, Systemverwaltungsmodus und dergleichen. Daher bleiben selbst dann, wenn bösartige Software eine privilegierte vertrauenswürdige Domänen-Insel in der Art des OS übernimmt, im Speicher in der TDI gespeicherte sensitive Daten geschützt.
  • Jede TDI kann unabhängig von anderen TDIs arbeiten und einen oder mehrere logische Prozessoren, Speicher und E/A, die einem Vertrauenswürdige-Domänen-Insel-Ressourcenmanager (TDIRM) zugewiesen sind, verwenden. Der TDIRM kann als Teil des Host-OS, des Hypervisors oder als getrenntes Softwareprogramm arbeiten und hat die vollständige Kontrolle über die Kerne und andere Plattformhardware. Der TDIRM weist logische Prozessoren (beispielsweise Ausführungs-Threads eines physischen Prozessors) TDIs zu, kann jedoch nicht auf den TDI-Ausführungszustand auf dem einen oder den mehreren zugewiesenen logischen Prozessoren zugreifen. Ähnlich kann ein TDIRM den TDIs physische Speicher- und E/A-Ressourcen zuweisen, infolge der Verwendung getrennter Verschlüsselungsschlüssel jedoch nicht den Speicherzustand einer TDI erfahren. Software, die in einer TDI ausgeführt wird, kann mit verringerten Privilegien arbeiten (beispielsweise kann Mandantensoftware keinen vollständigen Zugriff auf alle auf dem Host-System verfügbaren Ressourcen haben), so dass der TDIRM die Kontrolle von Plattformressourcen behalten kann. Der TDIRM kann jedoch nicht die Vertraulichkeit oder Integrität des TDI-Zustands im Speicher oder in den CPU-Strukturen unter definierten Umständen beeinträchtigen.
  • TDI-RESSOURCENMANAGER/TDI-STEUERSTRUKTUR/GESCHÜTZTER-TDI-SPEICHER
  • Demgemäß werden beim offenbarten Verfahren zur Erzeugung einer Vertrauenswürdige-Ausführungsdomänen-Basis auf einer vertrauenswürdigen Domänen-Insel durch eine einen Vertrauenswürdige-Domänen-Insel-Ressourcenmanager (TDIRM) ausführende Verarbeitungsvorrichtung eine Vertrauenswürdige-Domänen-Insel-Steuerstruktur (TDICS) und ein geschützter Vertrauenswürdige-Domänen-Insel-Speicher (TDIPM) in Zusammenhang mit einer vertrauenswürdigen Domänen-Insel (TDI) initialisiert. Beim Verfahren werden ferner ein einmaliger Verschlüsselungsschlüssel erzeugt, der einmalige Verschlüsselungsschlüssel einer verfügbaren Host-Schlüsselkennung (HKID) in einer Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TDME)-Maschine zugewiesen und die HKID in der TDICS gespeichert. Beim Verfahren werden ferner ein logischer Prozessor mit der TDI assoziiert, eine Speicherseite von einem Adressraum des logischen Prozessors dem TDIPM hinzugefügt und die Ausführungssteuerung auf den logischen Prozessor übertragen, um die TDI auszuführen.
  • Gemäß einigen Ausführungsformen arbeiten der TDIRM, die TDICS, der TDIPM usw. auf vertrauenswürdigen Domänen-Inseln (TDIs) und sind damit assoziiert. Gemäß anderen Ausführungsformen arbeiten diese Elemente jedoch auf vertrauenswürdige Domänen-Inseln. Vertrauenswürdige Domänen-Inseln ähneln konzeptionell vertrauenswürdigen Domänen, beziehen sich jedoch auf eine „Inselumgebung“, die einen in sich abgeschlossenen Geltungsbereich von Host-Schlüsselkennungen bietet. Weil der Geltungsbereich auf die Grenzen einer Insel beschränkt ist, können mehrere Inseln identische Host-Schlüsselkennungen aufweisen. Daher nimmt die Anzahl der für die Plattform verfügbaren Schlüsselkennungen proportional zur Anzahl der definierten Inseln zu. Beispielsweise kann eine TD-Insel einen Socket umfassen, wobei es mehrere Sockets im System gibt. Andernfalls kann eine TD-Insel eine oder mehrere Speichersteuereinrichtungen umfassen. Wenngleich sie konzeptionell ähnlich sind, werden die Konzepte von TDIRM, TDICS, TDIPM usw. manchmal als TDIRM, TDICS, TDIPM usw. bezeichnet, wobei das „I“ bedeutet, dass der Begriff mit einer „Insel“ assoziiert ist.
  • ERZEUGEN UND ZERSTÖREN VON VERTRAUENSWÜRDIGEN DOMÄNEN-INSELN
  • Aspekte der vorliegenden Offenbarung betreffen die Erzeugung und Zerstörung einer vertrauenswürdigen Domänen-Insel (TDI). Eine TDI bezieht sich auf eine sichere Softwareausführungsumgebung, die eine Kunden(beispielsweise Mandanten)-Arbeitslast unterstützen kann. Die Mandantenarbeitslast kann ein Betriebssystem (OS) sowie andere über dem OS laufende Anwendungen einschließen. Die Mandantenarbeitslast kann auch eine über einem Virtuelle-Maschine-Überwacher (VMM) laufende virtuelle Maschine (VM) sowie andere Anwendungen einschließen.
  • Herkömmliche Cloud-Server-Rechenumgebungen stellen ferne Rechenressourcen und ferne Datenspeicherressourcen für verschiedene Vorrichtungen bereit. Während ein Mandant auf eine ferne Berechnung und einen Datenspeicher, die von einem Cloud-Dienstanbieter (CSP) bereitgestellt werden, zugreift, ist es besonders wichtig, dass Daten vor Zugriff durch unberechtigte Personen und bösartige Software geschützt werden. Nicht verschlüsselte Klartextdaten, die sich im Speicher befinden, sowie Daten, die sich zwischen dem Speicher und einem Prozessor bewegen, können für eine Vielzahl von Angriffen verwundbar sein. Angreifer können eine Vielzahl von Techniken (beispielsweise Bus-Scannen, Speicher-Scannen usw.) verwenden, um Daten aus dem Speicher abzurufen. In einigen Fällen umfassen Daten Schlüssel oder andere Informationen, die für die Verschlüsselung sensitiver Daten verwendet werden.
  • GESAMTSPEICHERVERSCHLÜSSELUNG UND MEHRSCHLÜSSEL-GESAMTSPEICHERVERSCHLÜSSELUNG
  • Die Gesamtspeicherverschlüsselungs(TME)-Technologie stellt eine Lösung zum Schützen von Daten im Speicher bereit. Die TME ermöglicht die Verschlüsselung von Speicherzugriffen durch auf einem Prozessorkern ausgeführte Software unter Verwendung eines Verschlüsselungsschlüssels. Der Verschlüsselungsschlüssel kann beispielsweise ein zur Boot-Zeit erzeugter 128-Bit-Schlüssel sein und verwendet werden, um zu externen Speicherbussen gesendete Daten zu verschlüsseln. Insbesondere können die Daten, wenn der Prozessor eine Schreibanforderung an den Speicher stellt, durch eine Speicherverschlüsselungsmaschine verschlüsselt werden, bevor sie zum Speicher gesendet werden, wo sie in verschlüsselter Form gespeichert werden. Wenn die Daten aus dem Speicher gelesen werden, werden sie in verschlüsselter Form zum Prozessor gesendet und durch den Verschlüsselungsschlüssel entschlüsselt, wenn sie vom Prozessor empfangen werden. Weil Daten in Form von Klartext im Prozessor verbleiben, erfordert die TME-Technologie keine Modifikation an der existierenden Software und an der Art, in der die existierende Software mit dem Prozessor interagiert.
  • Eine Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TME)-Technologie ist eine Erweiterung der TME-Technologie, welche Unterstützung für mehrere Verschlüsselungsschlüssel bereitstellt. Dies ermöglicht eine aufgegliederte Speicherverschlüsselung. Beispielsweise kann die Prozessorarchitektur die Erzeugung mehrerer Verschlüsselungsschlüssel während des Boot-Prozesses (d. h. der Operationen, die von einem Rechensystem ausgeführt werden, wenn das System zuerst hochgefahren wird) erlauben, die zu verwenden sind, um verschiedene Speicherseiten zu verschlüsseln. Schlüsselkennungen (IDs), die mit den Verschlüsselungsschlüsseln assoziiert sind, können von verschiedenen Hardware- und Softwarekomponenten als Teil der TME- und MK-TME-Technologien verwendet werden. Die Mehrschlüsselerweiterung ist insbesondere dafür geeignet, mit Mehrere-vertrauenswürdige-Domänen-Inselarchitekturen in der Art von Architekturen, die durch CSPs verwendet werden, zu arbeiten, weil die Anzahl der unterstützten Schlüssel implementationsabhängig sein kann.
  • Bei einigen Implementationen haben CSPs eine Wahl, Seiten eines VMs festzulegen, die unter Verwendung eines VM-spezifischen Schlüssels zu verschlüsseln sind. In anderen Fällen wählt ein CSP spezifische VM-Seiten, die in Klartext verbleiben sollen oder unter Verwendung verschiedener vergänglicher Schlüssel, die für Software opak sein können, verschlüsselt werden sollen. Eine MK-TME-Maschine kann verwendet werden, um verschiedene Seiten zu unterstützen, die unter Verwendung anderer Schlüssel zu verschlüsseln sind. Die MK-TME-Maschine kann wenigstens einen Schlüssel pro vertrauenswürdiger Domänen-Insel unterstützen und daher eine kryptographische Isolation zwischen verschiedenen auf einem CSP vorhandenen Arbeitslasten erreichen. Eine Arbeitslast kann einem Mandanten oder Eigentümer (beispielsweise einer Entität, welche die Verwendung des Host-Servers vom CSP mietet) zugeordnet werden.
  • TDIX-ARCHITEKTUR, DIE MIT VIRTUELLE-MASCHINE-ERWEITERUNGEN ZUSAMMENARBEITET
  • Die Vertrauenswürdige-Domänen-Insel-Erweiterung(TDIX)-Architektur kann mit anderen Virtualisierungsarchitekturerweiterungen in der Art von VMX (Virtuelle-Maschine-Erweiterungen) zusammenarbeiten. VMX ermöglicht es, dass sich mehrere Betriebssysteme sicher und effizient gleichzeitig Prozessorressourcen teilen. Ein Rechensystem mit VMX kann als mehrere virtuelle Systeme oder VMs wirken. Jede VM kann Betriebssysteme und Anwendungen in getrennten Partitionen ausführen. VMX stellt auch eine als Virtuelle-Maschine-Überwacher (VMM) bezeichnete Systemsoftwareschicht bereit, die zur Behandlung des Betriebs virtueller Maschinen (vergl. TDIRM) verwendet wird.
  • VMX kann eine Virtuelle-Maschine-Steuerstruktur (VMCS) zur Behandlung von VM-Übergängen (beispielsweise VM-Eintritten und VM-Austritten) bereitstellen. Ein VM-Eintritt ist ein Übergang vom VMM- in den VM-Betrieb. VM-Eintritte können durch einen vom VMM ausgeführten Befehl ausgelöst werden. Ein VM-Austritt ist ein Übergang vom VM-Betrieb in den VMM. VM-Austritte können durch Hardwareereignisse ausgelöst werden, die einen Austritt aus der VM erfordern. Beispielsweise kann ein Seitenfehler in einer die VM unterstützenden Seitentabelle einen VM-Austritt hervorrufen. Die VMCS kann eine sechsteilige Datenstruktur zur Behandlung von VM-Übergängen sein. Die VMCS kann Folgendes nachverfolgen: einen Gastzustandsbereich (beispielsweise den Prozessorzustand, wenn ein VM-Austritt geschieht, welcher bei VM-Eintritten geladen wird), einen Host-Zustandsbereich (beispielsweise den Prozessorzustand, der bei VM-Austritten geladen wird), VM-Ausführungssteuerfelder (beispielsweise Felder, welche die Ursachen von VM-Austritten festlegen), VM-Austrittssteuerfelder, VM-Eintrittssteuerfelder und VM-Austrittsinformationsfelder (beispielsweise Dateien, die Informationen über VM-Austritte empfangen und die Ursache und die Natur des VM-Austritts beschreiben).
  • Bei einigen Implementationen arbeitet TDIX als Ersatz für VMX, was viele der Merkmale von VMX einschließt und eine zusätzliche Sicherheitsschicht hinzufügt, gemäß hier beschriebenen Ausführungsformen. Bei anderen Implementationen arbeitet TDIX mit VMX zusammen. Beispielsweise kann ein CSP-Host-Server, der eine Virtualisierungsarchitektur (beispielsweise VMX) ausführt, sowohl eine MK-TME-Technologie als auch eine TDIX-Architektur für eine wirksame Ausführung von Mandantensoftware verwenden müssen. Gemäß einigen Ausführungsformen verwenden MK-TME-Verschlüsselungsschaltungen einen Ciphertext-Stealing-Advanced-Verschlüsselungsstandard (XTS-AES) in Übereinstimmung mit IEEE 1619, einem Standard des Institute of Electronics and Electrical Engineers. Ein Host-Server kann sehr sensitive Anwendungen innerhalb TDIs ausführen, so dass selbst der VMs ausführende Hypervisor keinen Zugriff auf die einer TDI zugeordneten Speicherseiten und Verschlüsselungsschlüssel und ihre vertrauenswürdige Rechenbasis (TCB) hat. Eine TCB bezieht sich auf einen Satz von Hardware-, Firmware- und/oder Softwarekomponenten, die eine Fähigkeit haben, das Vertrauen für den Gesamtbetrieb des Systems zu beeinflussen. Gleichzeitig kann der Host-Server Anwendungen, die weniger Sicherheit und Isolation erfordern, unter Verwendung der MK-TME-Technologie ausführen, wobei der Hypervisor die Kontrolle über Speicherseiten und Verschlüsselungsschlüssel behält, die bei diesen weniger sensitiven Anwendungen verwendet werden. Der VMM kann dann verschiedene Anwendungen unter Verwendung verschiedener MK-TME-Schlüssel voneinander isolieren, jedoch weiter in der TCB jeder Anwendung bleiben.
  • Aspekte der vorliegenden Offenbarung adressieren in verschiedenen Implementationen die Notwendigkeit zum Ermöglichen einer Koexistenz zwischen der MK-TME-Technologie und der TDIX-Architektur. Bei einigen Implementationen gewährleistet das offenbarte Rechensystem, dass TDIs zugeordnete Schlüsselkennungen nicht von MK-TME-Software in der Art des Hypervisors oder von VMs, die außerhalb der TCB der TDI ausgeführt werden, verwendet werden können. Bei verwandten Implementationen gewährleisten die offenbarten Architekturen, dass keine Schlüsselkennung, die als eine beschränkte Schlüsselkennung für die TDI zugewiesen ist, gleichzeitig von zwei aktiven TDIs verwendet werden kann. Es kann im Interesse einer zusätzlichen Sicherheit in TDIs gespeicherter Daten auch wünschenswert sein, dass Schlüsselkennungen ausgelöschter TDIs anderen TDIs wieder zugewiesen werden, nachdem alle Cache-Daten in Zusammenhang mit der ausgelöschten TDI geräumt wurden.
  • ZUGRIFF AUF GETEILTE DATENSTRUKTUREN
  • Überdies kann ein Client selbst innerhalb einer sehr sicheren TDI mit geteilten Strukturen, beispielsweise geteilten Hardwarevorrichtungen, kommunizieren müssen. Beispielsweise können Ein-/Ausgabe(E/A)-Vorrichtungen, Drucker, Netzadapter, Router oder andere Verarbeitungsvorrichtungen und dergleichen unter Verwendung der MK-TME-Schutzmaßnahmen von mehreren TDIs und vom VMs ausführenden Hypervisor verwendet werden. Bei einigen Implementationen wird der Zugriff auf solche geteilten Strukturen (vor anderen Anwendungen oder bösartigen Angriffen von außen) durch Verschlüsseln von Speichertransaktionen in Bezug auf Operationen der geteilten Strukturen gesichert. Dementsprechend kann eine TDI in der Lage sein müssen, verschiedene Verschlüsselungsschlüssel zu verwenden: wenigstens einen beschränkten Schlüssel für ihre sicheren Operationen und den Zugriff auf die privaten Speicherseiten der TDI und wenigstens einen unbeschränkten Schlüssel für die TDI-Kommunikationen mit den geteilten Strukturen. In einer TCB einer TDI ausgeführte Software kann versuchen, einen unbeschränkten Schlüssel für Speichertransaktionen, die private Speicherseiten betreffen, zu verwenden. Beispielsweise kann vertrauenswürdige Software versuchen, Daten unter Verwendung eines unbeschränkten Schlüssels in eine private Speicherseite zu schreiben. Bei Nichtvorhandensein eines in der momentanen Spezifikation offenbarten Hardwareschutzes können solche Daten für einen Softwarezugriff (beispielsweise eine Leseoperation) von einem Programm außerhalb der TCB, das Zugriff auf den geteilten unbeschränkten Schlüssel erhalten kann, verwundbar sein.
  • Einige Systeme zum Bereitstellen einer Isolation in virtualisierten Systemen entfernen die CSP-Software nicht ganz aus der TCB des Mandanten. Ferner können solche Systeme die TCB durch die Verwendung getrennter Chipsatz-Untersysteme erheblich vergrößern, was Implementationen dieser Offenbarung vermeiden. Die TDI-Architektur dieser Offenbarung sieht eine Isolation zwischen Kunden(Mandanten)-Arbeitslasten und CSP-Software durch Entfernen der CSP-Software aus der TCB vor, wodurch die TCB explizit verkleinert wird. Implementationen bieten eine technische Verbesserung gegenüber alternativen Systemen durch Bereitstellen einer sicheren Isolation für CSP-Kundenarbeitslasten (Mandanten-TDIs) und ermöglichen das Entfernen von CSP-Software aus der TCB eines Kunden, während die Sicherheits- und Funktionalitätsanforderungen des CSPs erfüllt werden. Zusätzlich ist die TDI-Architektur auf mehrere TDIs, welche mehrere Mandantenarbeitslasten unterstützen können, skalierbar. Ferner kann die hier beschriebene TDI-Architektur auf jeden dynamischen Direktzugriffsspeicher (DRAM) oder Storage-Class-Memory(SCM)-basierten Speicher in der Art eines nichtflüchtigen Doppelreihen-Speichermoduls (NV-DIMM) angewendet werden. Daher ermöglichen die offenbarten Ausführungsformen, dass Software Leistungsvorteile in der Art eines NVDIMM-Direktzugriffsspeicher(DAS)-Modus für SCM ausnutzt, ohne Plattformsicherheitsanforderungen zu beeinträchtigen.
  • Es ist eine Vielzahl von Technologien aufgetreten, die versuchen, Systeme und Speicher sicher zu machen, insbesondere weil immer mehr Unternehmensdaten in die Cloud verschoben werden. Neu auftretende Technologien umfassen die vorstehend erwähnte Gesamtspeicherverschlüsselung (TME), wobei Daten, die sich von einem Kern in den Speicher bewegen, in Hardware verschlüsselt werden und auf ihrem Weg zurück zum Kern wiederum in Hardware entschlüsselt werden. Die Mehrschlüssel-TME (MK-TME) ist eine Erweiterung von TME, welche die Verwendung mehrerer Schlüssel (die Anzahl der unterstützten Schlüssel ist implementationsabhängig) und Software, die konfigurierbar ist, um zu ermöglichen, dass verschiedene Seiten unter Verwendung verschiedener Schlüssel verschlüsselt werden, ermöglicht. Die MK-TME-Maschine unterstützt einen Schlüssel pro Vertrauenswürdige-Domänen-Insel/Mandant (jede vertrauenswürdige Domänen-Insel kann als eine unabhängige Arbeitslast ausführend betrachtet werden) und hilft dabei, die kryptographische Isolation zu erreichen, beispielsweise zwischen verschiedenen CSP-Arbeitslasten.
  • Offenbarte Ausführungsformen stellen ein verbessertes Speichersystem bereit. Die Vertrauenswürdige-Domänen-Insel-Erweiterung(TDIX)-Architektur definiert eine manchmal in einem System-on-a-Chip(SoC)-Zusammenhang verwendete Fähigkeit, die eine Isolation zwischen Kunden- oder Mandantenarbeitslasten und der Cloud-Dienstanbieter(CSP)-Software bereitstellt. Schlüsselkomponenten der TDIX-Architektur weisen einige der vorstehend beschriebenen Aspekte auf, einschließlich der Folgenden: 1) Speicherverschlüsselung über eine Gesamtspeicherverschlüsselungs(TME)-Maschine und Mehrschlüsselerweiterungen von TME (MK-TME), 2) Softwareressourcen-Managementschicht (TDI-RM) und 3) Ausführungszustands- und Speicherisolationsfähigkeiten, beispielsweise in einem System-on-a-Chip (SoC). Die TDIX-Architektur bietet gegenüber Software einen Vorteil, nämlich die Fähigkeit, 1) Gesamtspeicherverschlüsselung, 2) Mehrschlüssel-Speicherverschlüsselung und 3) vertrauenswürdige Domänen-Inseln auf der Grundlage von Verwendungs- und Sicherheitsanforderungen bereitzustellen.
  • SICHERER ARBITRIERUNGSMODUS
  • TDIX baut auf dem sicheren Arbitrierungsmodus (SEAM) auf, der eine Erweiterung von VMX und MK-TME ist. Das im SEAM-Modus laufende TDIX-SEAM-Modul dient als vertrauenswürdiger Vermittler zwischen dem Host-VMM und den Gast-TDIs. Weil TDIX auf MK-TME aufbaut, beruht es für die verfügbare Anzahl von Verschlüsselungsschlüsseln auf der gleichen Architektur und kann unter einigen der gleichen Beschränkungen leiden, d. h. die Anzahl der verfügbaren Schlüsselkennungen kann begrenzt sein, weil sie physische Adressbits verwenden. Offenbarte Ausführungsformen erhöhen die Anzahl der Schlüsselkennungen für TDIX pro Plattform durch Begrenzen des Geltungsbereichs von Schlüsselkennungen auf TDIX-Inseln.
  • ERZEUGEN, BEREITSTELLEN, VERWENDEN UND ZERSTÖREN VON VERTRAUENSWÜRDIGEN DOMÄNEN-INSELN
  • Demgemäß werden hier Ausführungsformen einer Erfindung offenbart, wobei TDIX-Inseln verwendet werden, welche in sich abgeschlossene Speicherpartitionen sind, wobei der TDI-Schlüsselkennungs-Geltungsbereich innerhalb der Insel enthalten ist. Falls eine TDIX-Insel als Socket definiert ist, würden die Schlüsselkennungen beispielsweise ferner mit der Anzahl der Sockets auf der Plattform skalieren, weil sie auf einer Pro-Socket-Basis eindeutig wären. Dies ermöglicht die Skalierung von Schlüsselkennungen über die Physische-Adressen-Bitbeschränkungen hinaus auf der Grundlage der Anzahl der Inseln pro Plattform.
  • Vorteile der offenbarten Ausführungsformen umfassen Folgende: 1) eine Unterstützung für eine (Vertrauenswürdige-Domänen-Insel-Erweiterung)-Architektur, die eine Sicherheitsumgebung mit hoher Garantie bereitstellt, einschließlich beispielsweise Mandantensoftware ausführenden CSP-Arbeitslasten, 2) eine Fähigkeit zum Skalieren von TDIX-Schlüsseln oder Schlüsselkennungen über die Physische-Adressen-Bitbeschränkungen hinaus und 3) eine Unterstützung für TDIX-Inseln könnte als SEAM/SW-Upgrade für ein die TDIX-Architektur verwendendes System implementiert werden.
  • Einige alternative unterlegene Ansätze, die TD-Inseln nicht ausnutzen, unterstützen nicht viele TDIX-Fähigkeiten, wie Speicherintegrität, EPT (Extended Page Tables), was dann eine wesentliche Einschränkung für die Installation in Cloud-Szenarien ist. Alternative Ansätze nutzen auch kein Schlüsselkonzept für TD-Inseln für die Schlüsselskalierung.
  • Wie vorstehend erwähnt, erweitert die Vertrauenswürdige-Domänen-Insel-Erweiterung(TDIX)-Architektur Virtuelle-Maschine-Erweiterungen (VMX) durch eine als vertrauenswürdige Domänen-Insel (TDI) bezeichnete neue Art eines Virtuelle-Maschine-Gasts. Eine TDI läuft in einem CPU-Modus, der die Vertraulichkeit seiner Speicherinhalte und seines CPU-Zustands vor jeglicher anderer Software, einschließlich des hostenden Virtuelle-Maschine-Überwachers (VMM), schützt, sofern sie nicht explizit von der TDI selbst geteilt werden. TDIX baut auf dem sicheren Arbitrierungsmodus (SEAM) auf, der eine Erweiterung von VMX und MK-TME ist. Das im SEAM-Modus laufende Intel-TDIX-SEAM-Modul ist eine Art eines parallelen VMMs, die als Vermittler zwischen dem Host-VMM und den Gast-TDIs dient. Weil TDIX auf MK-TME aufbaut, beruht es für die Anzahl der Verschlüsselungsschlüssel auf derselben Architektur und leidet an einigen der gleichen Beschränkungen (d. h. einer begrenzten Anzahl von Schlüsselkennungen), weil sie physische Adressbits verwenden. Ausführungsformen der vorliegenden Offenbarung stellen einen Weg zum Erhöhen der Anzahl der Schlüsselkennungen pro Plattform durch Begrenzen des Geltungsbereichs der Schlüsselkennungen auf individuelle TDIX-Inseln bereit. Falls eine TDIX-Insel ein Socket ist, würden die Schlüsselkennungen beispielsweise weiter durch die Anzahl der Sockets auf der Plattform skalieren.
  • Insbesondere stellen die offenbarten Ausführungsformen die Vorteile der Erfindung durch Ausführen von einem oder mehreren der folgenden Algorithmen sicher:
    1. 1) Partitionsspeicher wird für die Verwendung mit TDIX in Inseln verfügbar gemacht, wobei eine Insel ein zusammenhängender physischer Speicherbereich ist und einige konfigurierbare TDIX-Speicherbereiche (CMRs) umspannen kann. Ein einziger CMR kann mehrere Inseln unterstützen. Für ein Beispiel der Partitionierung von Speicher in TD-Inseln sei auf die nachfolgende Erörterung von 3 verwiesen.
    2. 2) Gewährleisten, dass der gesamte Speicher, der beispielsweise durch einen VMM einer TDI (durch VMM) zugeordnet wird, in einer einzigen Insel vorhanden ist (darauf beschränkt ist). Verwenden von SEAM als vertrauenswürdiger Vermittler zwischen Speicher und Prozessorkernen zur Prüfung und Erzwingung, dass jede TDI auf eine einzige Insel beschränkt ist. Die Zuordnung der privaten Seite aller TDIs zu einer einzigen Insel wird durch SEAM erzwungen/geprüft.
    3. 3) Jede Insel wird einer getrennten Speicherverschlüsselungs-Schlüsseltabelle (zur Verschlüsselung von Inselspeicher) zugeordnet (damit assoziiert). Auf eine Insel abzielende Speichertransaktionen werden mit einem aus der eindeutigen Schlüsseltabelle der Insel ausgewählten Schlüssel verschlüsselt (auf der Grundlage der Speichertransaktions-Schlüsselkennung).
    4. 4) Die Speicherpartitionierung von Inseln wird zur System-Boot-Zeit festgelegt und gesperrt. Gemäß einigen Ausführungsformen geschieht die Partitionierung durch das BIOS (eingebaute Betriebssystem) auf der Grundlage einer Hardwareunterstützung für die Anzahl der Schlüsseltabellen und zugeordneten Inseln. Nach der Partitionierung kann das BIOS in einer Advanced-Configuration-and-Power-Interface(ACPI)-Tabelle über die Einrichtung berichten, d. h. mit jeder Insel assoziierte Speicherbereiche. Gemäß einigen Ausführungsformen wird die Konfiguration durch sichere Systemsoftware geprüft und validiert (beispielsweise kann die MCHECK-Funktion verwendet werden, um die Konsistenz zwischen zugeordneten Partitionen zu prüfen).
  • Sobald sie konfiguriert wurden, können der VMM und der TDIRM gemäß einigen Ausführungsformen eine fortgesetzte Ausnutzung von Vorteilen der Erfindung unterstützen. Beispielsweise können der VMM und der TDIRM zur TDI-Erzeugungszeit (TDICREATE) eine TDI einer der Inseln im System zuweisen (darauf beschränken). Als ein weiteres Beispiel zuordnen/zuweisen der VMM und der TDIRM, wenn private Seiten TDIs zugeordnet und zugewiesen werden, nur Seiten in der Insel, der TDIs zur Erzeugungszeit zugewiesen wurden. Weitere Vorteile können erreicht werden, wenn die TDI-Speicherverschlüsselung gestartet wird, wobei die TDI-Schlüsselprogrammierung nur für die Schlüsseltabelle gestartet wird, die der mit der TDI (unter Verwendung von TDICONFIGKEYS) zugeordneten Insel assoziiert ist. Wenn die Einplanung aufgehoben wird, werden in der TDI nur die Caches geräumt, die auf die TDI-Insel abgebildet sind, d. h. bevor die zurückgerufenen Schlüsselkennungen der TDI einer neu geplanten TDI zugeordnet werden.
  • Offenbarte Ausführungsformen unterstützen daher eine Speicherverwaltung und -abbildung auf einer Pro-Insel-Basis. Ferner unterstützen offenbarte Ausführungsformen eine TD-Inselzuweisung zur Erzeugungszeit (d. h. bei TDICREATE) und gewährleisten, dass alle privaten TDI-Seiten nur einer dieser Insel zugewiesenen TDI zugewiesen werden. Es wird die Konfiguration eines Speicherverschlüsselungsschlüssels pro Insel unterstützt (TDICONFIGKEYS).
  • Es sei bemerkt, dass offenbarte Ausführungsformen Cache-Räumungen (TBWBINVD) auf einer Pro-Insel-Basis unterstützen, was Leistungsvorteile hat, weil dabei nicht alle Caches im System geräumt werden.
  • Wie vorstehend erwähnt, wird infolge des in sich abgeschlossenen Geltungsbereichs von Verschlüsselungs-Host-Schlüsselkennungen bei den TD-Inseln in offenbarten Ausführungsformen die Anzahl der für die Plattform verfügbaren Schlüsselkennungen erhöht. Wenn jede TD-Insel auf einen von mehreren Sockets in einer Plattform abgebildet wird, ist die Anzahl der Host-Schlüsselkennungen (HKIDs) im System beispielsweise gleich der Anzahl der Sockets im System multipliziert mit der Anzahl der Einträge in der Schlüsseleigentümerschaftstabelle (KOT). Bei einem anderen Beispiel ist, wenn jede TD-Insel auf eine von mehreren Speichersteuereinrichtungen in jedem von mehreren Sockets in einer Plattform abgebildet wird, die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Speichersteuereinrichtungen in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT.
  • 1 ist ein Blockdiagramm, das Verarbeitungskomponenten zur Ausführung von Befehlen gemäß einigen Ausführungsformen zeigt. Wie dargestellt ist, speichert der Speicher 101 einen oder mehrere auszuführende Befehle 103. Beim Betrieb werden der eine oder die mehreren Befehle 103 durch eine Abrufungsschaltungsanordnung 105 aus dem Speicher 101 abgerufen. Der abgerufene Befehl 107 wird durch eine Decodierschaltungsanordnung 109 decodiert, um einen decodierten Befehl 111 zu erzeugen. Gemäß einigen Ausführungsformen umfasst diese Decodierung das Erzeugen mehrerer Mikrooperationen, die von der Ausführungsschaltungsanordnung (in der Art einer Ausführungsschaltungsanordnung 117) auszuführen sind. Die Decodierschaltungsanordnung 109 decodiert auch Befehlssuffixe und -präfixe (falls verwendet).
  • Gemäß einigen Ausführungsformen stellt eine Registerumbenennungs-, Registerzuordnungs- und/oder Planungsschaltung 113 eine Funktionalität bereit, um eines oder mehrere der Folgenden auszuführen: 1) Umbenennen logischer Operandenwerte in physikalische Operandenwerte (beispielsweise gemäß einigen Ausführungsformen eine Register-Alias-Tabelle), 2) Zuweisen von Statusbits und Flags zu decodierten Befehlen und 3) Planen von decodierten Befehlen zur Ausführung auf der Ausführungsschaltungsanordnung 117 von einem Befehls-Pool aus (beispielsweise unter Verwendung einer Reservierungsstation gemäß einigen Ausführungsformen).
  • Register (eine Registerdatei) und/oder ein Speicher 115 speichern Daten als Operanden der Befehle, die durch die Ausführungsschaltungsanordnung 117 zu verarbeiten sind. Gemäß einigen Ausführungsformen übergibt die Rückschreibschaltung 119 Ergebnisse ausgeführter Befehle.
  • Beispielhafte Registertypen umfassen Schreibmaskenregister, gepackte Datenregister, Register für allgemeine Zwecke und Gleitkommaregister, wie nachstehend zumindest mit Bezug auf 19 weiter beschrieben und dargestellt wird. Die Ausführungsschaltungsanordnung 117 und das System 100 werden weiter mit Bezug auf die 2 - 16, 20A-B und 21A-B dargestellt und beschrieben.
  • 2A zeigt ein Blockdiagramm einer Ausführungsform eines Mehr-Socket-Rechensystems, das eine Isolation in virtualisierten Systemen unter Verwendung auf Sockets abgebildeter vertrauenswürdiger Domänen-Inseln (TDI) bereitstellt. Wie dargestellt, weist ein System mit zwei Sockets eine auf jeden Socket abgebildete TD-Insel auf. Eine TD-Insel 200 ist auf Socket 205 abgebildet, der einen oder mehrere Kerne 210, einen Cache 215, zwei AES-XTS-220-Verschlüsselungsschaltungen, zwei Speichersteuereinrichtungen 225 und zwei Sätze aus einem oder mehreren DRAMs 230 aufweist. Eine TD-Insel 255 ist auf Socket 255 abgebildet, der einen oder mehrere Kerne 260, einen Cache 265, zwei AES-XTS-270-Verschlüsselungsschaltungen, zwei Speichersteuereinrichtungen 275 und zwei Sätze aus einem oder mehreren DRAMs 280 aufweist. Aus Gründen der Einfachheit ist jeder der Sockets 205 und 255 als zwei Speichersteuereinrichtungen und Verschlüsselungsschaltungen aufweisend dargestellt, diese Anzahl kann jedoch ohne Einschränkung gemäß anderen Ausführungsformen variieren. Vorteilhafterweise ist bei Verwendung von TDIX-Inseln mit einem in sich abgeschlossenen Geltungsbereich von Schlüsselkennungen die Anzahl der verfügbaren Schlüsselkennungen in der Plattform gleich einer Schlüsseltabellengröße multipliziert mit der Anzahl der Sockets. Beispielsweise wurde die Anzahl der verfügbaren Schlüsselkennungen durch die Verwendung von IDX-Inseln verdoppelt.
  • 2B zeigt ein Blockdiagramm einer Ausführungsform eines Mehr-Socket-Rechensystems, das eine Isolation in virtualisierten Systemen unter Verwendung auf Speichersteuereinrichtungen abgebildeter vertrauenswürdiger Domänen-Inseln (TDI) bereitstellt. Wie dargestellt, weist ein System mit zwei Sockets eine auf jede Speichersteuereinrichtung 225, 275 abgebildete TD-Insel 201, 202, 252, 252 auf. Hier weist Socket 205 einen oder mehrere Kerne 210, einen Cache 215, zwei AES-XTS-220-Verschlüsselungsschaltungen, zwei Speichersteuereinrichtungen 225 und zwei Sätze aus einem oder mehreren DRAMs 230 auf. Socket 255 weist einen oder mehrere Kerne 260, einen Cache 265, zwei AES-XTS-270-Verschlüsselungsschaltungen, zwei Speichersteuereinrichtungen 275 und zwei Sätze aus einem oder mehreren DRAMs 280 auf. Aus Gründen der Einfachheit ist jeder der Sockets 205 und 255 als zwei Speichersteuereinrichtungen und Verschlüsselungsschaltungen aufweisend dargestellt, diese Anzahl kann jedoch ohne Einschränkung gemäß anderen Ausführungsformen variieren. Vorteilhafterweise ist bei Verwendung von TDIX-Inseln mit einem in sich abgeschlossenen Geltungsbereich von Schlüsselkennungen die Anzahl der verfügbaren Schlüsselkennungen in der Plattform gleich einer Schlüsseltabellengröße multipliziert mit der Anzahl der Sockets. Beispielsweise wurde hier durch die Verwendung von TDIX-Inseln, die auf jede von der Kombination von vier Speichersteuereinrichtungen 275 und von AES XTS 270 abgebildet sind, die Anzahl der verfügbaren Schlüsselkennungen vervierfacht. Insbesondere gleicht die Anzahl der verfügbaren Schlüsselkennungen der Anzahl der Sockets multipliziert mit der Schlüsseltabellengröße multipliziert mit der Anzahl der Speichersteuereinrichtungen pro Socket.
  • 3 zeigt eine Ausführungsform einer Speicherkarte eines Rechensystems, wodurch eine Isolation in virtualisierten Systemen unter Verwendung vertrauenswürdiger Domänen-Inseln (TDIs) bereitgestellt wird. Wie dargestellt, hat der Speicher 300 einen oberen Speicherbereich 305 und einen unteren Speicherbereich 310. Der Speicher 300 wurde in N konfigurierbare Speicherbereiche (CMRs) für die Verwendung mit TDIX-Inseln partitioniert: CMR 0 315, CMR 1320, CMR 2 325, CMR 3 335, CMR 4 340, CMR 5 350, CMR 6 355 und CMR N-1 360. Der Speicher 300 enthält auch zwei Nicht-TDIX-Partitionen, nämlich Nicht-TDIX 330 und nicht-TDIX 345. Wie dargestellt, ist der Speicher 300 auch in M TDIX-Inseln unterteilt, nämlich Insel 0 365, Insel 1 370, Insel 2 375, Insel 3 380 und Insel M-1 385, die jeweils eine Schlüsseltabelle aufweisen. Jede der TDIX-Inseln kann auf einen oder mehrere konfigurierbare Speicherbereiche abgebildet werden. Beispielsweise ist die TDIX-Insel 0 365 auf CMR 0 315 und CMR 1 320 abgebildet.
  • 4 zeigt ein Flussdiagramm eines Verfahrens zur Erzeugung einer vertrauenswürdigen Domänen-Insel (TDI) gemäß einer Ausführungsform. Wie dargestellt, soll eine Verarbeitungsvorrichtung in der Art eines TDIRMs (Vertrauenswürdige-Domänen-Insel-Ressourcenmanager) einen Ablauf 400 ausführen. Wie vorstehend beschrieben, kann der TDIRM als Teil des Host-OS, des Hypervisors oder als getrenntes Softwareprogramm arbeiten und hat die vollständige Kontrolle über die Kerne und andere Plattformhardware.
  • Nach Beginn soll der TDIRM bei 405 eine Vertrauenswürdige-Domänen-Insel-Steuerstruktur (TDICS) initialisieren, die einer ersten TDI zugeordnet ist. Bei 410 soll der TDIRM einen geschützten Vertrauenswürdige-Domänen-Insel-Speicher (TDIPM) initialisieren, welcher der ersten TDI zugeordnet ist.
  • Bei 415 soll der TDIRM eine verfügbare Host-Schlüsselkennung (HKID) in einer Schlüsseleigentümerschaftstabelle (KOT) identifizieren. Die KOT ist eine für die Verwaltung des HKID-Inventars innerhalb eines TDIX-fähigen Systems verwendete Datenstruktur. Gemäß einigen Ausführungsformen ist eine spezifische Anzahl von HKIDs für die Verwendung durch alle durch den TDIRM erzeugten TDIs verfügbar. Die KOT hält unter anderem Zustände aller HKIDs, die für die Verwendung durch alle im System erzeugten TDIs verfügbar sind. Eine HKID kann einen Zustand zugewiesen, frei (oder verfügbar), zurückgefordert oder konfiguriert aufweisen.
  • Bei 420 soll der TDIRM die HKID einem kryptographischen Schlüssel zuweisen und die HKID in der TDICS speichern. Gemäß einigen Ausführungsformen weist der TDIRM der verfügbaren HKID (bei 415 identifiziert) auf einer Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TME)-Maschine einen einmaligen kryptographischen Schlüssel zu. Der TDIRM kann einen Befehl (beispielsweise TDCONFIGKEY) ausführen, um den einmaligen kryptographischen Schlüssel und die verfügbare HKID für die Verwendung durch eine Verschlüsselungsmaschine in der Art der Verschlüsselungsmaschine 554 aus 5, die auf der TDI arbeitet, zu konfigurieren. Der TDCONFIGKEY-Befehl entspricht dem zum Definieren und/oder Konfigurieren einer geschützten Domäne in der Art der konfigurierbaren Speicherdomänen des Speichers 300, wie mit Bezug auf 3 erläutert und beschrieben, verwendeten PCONFIG-Befehl. Durch Ausführen des TDCONFIGKEY-Befehls veranlasst der TDIRM eine Speicherschutz-Steuereinrichtung einer MK-TME-Maschine (beispielsweise die Speicherschutz-Steuereinrichtung 842 aus 8), den Schlüssel und einen Schutzmodus für die TDI zu programmieren. Die Speicherschutz-Steuereinrichtung kann dann einen Statuscode zum TDIRM zurückgeben, wodurch angegeben wird, dass der Schlüssel konfiguriert wurde.
  • Bei 425 soll der TDIRM einen ersten Kern mit der ersten TDI assoziieren. Beispielsweise kann der TDIRM einen logischen Prozessor mit der ersten TDI assoziieren, die auf dem assoziierten logischen Prozessor arbeiten kann. Gemäß einigen Ausführungsformen wirkt der TDIRM als ein vollständiger Host und übt Kontrolle über den logischen Prozessor und den Verarbeitungskern, worauf der logische Prozessor arbeitet, aus. Die Aktionen, die erforderlich sind, um einen logischen Prozessor mit der TDI zu assoziieren, werden in weiteren Einzelheiten mit Bezug auf 11 beschrieben.
  • Bei 430 soll der TDIRM dem TDIPM eine Speicherseite von einem Adressraum des ersten Kerns hinzufügen. Beispielsweise fügt der TDIRM dem TDIPM eine Speicherseite vom Adressraum eines logischen Prozessors hinzu, wie detaillierter mit Bezug auf 12 beschrieben.
  • Gemäß einigen Ausführungsformen misst der TDIRM bei 435 die Speicherseite durch Erweitern einer TDI-Messung durch einen Inhaltsbestandteil der Speicherseite. Beispielsweise führt der TDIRM einen spezifischen Befehl (beispielsweise TDEXTEND) zur Erweiterung der TDI-Messung mit den Inhalten der hinzugefügten Seite aus. Eine Messung wird auf die TD erweitert, um zu verhindern, dass die für die Erzeugung der TD verwendeten Befehle erneut verwendet werden (beispielsweise TDCREATE, TDADDPAGE usw.). Die Messung der TD kann durch Berechnen eines sicheren Hashes über die Eingaben von Befehlen erhalten werden, die verwendet werden, um die TD zu erzeugen und den anfänglichen Code und die Daten in den Speicher zu laden (beispielsweise TDCREATE, TDADD und TDEXTEND). Die Messung kann unter Verwendung eines sicheren Hashing-Algorithmus berechnet werden, so dass die Systemsoftware nur eine TD bilden kann, die mit einer erwarteten Messung übereinstimmt, indem der genauen Sequenz der vom TDIRM ausgeführten Befehle gefolgt wird. Der TDIX-Entwurf kann eine sichere 256-Bit-SHA-2-Hash-Funktion verwenden, um die Messungen zu berechnen. Gemäß einer Ausführungsform kann die TD-Messung auf jeden 256-Byte-Bereich der zum TDPM hinzugefügten Seite erweitert werden. Die Messung wird wiederholt, bis jeder 256-Byte-Bereich der hinzugefügten TD-Seite gemessen wurde. Jede TD-Messung kann in einem Feld der TDCS gespeichert werden.
  • Bei 440 soll der TDIRM die Ausführungssteuerung auf den ersten Kern übertragen, um die erste TDI auszuführen (wie weiter mit Bezug auf 13 beschrieben wird), wobei der Geltungsbereich des TDIPMs auf die Grenzen der ersten TDI beschränkt ist.
  • 5 zeigt ein Blockdiagramm einer Ausführungsform eines Rechensystems, das eine Isolation in virtualisierten Systemen unter Verwendung von vertrauenswürdigen Domänen-Inseln (TDIs) bereitstellt. Beim Betrieb kann das Rechensystem 500 gemäß Implementationen dieser Offenbarung eine Isolation in virtualisierten Systemen unter Verwendung von TDIs bereitstellen. Das Rechensystem 500 kann einen Virtualisierungsserver 501 aufweisen, der einen Prozessor 550, einen Speicher 535 und eine Netzschnittstelle 555 aufweist. Der Prozessor 550 kann eine TDI-Architektur und ISA-Erweiterungen für die TDI-Architektur (beispielsweise TDIX) implementieren.
  • Die TDI 520A, 520N kann als Teil der durch den Prozessor 550 implementierten TDI-Architektur ausgeführt werden. Die TDI 520A, 520N kann sich auf eine Softwareausführungsumgebung zur Unterstützung einer Kunden(beispielsweise Mandanten)-Arbeitslast beziehen. Wie dargestellt, weist die TDI 520A eine TDICS 510A auf, die eine TCSList 612, eine TDI-Kennung 614, eine Schlüsselkennung 616, eine Revisionskennung 618, eine TDI-Messung 620, eine MK-TME-Schlüsselschlitzkennung 622 und andere TDI-Metadaten 624 aufweist, wie in 6 dargestellt. Die TDI 520A weist auch eine TDITCS 515A auf, die eine übergeordnete TDICS-Referenz 630 und einen TDI-Zustand 632 aufweist, wie in 6 dargestellt. Die TDI 520A weist ferner eine TDIRCS 634 auf, die einen TDIRM-Zustand 636 aufweist. TDICS 510A, TDITCS 515A und TDIRCS 634 laufen alle im TDIPM 608.
  • Die Mandantenarbeitslast kann ein OS zusammen mit anderen über dem OS laufenden Anwendungen aufweisen. Die Mandantenarbeitslast kann auch eine über einem VMM laufende VM aufweisen. Die TDI-Architektur kann eine Fähigkeit zum Schützen der in einer TDI 520A, 520N laufenden Mandantenarbeitslast durch Bereitstellen einer Isolation zwischen der TDI 520A, 520N und anderer Software (beispielsweise durch den CSP bereitgestellter Software), die auf dem Prozessor 550 ausgeführt wird, bereitstellen. Die TDI-Architektur legt der Anzahl der innerhalb eines Systems arbeitenden TDIs keine Architekturbeschränkungen auf, Software- und Hardwarebeschränkungen können jedoch die Anzahl der gleichzeitig auf einem System laufenden TDIs infolge anderer Randbedingungen beschränken.
  • Eine Mandantenarbeitslast kann innerhalb einer TDI 520A, 520N ausgeführt werden, wenn der Mandant einem CSP nicht vertraut, Vertraulichkeit zu erzwingen. Um gemäß Implementationen dieser Offenbarung zu arbeiten, muss eine CPU, auf der die TDI auszuführen ist, die TDI-Architektur unterstützen. Gemäß einer Ausführungsform kann die Mandantenarbeitslast eine über einem VMM laufende VM aufweisen. Dabei kann auch ein Virtualisierungsmodus (beispielsweise VMX) durch die CPU unterstützt werden, auf der die TDI auszuführen ist. Gemäß einer anderen Ausführungsform kann die TDI 520A, 520N nicht unter Verwendung eines Virtualisierungsmodus arbeiten, sondern stattdessen ein leichteres Betriebssystem (OS) innerhalb der TDI 520A, 520N ausführen.
  • Die TDI-Architektur kann eine Isolation zwischen der TDI 520A, 520N und anderer auf dem Prozessor 550 ausgeführter Software durch Funktionen einschließlich Speicherverschlüsselung, TDI-Ressourcenverwaltung und Ausführungszustands- und Verwaltungsisolationsfähigkeiten bereitstellen. Eine Verschlüsselungsschaltung 554 des Prozessors 550 kann in den Speicher 535 geschriebene Daten verschlüsseln. Gemäß Ausführungsformen dieser Offenbarung kann die Verschlüsselungsmaschine 554 eine Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TME)-Maschine sein. Die Gesamtspeicherverschlüsselungs(TME)-Technologie ermöglicht die Verschlüsselung von Speicherzugriffen durch auf einem Prozessorkern ausgeführte Software unter Verwendung eines Verschlüsselungsschlüssels. Die Mehrschlüssel-TME-Technologie kann eine TME-Erweiterung sein, die Unterstützung für mehrere Verschlüsselungsschlüssel bereitstellt, wodurch eine aufgegliederte Verschlüsselung ermöglicht wird. Speicherverschlüsselung kann ferner durch mehrere vom Prozessor 550 gehaltene Schlüsseltabellen (beispielsweise Schlüsseleigentümerschaftstabelle (KOT) 562 und Schlüsselverschlüsselungstabelle (KET) 574) unterstützt werden. Die Schlüsseltabellen können im On-Chip-Speicher gespeichert werden, wobei der On-Chip-Speicher durch von der Verarbeitungsvorrichtung ausgeführte Software nicht direkt zugänglich ist. Der On-Chip-Speicher kann sich physisch auf demselben Chip befinden wie der Verarbeitungskern. Eine Ressourcenverwaltungsfähigkeit kann durch einen TDIRM 525 bereitgestellt werden. Ausführungszustands- und Verwaltungsfähigkeiten können durch eine Speichereigentümerschaftstabelle (MOT) 572 und zugangsgesteuerte TDI-Steuerstrukturen in der Art der Vertrauenswürdige-Domänen-Insel-Steuerstruktur (TDICS) 510A, 510N und einer Vertrauenswürdige-Domänen-Insel-Thread-Steuerstruktur (TDITCS) 515A, 515N bereitgestellt werden. Weitere Einzelheiten in Bezug auf die Funktion dieser Komponenten werden nachstehend mit Bezug auf 6 beschrieben.
  • Der TDIRM 525 repräsentiert eine Ressourcenverwaltungsschicht der TDI-Architektur. Gemäß einigen Ausführungsformen kann der TDIRM 525 als Teil des CSP/Root-VMMs (beispielsweise eines primären VMMs, der Maschinenebenenoperationen des VMMs und der VMs behandelt) implementiert werden. Der TDIRM 525 kann ein Softwaremodul sein, das als Teil der TDI-Architektur aufgenommen ist, wodurch der Betrieb der TDIs 520A, 520N behandelt wird. Der TDIRM 525 kann als Host wirken und Kontrolle über den Prozessor und andere Plattformhardware haben. Der TDIRM 525 kann Software in einer TDI einen oder mehrere logische Prozessoren zuweisen und auch einer TDI Physischer-Speicher- und E/A-Ressourcen zuweisen. Wenngleich der TDIRM 525 Ressourcen in der Art von CPU-Zeit, Speicher und E/A-Zugriff in TDIs 520A, 520N zuweisen und verwalten kann, kann er außerhalb der TCB der TDIs 520A, 520N arbeiten. Beispielsweise kann der TDIRM nicht auf den Ausführungszustand einer TDI auf dem einen oder den mehreren zugewiesenen logischen Prozessoren zugreifen und nicht auf den Speicherzustand einer TDI zugreifen/diesen spoofen. Dies kann durch die Verwendung getrennter Verschlüsselungsschlüssel und anderer Integritäts-/Wiedergabesteuerungen auf dem Speicher erzwungen werden.
  • Der Virtualisierungsserver 501 kann eine Anzahl von Client-Vorrichtungen 570A, 570B bis 570N unterstützen. TDIs können von Client-Vorrichtungen 570A, 570B bis 570N über die Netzschnittstelle 555 zugänglich sein. Die Client-Vorrichtungen 570A, 570B bis 570N können durch auf dem Prozessor 550 ausgeführte Software (beispielsweise durch den CSP bereitgestellte Software) miteinander und mit anderen Vorrichtungen kommunizieren. Die TDI 520A, 520N kann sich auf eine Mandantenarbeitslast beziehen, welche die Client-Vorrichtungen 570A, 570B bis 570N durch den Prozessor 550 ausführen. Wie zuvor erörtert, kann die Mandantenarbeitslast ein OS sowie Ring-3-Anwendungen, die über dem OS laufen, aufweisen. Die Mandantenarbeitslast kann gemäß hier beschriebenen Ausführungsformen auch eine über einem VMM (beispielsweise Hypervisor) laufende VM zusammen mit anderen Ring-3-Anwendungen aufweisen. Jede Client-Vorrichtung 570A, 570B bis 570N kann einen Desktopcomputer, einen Tabletcomputer, einen Laptopcomputer, ein Netbook, einen Netbookcomputer, einen persönlichen digitalen Assistenten (PDA), einen Server, eine Workstation, ein Mobiltelefon, eine mobile Rechenvorrichtung, ein Smartphone, ein Internetgerät oder einen anderen Typ einer Rechenvorrichtung umfassen, ist jedoch nicht darauf beschränkt.
  • Der Prozessor 550 kann einen oder mehrere Verarbeitungskerne 560, Bereichsregister 580, eine Speichersteuereinrichtung 552 (beispielsweise eine Speicherverwaltungseinheit (MMU)) und E/A-Ports 556 umfassen. Der Prozessor 550 kann in einem Rechensystem 500 verwendet werden, das einen Desktopcomputer, einen Tabletcomputer, einen Laptopcomputer, ein Netbook, einen Notebookcomputer, einen PDA, einen Server, eine Workstation, ein Mobiltelefon, eine mobile Rechenvorrichtung, ein Smartphone, ein Internetgerät oder einen anderen Typ einer Rechenvorrichtung umfasst, jedoch nicht darauf beschränkt ist. Gemäß einer anderen Ausführungsform kann der Prozessor 550 in einem System-on-a-Chip(SoC)-System verwendet werden.
  • Ein oder mehrere logische Prozessoren (beispielsweise Ausführungs-Threads) können auf einem oder mehreren Verarbeitungskernen 560 arbeiten. Die TDI 520A, 520N kann auf diesen Ausführungs-Threads arbeiten. Der TDIRM 525 kann als vollständiger Host wirken und eine vollständige Kontrolle über den einen oder die mehreren Verarbeitungskerne 560 und alle auf dem einen oder den mehreren Verarbeitungskernen 560 arbeitende logische Prozessoren haben. Der TDIRM 525 kann Software innerhalb der TDI 520A, 520N zur Ausführung auf dem mit der TDI 520A, 520N assoziierten logischen Prozessor zuweisen. Gemäß Ausführungsformen dieser Offenbarung kann der TDIRM 525 jedoch durch die Verwendung getrennter Verschlüsselungsschlüssel nicht auf den Ausführungszustand der TDI 520A, 520N auf dem einen oder den mehreren zugewiesenen logischen Prozessoren zugreifen. Der TDIRM 525 kann daran gehindert werden, auf den Ausführungszustand der TDI 520A, 520N zuzugreifen, weil er sich außerhalb der TCB der TDI 520A, 520N befindet. Daher kann dem TDIRM 525 nicht für den Zugriff auf den Ausführungszustand getraut werden, wodurch möglicherweise dem nicht vertrauenswürdigen TDIRM 525 Informationen über die Mandantenarbeitslast bereitgestellt werden könnten. Durch Verhindern, dass der TDIRM 525 auf den Ausführungszustand der TDI 520A, 520N zugreift, wird die Integrität der auf der TDI 520A, 520N ausgeführten Mandantenarbeitslast erzwungen.
  • Der Virtualisierungsserver 501 kann ferner einen Speicher 535 zum Speichern von Programmbinärdaten und anderen Daten aufweisen. Der Speicher 535 kann sich auf Hauptspeicher beziehen oder sich sowohl auf Hauptspeicher als auch auf Sekundärspeicher beziehen, was Nurlesespeicher (ROM), Festplattenlaufwerke (HDD) usw. einschließen kann. Der TDIRM 525 kann einen spezifischen Teil des Speichers 535 zur Verwendung durch die TDI 520A, 520N als geschützten TD-Insel-Speicher TDIPM 505A, 505N zuordnen. Der TDIPM 505A, 505N kann durch einen einmaligen kryptographischen Schlüssel verschlüsselt werden, der durch den TDIRM 525 erzeugt wird, wenn die TDI 520A, 520N erzeugt wird. Der TDIRM 525 kann den einmaligen kryptographischen Schlüssel für die Verschlüsselung des TDIPM 505A, 505N erzeugen, den einmaligen kryptographischen Schlüssel jedoch nicht für den Zugriff auf innerhalb des TDIRM 505A, 505N gespeicherte Inhalte verwenden.
  • Die TDI 520A, 520N kann Virtueller-Speicher-Adressen, die auf Gast-Physischer-Speicher-Adressen abgebildet sind, und Gast-Physischer-Speicher-Adressen, die durch die Speichersteuereinrichtung 552 auf Host/System-Physischer-Speicher-Adressen abgebildet sind, verwenden. Wenn die TDI 520A, 520N versucht, auf eine Virtueller-Speicher-Adresse zuzugreifen, die einer Physischer-Speicher-Adresse einer in den Speicher 535 geladenen Seite entspricht, kann die Speichersteuereinrichtung 552 die angeforderten Daten durch die Verwendung einer erweiterten Seitentabelle (EPT) 540 und einer Gastseitentabelle (GPT) 545 zurückgeben. Die Speichersteuereinrichtung 552 kann eine EPT-Durchlauf-Logik und eine GPT-Durchlauf-Logik zum Übersetzen physischer Gastadressen in physische Host-Adressen des Hauptspeichers und zum Bereitstellen von Parametern für ein Protokoll, das es dem einen oder den mehreren Verarbeitungskernen 560 ermöglicht, diese Abbildungen zu lesen, zu durchlaufen und zu interpretieren, aufweisen.
  • Gemäß einer Ausführungsform können innerhalb der TDI 520A, 520N ausgeführte Aufgaben nicht direkt unter Verwendung der physischen Adresse des Speichers 535 auf den Speicher 535 zugreifen. Stattdessen greifen diese Aufgaben durch virtuelle Adressen auf den virtuellen Speicher der TDI 520A, 520N zu. Die virtuellen Adressen der Virtueller-Speicher-Seiten innerhalb des virtuellen Speichers können auf die physischen Adressen des Speichers 535 abgebildet werden. Der virtuelle Speicher der TDI 520A, 520N kann in als Virtueller-Speicher-Seiten bezeichnete Einheiten fester Größe, die jeweils eine entsprechende virtuelle Adresse aufweisen, unterteilt werden. Der Speicher 535 kann entsprechend physischen Speicherseiten (beispielsweise Speicher-Frames), die jeweils eine feste Größe aufweisen, organisiert werden. Jedem Speicher-Frame kann eine Kennung zugewiesen werden, die den Speicher-Frame eindeutig identifiziert. Eine Virtueller-Speicher-Seite der virtuellen Adresse kann entsprechend einer Einheit fester Größe im physischen Adressraum des Speichers 535 abgebildet werden (beispielsweise einem Speicher-Frame, einer Physischer-Speicher-Seite). Während der Ausführung einer Gastanwendung (beispielsweise einer VM) innerhalb der TDI 520A, 520N kann der Prozessor 550 ansprechend auf eine Anforderung zum Zugreifen auf den Speicher 535 Abbildungen (beispielsweise Abbildungen einer Virtueller-Speicher-Seite auf eine Physischer-Speicher-Seite in Seitentabellen in der Art der GPT 545 der Gastanwendung und der EPT 540 des TDIRMs 525) für den Zugriff auf Physischer-Speicher-Seiten des Speichers 535 verwenden.
  • Gemäß einer Ausführungsform kann die TDI 520A, 520N durch den TDIRM 525 erzeugt und gestartet werden. Der TDIRM 525 kann die TDI 520A beispielsweise durch Ausführen eines spezifischen Befehls (beispielsweise TDICREATE) erzeugen. Der TDIRM 525 kann einen ausgerichteten 4-KB-Bereich des physischen Speichers 535 (entsprechend einer Speicherseite) auswählen und die Adresse der Speicherseite als Parameter für den Befehl zur Erzeugung der TDI 520A bereitstellen. Der durch den TDIRM 525 ausgeführte Befehl kann ferner den Prozessor 550 veranlassen, einen einmaligen kryptographischen Schlüssel (auch als vergänglicher Schlüssel bezeichnet) zu erzeugen. Der einmalige kryptographische Schlüssel kann einer in der KOT 562 gespeicherten verfügbaren HKID zugewiesen werden. Die KOT 562 kann eine für auf dem Prozessor 550 ausgeführte Software unsichtbare Datenstruktur, beispielsweise zur Verwaltung eines Inventars von HKIDs innerhalb der TDI-Architektur, sein. Die verfügbare HKID kann auch in der TDICS 510A gespeichert werden. Die KOT 562 und die Verwendung von HKIDs werden in weiteren Einzelheiten mit Bezug auf 6 beschrieben. Der Prozessor 550 kann, wie auch in weiteren Einzelheiten mit Bezug auf 6 beschrieben, die MOT 572 konsultieren, um der TDI 520A Speicherseiten zuzuordnen. Die MOT 572 kann eine für auf dem Prozessor 550 ausgeführte Software unsichtbare Datenstruktur sein, die vom Prozessor 550 verwendet wird, um die Zuweisung von Physischer-Speicher-Seiten zu ausführenden TDIs zu erzwingen. Die MOT 572 kann dem TDIRM 525 die Fähigkeit geben, Speicher als Ressource für jede erzeugte TDI (beispielsweise TDI 520A, 520N) zu verwalten, ohne jegliche Einsicht in Daten, die im zugewiesenen TDIPM gespeichert sind, zu erhalten.
  • Der Prozessor 550 kann eine Speicherverschlüsselungsmaschine 554 (beispielsweise MK-TME-Maschine) zur Verschlüsselung (und Entschlüsselung) von Speicher, auf den während der Ausführung eines Gastprozesses (beispielsweise einer Anwendung oder einer VM) zugegriffen wird, innerhalb der TDI 520A, 520N verwenden. Wie vorstehend erörtert wurde, ermöglicht die TME die Verschlüsselung von Speicherzugriffen durch auf einem Verarbeitungskern (beispielsweise dem einen oder den mehreren Verarbeitungskernen 560) ausgeführte Software unter Verwendung eines Verschlüsselungsschlüssels. Die MK-TME ist eine Erweiterung der TME, welche die Verwendung mehrerer Verschlüsselungsschlüssel ermöglicht, wodurch eine aufgegliederte Verschlüsselung ermöglicht wird. Gemäß einigen Ausführungsformen kann der Prozessor 550 die Verschlüsselungsmaschine 554 verwenden, um zu bewirken, dass verschiedene Seiten unter Verwendung verschiedener Verschlüsselungsschlüssel (beispielsweise einmaliger Verschlüsselungsschlüssel) verschlüsselt werden. Gemäß verschiedenen Ausführungsformen kann die Verschlüsselungsmaschine 554 in der hier beschriebenen TDI-Architektur verwendet werden, um einen oder mehrere Verschlüsselungsschlüssel (beispielsweise vergängliche Schlüssel), die für jede TDI 520A, 520N erzeugt werden, zu unterstützen, um dabei zu helfen, eine kryptographische Isolation zwischen verschiedenen Mandantenarbeitslasten zu erreichen. Wenn die Verschlüsselungsmaschine 554 in der TDI-Architektur verwendet wird, kann die CPU beispielsweise standardmäßig erzwingen, dass alle Seiten, die mit jeder TDI 520A, 520N assoziiert sind, unter Verwendung eines für diese TDI spezifischen Schlüssels verschlüsselt werden.
  • Jede TDI 520A, 520N kann ferner wählen, dass spezifische TDI-Seiten Klartext sind oder durch die Verwendung verschiedener Verschlüsselungsschlüssel, die für auf dem Prozessor 550 ausgeführte Software (beispielsweise durch den CSP bereitgestellte Software) opak sind, verschlüsselt werden. Beispielsweise können Speicherseiten innerhalb des TDIPMs 505A, 505N durch die Verwendung einer Kombination von Verschlüsselungsschlüsseln, die dem TDIRM 525 unbekannt sind, und eine Bindeoperation (beispielsweise eine Operation zur Abbildung der virtuellen TDI-Adressen auf entsprechende physische Adressen) verschlüsselt werden. Die durch den TDIRM 525 ausgeführte Bindeoperation kann die Speicherseiten innerhalb des TDIPMs 505A, 505N durch die Verwendung einer physischen Host-Adresse (HPA) der Seite als Parameter für einen Verschlüsselungsalgorithmus, der für die Verschlüsselung der Speicherseite verwendet wird, an eine bestimmte TDI binden. Falls eine Speicherseite zu einer anderen Stelle des Speichers 535 verschoben wird, kann die Speicherseite daher selbst dann nicht korrekt entschlüsselt werden, wenn der TDI-spezifische Verschlüsselungsschlüssel verwendet wird.
  • Gemäß einer Ausführungsform kann die TDI 520A, 520N durch den TDIRM 525 zerstört werden. Der TDIRM 525 kann die TDI 520A beispielsweise durch Ausführen eines spezifischen Befehls (beispielsweise TDISTOP) veranlassen, die Ausführung auf einem der TDI 520A zugeordneten logischen Prozessor zu unterbrechen. Der TDIRM 525 kann alle Cache-Einträge eines Caches 570 räumen, wobei der Cache 570 dem die TDI 520A ausführenden logischen Prozessor zugeordnet ist. Sobald alle Cache-Einträge des Caches 570 geräumt wurden, kann der TDIRM 525 die dem einmaligen kryptographischen Schlüssel zugewiesene HKID als für die Zuweisung zu einem anderen einmaligen kryptographischen Schlüssel in Zusammenhang mit anderen TDIs (beispielsweise TDI 520N) verfügbar markieren. Der TDIRM 525 kann dann alle Seiten aus dem mit der TDI 520A assoziierten TDIPM (beispielsweise TDIPM 505A) entfernen.
  • Das Rechensystem 500 repräsentiert Verarbeitungssysteme, die auf PENTIUM IM™, PENTIUM 4™, Xeon™, Itanium, XSCALE™ oder CORE™, die von Intel Corporation aus Santa Clara, Kalifornien, verfügbar sind, Prozessoren von Advanced Micro Devices, Inc., ARM-Prozessoren in der Art der ARM-Cortex®-Prozessorfamilie, StrongARM™-Vorrichtungen und/oder anderen Vorrichtungen beruhen. Gemäß anderen Ausführungsformen können auch andere Systeme verwendet werden (beispielsweise PCs mit anderen Mikroverarbeitungsvorrichtungen, Ingenieurs-Workstations, Settop-Boxes usw.). Bei einer Implementation führt das Rechensystem 500 eine Version des von Microsoft Corporation aus Redmond, Washington erhältlichen Windows™-Betriebssystems aus, wenngleich auch andere Betriebssysteme (beispielsweise UNIX, Linux usw.), eingebettete Software und/oder graphische Benutzerschnittstellen verwendet werden können. Demgemäß sind Implementationen dieser Offenbarung auf keine spezifische Kombination einer Hardwareschaltungsanordnung und von Software beschränkt.
  • Bei einem der Erläuterung dienenden Beispiel können der eine oder die mehreren Verarbeitungskerne 560 Prozessorlogik und -schaltungen (beispielsweise Mikroarchitekturen) aufweisen. Der eine oder die mehreren Verarbeitungskerne 560 mit verschiedenen Mikroarchitekturen können sich zumindest einen Teil eines gemeinsamen Befehlssatzes teilen. Beispielsweise können ähnliche Registerarchitekturen auf verschiedene Arten in verschiedenen Mikroarchitekturen unter Verwendung verschiedener Techniken implementiert werden, einschließlich dedizierter physischer Register, eines oder mehrerer dynamisch zugeordneter physischer Register unter Verwendung eines Registerumbenennungsmechanismus (beispielsweise durch die Verwendung einer Register-Alias-Tabelle (RAT), eines Umordnungspuffers (ROB), einer Zurückzieh-Registerdatei usw.). Der eine oder die mehreren Verarbeitungskerne 560 können Befehle des Rechensystems 500 ausführen. Die Befehle können eine Vorabruflogik zum Abrufen von Befehlen, eine Decodierlogik zum Decodieren von Befehlen, eine Ausführungslogik zur Ausführung von Befehlen und dergleichen einschließen, sind jedoch nicht darauf beschränkt. Der eine oder die mehreren Prozessorkerne 560 können einen Cache 570 zum Speichern von Befehlen und/oder Daten aufweisen. Der Cache 570 kann einen Level-One(L1)-Cache, einen Level-Two(L2)-Cache und einen Last-Level-Cache (LLC) einschließen, ist jedoch nicht darauf beschränkt. Der Cache 570 kann auch eine andere Konfiguration des Cache-Speichers innerhalb des Prozessors 550 aufweisen.
  • Implementationen der vorliegenden Offenbarung sind nicht auf Desktop-Rechensysteme beschränkt. Alternative Implementationen können in anderen Vorrichtungen in der Art handgehaltener Vorrichtungen und eingebetteter Anwendungen verwendet werden. Einige Beispiele handgehaltener Vorrichtungen umfassen Mobiltelefone, Internetprotokollvorrichtungen, Digitalkameras, persönliche digitale Assistenten (PDAs), handgehaltene PCs usw. Eingebettete Anwendungen können eine Mikrosteuereinrichtung, eine digitale Signalverarbeitungsvorrichtung (DSP), einen SoC, Netzcomputer (NetPC), Settop-Boxes, Netz-Hubs, Weitbereichsnetz(WAN)-Switches oder ein anderes System, das einen oder mehrere Befehle gemäß zumindest einer Spezifikation ausführen kann, einschließen.
  • Eine Implementation kann im Kontext eines Einzelverarbeitungsvorrichtungs-Desktopcomputer-oder-Serversystems beschrieben werden und durch alternative Implementationen in ein Mehrverarbeitungsvorrichtungssystem aufgenommen werden. Das Rechensystem 500 kann ein Beispiel einer „Hub“-Systemarchitektur sein. Das Rechensystem 500 kann einen Prozessor 550 zur Verarbeitung von Datensignalen aufweisen. Der Prozessor 550 kann als ein der Erläuterung dienendes Beispiel eine Komplexer-Befehlssatz-Architektur(CISC)-Mikroverarbeitungsvorrichtung, eine Reduzierter-Befehlssatz-Architektur(RISC)-Mikroverarbeitungsvorrichtung, eine Sehr-langes-Befehlswort(VLIW)-Mikroverarbeitungsvorrichtung, eine Verarbeitungsvorrichtung, die eine Kombination von Befehlssätzen implementiert, oder eine andere Verarbeitungsvorrichtung in der Art beispielsweise einer Digitalsignal-Verarbeitungsvorrichtung einschließen. Der Prozessor 550 kann mit einem Verarbeitungsvorrichtungsbus gekoppelt sein, der Datensignale zwischen dem Prozessor 550 und anderen Komponenten im Rechensystem 500 in der Art des Hauptspeichers und/oder eines Sekundärspeichers innerhalb des Speichers 535 überträgt, Befehlsdaten speichert oder eine Kombination davon ausführt. Die anderen Komponenten des Rechensystems 500 können einen Graphikbeschleuniger, einen Speichersteuereinrichtungs-Hub, einen E/A-Steuereinrichtungs-Hub, einen Drahtlostransceiver, ein Flash-BIOS, eine Netzsteuereinrichtung, eine Audiosteuereinrichtung, einen seriellen Erweiterungsport, eine Ein-/Ausgabe(E/A)-Steuereinrichtung usw. umfassen. Diese Elemente führen ihre herkömmlichen Funktionen aus, die Fachleuten auf dem Gebiet wohlbekannt sind.
  • Bei einer Implementation kann der Prozessor 550 einen internen L1-Cache-Speicher als Teil des Caches 570 aufweisen. Abhängig von der Architektur kann der Prozessor 550 einen einzigen internen Cache oder mehrere Ebenen interner Caches innerhalb des Caches 570 aufweisen. Andere Implementationen weisen abhängig von der bestimmten Implementation und von den bestimmten Anforderungen eine Kombination sowohl interner als auch externer Caches auf. Eine Registerdatei kann zum Speichern verschiedener Datentypen in verschiedenen Registern, einschließlich Natürliche-Zahlen-Registern, Gleitkommaregistern, Vektorregistern, Bank-Registern, Shadow-Registern, Checkpoint-Registern, Statusregistern, Konfigurationsregistern und Befehlszeigerregistern, verwendet werden.
  • Es sei bemerkt, dass die Ausführungseinheit eine Gleitkommaeinheit aufweisen kann oder dass dies nicht der Fall sein kann. Der Prozessor 550 weist bei einer Implementation einen Mikrocode(ucode)-ROM zum Speichern von Microcode auf, der, wenn er ausgeführt wird, Algorithmen für bestimmte Makrobefehle zur Behandlung komplexer Szenarien ausführen soll. Hier ist Mikrocode möglicherweise aktualisierbar, um logische Fehler/Berichtigungen für den Prozessor 550 zu behandeln.
  • Alternative Implementationen einer Ausführungseinheit können auch in Mikrosteuereinrichtungen, eingebetteten Verarbeitungsvorrichtungen, Graphikvorrichtungen, DSPs und anderen Typen von Logikschaltungen verwendet werden. Das System 500 kann den Speicher 535 aufweisen. Der Speicher 535 kann eine DRAM-Vorrichtung, eine Statischer-Direktzugriffsspeicher(SRAM)-Vorrichtung, eine Flash-Speichervorrichtung oder eine andere Speichervorrichtung einschließen. Der Hauptspeicher speichert durch Datensignale repräsentierte Befehle und/oder Daten, die durch den Prozessor 550 auszuführen sind. Der Prozessor 550 ist über einen Verarbeitungsvorrichtungsbus mit dem Hauptspeicher gekoppelt. Ein Systemlogikchip in der Art eines Speichersteuereinrichtungs-Hubs (MCH) kann mit dem Verarbeitungsvorrichtungsbus und dem Speicher 535 gekoppelt sein. Ein MCH kann einen Speicherweg hoher Bandbreite zum Speicher 535 zur Befehls- und Datenspeicherung von Graphikbefehlen, Daten und Texturen bereitstellen. Der MCH kann verwendet werden, um Datensignale zwischen dem Prozessor 550, dem Speicher 535 und anderen Komponenten im System 500 zu leiten und die Datensignale beispielsweise zwischen dem Verarbeitungsvorrichtungsbus, dem Speicher 535 und der System-E/A zu überbrücken. Der MCH kann durch eine Speicherschnittstelle mit dem Speicher 535 gekoppelt sein. Bei einigen Implementationen kann der Systemlogikchip einen Graphikport zur Kopplung mit einer Graphiksteuereinrichtung durch eine Accelerated-Graphics-Port(AGP)-Zwischenverbindung bereitstellen.
  • Das Rechensystem 500 kann auch einen E/A-Steuereinrichtungs-Hub(ICH) aufweisen. Der ICH kann direkte Verbindungen zu einigen E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellen. Der lokale E/A-Bus kann ein schneller E/A-Bus zur Verbindung von Peripheriegeräten mit dem Speicher 535, dem Chipsatz und dem Prozessor 550 sein. Einige Beispiele sind die Audiosteuereinrichtung, ein Firmware-Hub (Flash-BIOS), ein Drahtlostransceiver, ein Datenspeicher, eine Legacy-E/A-Steuereinrichtung, die Benutzereingabe- und Tastaturschnittstellen enthält, ein serieller Erweiterungsport in der Art eines universellen seriellen Busses (USB) und eine Netzsteuereinrichtung. Die Datenspeichervorrichtung kann ein Festplattenlaufwerk, ein Diskettenlaufwerk, eine CD-ROM-Vorrichtung, eine Flash-Speichervorrichtung oder eine andere Massenspeichervorrichtung umfassen.
  • Für eine andere Implementation eines Systems können die von dem vorstehend beschriebenen einen oder den mehreren Verarbeitungskernen 560 ausgeführten Befehle mit einem System-on-a-Chip (SoC) verwendet werden. Eine Implementation eines SoCs weist eine Verarbeitungsvorrichtung und einen Speicher auf. Der Speicher für ein solches System ist ein Flash-Speicher. Der Flash-Speicher kann sich auf demselben Die wie die Verarbeitungsvorrichtung und andere Systemkomponenten befinden. Zusätzlich können sich auch andere Logikblöcke wie eine Speichersteuereinrichtung oder eine Graphiksteuereinrichtung auf einem SoC befinden.
  • 6 zeigt ein Blockdiagramm einer anderen Ausführungsform eines Rechensystems, das eine Isolation in virtualisierten Systemen unter Verwendung von vertrauenswürdigen Domänen-Inseln (TDIs) bereitstellt. Der Prozessor 638 kann dem in 5 dargestellten Prozessor 550 entsprechen. Bei einer Implementation weist der Prozessor 638 einen Cache 670 auf und führt einen Anwendungsstapel 672 über einen oder mehrere Verarbeitungskerne 560 aus. Wie zuvor erörtert, kann der Prozessor 638 eine TDI-Architektur und TDIX bereitstellen, um für Kundensoftware, die in TDIs (beispielsweise TDI 520A, 520N) in einer nicht vertrauenswürdigen CSP-Infrastruktur ausgeführt wird, Vertraulichkeit und Integrität bereitzustellen.
  • Gemäß einer Ausführungsform kann die TDI-Architektur ISA-Erweiterungen (als TDIX bezeichnet) bereitstellen, die einen vertraulichen Betrieb des OS und von OS-verwalteten Anwendungen (virtualisiert und nicht virtualisiert) unterstützen. Ein Rechensystemen in der Art eines den Prozessor 638 aufweisenden Rechensystems mit aktivierten TDIX kann als mehrere als TDIs bezeichnete verschlüsselte Kontexte wirken. Im Interesse einer einfachen Erklärung ist in 6 eine einzige TDI 520A dargestellt. Jede TDI 520A kann VMMs, VMs, Betriebssysteme und/oder andere Anwendungen ausführen. In 6 ist die TDI 520A als hostende VM 640 dargestellt.
  • Bei einigen Implementationen kann der TDIRM 525 mit dem VMM 526 kompatibel sein. Der VMM 526 kann sich auf Software, Firmware und/oder Hardware beziehen, die verwendet werden, um Gastanwendungen in der Art der VM 640 zu erzeugen, auszuführen und zu verwalten. Der VMM 526 kann die VM 640 erzeugen und ausführen und der VM 640 einen oder mehrere virtuelle Prozessoren (beispielsweise vCPUs) zuordnen. Der VMM 526 kann es der VM 640 ermöglichen, auf Hardware des zugrunde liegenden Rechensystems in der Art des Rechensystems 500 aus 5 zuzugreifen. Die VM 640 kann ein Gast-OS ausführen, und der VMM 526 kann die Ausführung des Gast-OS verwalten. Das Gast-OS kann den Zugriff virtueller Prozessoren der VM 640 auf zugrunde liegende Hardware- und Software-Ressourcen des Rechensystems 500 steuern. Es sei bemerkt, dass der VMM 526, wenn es zahlreiche auf dem Prozessor 638 arbeitende VMs gibt, jedes der auf den zahlreichen Gästen ausgeführten Gastbetriebssysteme verwalten kann. Bei einigen Implementationen kann der VMM mit der TDI 520A implementiert werden, um die VM 640 zu verwalten. Der VMM 526 kann als ein Mandanten-VMM und/oder ein Nicht-Root-VMM bezeichnet werden.
  • Gemäß einer Ausführungsform kann der TDIRM eine Vertrauenswürdige-Domänen-Insel-virtuelle-Maschine-Steuerstruktur (TDIVMCS) initialisieren und sie gemäß einer Virtualisierungsarchitektur und ISA-Erweiterungen (beispielsweise VMX) als eine arbeitende Virtuelle-Maschine-Steuerstruktur (VMCS) aktivieren. Ähnlich der TDICS 510A kann eine VMCS eine Datenstruktur sein, die im vom VMM verwalteten Speicher gespeichert wird. Die VMCS kann die Host- und Gastzustandsinformationen speichern, die zur Virtualisierung eines logischen Prozessors der VM benötigt werden, während die TDICS für TDIX spezifische Steuerinformationen speichern kann, wie nachstehend detaillierter mit Bezug auf Tabelle 1 erörtert wird. Die TDIVMCS kann die für die Ausführung einer TDI in der Art der TDI 520A benötigten Host- und Gastzustandsinformationen speichern. Die TDIVMCS kann als VMCS für die VM 640 und den innerhalb der TDI 520A arbeitenden VMM verwendet werden.
  • Die MOT 572 kann eine Struktur sein, die für jegliche Software, die vom Prozessor 638 behandelt wird, unsichtbar ist, um die Zuweisung von Physischer-Speicher-Seiten für die Ausführung von TDIs in der Art der TDI 520A zu erzwingen. Der Prozessor 638 kann die MOT 572 verwenden, um zu erzwingen, dass als eine Mandanten-TDI 520A oder ein Mandanten-TDIRM 525 arbeitende Software nicht auf Speicher zugreifen kann, der mit physischen Adressen assoziiert ist, es sei denn, dass er ihr explizit zugewiesen wurde. Um dies zu erreichen, kann die MOT 572 erzwingen, dass Software außerhalb der TDI 520A, einschließlich des TDIRMs 525, auf keinen Speicher zugreifen kann, der zu einer anderen TDI gehört (beispielsweise der TDI 520N aus 5). Die MOT 572 kann auch erzwingen, dass Speicherseiten, die durch die MOT 572 spezifischen TDIs in der Art der TDI 520A zugewiesen werden, von jedem Prozessor im System zugänglich sein sollten (wobei der Prozessor die TDI ausführt, welcher der Speicher zugewiesen ist). Bei einer Implementation kann die MOT 572 eine Speicherzugriffssteuerung während des Seiten-Durchlaufs für durch Software ausgeführte Speicherzugriffe erzwingen. Physischer-Speicher-Zugriffe, die durch den Prozessor 638 ausgeführt werden, der weder der TDI 520A noch dem TDIRM 525 zugewiesen ist, können fehlschlagen.
  • Die MOT 572 kann zum Halten von Metadatenattributen (beispielsweise Sicherheitsattributen) für jede 4-KB-Seite des Speichers verwendet werden. Beispielsweise kann die MOT 572 Attribute halten, welche Folgende einschließen: Seitenstatus (beispielsweise ob eine Seite im Speicher gültig ist oder nicht), Seitenkategorie (beispielsweise DRAM, NVRAM, E/A, reserviert), Seitenzustand (gibt beispielsweise an, ob die Seite einer anderen TDI (beispielsweise der TDI 520N aus 5) oder dem TDIRM 525 zugewiesen ist, für die Zuweisung frei ist, gegen eine Zuweisung blockiert ist oder anhängig ist) und TDID (beispielsweise eine Kennung, welche die Seite einer spezifischen eindeutigen TDI zuweist). Zusätzliche Strukturen können für zusätzliche Seitengrößen (beispielsweise 2 MB, 1 GB usw.) definiert werden. Bei anderen Implementationen können andere Seitengrößen durch eine hierarchische Seitenstruktur (beispielsweise eine Seitentabelle) unterstützt werden. Eine 4-KB-Seitenreferenz in der MOT 572 kann zu einer laufenden Instanz der TDI 520A gehören. Die 4-KB-Seitenreferenz kann auch ein gültiger Speicher sein oder als ungültig markiert sein. Bei einer Implementation kann jede TDI-520A-Instanz eine Seite aufweisen, die eine TDICS 510A für diese TDI 520A hält.
  • Die KOT 562 kann eine Datenstruktur, beispielsweise eine Tabelle, zur Verwaltung eines Inventars von HKIDs innerhalb der TDI-Architektur sein. Ähnlich der MOT 572 kann die KOT 562 für auf dem Prozessor 638 arbeitende Software unsichtbar sein. Die KOT 562 kann für die Zuweisung einer HKID zu einem für die TDI 520A erzeugten einmaligen kryptographischen Schlüssel verwendet werden. Gemäß einer Ausführungsform können mehrere einmalige kryptographische Schlüssel für die TDI 520A erzeugt werden. Gemäß einer weiteren Ausführungsform kann eine andere HKID jedem für die TDI 520A erzeugten einmaligen kryptographischen Schlüssel zugewiesen werden. Die KOT 562 kann ferner gemäß hier beschriebenen Ausführungsformen vom TDIRM 525 verwendet werden, um einmaligen kryptographischen Schlüsseln zugewiesene HKIDs zu widerrufen und das Räumen des Caches 570 nach der TDI-Zerstörung zu steuern.
  • Die KOT 562 kann alle für die Verwendung durch alle TDIs, die auf einem Rechensystem gemäß der TDIX-Architektur ausgeführt werden, verfügbaren HKIDs verfolgen. Eine HKID kann einen Zustand zugewiesen, frei (oder verfügbar), zurückgefordert oder konfiguriert aufweisen. Eine HKID, die einen freien Zustand aufweist, ist für die Zuweisung zu kryptographischen Schlüsseln verfügbar (beispielsweise einem für die TDI 520A erzeugten einmaligen kryptographischen Schlüssel). Eine HKID, die einen zugewiesenen Zustand aufweist, ist einem kryptographischen Schlüssel, der mit einer TDI assoziiert ist, zugewiesen und daher nicht für die Zuweisung zu nachfolgenden kryptographischen Schlüsseln verfügbar. Eine HKID, die einen konfigurierten Zustand aufweist, wurde zusammen mit ihrem zugewiesenen kryptographischen Schlüssel in einer Verschlüsselungsmaschine (beispielsweise der Verschlüsselungsmaschine 554 aus 5) konfiguriert. Einer HKID wird während des Prozesses der Zerstörung der TDI 520A ein zurückgeforderter Zustand gegeben. Eine HKID kann einen zurückgeforderten Zustand haben, bis alle Cache-Einträge des Caches 570 geräumt wurden. Wenn alle Cache-Einträge geräumt wurden, kann der Zustand der HKID von zurückgefordert zu verfügbar geändert werden.
  • Die KET 574 kann eine für auf dem Prozessor 638 ausgeführte Software unsichtbare Datenstruktur zur Konfiguration einer Verschlüsselungsmaschine (beispielsweise der Verschlüsselungsmaschine 554 aus 5) sein. Die KET 574 kann durch die HKID indexiert sein und angeben, ob jede HKID in der Verschlüsselungsmaschine konfiguriert wurde. Die KET ist in 6 auch als KET 660 dargestellt, welche die HKID 662 und den Schlüssel 664 aufweist.
  • Die TDICS 510A kann der TDI 520A zugewiesen und im TDIPM 505A gespeichert werden. Die TDICS 510A kann eine Zugriffssteuerstruktur sein, die Teil der TDI-Architektur ist und vom TDIRM 525 behandelt wird. Die TDICS 510A kann Übergänge in einen TDIX-Betrieb und aus diesem heraus behandeln (beispielsweise TDI-Eintritte und TDI-Austritte). Übergänge vom TDIRM 525 in den TDIX-Mandantenbetrieb werden als TDI-Eintritte bezeichnet. TDI-Eintritte können durch einen vom TDIRM 525 ausgeführten Befehl ausgelöst werden. Übergänge vom TDIX-Mandantenbetrieb zum TDIRM 525 werden als TDI-Austritte bezeichnet. TDI-Austritte können durch ein Hardwareereignis, das einen Austritt aus der TDI 520A erfordert, ausgelöst werden. Beispielsweise kann ein Seitenfehler in einer die TDI unterstützenden Seitentabelle (beispielsweise EPT 540 aus 5) einen TDI-Austritt hervorrufen.
  • Die TDICS 510A kann einen natürlich ausgerichteten 4-KB-Bereich des Speichers 535 belegen (beispielsweise eine Seite des Speichers). Die TDICS 510A kann die folgenden nachstehend in TABELLE 1 dargestellten Felder aufweisen, ist jedoch nicht darauf beschränkt. Die in der TDICS gespeicherten TDIX-Steuerinformationen sind Folgende: Tabelle 1
    Gebiet Größe (Bytes) Beschreibung
    REVISION 4 Revisionskennung
    TDID 8 (40 Bits gültig, Rest reserviert) TDI-Kennung
    ZÄH LWERT-TCS 4 (16 Bits gültig, Rest reserviert) Anzahl der TDITCSs, die mit dieser TDICS assoziiert sind
    ZÄHLWERT_BELEGT_TC S 4 (16 Bits gültig, Rest reserviert) Anzahl der belegten TDITCSs, die mit dieser TDIS assoziiert sind
    KID_EINTRAG_0 8 (8 Bits gültig, Rest reserviert) Vergängliche Schlüsselkennung für der TDI während TDICREATE zugewiesenen einmaligen kryptographischen Schlüssel
    ATTRIBUTE 16 Attribute der TDI
    MRTDI 48 SHA-384-Messung der anfänglichen Inhalte der TDI
    RESERVIERT 16 (muss null sein) Für MREG-Wachstum zu SHA 512 reserviert
    MRSWID 48 Durch Software definierte Kennung für nach anfänglichen Erzeugungen geladene zusätzliche Logik
    MRCONFIGID 48 Durch Software definierte Kennung für zusätzliche TDI-SW-Konfiguration
    MROWNER 48 Durch Software definierte Kennung für den VM-Eigentümer
    MROWNERCONFIG 48 Durch Software definierte Kennung für eine zusätzliche Bildkonfiguration vom Eigentümer
    XCRO 8 Anfangswerte von XCRO
    OWNERID 8 Eigentümerkennung
    MRTDI BLOCKS 4 Anzahl der in MRTDI aktualisierten Blöcke (nur von Vor-TDINIT benötigt)
    ZÄHLWERT_TCS_MAX Der Maximalwert spezifiziert die Maximalzahl der logischen Prozessoren, die dieser TDI zugewiesen werden können (maximal möglich ist 4095)
    RESERVIERT Reserviert (andere TDI-Metadaten)
  • Gemäß einer Ausführungsform können mehrere logische Prozessoren der TDI 520A zugewiesen werden. Für jeden der TDI 520A zugewiesenen logischen Prozessor kann eine Vertrauenswürdige-Domänen-Insel-Thread-Steuerstruktur(TDITCS)-515A-Seite zum TDIPM 505A hinzugefügt werden. Gemäß einer Ausführungsform können mehrere TDITCS-515A-Seiten zum TDIPM 505A hinzugefügt werden. Die TDITCS 515A kann gemäß nachstehend erörterten Ausführungsformen für den Eintritt in die TDI 520A oder für den Austritt aus dieser verwendet werden. Die TDITCS 515A kann einen Zustandsspeicherbereich (SSA) zum Speichern des Ausführungszustands für einen der TDI 520A zugewiesenen logischen Prozessor aufweisen. Falls eine TDI-Austrittsbedingung auftritt, wenn der Prozessor 638 einen Befehl in Zusammenhang mit einer Speicherseite des TDIPMs 505A ausführt (d. h. der Prozessor in einem Mandantenmodus arbeitet), kann ein TDIEXIT-Befehl vom TDIRM 525 ausgeführt werden. Der Zustand der TDI 520A kann in TDICS 515A gespeichert werden. Gemäß einer anderen Ausführungsform kann der TDIRM 525, falls eine TDI-Austrittsbedingung auftritt, wenn der Prozessor 638 im Kontext eines Nicht-Root-VMMs innerhalb der TDI 520A arbeitet, einen VMEXIT-Befehl für den TDI-VMM ausführen. Der Mandanten-VMM-Zustand kann in der TDITCS 515A gespeichert werden, und der TDIRM 525 kann anschließend einen TDI-Austritt ausführen.
  • Wie vorstehend erörtert, kann die TDITCS 515A den Ausführungszustand der TDI 520A im SSA halten. Der Ausführungszustand der TDI 520A kann den Ausführungszustand des die TDI 520A ausführenden logischen Prozessors, eine Verbindung zurück zu einer übergeordneten TDICS (beispielsweise TDICS 510A), mehrere TDITCS-Ausführungs-Flags, einen TDI-Zustand, der einem Supervisor-Modus entspricht, und einen TDI-Zustand, der einem Benutzer entspricht, aufweisen.
  • Gemäß einer Ausführungsform können die TDICS 510A und die TDITCS 515A durch die MOT 572 zugangsgesteuert werden (beispielsweise kann eine in der MOT 572 gespeicherte Verschlüsselungsschlüsselkennung zum Erzwingen von Speicherzugriffssteuerungen verwendet werden). Bei einer Implementation können die TDICS 510A und die TDITCS durch Speicherung in einem oder mehreren beschränkten Bereichsregistern in der Art der in 5 dargestellten Bereichsregister 580 des Prozessors 550, das für Speicherzugriffe unzugänglich ist, zugriffsgesteuert werden.
  • Der TDIRM-525-Zustandsbereich kann in einer TDIRM-Steuerstruktur (TDIRCS) 634 gespeichert werden. Die TDIRCS 634 kann auch als neuer Typ einer VM-Steuerstruktur, die nur einen Host-Zustand, Steuerungen und eine TDI-Austrittsinformation enthält, implementiert werden.
  • 7 zeigt ein Blockdiagramm einer anderen Ausführungsform eines Rechensystems, das eine Isolation in virtualisierten Systemen unter Verwendung von TDIs bereitstellt. 7 zeigt ein Blockdiagramm eines beispielhaften TDI-Lebenszyklus 700 und der Interaktionen zwischen der TDI 702 und dem TDIRM 708. Bei einer Implementation können die TDI 702 und der TDIRM 708 ihren mit Bezug auf die 5 - 6 beschriebenen Entsprechungen gleichen. Die TDI-Architektur kann der von der Rechenvorrichtung 500 aus 5 bereitgestellten TDI-Architektur gleichen. Die TDI-Architektur 700 kann eine Schicht bereitstellen, die den Lebenszyklus von auf einem System aktiven TDIs verwaltet. Eine Prozessorunterstützung für TDIs kann durch einen als TDIX-Betrieb bezeichneten Prozessorbetrieb bereitgestellt werden. Es gibt zwei Typen von TDIX-Betriebsarten, nämlich Ressourcenmanagerbetrieb und Mandantenbetrieb. Im Allgemeinen läuft der TDIRM 708 im TDIX-Ressourcenmanagerbetrieb und laufen TDIs in der Art der TDI 702 im TDIX-Mandantenbetrieb. Übergänge zwischen dem Ressourcenmanagerbetrieb und dem Mandantenbetrieb werden als TDIX-Übergänge bezeichnet.
  • Es gibt zwei Typen von TDIX-Übergängen, nämlich TDI-Eintritt 716 und TDI-Austritt 714. Übergänge vom TDIX-Ressourcenmanagerbetrieb in den TDIX-Mandantenbetrieb werden als TDI-Eintritte 716 bezeichnet. TDI-Eintritte können durch einen vom TDIRM 708 ausgeführten Befehl ausgelöst werden. Übergänge vom TDIX-Mandantenbetrieb in den TDIX-Ressourcenmanagerbetrieb werden als TDI-Austritte 714 bezeichnet. TDI-Austritte 714 können durch ein Hardwareereignis, das einen Austritt aus der TDI erfordert, ausgelöst werden. Beispielsweise kann ein Seitenfehler in einer die TDI unterstützenden Seitentabelle (beispielsweise EPT 540 aus 5) einen TDI-Austritt 714 hervorrufen.
  • Wie vorstehend erörtert, verhält sich der Prozessor im TDIX-Ressourcenmanagerbetrieb ähnlich wie außerhalb des TDIX-Betriebs. Die Hauptunterschiede bestehen darin, dass ein Satz von TDIX-Operationen (TDIX-Befehlen) verfügbar ist und dass Werte, die in bestimmte Steuerregister geladen werden können, darauf beschränkt sind, die Modi und Fähigkeiten des TDIRMs 708 zu beschränken.
  • Das Prozessorverhalten im TDIX-Mandantenbetrieb ist auf die Herstellung einer Isolation beschränkt. Beispielsweise weil an Stelle eines gewöhnlichen Betriebs bestimmte Ereignisse (beispielsweise Seitenfehler, unberechtigter Zugriff auf Speicherseiten, Aufgabenwechsel, Mandantenarbeitslastbeendigung usw.) TDI-Austritte 714 in den TDIRM 708. Diese TDI-Austritte 714 erlauben es dem TDIRM 708 nicht, das Verhalten oder den Zustand der TDI 702 zu modifizieren. Der TDIRM 708 kann Plattformfähigkeiten verwenden, um die Kontrolle über Plattformressourcen zu behalten. In der TDI 702 laufende Software (beispielsweise Mandanten-VM1 704A mit VM-Austritt 710 und VM-Eintritt 712, Mandanten-VM2 704B usw.) kann durch Software sichtbare Informationen zur Bestimmung, ob sie in einer TDI 702 läuft, verwenden und lokale Messrichtlinien an zusätzlicher in die TDI 702 geladener Software erzwingen. Die Validierung des Sicherheitszustands der TDI 702 ist jedoch ein von einer fernen Attestierungspartei ausgeführter Vorgang, um Vertraulichkeit zu gewährleisten.
  • Die TDI-Architektur 700 kann dafür ausgelegt werden, Kompatibilitätsprobleme an Software, die auf Virtualisierung beruht, zu minimieren, wenn sie in einer TDI 702 läuft. Die TDI-Architektur 700 lässt die meisten Interaktionen zwischen der im Mandantenbetrieb laufenden VM 704A, 704B und dem im Mandantenbetrieb laufenden Mandanten-VMM 706 unverändert. Falls in der TDI 702 kein VMM 706 vorhanden ist, kann ein VM-OS (nicht dargestellt) modifiziert werden, um mit dem TDIRM 708 als Root-VMM zu arbeiten.
  • Bei einer Implementation kann der TDIRM 708 explizit entscheiden, einen TDI-Austritt 714 zu bewirken, beispielsweise um eine TDI 702 zu beenden oder Speicherressourcen zu verwalten (beispielsweise eine zugewiesene Speicherressource abgeben, freie Speicherressourcen anfordern usw.). Die TDI-Architektur 700 kann auch einem TDIRM 708 die Fähigkeit geben, TDI-Austritte 714 zur Präemption zu erzwingen. Bei TDI-Austritten 714 erzwingt die TDI-Architektur, dass der Ausführungszustand der TDI 702 in einer der TDI 702 zugeordneten CPUzugriffsgesteuerten Speicherstruktur (beispielsweise TDITCS 515A) gesichert und unter Verwendung eines der TDI 702 zugeordneten eindeutigen Verschlüsselungsschlüssels (beispielsweise eines einmaligen Verschlüsselungsschlüssels), welcher für den TDIRM 708 oder andere TDIs nicht sichtbar ist, verschlüsselt werden kann, um die Vertraulichkeit des TDI-Zustands gegenüber dem TDIRM 708 oder anderen TDIs zu schützen. Der TDI-Ausführungszustand kann ähnlich vor Spoofing (wobei sich beispielsweise eine Person oder ein Programm durch Fälschen von Daten erfolgreich als eine andere oder ein anderes ausgibt), Neuabbilden (beispielsweise Neuabbilden des physischen Speichers einer geschützten virtuellen Adresse auf eine neue virtuelle Adresse innerhalb des Kontexts eines bösartigen Moduls) und/oder Wiederausführen über Integritätssteuerungen (beispielsweise wird eine gültige Datenübertragung bösartig oder betrügerisch wiederholt oder verzögert) am Speicher geschützt werden.
  • Der TDI-Eintritt 716 ist ein komplementäres Ereignis zum TDI-Austritt 714. Beispielsweise kann ein TDI-Eintritt 716 geschehen, wenn der TDIRM 708 die Ausführung einer TDI 702 auf einem logischen Prozessor plant und die Ausführung zur in der TDI 702 laufenden Software überträgt. Während des TDI-Eintritts 716 kann die TDI-Architektur 700 erzwingen, dass der Ausführungszustand des TDIRMs 708 in einem Speicher gespeichert wird, der im Besitz des TDIRMs ist (d. h. des TDIPMs 505A und 505N aus 5), der unter Verwendung eines eindeutigen Verschlüsselungsschlüssels (beispielsweise einmaligen Verschlüsselungsschlüssels), der zur ausschließlichen Verwendung durch den TDIRM 708 zugewiesen ist, verschlüsselt ist.
  • TDIs in der Art der TDI 702 können durch den TDIRM 708 unter Verwendung spezifischer Befehle (beispielsweise TDICREATE, TDIADDPAGE usw.) eingerichtet werden, um zu bewirken, dass der TDI Speicherplatz zugeordnet wird und er unter Verwendung eines eindeutigen Verschlüsselungsschlüssels, der für den TDIRM 708 oder andere Software nicht sichtbar ist, verschlüsselt wird. Vor der Ausführung jeglicher zur TDI 702 gehörender Befehle auf einem logischen Prozessor kann der gesamte im TDIPM (beispielsweise TDIPM 505A und 505N aus 5) gespeicherte TDI-Speicher unter Verwendung eines der TDI 702 zugeordneten eindeutigen Schlüssels (beispielsweise eines einmaligen kryptographischen Schlüssels) verschlüsselt werden. Wenngleich hier spezifische Befehlsnamen erwähnt sind, können andere Namen für die Befehle bei Implementationen der Offenbarung verwendet werden, welche nicht auf die hier bereitgestellten spezifischen Namen beschränkt sind.
  • Bei einer Implementation kann der TDIRM 708 jede TDI 702 mit einem kleinen Softwarebild (ähnlich IBB oder anfänglicher Boot-Block) nach der Signaturverifikation starten und die IBB-Messung (zur nachfolgenden Attestierung) unter Verwendung einer Plattform-Vertrauenswurzel aufzeichnen. Die Messung kann für das kleine Softwarebild erhalten werden, um zu verhindern, dass die für das Starten der TDI 702 verwendeten Befehle erneut verwendet werden. Die Messung kann unter Verwendung eines sicheren Hashing-Algorithmus berechnet werden, so dass die Systemsoftware nur eine TDI implementieren kann, die mit einer erwarteten Messung übereinstimmt, indem der genauen Sequenz der vom TDIRM 708 ausgeführten Befehle gefolgt wird. Der TDIX-Entwurf kann eine sichere 256-Bit-SHA-2-Hash-Funktion verwenden, um die Messungen zu berechnen. Die in der TDI 702 ausgeführte IBB-Software kann für den Abschluss des gemessenen Starts der TDI 702 und für die Anforderung zusätzlicher Ressourcen vom TDIRM 708 verantwortlich sein. Gemäß einer Ausführungsform kann die TDI 702 einen einzigen Verschlüsselungsschlüssel verwenden, um den gesamten TDIPM zu schützen. Gemäß einer anderen Ausführungsform kann die TDI 702 mehrere Verschlüsselungsschlüssel verwenden, um den TDIPM zu schützen, wobei die jeweiligen Verschlüsselungsschlüssel mit verschiedenen Mandanten-VMs 704A, 704B und/oder Containern oder anderen Speicherressourcen in der Art von NVRAM assoziiert werden können. Demgemäß kann die TDI 702, wenn sie beim ersten Mal erzeugt wird, einen exklusiven CPU-erzeugten MK-TME-Schlüssel verwenden. Danach kann die TDI 702 optional zusätzliche MK-TME-Verschlüsselungsschlüssel für jeden durch Mandantensoftware behandelten Kontext, der innerhalb der TDI 702 arbeitet, einrichten, wie vorstehend erörtert wurde.
  • Um den Softwarekompatibilitätseinfluss auf VMMs für CSP zu minimieren (beispielsweise TDIRM 708 und Mandanten-VMM 706), kann ein Virtualisierungsbetrieb (beispielsweise VMX) innerhalb einer TDI 702 in der TDI-Architektur 700 unmodifiziert bleiben. Ähnlich kann der Betrieb von VMM-Software in der Art der EPT- und GPT-Verwaltung unter der Kontrolle des Mandanten-VMMs 706 bleiben (falls einer in der TDI 702 aktiv ist und nicht vom TDIRM 708 behandelt wird). Weil der TDIRM 708 jeder TDI 702 physischen Speicher zuweist, weist die TDI-Architektur 700 die MOT 572 auf, wie mit Bezug auf 5 beschrieben. Mit Bezug auf 5 sei bemerkt, dass der Prozessor 550 die TDIRM-verwaltete MOT 572 konsultieren kann, um Teile des Speichers 535 TDIs zuzuordnen (beispielsweise der TDI 702). Dies kann dem TDIRM 708 die vollständige Fähigkeit zur Verwaltung von Speicher als Ressource ermöglichen, ohne Einsicht in Daten, die im zugewiesenen TDI-Speicher resident sind, zu haben. Bei einigen vorstehend offenbarten Implementationen können sich der Plattform(beispielsweise Root)-VMM und der TDIRM 708 in derselben Verschlüsselungsschlüssel-vertrauenswürdige-Domänen-Insel befinden, so dass sie sich die Speicherverwaltungs- und Planerfunktionen teilen (aber noch immer außerhalb der Mandanten-TCB bleiben).
  • 8 ist ein Blockdiagramm einer Ausführungsform einer TDI-Architektur. 8 zeigt eine beispielhafte Ausführungsform einer Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TME)-Maschine. Die MK-TME-Maschine kann gemäß Ausführungsformen dieser Offenbarung als Verschlüsselungsmaschine verwendet werden. Gemäß der erläuterten Ausführungsform weist ein Speicherschutzsystem 800 einen Prozessor 802, einen Systemagenten 803 und einen Speicher 810 auf. Das Speicherschutzsystem 800 kann einen kryptographischen Schutz im Speicher 810 gespeicherter Daten bereitstellen. Der Prozessor 802 kann dem in 5 dargestellten Prozessor 550 und dem in 6 dargestellten Prozessor 638 entsprechen. Der Speicher 810 kann dem auch in 5 dargestellten Speicher 535 entsprechen. Der Systemagent 803 kann, wenngleich er in 5 nicht dargestellt ist, eine Komponente des Virtualisierungsservers 501 sein. Insbesondere kann der Systemagent 803 eine Komponente des Prozessors 550 sein und kann die Speichersteuereinrichtung 808 der Speichersteuereinrichtung 552 aus 5 entsprechen.
  • Der Systemagent 803 kann zur Bereitstellung verschiedener Funktionen für den Prozessor 802 verwendet werden, wie das Verwalten des Zugriffs auf den Speicher 810 und/oder andere Ressourcen des Systems 800. Gemäß der erläuterten Ausführungsform kann der Systemagent 803 beispielsweise eine Speichersteuereinrichtung 808 zum Steuern und/oder Verwalten des Zugriffs auf den Speicher 810 des Systems 800 aufweisen. Überdies kann der Systemagent 803, wie nachstehend beschrieben wird, auch eine Systemschutz-Steuereinrichtung 803 zum Schützen im Speicher 810 gespeicherter Daten aufweisen. Gemäß einigen Ausführungsformen kann der Systemagent 803 auch eine Schnittstelle zwischen dem Prozessor 802 und anderen Komponenten des Systems 800 bereitstellen (beispielsweise unter Verwendung einer Direktmedienschnittstelle (DMI) und/oder einer PCI-Express-Brücke). Gemäß verschiedenen Ausführungsformen kann der Systemagent 803 eine Kombination von Logikelementen aufweisen, die dafür ausgelegt sind, Funktionalität des hier beschriebenen Systemagenten 803 auszuführen, ob aus dem Speicher oder einem anderen nichtflüchtigen computerlesbaren Medium geladen oder direkt in Hardware implementiert, einschließlich der folgenden nicht einschränkenden Beispiele: einem Mikroprozessor, einem Digitalsignalprozessor (DSP), einem feldprogrammierbaren Gate-Array (FPGA), einer Graphikverarbeitungseinheit (GPU), einem programmierbaren Logik-Array (PLA), einer anwendungsspezifischen integrierten Schaltung (ASIC) und/oder einem VM-Prozessor. Der Systemagent 803 kann mit dem Prozessor 802 integriert sein, oder der Systemagent 803 kann alternativ auf einem getrennten Chip implementiert sein, der kommunikativ mit dem Prozessor 802 gekoppelt oder verbunden ist.
  • Die Speichersteuereinrichtung 808 kann zum Steuern und/oder Verwalten des Zugriffs auf den Speicher 810 des Systems 800 verwendet werden. Gemäß verschiedenen Ausführungsformen kann die Speichersteuereinrichtung 808 unter Verwendung einer Kombination von Hardware- und/oder Softwarelogik, einschließlich eines Mikroprozessors, ASICs, FPGAs, PLAs, einer VM und/oder eines anderen Typs von Schaltungsanordnung oder Logik implementiert werden.
  • Gemäß der erläuterten Ausführungsform stellt das System 800 einen kryptographischen Speicherschutz für den Speicher 810 bereit. Gemäß einigen Ausführungsformen kann der kryptographische Speicherschutz beispielsweise durch Erweitern und/oder Modifizieren einer bestimmten Computerarchitektur implementiert werden. Beispielsweise kann der kryptographische Speicherschutz durch Erweitern der Funktionalität eines Prozessors 802 und/oder durch Einbringen einer Speicherschutz-Steuereinrichtung 804 implementiert werden. Gemäß der erläuterten Ausführungsform wird die Funktionalität des Prozessors 802 beispielsweise darauf erweitert, Steuerregister 801 und einen oder mehrere Prozessorbefehle zu unterstützen, die verwendet werden können, um einen kryptographischen Speicherschutz zu ermöglichen und/oder zu konfigurieren, und wird die Speicherschutz-Steuereinrichtung 804 implementiert, um den kryptographischen Speicherschutz bereitzustellen. Die Steuerregister 803 können in 5 dargestellten Bereichsregistern 580 entsprechen. Wenngleich beim erläuterten Beispiel getrennte Logikblöcke verwendet werden, um die Speicherschutz-Steuereinrichtung 804 und den Prozessor 802 zu zeigen, können die Speicherschutz-Steuereinrichtung 804 und der Prozessor 802 gemäß tatsächlichen Ausführungsformen miteinander integriert sein oder alternativ als getrennte Komponenten implementiert sein. Gemäß verschiedenen Ausführungsformen kann die Speicherschutz-Steuereinrichtung 804 beispielsweise unter Verwendung einer Kombination von Hardware- und/oder Softwarelogik, einschließlich eines Mikroprozessors, ASICs, FPGAs, PLAs, einer VM und/oder eines anderen Typs von Schaltungsanordnung oder Logik implementiert sein.
  • Die Speicherschutz-Steuereinrichtung 804 kann eine Speicherverschlüsselung verwenden, um im Speicher 810 gespeicherte Daten zu schützen. Gemäß einigen Ausführungsformen kann die Speicherschutz-Steuereinrichtung 804 beispielsweise auf dem Speicherweg oder Speicherbus implementiert sein, um eine Verschlüsselung zum und vom Speicher 810 und/oder darin gespeicherter Daten zu ermöglichen. Überdies kann die Speicherschutz-Steuereinrichtung 804 gemäß einigen Ausführungsformen konfigurierbar oder programmierbar sein und Unterstützung für mehrere Verschlüsselungsschlüssel aufweisen. Dementsprechend kann die Speicherschutz-Steuereinrichtung 804 dafür ausgelegt oder programmiert werden (beispielsweise durch Software), verschiedene Gebiete oder Seiten des Speichers 810 unter Verwendung verschiedener Verschlüsselungsschlüssel und/oder Algorithmen zu verschlüsseln. Auf diese Weise kann eine Speicherverschlüsselung für verschiedene Benutzer, Mandanten, Kunden, Anwendungen und/oder Arbeitslasten getrennt bereitgestellt und konfiguriert werden.
  • Beispielsweise kann die Speicherschutz-Steuereinrichtung 804 gemäß einigen Ausführungsformen verwendet werden, um verschiedene gesicherte oder geschützte vertrauenswürdige Domänen-Inseln zu definieren, die durch die Verwendung der Speicherverschlüsselung getrennt konfiguriert und geschützt werden können. Gemäß einigen Ausführungsformen kann eine „vertrauenswürdige Domänen-Insel“ beispielsweise als Sammlung von Ressourcen angesehen werden, die mit einer bestimmten Arbeitslast (beispielsweise einer TDI) assoziiert ist, und Speichergebiete aufweisen, die mit der Arbeitslast assoziierte Daten enthalten. Beispielsweise kann eine TDI für eine Kundenarbeitslast eines CSPs Ressourcen (beispielsweise Speicher) aufweisen, die mit einem OS, einer VM (beispielsweise einer VM, die auf einem von einem TDIRM ausgeführten VMM läuft) und/oder jeglichen Ring-3-Anwendungen, die auf dem OS oder der VM laufen, assoziiert sind. Die Speicherschutz-Steuereinrichtung 804 kann es ermöglichen, dass die geschützten vertrauenswürdigen Domänen-Inseln getrennt konfiguriert und geschützt werden, wodurch ermöglicht wird, dass jede geschützte vertrauenswürdige Domänen-Insel durch Verschlüsseln ihres zugeordneten Codes und/oder ihrer zugeordneten Daten mit einem eindeutigen Verschlüsselungsschlüssel kryptographisch im Speicher isoliert wird. Auf diese Weise können die Arbeitslasten verschiedener Benutzer, Kunden und/oder Mandanten durch Definieren verschiedener geschützter vertrauenswürdiger Domänen-Inseln für die verschiedenen Arbeitslasten kryptographisch isoliert werden.
  • Gemäß einigen Ausführungsformen kann der kryptographische Speicherschutz des Systems 800 durch die Verwendung von Prozessorbefehlen und/oder Hardwareregistern entdeckt und konfiguriert werden. Beispielsweise kann ein Prozessorbefehl gemäß einigen Ausführungsformen verwendet werden, um festzustellen, ob der kryptographische Speicherschutz vom System 800 unterstützt wird, beispielsweise durch einen CPU-Identifikations(CPUID)-Befehl, der von Software verwendet wird, um die Fähigkeiten eines bestimmten Prozessors zu identifizieren.
  • Nach der Feststellung, dass der kryptographische Speicherschutz vom System 800 unterstützt wird, kann der kryptographische Speicherschutz durch die Verwendung von Hardwareregistern in der Art der Steuerregister 803 des Prozessors 802 aktiviert und/oder konfiguriert werden. Beispielsweise können die Steuerregister 803 verschiedene modellspezifische Register (MSRs) aufweisen, die es Software erlauben, die Kryptographischer-Speicher-Schutzfähigkeiten des Systems 800 zu entdecken, zu aktivieren und/oder zu konfigurieren. Gemäß einigen Ausführungsformen können die Steuerregister 803 beispielsweise ein Speicherverschlüsselungsfähigkeitsregister, ein Speicherverschlüsselungsaktivierungsregister und/oder ein oder mehrere Speicherverschlüsselungsausschlussregister aufweisen.
  • Gemäß der erläuterten Ausführungsform hält die Speicherschutz-Steuereinrichtung 804 eine interne Vertrauenswürdige-Domänen-Insel-Schlüsseltabelle 806 zum Identifizieren geschützter vertrauenswürdiger Domänen-Inseln (beispielsweise TDIs), die im System 800 konfiguriert wurden. Die Schlüsseltabelle 806 kann unter Verwendung einer Form eines Speichers oder Massenspeichers (beispielsweise RAM) und auch direkt auf der Speicherschutz-Steuereinrichtung 804, im Speicher 810 und/oder unter Verwendung einer anderen Speicherkomponente implementiert werden.
  • Die Einträge 812A, 812B, 812C und 812D der Vertrauenswürdige-Domänen-Insel-Schlüsseltabelle 806 entsprechen jeweils einer anderen geschützten vertrauenswürdigen Domänen-Insel (beispielsweise einer TDI). Beispielsweise kann jeder Eintrag 812A-D einen Schlüssel oder eine Vertrauenswürdige-Domänen-Insel-Kennung, einen Schutzmodus und einen zugeordneten Verschlüsselungsschlüssel (beispielsweise einen einmaligen kryptographischen Schlüssel) aufweisen. Gemäß einigen Ausführungsformen kann eine Schlüsselkennung (beispielsweise eine HKID) beispielsweise die höherwertigen Bits der Speicheradressen repräsentieren, die sich innerhalb der zugeordneten geschützten vertrauenswürdigen Domänen-Insel befinden. Beim erläuterten Beispiel wird jede Schlüsselkennung in der Vertrauenswürdige-Domänen-Insel-Schlüsseltabelle 806 unter Verwendung von 5 Bits repräsentiert. Dementsprechend deckt die geschützte vertrauenswürdige Domänen-Insel in Zusammenhang mit einer gegebenen Schlüsselkennung alle Speicheradressen ab, deren höchstwertige 5 Bits mit der Schlüsselkennung übereinstimmen. Gemäß der erläuterten Ausführungsform kann die Schlüsselkennung als ein Feld in der Schlüsseltabelle 806 gespeichert werden, gemäß alternativen Ausführungsformen kann die Schlüsselkennung jedoch als ein Index für die Schlüsseltabelle 806 verwendet werden, statt direkt darin gespeichert zu werden.
  • Überdies können gemäß einigen Ausführungsformen mehrere Schutzmodi unterstützt werden und kann jede geschützte vertrauenswürdige Domänen-Insel unter Verwendung eines bestimmten Schutzmodus geschützt werden. Beispielsweise können die Standardschutzmodi gemäß einigen Ausführungsformen einen Klartextmodus (beispielsweise unverschlüsselt), einen Standard- oder Sollverschlüsselungsmodus (beispielsweise unter Verwendung eines Standard- oder Sollverschlüsselungsschlüssels verschlüsselt) und/oder einen eigens eingerichteten Verschlüsselungsmodus (beispielsweise unter Verwendung eines eindeutigen Verschlüsselungsschlüssels verschlüsselt) umfassen. Dementsprechend kann die Schlüsseltabelle 806 den Schutzmodus in Zusammenhang mit jeder geschützten vertrauenswürdigen Domänen-Insel oder Schlüsselkennung identifizieren.
  • Beim erläuterten Beispiel weist die Vertrauenswürdige-Domänen-Insel-Schlüsseltabelle 806 vier Einträge auf. Der erste Eintrag identifiziert eine einer Schlüsselkennung 00000 entsprechende geschützte vertrauenswürdige Domänen-Insel (wodurch demgemäß alle Speicheradressen abgedeckt werden, die 00000 in den höchstwertigen 5 Bits enthalten), welche im Sollverschlüsselungsmodus unter Verwendung des Schlüssels „ABC“ geschützt ist. Der zweite Eintrag identifiziert eine einer Schlüsselkennung 00001 entsprechende geschützte vertrauenswürdige Domänen-Insel (wodurch demgemäß alle Speicheradressen abgedeckt werden, die 00001 in den höchstwertigen 5 Bits enthalten), welche im Klartextmodus geschützt ist und keinen zugeordneten Verschlüsselungsschlüssel aufweist. Der dritte Eintrag identifiziert eine einer Schlüsselkennung 00010 entsprechende geschützte vertrauenswürdige Domänen-Insel (wodurch demgemäß alle Speicheradressen abgedeckt werden, die 00010 in den höchstwertigen 5 Bits enthalten), welche im eigens eingerichteten Ausführungsmodus unter Verwendung des Schlüssels „XYZ“ geschützt ist. Der vierte Eintrag identifiziert eine einer Schlüsselkennung 00011 entsprechende geschützte vertrauenswürdige Domänen-Insel (wodurch demgemäß alle Speicheradressen abgedeckt werden, die 00011 in den höchstwertigen 5 Bits enthalten), welche im Sollverschlüsselungsmodus unter Verwendung des Schlüssels „ABC“ geschützt ist. Wie durch diese Beispiele gezeigt wird, hat die unter Verwendung des eigens eingerichteten Verschlüsselungsmodus geschützte vertrauenswürdige Domänen-Insel einen eindeutigen Schlüssel („XYZ“), teilen sich die vertrauenswürdigen Domänen-Inseln, die unter Verwendung des Sollverschlüsselungsmodus geschützt werden, einen Verschlüsselungsschlüssel („ABC“) und ist die im Klartextmodus geschützte vertrauenswürdige Domänen-Insel unverschlüsselt und weist damit keinen zugeordneten Schlüssel auf. Gemäß Ausführungsformen dieser Offenbarung können TDIs unter dem eigens eingerichteten Verschlüsselungsmodus geschützt werden und einen eindeutigen Schlüssel (beispielsweise einen einmaligen kryptographischen Schlüssel) aufweisen.
  • Gemäß einigen Ausführungsformen können geschützte vertrauenswürdige Domänen-Inseln unter Verwendung eines durch den Prozessor 802 implementierten Prozessorbefehls (beispielsweise PCONFIG) definiert und/oder konfiguriert werden. Dieser Prozessorbefehl kann zum Definieren und/oder Konfigurieren einer geschützten vertrauenswürdigen Domänen-Insel durch Programmieren eines neuen Eintrags oder Modifizieren eines existierenden Eintrags in der Schlüsseltabelle 806 der Speicherschutz-Steuereinrichtung 804 verwendet werden. Auf diese Weise können geschützte vertrauenswürdige Domänen-Inseln (beispielsweise TDIs) unter Verwendung des Prozessorbefehls programmatisch (beispielsweise durch Managementsoftware) definiert und konfiguriert werden.
  • Die 9 - 13 zeigen Verfahren 900, 1000, 1100, 1200 und 1300 zum Erzeugen einer TDI durch einen TDIRM gemäß bestimmten hier beschriebenen Ausführungsformen. Die 14 - 16 zeigen Verfahren 1400, 1500 und 1600 zum Zerstören einer TDI durch einen TDIRM gemäß bestimmten hier beschriebenen Ausführungsformen. Die Verfahren 900-1100 können durch eine Verarbeitungslogik, die aus Hardware (beispielsweise Schaltungsanordnung, zweckgebundene Logik, programmierbare Logik, Mikrocode usw.) besteht, ausgeführt werden. Gemäß einer Ausführungsform sollen die Verfahren 900-1600 teilweise durch den Prozessor 550 aus 5, der den TDIRM 525 ausführt, oder den Prozessor 638 aus 6, der den TDIRM 674 ausführt, ausgeführt werden. Beispielsweise können die Verfahren 900-1600 durch Logikschaltungsanordnungen des Prozessors 550, einschließlich eines oder mehrerer Prozessorkerne 560, des Caches 570, der MOT 572, der KOT 562, der KET 574, der WBT 564, der KMT 576, der Bereichsregister 580, der Speichersteuereinrichtung 552, der Verschlüsselungsmaschine 554 und der E/A-Ports 556, ausgeführt werden.
  • Im Interesse einer einfachen Erklärung sind die Verfahren 900-1600 als Schritte dargestellt und werden als solche beschrieben. Schritte gemäß dieser Offenbarung können jedoch in verschiedenen Reihenfolgen und/oder gleichzeitig mit anderen Schritten, die hier nicht vorgestellt und beschrieben werden, auftreten. Ferner können nicht alle dargestellten Schritte ausgeführt werden, um die Verfahren 900-1600 gemäß dem offenbarten Gegenstand zu implementieren. Zusätzlich werden Fachleute auf dem Gebiet verstehen und wertschätzen, dass die Verfahren 900, 1000, 1100, 1200, 1300, 1400, 1500 und 1600 alternativ als durch ein Zustandsdiagramm oder Ereignisse aufeinander bezogene Zustände repräsentiert werden könnten.
  • 9 zeigt ein Flussdiagramm eines Verfahrens 900 zur Erzeugung einer TDI. Wie zuvor erörtert wurde, kann eine TDI durch den TDIRM erzeugt und gestartet werden. Der TDIRM kann als ein Host wirken und Kontrolle über den Prozessor und Plattformhardware haben. Der TDIRM kann eine TDI durch Ausführen eines spezifischen Befehls (beispielsweise TDICREATE) erzeugen, wodurch der TDI-Erzeugungsprozess eingeleitet werden kann.
  • In Block 910 kann der TDIRM eine TDICS initialisieren. Wie vorstehend erörtert, ist die TDICS eine zugangsgesteuerte Struktur, die Teil von TDIX ISA ist und vom TDIRM verwaltet wird. Auf die TDICS kann jedoch nicht direkt durch den TDIRM zugegriffen werden. Die TDICS kann einen natürlich ausgerichteten 4-KB-Speicherbereich (beispielsweise eine Seite des Speichers) belegen. Die Seite, die von der TDICS in einer MOT (beispielsweise der in 5 dargestellten MOT 572 und der in 6 dargestellten MOT 644, wobei die letztgenannte eine HPA 646, einen Seitenstatus 648, einen Seitenzustand 650, eine TDID 652, eine Schlüsselkennung 654, eine GPA 656 und Gastbefugnisse 658 aufweist) belegt wird, kann gegen Software-Lese-/Schreibvorgänge blockiert werden, nachdem der TDICREATE-Befehl erfolgreich ausgeführt wurde. Der TDIRM kann die TDICS gemäß nachstehend mit Bezug auf 10 beschriebenen Ausführungsformen initialisieren.
  • In Block 912 kann der TDIRM einen geschützten TDI-Speicher (TDIPM) initialisieren. Der TDIPM kann ein Teil des einer TDI zuzuordnenden physischen Speichers sein. Der TDIRM kann gemäß einer nachstehend mit Bezug auf 10 beschriebenen Ausführungsform einen Teil des für die Zuordnung zu einer TDI verfügbaren physischen Speichers auswählen und dann den Teil des physischen Speichers als TDIPM initialisieren.
  • Gemäß einer Ausführungsform kann der TDIRM eine Zielseite für die TDICS im TDIPM zuordnen. Der TDIRM kann einen Bereich des physischen Speichers (beispielsweise einen ausgerichteten 4-KB-Bereich) auswählen und diesen als Parameter für den Befehl zur Erzeugung der TDI (beispielsweise TDICREATE) bereitstellen. Dieser Speicherbereich kann für die TDICS zugeordnet werden. Gemäß einigen Ausführungsformen kann der für die TDICS zugeordnete Speicherbereich gegen Lese- und Schreibvorgänge blockiert werden und ist daher innerhalb der TDIX-Architektur geschützt. Die TDICS kann beispielsweise eine TDI-Kennung, den der TDI zugeordneten Verschlüsselungsschlüssel und eine dem Verschlüsselungsschlüssel zugeordnete HKID halten.
  • In Block 914 kann der TDIRM bewirken, dass ein einmaliger kryptographischer Schlüssel erzeugt wird, der für die Verschlüsselung von Speicherseiten im TDIPM zu verwenden ist. Der einmalige kryptographische Schlüssel kann ein vergänglicher Schlüssel sein (d. h. ein kryptographischer Schlüssel, der für jede vom TDIRM erzeugte TDI erzeugt wird). Der TDIRM kann einen Schlüsselprogrammiermodus zum Programmieren des einmaligen kryptographischen Schlüssels für die TDI auswählen. Beispielsweise kann der TDIRM direkt einen Schlüssel für die vertrauenswürdige Domänen-Insel spezifizieren. Gemäß der hier beschriebenen TDI-Architektur kann der TDIRM bei anderen Beispielen fordern, dass ein zufälliger Schlüssel von der CPU erzeugt wird.
  • In Block 916 kann der TDIRM eine in einer Schlüsseleigentümerschaftstabelle (KOT) gespeicherte verfügbare Host-Schlüsselkennung (HKID) identifizieren. Wie vorstehend erörtert, kann die KOT eine für auf dem Prozessor ausgeführte Software unsichtbare Datenstruktur sein, die verwendet wird, um HKID-Inventar innerhalb der TDIX zu verwalten. Gemäß einigen Ausführungsformen kann die TDIX eine spezifische Anzahl von HKIDs aufweisen, die für die Verwendung durch alle durch den TDIRM erzeugten TDIs verfügbar sind. Die KOT kann alle HKIDs halten, die für die Verwendung durch alle auf dem Prozessor erzeugten TDIs verfügbar sind. Die KOT ist in 6 auch als KOT 666 dargestellt, welche die HKID 662 und den HKID-Zustand 668 aufweist. Wie vorstehend erörtert, kann eine HKID einen Zustand zugewiesen, frei (oder verfügbar), zurückgefordert oder konfiguriert aufweisen.
  • In Block 918 kann der TDIRM die HKID in der TDICS speichern. Während der Ausführung einer Mandantenarbeitslast in einer ausgeführten TDI kann die in der TDICS gespeicherte HKID als Teil eines Schutzmechanismus (beispielsweise TME, MK-TME) verwendet werden, um zu verhindern, dass bösartige oder nicht vertrauenswürdige Software (einschließlich des TDIRMs) auf Speicherseiten des TDIPMs zugreift.
  • In Block 920 kann der TDIRM den einmaligen kryptographischen Schlüssel der verfügbaren HKID auf einer Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TME)-Maschine zuweisen. Der TDIRM kann einen spezifischen Befehl (beispielsweise TDICONFIGKEY) ausführen, um den einmaligen kryptographischen Schlüssel und die verfügbare HKID auf MK-TME-Maschinen auf allen Paketen, für welche die TDI arbeiten kann, zu konfigurieren. Der TDICONFIGKEY-Befehl kann dem PCONFIG-Befehl entsprechen, der verwendet wird, um eine geschützte vertrauenswürdige Domänen-Insel des mit Bezug auf 8 beschriebenen Systems 800 zu definieren und/oder zu konfigurieren. Durch Ausführen des TDICONFIGKEY-Befehls kann der TDIRM eine Speicherschutz-Steuereinrichtung einer MK-TME-Maschine (beispielsweise die Speicherschutz-Steuereinrichtung 804 aus 8) veranlassen, den Schlüssel und einen Schutzmodus für die TDI zu programmieren. Die Speicherschutz-Steuereinrichtung kann dann einen Statuscode zum TDIRM zurückgeben, wodurch angegeben wird, dass der Schlüssel konfiguriert wurde.
  • In Block 922 kann der TDIRM einen logischen Prozessor mit der TDI assoziieren. Die TDI kann auf einem assoziierten logischen Prozessor arbeiten. Der TDIRM kann als vollständiger Host wirken und eine vollständige Kontrolle über den logischen Prozessor und den Verarbeitungskern, auf dem der logische Prozessor arbeitet, haben. Die Aktionen, die erforderlich sind, um einen logischen Prozessor mit der TDI zu assoziieren, werden in weiteren Einzelheiten mit Bezug auf 11 beschrieben.
  • In Block 924 kann der TDIRM eine Speicherseite aus dem Adressraum des logischen Prozessors zum TDIPM hinzufügen, der mit Bezug auf 12 detaillierter beschrieben wird.
  • In Block 926 kann der TDIRM die Speicherseite durch Erweitern einer TDI-Messung durch einen Inhaltsbestandteil der Speicherseite messen. Der TDIRM kann einen spezifischen Befehl (beispielsweise TDIEXTEND) ausführen, um die TDI-Messung mit den Inhalten der hinzugefügten Seite zu erweitern. Eine Messung wird auf die TDI erweitert, um zu verhindern, dass die für die Erzeugung der TDI verwendeten Befehle erneut verwendet werden (beispielsweise TDICREATE, TDIADDPAGE usw.). Die Messung der TDI kann durch Berechnen eines sicheren Hashes über die Eingaben von Befehlen erhalten werden, die verwendet werden, um die TD zu erzeugen und den anfänglichen Code und die Daten in den Speicher zu laden (beispielsweise TDICREATE, TDIADD und TDIEXTEND). Die Messung kann unter Verwendung eines sicheren Hashing-Algorithmus berechnet werden, so dass die Systemsoftware nur eine TDI bilden kann, die mit einer erwarteten Messung übereinstimmt, indem der genauen Sequenz der vom TDIRM ausgeführten Befehle gefolgt wird. Der TDIX-Entwurf kann eine sichere 256-Bit-SHA-2-Hash-Funktion verwenden, um die Messungen zu berechnen. Gemäß einer Ausführungsform kann die TDI-Messung auf jeden 256-Byte-Bereich der zum TDIPM hinzugefügten Seite erweitert werden. Die Messung wird wiederholt, bis jeder 256-Byte-Bereich der hinzugefügten TDI-Seite gemessen wurde. Jede TDI-Messung kann in einem Feld der TDICS gespeichert werden.
  • In Block 928 kann der TDIRM die Ausführungssteuerung auf den logischen Prozessor, der mit der TDI assoziiert ist, um die TDI auszuführen, übertragen, was mit Bezug auf 13 detaillierter beschrieben wird.
  • 10 zeigt ein Flussdiagramm eines Verfahrens 1000 zum Initialisieren einer TDICS und eines TDIPMs, der mit der TDI assoziiert ist. Das Verfahren 1000 kann den bei 910 (d. h. Initialisieren einer mit einer TDI assoziierten TDICS) und 912 (d. h. Initialisieren eines mit der TDI assoziierten TDIPMs) des in 9 dargestellten Verfahrens 900 ausgeführten Operationen entsprechen.
  • In Block 1010 kann eine TDICS-Bildseite durch den TDIRM in den Host-Speicher geladen werden.
  • In Block 1012 kann eine Anzahl von HKIDs, welche die TDI verwenden kann, vom TDIRM festgelegt werden. Gemäß einer Ausführungsform kann der TDI eine HKID zugeordnet werden, und ihr stände daher nur ein einmaliger kryptographischer Schlüssel für die Verschlüsselung des TDIPMs zur Verfügung. Gemäß einer anderen Ausführungsform können der TDI mehrere HKIDs zugeordnet werden, und ihr würden daher mehrere einmalige kryptographische Schlüssel für die Verschlüsselung des TDIPMs zur Verfügung stehen. Die Anzahl der HKIDs kann in der TDICS-Bildseite gespeichert werden.
  • In Block 1014 kann ein Teil des Host-Speichers als TDIPM zugewiesen werden. Wie vorstehend erörtert wurde, kann der TDIPM einen natürlich auftretenden 4-KB-Bereich des Host-Speichers (beispielsweise eine Seite des Speichers) belegen.
  • In Block 1016 kann eine Seite des TDIPMs als Zielseite für die TDICS zugeordnet werden.
  • In Block 1018 kann eine Ziel-TDICS-Seite von der in den TDIPM geladenen TDICS-Bildseite initialisiert werden.
  • 11 zeigt ein Flussdiagramm eines Verfahrens 1100 zum Assoziieren eines logischen Prozessors mit einer TDI. Das Verfahren 1100 kann der in Block 922 (d. h. Assoziieren eines logischen Prozessors mit der TDI) des in 9 dargestellten Verfahrens 900 ausgeführten Operation entsprechen.
  • In Block 1110 kann der TDIRM eine Zielseite für einen Vertrauenswürdige-Domänen-Insel-virtueller-Verarbeitungsplatz(TDIVPS) im TDIPM zuordnen. Der TDIVPS kann einen oder mehrere Verarbeitungs-Threads aufweisen, die mit der TDI assoziierte virtuelle Prozessoren emulieren.
  • In Block 1112 kann der TDIRM den TDIVPS an die TDICS binden, die mit der TDI assoziiert ist.
  • In Block 1114 kann der TDIRM einen logischen Prozessor mit dem TDIVPS assoziieren. Der logische Prozessor kann ein ausführbarer Thread auf dem Verarbeitungskern zur Ausführung der Mandantenarbeitslast der TDI sein.
  • In Block 1116 kann der TDIRM eine Zielseite für einen TDI-Zustandsspeicherbereich(SSA)-Frame in Zusammenhang mit dem logischen Prozessor im TDIPM zuordnen. Ein TDI-SSA kann als Teil der vorstehend mit Bezug auf die 5 und 6 erörterten TDITCS aufgenommen sein. Der TDI-SSA kann eine sichere Speicherseite sein, die den Zustand eines innerhalb der TDI ausgeführten Mandantenprozesses speichert.
  • In Block 1118 kann der TDIRM der dem TDIVPS zugeordneten Zielseite eine TDI-SSA-Seite aus dem Adressraum des logischen Prozessors hinzufügen. Der TDIRM kann einen spezifischen Befehl (beispielsweise TDIADDSSA) ausführen, der die Adresse der Zielseite als Eingabe bereitstellt, um eine TDISSA-Seite hinzuzufügen. Die Ausführung dieses Befehls kann die TDI-SSA-Seite an den TDIVPS binden.
  • Die zuvor beschriebenen Operationen des Verfahrens 1100 können für jeden durch den TDIRM erzeugten TDIVPS ausgeführt werden. Es sei bemerkt, dass der erste durch den TDIRM erzeugte TDIVPS ein virtueller Bootstrap-Prozessor (BSP) sein kann. Der virtuelle BSP kann für während des TDI-Erzeugungsprozesses benötigte Bootstrap-Operationen zugeordnet werden. Jeder nachfolgende vom TDIRM erzeugte TDIVPS kann ein virtueller Anwendungsprozessor (AP) sein. Ein virtueller AP kann für jegliche Mandantenoperationen, die erforderlich sind, während die TDI ausführt, zugeordnet werden.
  • 12 zeigt ein Flussdiagramm eines Verfahrens 1200 zum Hinzufügen einer Speicherseite aus dem Adressraum des logischen Prozessors zum TDIPM. Das Verfahren 1200 kann der in Block 924 ausgeführten Operation (d. h. Hinzufügen einer Speicherseite aus dem Adressraum des logischen Prozessors zum TDIPM) des in 9 dargestellten Verfahrens 900 entsprechen.
  • In Block 1210 kann der TDIRM eine physische Seite des Host-Speichers einer TDI-Boot-Bildseite zuordnen. Gemäß einer Ausführungsform kann der TDIRM der TDI-Boot-Bildseite mehrere physische Seiten des Host-Speichers zuordnen.
  • In Block 1212 kann der TDIRM die TDI-Boot-Bildseite in die im Host-Speicher zugeordnete physische Seite laden. Die TDI-Boot-Bildseite kann Code- und Datenseiten enthalten, die verwendet werden, wenn die TDI zum ersten Mal durch den mit der TDI assoziierten logischen Prozessor ausgeführt wird.
  • In Block 1214 kann der TDIRM eine Speicherseite im Host-Speicher zum Kopieren in den mit der TDI assoziierten TDIPM auswählen.
  • In Block 1216 kann der TDIRM eine Zielseite des TDIPMs für die kopierte Speicherseite zuordnen.
  • In Block 1218 kann der TDIRM die Inhalte der ausgewählten Speicherseite unter Verwendung eines einmaligen kryptographischen Schlüssels, welcher der TDI zugeordnet ist, verschlüsseln. Der einmalige kryptographische Schlüssel kann derselbe Schlüssel sein, der durch den TDIRM in Block 914 (d. h. Erzeugen eines einmaligen kryptographischen Schlüssels) des in 9 dargestellten Verfahrens 900 erzeugt wird.
  • In Block 1220 kann der TDIRM die ausgewählte Speicherseite in die Zielseite des TDIPMs kopieren.
  • In Block 1222 kann der TDIRM eine TDI-Messung mit den Inhalten der kopierten Seite auf jedem 256-Byte-Bereich der Speicherseite erweitern.
  • 13 zeigt ein Flussdiagramm eines Verfahrens 1300 zum Übertragen der Ausführungssteuerung auf den logischen Prozessor zur Ausführung der TDI. Das Verfahren 1300 kann der in Block 928 ausgeführten Operation (d. h. Übertragen der Ausführungssteuerung auf den logischen Prozessor zur Ausführung der TDI) des in 9 dargestellten Verfahrens 900 entsprechen. Die folgenden Operationen können auf jedem logischen Prozessor ausgeführt werden, auf dem der TDIRM die TDI starten möchte.
  • In Block 1310 kann der TDIRM eine als virtueller Bootstrap-Verarbeitungsplatz zugewiesene nicht verwendete TDIVPS-Seite identifizieren.
  • In Block 1312 kann der TDIRM eine physische Seite eines Host-Speichers für eine TDI-EPT zuordnen.
  • In Block 1314 kann der TDIRM eine TDI-Boot-Bildseite aus dem Host-Speicher auf die für die TDI-EPT zugeordnete Seite abbilden. Die TDI-Boot-Bildseite kann der TDI-Boot-Bildseite gleichen, die in Block 1212 (d. h. Laden der TDI-Boot-Bildseite in die im Host-Speicher zugeordnete physische Seite) des in 12 dargestellten Verfahrens 1200 in die im Host-Speicher zugeordnete physische Seite geladen wurde.
  • In Block 1316 kann der TDIRM eine physische Seite des Host-Speichers zuordnen und sie für eine Vertrauenswürdige-Domänen-virtuelle-Maschine-Steuerstruktur (TDIVMCS) initialisieren.
  • In Block 1318 kann der TDIRM die TDIVMCS als arbeitende Virtuelle-Maschine-Steuerstruktur (VMCS) aktivieren. Der TDIRM kann einen spezifischen Befehl (beispielsweise VMPTRLD) ausführen, der die TDIVMCS als arbeitende VMCS aktiviert.
  • In Block 1320 kann der TDIRM die TDIVMCS initialisieren. Der TDIRM kann einen spezifischen Befehl (beispielsweise VMWRITE) ausführen, der die TDIVMCS initialisiert. Der ausgeführte Befehl kann einen Host-Zustand für die TDIVMCS festlegen. Der ausgeführte Befehl kann auch einen Zeiger auf die TDI-EPT und eine Verknüpfung zur ausgewählten TDIVPS-Seite setzen.
  • In Block 1322 kann der TDIRM die Ausführungssteuerung auf den logischen Prozessor zur Ausführung der TDI übertragen.
  • 14 zeigt ein Flussdiagramm eines Verfahrens 1400 zum Zerstören einer TDI. Gemäß Ausführungsformen dieser Offenbarung kann eine TDI durch den TDIRM zerstört werden. Der TDIRM kann eine TDI durch Ausführen eines spezifischen Befehls (beispielsweise TDISTOP), wodurch der TDI-Zerstörungsprozess eingeleitet werden kann, zerstören.
  • In Block 1410 kann der TDIRM eine TDI daran hindern, auf einem logischen Prozessor auszuführen, wie detaillierter mit Bezug auf 15 beschrieben wird.
  • In Block 1412 kann der TDIRM einen Cache-Eintrag eines dem logischen Prozessor zugeordneten Caches räumen, wobei der Cache-Eintrag Inhalte einer der TDI zugeordneten Speicherseite enthält.
  • In Block 1414 kann der TDIRM eine einem einmaligen kryptographischen Schlüssel, der der TDI zugeordnet ist, zugewiesene HKID als zurückgefordert markieren. Wie vorstehend erörtert wurde, ist die HKID, falls sie als zurückgefordert markiert wurde, nicht mehr einem einmaligen kryptographischen Schlüssel zugewiesen, welcher der zerstörten TDI zugeordnet ist, jedoch nicht für die Zuweisung zu anderen einmaligen kryptographischen Schlüsseln, die anderen TDIs zugeordnet sind, durch den TDIRM bereit. Der TDIRM kann die HKID erst dann als verfügbar markieren, wenn alle Cache-Einträge des dem logischen Prozessor zugeordneten Caches geräumt wurden.
  • In Block 1416 kann der TDIRM entscheiden, ob Einträge des dem logischen Prozessor zugeordneten Caches geräumt wurden. Falls der TDIRM festgestellt hat, dass nicht alle Cache-Einträge des dem logischen Prozessor zugeordneten Caches geräumt wurden, kann er den Status der HKID in der KOT als zurückgefordert beibehalten. Gemäß einer Ausführungsform kann der TDIRM alle Einträge eines Translation-Lookaside-Buffers (TLB), der dem logischen Prozessor zugeordnet ist, räumen.
  • In Block 1418 kann der TDIRM die HKID als für die Zuweisung zu anderen einmaligen kryptographischen Schlüsseln, die anderen TDIs zugeordnet werden, verfügbar markieren. Durch Ändern des Zustands der HKID auf verfügbar kann die HKID anderen einmaligen kryptographischen Schlüsseln zugewiesen werden, ohne dass das Risiko besteht, dass auf die durch den zuvor zugewiesenen Schlüssel geschützte Inhalte zugegriffen werden könnte.
  • In Block 1420 kann der TDIRM eine Speicherseite aus einem der TDI zugeordneten TDIPM entfernen, wie detaillierter mit Bezug auf 16 beschrieben wird.
  • 15 zeigt ein Flussdiagramm eines Verfahrens 1500 zum Verhindern, dass eine TDI auf einem logischen Prozessor ausführt. Das Verfahren 1500 kann den in den Blöcken 1410 (d. h. Verhindern, dass eine TDI auf einem logischen Prozessor ausführt) und 1412 (d. h. Räumen eines Cache-Eintrags eines dem logischen Prozessor zugeordneten Caches, wobei der Cache-Eintrag Inhalte einer der TDI zugeordneten Speicherseite enthält) ausgeführten Operationen des in 14 dargestellten Verfahrens 1400 entsprechen.
  • In Block 1510 kann der TDIRM eine auf einer Host-Maschine arbeitende TDI für die Zerstörung auswählen. Eine TDI kann zerstört werden, weil ein innerhalb der TDI arbeitender Mandantenprozess beendet wurde. Eine TDI kann auch zerstört werden, um nicht verfügbare HKIDs anderen TDIs, welche der TDIRM später erzeugen wird, neu zuzuordnen.
  • In Block 1512 kann der TDIRM verhindern, dass in einer Speicherseite des TDIPMs in Zusammenhang mit der TDI gespeicherte Befehle auf der Host-Maschine ausgeführt werden.
  • In Block 1514 kann der TDIRM einen Inter-Prozessor-Interrupt zu einem logischen Prozessor aussenden, der einen in einer Speicherseite des TDIRMs gespeicherten Befehl ausführt, wodurch auf dem logischen Prozessor ein Austritt hervorgerufen wird.
  • In Block 1516 kann der TDIRM einen Cache-Eintrag eines dem logischen Prozessor zugeordneten Caches räumen, wobei der Cache-Eintrag Inhalte einer der TDI zugeordneten Speicherseite enthält.
  • 16 zeigt ein Flussdiagramm eines Verfahrens 1600 zum Entfernen einer Speicherseite aus einem mit einer TDI assoziierten TDIPM. Das Verfahren 1600 kann der in Block 1420 (d. h. Entfernen einer Speicherseite aus einem mit der TDI assoziierten TDIPM) des in 14 dargestellten Verfahrens 1400 ausgeführten Operation entsprechen.
  • In Block 1610 kann der TDIRM eine Speicherseite in Zusammenhang mit einer auf einer TDI arbeitenden Mandantenarbeitslast aus einem TDIPM entfernen. Der TDIRM kann einen spezifischen Befehl (beispielsweise TDIREMOVEPAGE) ausführen und die Adresse der Speicherseite in Zusammenhang mit der Mandantenarbeitslast bereitstellen, um die Speicherseite zu entfernen.
  • Bei 1612 kann der TDIRM eine einer TDI-EPT zugeordnete Speicherseite aus einem Host-Speicher, der einem die TDI ausführenden logischen Prozessor zugeordnet ist, entfernen. Der TDIRM kann einen spezifischen Befehl (beispielsweise TDIREMOVEPAGE) ausführen und die Adresse der der TDI-EPT zugeordneten Speicherseite bereitstellen, um die Speicherseite aus dem Host-Speicher zu entfernen.
  • In Block 1614 kann der TDIRM eine einem TDI-Zustandsspeicherbereich(SSA)-Frame zugeordnete Speicherseite aus dem TDIPM erzeugen. Der TDIRM kann einen spezifischen Befehl (beispielsweise TDIREMOVEPAGE) ausführen und die Adresse der dem TDI-SSA-Frame zugeordneten Speicherseite bereitstellen, um die Speicherseite aus dem TDIPM zu entfernen.
  • In Block 1616 kann der TDIRM eine einem TDI-VPS zugeordnete Speicherseite aus dem TDIPM entfernen. Der TDIRM kann einen spezifischen Befehl (beispielsweise TDIREMOVEPAGE) ausführen und die Adresse der dem TDI-VPS zugeordneten Speicherseite bereitstellen, um die Speicherseite aus dem TDIPM zu entfernen.
  • In Block 1618 kann der TDIRM eine einer TDICS zugeordnete Speicherseite aus dem TDIPM entfernen. Der TDIRM kann einen spezifischen Befehl (beispielsweise TDIREMOVEPAGE) ausführen und die Adresse der der TDICS zugeordneten Speicherseite bereitstellen, um die Speicherseite aus dem TDIPM zu entfernen.
  • In Block 1620 kann der TDIRM eine einer TDI-VMCS zugeordnete Seite aus dem Host-Speicher entfernen. Der TDIRM kann einen spezifischen Befehl (beispielsweise VMCLEAR) ausführen und die Adresse der der TDI-VMCS zugeordneten Speicherseite bereitstellen, um die Speicherseite aus dem Host-Speicher zu entfernen.
  • BEFEHLSSÄTZE
  • Ein Befehlssatz kann ein oder mehrere Befehlsformate aufweisen. Ein gegebenes Befehlsformat kann verschiedene Felder definieren (beispielsweise die Anzahl von Bits, die Stelle der Bits), um unter anderem die auszuführende Operation (beispielsweise Opcode) und den einen oder die mehreren Operanden, woran diese Operation auszuführen ist, und/oder ein oder mehrere andere Datenfelder (beispielsweise eine Maske) zu spezifizieren. Einige Befehlsformate werden ferner durch die Definition von Befehlsschablonen (oder Unterformaten heruntergebrochen). Beispielsweise können die Befehlsschablonen eines gegebenen Befehlsformats so definiert werden, dass sie unterschiedliche Teilmengen der Befehlsformatfelder aufweisen (die enthaltenen Felder liegen typischerweise in der gleichen Reihenfolge vor, zumindest einige haben jedoch unterschiedliche Bitpositionen, weil weniger Felder aufgenommen sind) und/oder so definiert werden, dass sie ein anderes interpretiertes gegebenes Feld aufweisen. Demgemäß wird jeder Befehl eines ISA unter Verwendung eines gegebenen Befehsformats ausgedrückt (und, falls definiert, in einer gegebenen der Befehlsschablonen dieses Befehlsformats) und weist Felder zur Spezifikation der Operation und der Operanden auf. Beispielsweise hat ein beispielhafter ADD-Befehl einen spezifischen Opcode und ein spezifisches Befehlsformat, das ein Opcode-Feld zur Spezifikation dieses Opcodes und Operandenfelder zur Auswahl von Operanden (Quellel/Ziel und Quelle2) aufweist, und weist ein Auftreten dieses ADD-Befehls in einem Befehlsstrom spezifische Inhalte in den Operandenfeldern auf, welche spezifische Operanden auswählen. Ein Satz von SIMD-Erweiterungen, der als Advanced Vector Extensions (AVX) (AVX1 und AVX2) bezeichnet wird und das Vector-Extensions(VEX)-Codierschema verwendet, wurde herausgegeben und/oder veröffentlicht (siehe beispielsweise Intel® 64 und IA-32 Architectures Software Developer's Manual, September 2014 und Intel® Advanced Vector Extensions Programming Reference, Oktober 2014).
  • BEISPIELHAFTE BEFEHLSFORMATE
  • Hier beschriebene Ausführungsformen des einen oder der mehreren Befehle können in verschiedenen Formaten verwirklicht werden. Zusätzlich werden nachstehend beschriebene Systeme, Architekturen und Pipelines detailliert dargelegt. Ausführungsformen des einen oder der mehreren Befehle können auf solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind jedoch nicht auf die detailliert dargelegten beschränkt.
  • GENERISCHES VEKTORFREUNDLICHES BEFEHLSFORMAT
  • Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das für Vektorbefehle geeignet ist (es gibt beispielsweise bestimmte für Vektoroperationen spezifische Felder). Wenngleich Ausführungsformen beschrieben werden, bei denen sowohl Vektor- als auch Skalaroperationen durch das vektorfreundliche Befehlsformat unterstützt werden, verwenden alternative Ausführungsformen nur Vektoroperationen des vektorfreundlichen Befehlsformats.
  • Die 17A - 17B sind Blockdiagramme, die ein generisches vektorfreundliches Befehlsformat und Befehlsschablonen davon gemäß einigen Ausführungsformen der Erfindung zeigen. 17A ist ein Blockdiagramm, das ein generisches vektorfreundliches Befehlsformat und Klasse-A-Befehlsschablonen davon zeigt, gemäß einigen Ausführungsformen der Erfindung, während 17B ein Blockdiagramm ist, welches das generische vektorfreundliche Befehlsformat und Klasse-B-Befehlsschablonen davon zeigt, gemäß einigen Ausführungsformen der Erfindung. Insbesondere ist ein generisches vektorfreundliches Befehlsformat 1700 dargestellt, für das Klasse-A- und Klasse-B-Befehlsschablonen definiert sind, die beide Kein-Speicherzugriffs-Befehlsschablonen 1705 und Speicherzugriffs-Befehlsschablonen 1720 aufweisen. Der Begriff generisch in Zusammenhang mit dem vektorfreundlichen Befehlsformat bezieht sich darauf, dass das Befehlsformat nicht an einen spezifischen Befehlssatz gebunden ist.
  • Wenngleich Ausführungsformen der Erfindung beschrieben werden, bei denen das vektorfreundliche Befehlsformat Folgendes unterstützt: eine 64-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit(4-Byte)- oder 64-Bit(8-Byte)-Datenelementbreiten (oder -größen) (so dass ein 64-Byte-Vektor entweder aus 16 Doppelwort-Größenelementen oder alternativ 8-Quadwort-Größenelemeten besteht), eine 64-Byte-Vektoroperandenlänge (oder -größe) mit 16-Bit(2-Byte)- oder 8-Bit(l-Byte)-Datenelementbreiten (oder -größen), eine 32-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit(4-Byte)-, 64-Bit(8-Byte)-, 16-Bit(2-Byte)- oder 8-Bit(1-Byte)-Datenelementbreiten (oder -größen) und eine 16-Byte-Vektoroperandenlänge (oder - größe) mit 32-Bit(4-Byte)-, 64-Bit(8-Byte)-, 16-Bit(2-Byte)- oder 8-Bit(1-Byte)-Datenelementbreiten (oder -größen), können alternative Ausführungsformen mehr, weniger und/oder verschiedene Vektoroperandengrößen (beispielsweise 256-Byte-Vektoroperanden) mit mehr, weniger oder verschiedenen Datenelementbreiten (beispielsweise 128-Bit(16-Byte)-Datenelementbreiten) unterstützen.
  • Die Klasse-A-Befehlsschablonen in 17A weisen Folgendes auf: 1) innerhalb der Kein-Speicherzugriffs-Befehlsschablonen 1705 sind eine Kein-Speicherzugriffs-Vollständige-Rundung-Steuertyp-Operations-Befehlsschablone 1710 und eine Kein-Speicherzugriffs-Datentransformationstypoperations-Befehlsschablone 1715 dargestellt, und 2) innerhalb der Speicherzugriffs-Befehlsschablonen 1720 sind eine temporale Speicherzugriffs-Befehlsschablone 1725 und eine nicht-temporale Speicherzugriffs-Befehlsschablone 1730 dargestellt. Die Klasse-B-Befehlsschablonen in 17B weisen Folgendes auf: 1) innerhalb der Kein-Speicherzugriffs-Befehlsschablonen 1705 sind eine Kein-Speicherzugriffs-Schreibmaskensteuerungs-Teilweise-Rundung-Steuertypoperations-Befehlsschablone 1712 und eine Kein-Speicherzugriffs-Schreibmaskensteuerungs-V-Größentyp-Operations-Befehlsschablone 1717 dargestellt, und 2) innerhalb der Speicherzugriffs-Befehlsschablonen 1720 ist eine Speicherzugriffs-Schreibmaskensteuerungs-Befehlsschablone 1727 dargestellt.
  • Das generische vektorfreundliche Befehlsformat 1700 weist die folgenden nachstehend in der in den 17A - 17B dargestellten Reihenfolge aufgelisteten Felder auf.
  • Formatfeld 1740 - ein spezifischer Wert (ein Befehlsformatkennungswert) in diesem Feld identifiziert eindeutig das vektorfreundliche Befehlsformat und demgemäß Instanzen von Befehlen im vektorfreundlichen Befehlsformat in Befehlsströmen. Dabei ist dieses Feld in dem Sinne optional, dass es für einen Befehlssatz nicht benötigt wird, der nur das generische vektorfreundliche Befehlsformat aufweist.
  • Basisoperationsfeld 1742 - sein Inhalt unterscheidet verschiedene Basisoperationen.
  • Registerindexfeld 1744 - sein Inhalt spezifiziert direkt oder durch Adresserzeugung die Stellen der Quell- und Zieloperanden, ob sie sich in Registern oder im Speicher befinden. Diese weisen eine ausreichende Anzahl von Bits auf, um N Register aus einer PxQ(beispielsweise 32x512, 16x128, 32x1024, 64x1024)-Registerdatei auszuwählen. Wenngleich gemäß einer Ausführungsform N aus bis zu drei Quell- und einem Zielregister bestehen kann, können alternative Ausführungsformen mehr oder weniger Quell- und Zielregister unterstützen (sie können beispielsweise bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als Ziel wirkt, sie können bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch als Ziel wirkt, und sie können bis zu zwei Quellen und ein Ziel unterstützen).
  • Das für Nicht-Speicherzugriffs-Formatbefehle als 1746A und für Speicherzugriffs-Formatbefehle als 1746B bezeichnete Modifiziererfeld 1746 unterscheidet das Auftreten von Befehlen im generischen Vektorbefehlsformat, welche einen Speicherzugriff spezifizieren, von jenen, bei denen das nicht der Fall ist, d. h. zwischen Kein-Speicherzugriffs-Befehlsschablonen 1705 und Speicherzugriffs-Befehlsschablonen 1720. Speicherzugriffsoperationen lesen und/oder schreiben in die Speicherhierarchie (wobei sie in manchen Fällen die Quell- und/oder Zieladressen unter Verwendung von Werten in Registern spezifizieren), während dies bei Nicht-Speicherzugriffsoperationen nicht der Fall ist (beispielsweise sind die Quelle und die Ziele Register). Wenngleich dieses Feld gemäß einer Ausführungsform auch zwischen drei verschiedenen Arten zur Ausführung von Speicherzugriffsberechnungen auswählt, können alternative Ausführungsformen mehr, weniger oder andere Arten zur Ausführung von Speicherzugriffsberechnungen unterstützen.
  • Erweiterungsoperationsfeld 1750 - sein Inhalt entscheidet, welche von einer Vielzahl verschiedener Operationen zusätzlich zur Basisoperation auszuführen ist. Dieses Feld ist kontextspezifisch. Gemäß einigen Ausführungsformen wird dieses Feld in ein Klassenfeld 1768, ein Alphafeld 1752 und ein Betafeld 1754 unterteilt. Das Erweiterungsoperationsfeld 1750 ermöglicht es, dass gemeinsame Gruppen von Operationen statt in 2, 3 oder 4 Befehlen in einem einzigen Befehl ausgeführt werden.
  • Skalierungsfeld 1760 - sein Inhalt ermöglicht die Skalierung des Inhalts des Indexfelds für die Speicherzugriffserzeugung (beispielsweise für eine Adresserzeugung, die 2Skalierung * Index + Basis verwendet).
  • Versatzfeld 1762A - sein Inhalt wird als Teil der Speicheradresserzeugung verwendet (beispielsweise für eine Adresserzeugung, die 2Skalierung * Index + Basis + Versatz verwendet).
  • Versatzfaktorfeld 1762B (es sei bemerkt, dass die Gegenüberstellung des Versatzfelds 1762A direkt über dem Versatzfaktorfeld 1762B angibt, dass das eine oder das andere verwendet wird) - sein Inhalt wird als Teil der Adresserzeugung verwendet: Es spezifiziert einen Versatzfaktor, der mit der Größe eines Speicherzugriffs (N) zu skalieren ist - wobei N die Anzahl der Bytes im Speicherzugriff ist (beispielsweise für eine Adresserzeugung, die 2Skalierung * Index + Basis + skalierter Versatz verwendet). Redundante niederwertige Bits werden ignoriert, so dass der Inhalt des Versatzfaktorfelds mit der Speicheroperanden-Gesamtgröße (N) multipliziert wird, um den endgültigen Versatz zu erzeugen, der bei der Berechnung einer effektiven Adresse zu verwenden ist. Der Wert von N wird durch die Prozessorhardware zur Laufzeit auf der Grundlage des Vollständiger-Opcode-Felds 1774 (hier nachstehend beschrieben) und des Datenmanipulationsfelds 1754C bestimmt. Das Versatzfeld 1762A und das Versatzfaktorfeld 1762B sind in dem Sinne optional, dass sie nicht für die Kein-Speicherzugriffs-Befehlsschablonen 1705 verwendet werden und/oder verschiedene Ausführungsformen nur eine oder keine der beiden implementieren können.
  • Datenelementbreitenfeld 1764 - sein Inhalt entscheidet, welche von einer Anzahl von Datenelementbreiten zu verwenden ist (gemäß einigen Ausführungsformen für alle Befehle, gemäß anderen Ausführungsformen für nur einige der Befehle). Dieses Feld ist in dem Sinne optional, dass es nicht erforderlich ist, falls nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung irgendeines Aspekts der Opcodes unterstützt werden.
  • Schreibmaskenfeld 1770 - sein Inhalt steuert auf einer Pro-Datenelement-Positionsbasis, ob diese Datenelementposition im Zielvektoroperanden das Ergebnis der Basisoperation und der Erweiterungsoperation reflektiert. Klasse-A-Befehlsschablonen unterstützen Zusammenfügung-Schreibmaskierung, während Klasse-B-Befehlsschablonen sowohl Zusammenfügung- als auch Nullsetzungs-Schreibmaskierungen unterstützen. Wenn zusammengefügt wird, ermöglichen Vektormasken, dass ein Satz von Elementen am Ziel während der Ausführung einer Operation (durch die Basisoperation und die Erweiterungsoperation spezifiziert) vor Aktualisierungen geschützt wird, und gemäß einer anderen Ausführungsform wird der alte Wert jedes Elements des Ziels bewahrt, wobei das entsprechende Maskenbit eine 0 aufweist. Wenn dagegen Nullsetzungsvektormasken ermöglichen, dass jeglicher Satz von Elementen am Ziel während der Ausführung einer Operation (durch die Basisoperation und die Erweiterungsoperation spezifiziert) auf Null gesetzt wird, wird gemäß einer Ausführungsform ein Element des Ziels auf Null gesetzt, wenn das entsprechende Maskenbit einen 0-Wert hat. Eine Teilmenge dieser Funktionalität ist die Fähigkeit zur Steuerung der Vektorlänge der ausgeführten Operation (d. h. der Spanne der modifizierten Elemente vom ersten bis zum letzten), es ist jedoch nicht erforderlich, dass die Elemente, die modifiziert werden, aufeinander folgen. Demgemäß ermöglicht das Schreibmaskenfeld 1770 teilweise Vektoroperationen, einschließlich Laden, Speichern, arithmetisch, logisch usw. Wenngleich Ausführungsformen der Erfindung beschrieben werden, bei denen der Inhalt des Schreibmaskenfelds 1770 eines von einer Anzahl von Schreibmaskenregistern auswählt, das die zu verwendende Schreibmaske aufweist (und wobei demgemäß der Inhalt des Schreibmaskenfelds 1770 indirekt identifiziert, dass die Maskierung auszuführen ist), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Schreibmaskenfelds 1770 direkt die auszuführende Maskierung spezifiziert.
  • Unmittelbar-Feld 1772 - sein Inhalt ermöglicht die Spezifikation eines Unmittelbar-Werts. Dieses Feld ist in dem Sinne optional, dass es in keiner Implementation des generischen vektorfreundlichen Formats vorhanden ist, das unmittelbar nicht unterstützt, und es in Befehlen, die kein Unmittelbar verwenden, nicht vorhanden ist.
  • Klassenfeld 1768 - sein Inhalt unterscheidet zwischen verschiedenen Klassen von Befehlen. Mit Bezug auf die 17A-B sei bemerkt, dass die Inhalte dieses Felds zwischen Klasse-A- und Klasse-B-Befehlen auswählen. In den 17A-B werden Quadrate mit abgerundeten Ecken verwendet, um anzugeben, dass ein spezifischer Wert in einem Feld vorhanden ist (beispielsweise Klasse A 1768A bzw. Klasse B 1768B für das Klassenfeld 1768 in den 17A-B).
  • BEFEHLSSCHABLONEN DER KLASSE A
  • Im Fall der Kein-Speicherzugriffs-Befehlsschablonen 1705 der Klasse A wird das Alphafeld 1752 als ein RS-Feld 1752A interpretiert, dessen Inhalt entscheidet, welcher der verschiedenen Erweiterungsoperationstypen auszuführen ist (beispielsweise werden Rundung 1752A.1 und Datentransformation 1752A.2 für die Kein-Speicherzugriffs-Rundungstypoperations-Befehlsschablone 1710 bzw. die Kein-Speicherzugriffs-Datentransformationstypoperations-Befehlsschablone 1715 verwendet), während das Betafeld 1754 entscheidet, welche der Operationen des spezifizierten Typs auszuführen ist. Bei den Kein-Speicherzugriffs-Befehlsschablonen 1705 sind das Skalierungsfeld 1760, das Versatzfeld 1762A und das Versatzfaktorfeld 1762B nicht vorhanden.
  • KEIN-SPEICHERZUGRIFFS-BEFEHLSSCHABLONEN-VOLLSTÄNDIGE-RuNDUNG-STEUERTYP-OPERATION
  • Bei der Kein-Speicherzugriffs-Vollständige-Rundung-Steuertyp-Operations-Befehlsschablone 1710 wird das Betafeld 1754 als Rundungssteuerfeld 1754A interpretiert, dessen Inhalt eine statische Rundung bereitstellt. Wenngleich gemäß den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerfeld 1754A eine Unterdrückung-aller-Gleitkommaausnahmen(SAE)-Feld 1756 und ein Rundungsoperations-Steuerfeld 1758 aufweist, können alternative Ausführungsformen diese beiden Konzepte in dasselbe Feld codieren oder nur das eine oder das andere dieser Konzepte/Felder aufweisen (beispielsweise nur das Rundungsoperations-Steuerfeld 1758 aufweisen).
  • SAE-Feld 1756 - sein Inhalt entscheidet, ob die Ausnahmeereignisberichterstattung zu deaktivieren ist oder nicht, wobei, wenn der Inhalt des SAE-Felds 1756 angibt, dass die Unterdrückung aktiviert ist, ein gegebener Befehl keine Art eines Gleitkommaausnahme-Flags angibt und keinen Gleitkomma-Ausnahme-Handler hervorruft.
  • Rundungsoperations-Steuerfeld 1758 - sein Inhalt entscheidet, welche von einer Gruppe von Rundungsoperationen auszuführen ist (beispielsweise Aufrundung, Abrundung, Rundung zu null und Rundung zum nächsten Nachbarn). Demgemäß ermöglicht das Rundungsoperations-Steuerfeld 1758 das Ändern des Rundungsmodus auf einer Pro-Befehl-Basis. Gemäß einigen Ausführungsformen, bei denen ein Prozessor ein Steuerregister zur Spezifikation von Rundungsmodi aufweist, überschreibt der Inhalt des Rundungsoperations-Steuerfelds 1750 diesen Registerwert.
  • KEIN-SPEICHERZUGRIFFS-BEFEHLSSCHABLONEN-DATENTRANSFORMATIONSTYPOPERATION
  • Bei der Kein-Speicherzugriffs-Datentransformationstypoperations-Befehlsschablone 1715 wird das Betafeld 1754 als Datentransformationsfeld 1754B interpretiert, dessen Inhalt entscheidet, welche von einer Anzahl von Datentransformationen auszuführen ist (beispielsweise keine Datentransformation, Swizzle, Rundsendung).
  • Im Fall einer Speicherzugriffs-Befehlsschablone 1720 der Klasse A wird das Alphafeld 1752 als ein Räumungshinweisfeld 1752B interpretiert, dessen Inhalt entscheidet, welcher der Räumungshinweise zu verwenden ist (in 17A werden temporal 1752B.1 bzw. nicht-temporal 1752B.2 für die Speicherzugriffs-temporal-Befehlsschablone 1725 bzw. die Speicherzugriffsnicht-temporal-Befehlsschablone 1730 spezifiziert), während das Betafeld 1754 als ein Datenmanipulationsfeld 1754C interpretiert wird, dessen Inhalt entscheidet, welche von einer Anzahl von Datenmanipulationsoperationen (auch als Primitive bekannt) auszuführen ist (beispielsweise keine Manipulation, Rundsendung, Aufwärtskonvertierung einer Quelle und Abwärtskonvertierung eines Ziels). Die Speicherzugriffs-Befehlsschablonen 1720 weisen das Skalierungsfeld 1760 und optional das Versatzfeld 1762A oder das Versatzfaktorfeld 1762B auf.
  • Vektorspeicherbefehle führen Vektorladevorgänge aus dem Speicher und Vektorspeichervorgänge in den Speicher mit Konvertierungsunterstützung aus. Wie bei regulären Vektorbefehlen übertragen Vektorspeicherbefehle Daten datenelementweise aus dem Speicher oder in diesen, wobei die Elemente, die tatsächlich übertragen werden, durch die Inhalte der Vektormaske, die als Schreibmaske ausgewählt wird, vorgeschrieben werden.
  • SPEICHERZUGRIFFSBEFEHLSSCHABLONEN-TEMPORAL
  • Temporale Daten sind Daten, die wahrscheinlich bald genug wiederverwendet werden, um von einem Caching zu profitieren. Dies ist jedoch ein Hinweis, und verschiedene Prozessoren können ihn auf verschiedene Arten implementieren, einschließlich den Hinweis ganz ignorieren.
  • SPEICHERZUGRIFFSBEFEHLSSCHABLONEN - NICHT-TEMPORAL
  • Nicht temporale Daten sind Daten, die nicht wahrscheinlich bald genug wiederverwendet werden, um von einem Caching im Ist-Level-Cache zu profitieren, und denen Priorität für eine Räumung gegeben werden sollte. Dies ist jedoch ein Hinweis, und verschiedene Prozessoren können ihn auf verschiedene Arten implementieren, einschließlich den Hinweis ganz ignorieren.
  • BEFEHLSSCHABLONEN DER KLASSE B
  • Im Fall der Befehlsschablonen der Klasse B wird das Alphafeld 1752 als Schreibmaskensteuer(Z)-Feld 1752C interpretiert, dessen Inhalt entscheidet, ob die vom Schreibmaskenfeld 1770 gesteuerte Schreibmaskierung zusammenfügend oder auf Null setzend sein sollte.
  • Im Fall der Kein-Speicherzugriffs-Befehlsschablonen 1705 der Klasse B wird ein Teil des Betafelds 1754 als ein RL-Feld 1757A interpretiert, dessen Inhalt entscheidet, welche der verschiedenen Erweiterungsoperationstypen auszuführen sind (beispielsweise sind Rundung 1757A.1 bzw. Vektorlänge (V-Größe) 1757A.2 für die Kein-Speicherzugriffs-Schreibmaskensteuerungs-teilweise-Rundung-Steuertypoperations-Befehlsschablone 1712 und die Kein-Speicherzugriffs-Schreibmaskensteuerungs-V-Größen-Typ-Operations-Befehlsschablone 1717 spezifiziert), während der Rest des Betafelds 1754 entscheidet, welche der Operationen des spezifizierten Typs auszuführen ist. Bei den Kein-Speicherzugriffs-Befehlsschablonen 1705 sind das Skalierungsfeld 1760, das Versatzfeld 1762A und das Versatzfaktorfeld 1762B nicht vorhanden.
  • Bei der Kein-Speicherzugriffs-Schreibmaskensteuerungs-teilweise-Rundung-Steuertypoperations-Befehlsschablone 1710 wird der Rest des Betafelds 1754 als Rundungsoperationsfeld 1759A interpretiert und wird die Ausnahmeereignis-Berichterstattung deaktiviert (ein gegebener Befehl teilt keine Art eines Gleitkommaausnahme-Flags mit und ruft keinen Gleitkomma-Ausnahme-Handler hervor).
  • Rundungsoperations-Steuerfeld 1759A - ebenso wie das Rundungsoperations-Steuerfeld 1758 entscheidet sein Inhalt, welche von einer Gruppe von Rundungsoperationen auszuführen ist (beispielsweise Aufrundung, Abrundung, Rundung zu null und Rundung zum nächsten Nachbarn). Demgemäß ermöglicht das Rundungsoperations-Steuerfeld 1759A das Ändern des Rundungsmodus auf einer Pro-Befehl-Basis. Gemäß einigen Ausführungsformen, bei denen ein Prozessor ein Steuerregister zur Spezifikation von Rundungsmodi aufweist, überschreibt der Inhalt des Rundungsoperations-Steuerfelds 1750 diesen Registerwert.
  • Bei der Kein-Speicherzugriffs-Schreibmaskensteuerungs-V-Größen-Typ-Operations-Befehlsschablone 1717 wird der Rest des Betafelds 1754 als Vektorlängenfeld 1759B interpretiert, dessen Inhalt entscheidet, welche von einer Anzahl von Datenvektorlängen zu verarbeiten ist (beispielsweise 128, 256 oder 512 Bytes).
  • Im Fall der Speicherzugriffs-Befehlsschablone 1720 der Klasse B wird ein Teil des Betafelds 1754 als Rundsendefeld 1757B interpretiert, dessen Inhalt entscheidet, ob die Rundsendetyp-Datenmanipulationsoperation auszuführen ist, während der Rest des Betafelds 1754 als Vektorlängenfeld 1759B interpretiert wird. Die Speicherzugriffs-Befehlsschablonen 1720 weisen das Skalierungsfeld 1760 und optional das Versatzfeld 1762A oder das Versatzfaktorfeld 1762B auf.
  • Mit Bezug auf das generische vektorfreundliche Befehlsformat 1700 ist ein Vollständiger-Opcode-Feld 1774 dargestellt, welches das Formatfeld 1740, das Basisoperationsfeld 1742 und das Datenelementbreitenfeld 1764 aufweist. Wenngleich eine Ausführungsform dargestellt ist, bei der das Vollständiger-Opcode-Feld 1774 all diese Felder aufweist, weist das Vollständiger-Opcode-Feld 1774 gemäß Ausführungsformen, die nicht alle von ihnen unterstützen, weniger als all diese Felder auf. Das Vollständiger-Opcode-Feld 1774 stellt den Operationscode (Opcode) bereit.
  • Das Erweiterungsoperationsfeld 1750, das Datenelementbreitenfeld 1764 und das Schreibmaskenfeld 1770 ermöglichen die Spezifikation dieser Merkmale auf einer Pro-Befehl-Basis im generischen vektorfreundlichen Befehlsformat.
  • Die Kombination aus dem Schreibmaskenfeld und dem Datenelementbreitenfeld erzeugt in der Hinsicht typisierte Befehle, dass sie es ermöglichen, dass die Maske auf der Grundlage verschiedener Datenelementbreiten angewendet wird.
  • Die verschiedenen in der Klasse A und der Klasse B angetroffenen Befehlsschablonen sind in unterschiedlichen Situationen vorteilhaft. Gemäß einigen Ausführungsformen der Erfindung können verschiedene Prozessoren oder verschiedene Kerne innerhalb eines Prozessors nur Klasse A, nur Klasse B oder beide Klassen unterstützen. Beispielsweise kann ein für die allgemeine Berechnung vorgesehener Hochleistungs-außerhalb-der-Reihe-Kern für allgemeine Zwecke nur Klasse B unterstützen, kann ein in erster Linie für Graphik- und/oder wissenschaftliche Berechnungen (Durchsatz) vorgesehener Kern nur Klasse A unterstützen und kann ein für beide vorgesehener Kern beide unterstützen (natürlich liegt ein Kern, der eine Mischung von Schablonen und Befehlen aus beiden Klassen, jedoch nicht alle Schablonen und Befehle aus beiden Klassen aufweist, innerhalb des Geltungsbereichs der Erfindung). Auch kann ein einzelner Prozessor mehrere Kerne aufweisen, die alle die gleiche Klasse unterstützen, oder wobei verschiedene Kerne verschiedene Klassen unterstützen. Beispielsweise kann bei einem Prozessor mit getrennten Kernen für Graphik- und allgemeine Zwecke einer der Graphikkerne, der in erster Linie für Graphik- und/oder wissenschaftliche Berechnungen vorgesehen ist, nur Klasse A unterstützen, während einer oder mehrere der Kerne für allgemeine Zwecke Hochleistungskerne für allgemeine Zwecke mit einer Außerhalb-der-Reihe-Ausführung und -Registerumbenennung sein können, die für Berechnungen für allgemeine Zwecke vorgesehen sind, welche nur Klasse B unterstützen. Ein anderer Prozessor, der keinen getrennten Graphikkern aufweist, kann einen oder mehrere In-der-Reihe- oder Außerhalb-der-Reihe-Kerne für allgemeine Zwecke aufweisen, die sowohl Klasse A als auch Klasse B unterstützen. Natürlich können gemäß verschiedenen Ausführungsformen der Erfindung Merkmale aus einer Klasse auch in der anderen Klasse implementiert werden. In einer höheren Sprache geschriebene Programme würden in eine Vielzahl verschiedener ausführbarer Formen versetzt werden (beispielsweise Just-in-time-kompiliert oder statisch kompiliert), welche Folgende aufweisen: 1) eine Form, die nur Befehle der vom Zielprozessor für die Ausführung unterstützten Klassen aufweist, oder 2) eine Form mit unter Verwendung verschiedener Kombinationen der Befehle aller Klassen geschriebenen alternativen Routinen und mit einem Steuerflusscode, der die auszuführenden Routinen auf der Grundlage der vom Prozessor, der den Code gegenwärtig ausführt, unterstützten Befehle auswählt.
  • BEISPIELHAFTES SPEZIFISCHES VEKTORFREUNDLICHES BEFEHLSFORMAT
  • 18A ist ein Blockdiagramm, das ein beispielhaftes spezifisches vektorfreundliches Befehlsformat zeigt, gemäß einigen Ausführungsformen der Erfindung. 18A zeigt ein spezifisches vektorfreundliches Befehlsformat 1800, das in dem Sinne spezifisch ist, dass es die Stelle, die Größe, die Interpretation und die Reihenfolge der Felder sowie Werte für einige dieser Felder spezifiziert. Das spezifische vektorfreundliche Befehlsformat 1800 kann verwendet werden, um den x86-Befehlssatz zu erweitern, so dass einige der Felder jenen, die beim existierenden x86-Befehlssatz und einer Erweiterung davon (beispielsweise AVX) verwendet werden, ähneln oder gleichen. Dieses Format bleibt mit dem Präfixcodierfeld, dem Realer-Opcode-Byte-Feld, dem MOD-R/M-Feld, dem SIB-Feld, dem Versatzfeld und den Unmittelbar-Feldern des existierenden x86-Befehlssatzes mit Erweiterungen konsistent. Es sind die Felder von 17A oder 17B dargestellt, in welche die Felder aus 18A abgebildet werden.
  • Es sei bemerkt, dass, wenngleich Ausführungsformen der Erfindung für die Zwecke der Erläuterung mit Bezug auf das spezifische vektorfreundliche Befehlsformat 1800 in Zusammenhang mit dem generischen vektorfreundlichen Befehlsformat 1700 beschrieben werden, die Erfindung nicht auf das spezifische vektorfreundliche Befehlsformat 1800 beschränkt ist, es sei denn, wo beansprucht. Beispielsweise erwägt das generische vektorfreundliche Befehlsformat 1700 eine Vielzahl möglicher Größen für die verschiedenen Felder, während gezeigt ist, dass das spezifische vektorfreundliche Befehlsformat 1800 Felder spezifischer Größen aufweist. Bei einem spezifischen Beispiel ist, wenngleich das Datenelementbreitenfeld 1764 im spezifischen vektorfreundlichen Befehlsformat 1800 als Ein-Bit-Feld dargestellt ist, die Erfindung nicht darauf beschränkt (d. h., dass das generische vektorfreundliche Befehlsformat 1700 andere Größen des Datenelementbreitenfelds 1764 erwägt).
  • Das spezifische vektorfreundliche Befehlsformat 1800 weist die folgenden nachstehend in der in 18A dargestellten Reihenfolge aufgelisteten Felder auf.
  • EVEX-Präfix (Bytes 0 - 3) 1802 - ist in einer Vier-Byte-Form codiert.
  • Formatfeld 1740 (EVEX-Byte 0, Bits [7:0]) - das erste Byte (EVEX-Byte 0) ist das Formatfeld 1740 und enthält 0x62 (den eindeutigen Wert, der gemäß einigen Ausführungsformen zur Unterscheidung des vektorfreundlichen Befehlsformats verwendet wird).
  • Die Bytes zwei bis vier (EVEX-Bytes 1 - 3) weisen eine Anzahl von Bitfeldern auf, die eine spezifische Fähigkeit bereitstellen.
  • REX-Feld 1805 (EVEX-Byte 1, Bits [7 - 5]) - besteht aus einem EVEX.R-Bitfeld (EVEX-Byte 1, Bit [7] - R), EVEX.X-Bitfeld (EVEX-Byte 1, Bit [6] -X) und EVEX.B-Bitfeld (EVEX-Byte 1, Bit[5] - B). Die EVEX.R-, EVEX.X- und EVEX.B-Bitfelder stellen die gleiche Funktionalität wie die entsprechenden VEX-Bitfelder bereit und werden unter Verwendung der 1s-Komplementform codiert, d. h. ZMM0 wird als 1111B codiert, ZMM15 wird als 0000B codiert. Andere Felder der Befehle codieren die unteren drei Bits der Registerindizes, wie auf dem Fachgebiet bekannt ist (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Addieren von EVEX.R, EVEX.X und EVEX.B gebildet werden können.
  • REX' 1810A - dies ist der erste Teil des REX'-Felds 1810 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4] - R'), das zur Codierung entweder der oberen 16 oder der unteren 16 des erweiterten 32-Register-Satzes verwendet wird. Gemäß einigen Ausführungsformen wird dieses Bit zusammen mit anderen, wie nachstehend angegeben wird, im bitinvertierten Format gespeichert, um vom BOUND-Befehl zu unterscheiden (im wohlbekannten x86-32-Bit-Modus), dessen Realer-Opcode-Byte 62 ist, jedoch im MOD-R/M-Feld (nachstehend beschrieben) den Wert 11 im MOD-Feld nicht akzeptiert, wobei alternative Ausführungsformen der Erfindung dieses und die anderen nachstehend angegebenen Bits nicht im invertierten Format speichern. Ein Wert von 1 wird zur Codierung der unteren 16 Register verwendet. Mit anderen Worten wird R'Rrrr durch Kombinieren von EVEX.R', EVEX.R und der anderen RRR von anderen Feldern gebildet.
  • Opcode-Zuordnungsfeld 1815 (EVEX-Byte 1, Bits [3:0] - mmmm) - sein Inhalt codiert ein impliziertes führendes Opcode-Byte (0F, 0F 38 oder 0F 3).
  • Datenelementbreitenfeld 1764 (EVEX-Byte 2, Bit [7] - W) - ist durch die Notation EVEX.W repräsentiert. EVEX.W wird verwendet, um die Granularität (Größe) des Datentyps zu definieren (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente).
  • EVEX.vvvv 1820 (EVEX-Byte 2, Bits [6:3]-vvvv) - die Rolle von EVEX.vvvv kann Folgendes aufweisen: 1) EVEX.vvvv codiert den ersten Quellregisteroperanden, der in invertierter Form (1s-Komplement) spezifiziert ist und für Befehle mit 2 oder mehr Quelloperanden gültig ist, 2) EVEX.vvvv codiert den Zielregisteroperanden, der in ls-Komplementform für bestimmte Vektorverschiebungen spezifiziert ist, oder 3) EVEX.vvvv codiert keinen Operanden, das Feld wird reserviert und sollte 1111b enthalten. Demgemäß codiert das EVEX.vvvv-Feld 1820 die vier niederwertigen Bits des in invertierter Form (1s-Komplement) gespeicherten ersten Quellregisterspezifizierers. Abhängig vom Befehl wird ein zusätzliches verschiedenes EVEX-Bitfeld verwendet, um die Spezifizierergröße auf 32 Register zu erweitern.
  • EVEX.U-1768-Klassenfeld (EVEX-Byte 2, Bit [2]-U) - falls EVEX.U = 0 ist, gibt es Klasse A oder EVEX.U0 an; falls EVEX.U = 1 ist, gibt es Klasse B oder EVEX.U1 an.
  • Präfixcodierfeld 1825 (EVEX-Byte 2, Bits [1:0]-pp) - es stellt zusätzliche Bits für das Basisoperationsfeld bereit. Zusätzlich zur Bereitstellung von Unterstützung für die Legacy-SSE-Befehle im EVEX-Präfixformat hat dies auch den Vorteil der Kompaktierung des SIMD-Präfixes (statt ein Byte für den Ausdruck des SIMD-Präfixes zu benötigen, benötigt der EVEX-Präfix nur 2 Bits). Gemäß einer Ausführungsform werden diese Legacy-SIMD-Präfixe zur Unterstützung von Legacy-SSE-Befehlen, die einen SIMD-Präfix (66H, F2H, F3H) sowohl im Legacy-Format als auch im EVEX-Präfixformat verwenden, in das SIMD-Präfixcodierfeld codiert und zur Laufzeit zum Legacy-SIMD-Präfix erweitert, bevor sie dem Decodierer-PLA bereitgestellt werden (so dass das PLA sowohl das Legacy- als auch das EVEX-Format dieser Legacy-Befehle ohne Modifikation ausführen kann). Wenngleich neuere Befehle den Inhalt des EVEX-Präfix-Codierfelds direkt als Opcode-Erweiterung verwenden könnten, erweitern bestimmte Ausführungsformen in ähnlicher Weise auf Konsistenz, ermöglichen jedoch, dass unterschiedliche Bedeutungen durch diese Legacy-SIMD-Präfixe spezifiziert werden. Eine alternative Ausführungsform kann das PLA umgestalten, um die 2 Bit-SIMD-Präfixcodierungen zu unterstützen, so dass die Erweiterung nicht erforderlich ist.
  • Alphafeld 1752 (EVEX-Byte 3, Bit [7] - EH; auch als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.Schreibmaskensteuerung und EVEX.N bekannt, auch mit α bezeichnet) - wie zuvor beschrieben, ist dieses Feld kontextspezifisch.
  • Betafeld 1754 (EVEX-Byte 3, Bits [6:4]-SSS, auch als EVEX.S2-0, EVEX.r2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB bekannt; auch mit βββ bezeichnet) - wie zuvor beschrieben, ist dieses Feld kontextspezifisch.
  • REX' 1810B - dies ist der Rest des REX'-Felds 1810 und ist das EVEX.V'-Bitfeld (EVEX-Byte 3, Bit [3] - V'), das zur Codierung entweder der oberen 16 oder der unteren 16 des erweiterten 32-Register-Satzes verwendet werden kann. Dieses Bit wird in einem bitinvertierten Format gespeichert. Ein Wert von 1 wird zur Codierung der unteren 16 Register verwendet. Mit anderen Worten wird V'VVVV durch Kombinieren von EVEX.V', EVEX.vvvv. gebildet.
  • Schreibmaskenfeld 1770 (EVEX-Byte 3, Bits [2:0]-kkk) - sein Inhalt spezifiziert den Index eines Registers in den Schreibmaskenregistern, wie zuvor beschrieben. Gemäß einigen Ausführungsformen hat der spezifische Wert EVEX.kkk = 000 ein spezielles Verhalten, das impliziert, dass keine Schreibmaske für den bestimmten Befehl verwendet wird (dies kann auf eine Vielzahl von Arten, einschließlich der Verwendung einer Schreibmaske, die mit ausschließlich Einsen festverdrahtet ist, oder Hardware, welche die Maskierungshardware umgeht, implementiert werden).
  • Realer-Opcode-Feld 1830 (Byte 4) ist auch als Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert.
  • Das MOD-R/M-Feld 1840 (Byte 5) weist das MOD-Feld 1842, das Reg-Feld 1844 und das R/M-Feld 1846 auf. Wie zuvor beschrieben, unterscheidet der Inhalt des MOD-Felds 1842 zwischen Speicherzugriffs- und Nicht-Speicherzugriffsoperationen. Die Rolle des Reg-Felds 1844 kann in Bezug auf zwei Situationen zusammengefasst werden: eine Codierung entweder des Zielregisteroperanden oder eines Quellregisteroperanden oder eine Behandlung als Opcode-Erweiterung und keine Verwendung zur Codierung eines Befehlsoperanden. Die Rolle des R/M-Felds 1846 kann Folgende umfassen: eine Codierung des Befehlsoperanden, der einen Speicherzugriff referenziert, oder eine Codierung entweder des Zielregisteroperanden oder eines Quellregisteroperanden.
  • Skalierung-, Index-, Basis(SIB)-Byte (Byte 6) 1850 - wie zuvor beschrieben, wird das Skalierungsfeld SIB.ss 1852 zur Speicheradresserzeugung verwendet. SIB.xxx 1854 und SIB.bbb 1856 - die Inhalte dieser Felder wurden zuvor in Bezug auf die Registerindizes Xxxx und Bbbb erwähnt.
  • Versatzfeld 1762A (Bytes 7 - 10) - wenn das MOD-Feld 1842 10 enthält, sind die Bytes 7 - 10 das Versatzfeld 1762A, und es wirkt ebenso wie der Legacy-32-Bitversatz (disp32), und es wirkt mit Bytegranularität.
  • Versatzfaktorfeld 1762B (Byte 7) - wenn das MOD-Feld 1842 01 enthält, ist Byte 7 das Versatzfaktorfeld 1762B. Die Stelle dieses Felds gleicht jener des 8-Bit-Versatzes (disp8) des Legacy-x86-Befehlssatzes, und es wirkt mit Bytegranularität. Weil disp8 vorzeichenerweitert ist, kann es nur zwischen -128- und 127-Byte-Offsets adressieren. In Bezug auf 64-Byte-Cache-Leitungen verwendet disp8 8 Bits, die auf nur vier wirklich verwendbare Werte -128, -64, 0 und 64 gesetzt werden können, weil jedoch häufig ein größerer Bereich erforderlich ist, wird disp32 verwendet, wobei disp32 4 Bytes benötigt. Im Gegensatz zu disp8 und disp32 ist das Versatzfaktorfeld 1762B eine Reinterpretation von disp8, wobei, wenn das Versatzfaktorfeld 1762B verwendet wird, der tatsächliche Versatz durch den Inhalt des Versatzfaktorfelds, multipliziert mit der Größe des Speicheroperandenzugriffs (N) festgelegt ist. Dieser Versatztyp wird als disp8*N bezeichnet. Dies verringert die durchschnittliche Befehlslänge (ein einziges Byte wird für den Versatz verwendet, jedoch mit einem viel größeren Bereich). Dieser komprimierte Versatz beruht auf der Annahme, dass der effektive Versatz ein Mehrfaches der Granularität des Speicherzugriffs ist, so dass die redundanten niederwertigen Bits des Adress-Offsets nicht codiert zu werden brauchen. Mit anderen Worten ersetzt das Versatzfaktorfeld 1762B den 8-Bit-Versatz des Legacy-x86-Befehlssatzes. Demgemäß wird das Versatzfaktorfeld 1762B in der gleichen Weise codiert wie ein 8-Bit-Versatz des x86-Befehlssatzes (so dass keine Änderungen in den ModRM/SIB-Codierregeln auftreten), mit der einzigen Ausnahme, dass disp8 zu disp8*N überladen wird. Mit anderen Worten gibt es keine Änderungen in den Codierregeln oder Codierlängen, sondern lediglich bei der Interpretation des Versatzwerts durch Hardware (welche den Versatz mit der Größe des Speicheroperanden skalieren muss, um einen byteweisen Adress-Offset zu erhalten). Das Unmittelbar-Feld 1772 wirkt wie zuvor beschrieben.
  • VOLLSTÄNDIGER-OPCODE-FELD
  • 18B ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats 1800 zeigt, welche das Vollständiger-Opcode-Feld 1774 bilden, gemäß einigen Ausführungsformen. Insbesondere weist das Vollständiger-Opcode-Feld 1774 das Formatfeld 1740, das Basisoperationsfeld 1742 und das Datenelementbreiten(W)-Feld 1764 auf. Das Basisoperationsfeld 1742 weist das Präfixcodierfeld 1825, das Opcode-Zuordnungsfeld 1815 und das Realer-Opcode-Feld 1830 auf.
  • REGISTERINDEXFELD
  • 18C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats 1800 zeigt, welche das Registerindexfeld 1744 bilden, gemäß einigen Ausführungsformen. Insbesondere weist das Registerindexfeld 1744 das REX-Feld 1805, das REX'-Feld 1810, das MODR/M.reg-Feld 1844, das MODR/M.r/m-Feld 1846, das VVVV-Feld 1820, das xxx-Feld 1854 und das bbb-Feld 1856 auf.
  • ERWEITERUNGSOPERATIONSFELD
  • 18D ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Befehlsformats 1800 zeigt, welche das Erweiterungsoperationsfeld 1750 bilden, gemäß einigen Ausführungsformen. Wenn das Klassenfeld (U) 1768 0 enthält, bedeutet es EVEX.U0 (Klasse A 1768A), wenn es 1 enthält, bedeutet es EVEX.U1 (Klasse B 1768B). Wenn U = 0 ist und das MOD-Feld 1842 11 enthält (was eine Kein-Speicherzugriff-Operation bedeutet), wird das Alphafeld 1752 (EVEX-Byte 3, Bit [7] - EH) als das rs-Feld 1752A interpretiert. Wenn das rs-Feld 1752A eine 1 enthält (Rundung 1752A.1), wird das Betafeld 1754 (EVEX-Byte 3, Bits [6:4]- SSS) als das Rundungssteuerfeld 1754A interpretiert. Das Rundungssteuerfeld 1754A weist ein Ein-Bit-SAE-Feld 1756 und ein Zwei-Bit-Rundungsoperationsfeld 1758 auf. Wenn das rs-Feld 1752A eine 0 enthält (Datentransformation 1752A.2), wird das Betafeld 1754 (EVEX-Byte 3, Bits [6:4]-SSS) als ein Drei-Bit-Datentransformationsfeld 1754B interpretiert. Wenn U = 0 ist und das MOD-Feld 1842 00, 01 oder 10 enthält (was eine Speicherzugriffsoperation bedeutet), wird das Alphafeld 1752 (EVEX-Byte 3, Bit [7] - EH) als das Räumungshinweis(EH)-Feld 1752B interpretiert und wird das Betafeld 1754 (EVEX-Byte 3, Bits [6:4]- SSS) als ein Datenmanipulationsfeld 1754C mit drei Bits interpretiert.
  • Wenn U = 1 ist, wird das Alphafeld 1752 (EVEX-Byte 3, Bit [7] - EH) als das Schreibmaskensteuer(Z)-Feld 1752C interpretiert. Wenn U = 1 ist und das MOD-Feld 1842 11 enthält (was eine Kein-Speicherzugriff-Operation bedeutet), wird ein Teil des Betafelds 1754 (EVEX-Byte 3, Bit [4]- S0) als das RL-Feld 1757A interpretiert, und wenn es eine 1 (Rundung 1757A.1) enthält, wird der Rest des Betafelds 1754 (EVEX-Byte 3, Bit [6-5]- S2-1) als das Rundungsoperationsfeld 1759A interpretiert, während, wenn das RL-Feld 1757A eine 0 enthält (V-Größe 1752.A2), der Rest des Betafelds 1754 (EVEX-Byte 3, Bit [6-5]- S2-1) als Vektorlängenfeld 1759B (EVEX-Byte 3, Bit [6-5]- L1-0) interpretiert wird. Wenn U = 1 ist und das MOD-Feld 184200, 01 oder 10 enthält (was eine Speicherzugriffsoperation bedeutet), wird das Betafeld 1754 (EVEX-Byte 3, Bit [6:4]- SSS) als das Vektorlängenfeld 1759B (EVEX-Byte 3, Bit [6-5]- L1-0) und das Rundsendefeld 1757B (EVEX-Byte 3, Bit [4]- B) interpretiert.
  • BEISPIELHAFTE REGISTERARCHITEKTUR
  • 19 ist ein Blockdiagramm einer Registerarchitektur 1900 gemäß einigen Ausführungsformen. Gemäß der dargestellten Ausführungsform gibt es 32 Vektorregister 1910, die 512 Bits breit sind, wobei diese Register als zmm0 bis zmm31 bezeichnet werden. Die niederwertigen 256 Bits der unteren 16 zmm-Register sind Registern ymm0-16 überlagert. Die niederwertigen 128 Bits der unteren 16 zmm-Register (die niederwertigen 128 Bits der ymm-Register) sind den Registern xmmO-15 überlagert. Das spezifische vektorfreundliche Befehlsformat 1800 wirkt wie in den nachstehenden Tabellen dargestellt auf diese überlagerte Registerdatei.
    Einstellbare Vektorlänge Klasse Operationen Register
    Befehlsschablonen, die das Vektorlängenfeld 1759B nicht aufweisen A (Figur 1710, 1715, zmm-Register (die Vektorlänge beträgt
    17A; 1725, 1730 64 Bytes)
    U = 0)
    B (Figur 1712 zmm-Register (die Vektorlänge beträgt
    17B; 64 Bytes)
    U = 1)
    Befehlsschablonen, die B (Figur 1717, 1727 zmm-, ymm- oder xmm-Register (die
    das Vektorlängenfeld 17B; Vektorlänge beträgt 64 Bytes, 32 Bytes
    1759B aufweisen U = 1) oder 16 Bytes), abhängig vom Vektorlängenfeld 1759B
  • Mit anderen Worten wählt das Vektorlängenfeld 1759B zwischen einer maximalen Länge und einer oder mehreren anderen geringeren Längen, wobei jede solche geringere Länge die Hälfte der vorhergehenden Länge ist und Befehlsschablonen ohne das Vektorlängenfeld 1759B auf die maximale Vektorlänge wirken. Ferner wirken die Klasse-B-Befehlsschablonen des spezifischen vektorfreundlichen Befehlsformats 1800 auf gepackte oder skalare Gleitkommadaten mit einfacher oder doppelter Genauigkeit und gepackte oder skalare ganzzahlige Daten. Skalaroperationen sind Operationen, die auf die Datenelementposition unterster Ordnung in einem zmm/ymm/xmm-Register ausgeführt werden, wobei die Datenelementpositionen höherer Ordnung entweder so belassen werden, wie sie vor dem Befehl waren, oder auf null gesetzt werden, wobei dies von der Ausführungsform abhängt.
  • Schreibmaskenregister 1915 - gemäß der dargestellten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), die jeweils 64 Bits groß sind. Gemäß einer alternativen Ausführungsform sind die Schreibmaskenregister 1915 16 Bits groß. Wie zuvor beschrieben, kann das Vektormaskenregister k0 gemäß einigen Ausführungsformen nicht als Schreibmaske verwendet werden, wobei, wenn die Codierung, die normalerweise k0 angibt, für eine Schreibmaske verwendet wird, sie eine festverdrahtete Schreibmaske von 0xffff auswählt, wodurch effektiv die Schreibmaskierung für diesen Befehl deaktiviert wird.
  • Register für allgemeine Zwecke 1925 - gemäß der dargestellten Ausführungsform gibt es sechzehn 64-Bit-Register für allgemeine Zwecke, die zusammen mit den existierenden x86-Adressiermodi verwendet werden, um Speicheroperanden zu adressieren. Diese Register sind mit den Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 bezeichnet.
  • Skalare Gleitkomma-Stapelregisterdatei (x87-Stapel) 1945, auf der die gepackte ganzzahlige flache MMX-Registerdatei 1950 stellvertretend angesprochen wird - gemäß der dargestellten Ausführungsform ist der x87-Stapel ein Acht-Elemente-Stapel, der zur Ausführung skalarer Gleitkommaoperationen an 32/64/80-Bit-Gleitkommadaten unter Verwendung der x87-Befehlssatzerweiterung verwendet wird, während die MMX-Register verwendet werden, um Operationen an gepackten ganzzahligen 64-Bit-Daten auszuführen sowie Operanden für einige Operationen zu halten, die zwischen den MMX- und XMM-Registern ausgeführt werden.
  • Alternative Ausführungsformen können breitere oder schmalere Register verwenden. Zusätzlich können alternative Ausführungsformen mehr, weniger oder andere Registerdateien und Register verwenden.
  • BEISPIELHAFTE KERNARCHITEKTUREN, PROZESSOREN UND COMPUTERARCHITEKTUREN
  • Prozessorkerne können auf verschiedene Arten, für verschiedene Zwecke und in verschiedenen Prozessoren implementiert werden. Beispielsweise können Implementationen solcher Kerne Folgendes aufweisen: 1) einen In-der-Reihe-Kern für allgemeine Zwecke, der für Berechnungen für allgemeine Zwecke vorgesehen ist, 2) einen Hochleistungs-außerhalb-der-Reihe-Kern für allgemeine Zwecke, der für Berechnungen für allgemeine Zwecke vorgesehen ist, 3) einen Kern für spezielle Zwecke, der in erster Linie für Graphik- und/oder wissenschaftliche Berechnungen (Durchsatz) vorgesehen ist. Implementationen verschiedener Prozessoren können Folgendes aufweisen: 1) eine CPU, die einen oder mehrere In-der-Reihe-Kerne für allgemeine Zwecke, die für Berechnungen für allgemeine Zwecke vorgesehen sind, und/oder einen oder mehrere Außerhalb-der-Reihe-Kerne für allgemeine Zwecke, die für Berechnungen für allgemeine Zwecke vorgesehen sind, aufweist, und 2) einen Coprozessor, der einen oder mehrere Kerne für spezielle Zwecke aufweist, die in erster Linie für graphische und/oder wissenschaftliche Zwecke (Durchsatz) vorgesehen sind. Solche verschiedene Prozessoren führen zu verschiedenen Computersystemarchitekturen, die Folgendes aufweisen können: 1) den Coprozessor auf einem von der CPU getrennten Chip, 2) den Coprozessor auf einem getrennten Die in derselben Baugruppe wie eine CPU, 3) den Coprozessor auf demselben Die wie eine CPU (wobei in diesem Fall ein solcher Coprozessor manchmal als Logik für spezielle Zwecke in der Art einer integrierten Graphik- und/oder wissenschaftlichen Logik (Durchsatz) oder als Kerne für spezielle Zwecke bezeichnet wird) und 4) ein System-auf-einem-Chip, das auf demselben Die die beschriebene CPU (manchmal als Anwendungskern(e) oder Anwendungsprozessor(en) bezeichnet), den vorstehend beschriebenen Coprozessor und zusätzliche Funktionalität aufweisen kann. Als nächstes werden beispielhafte Kernarchitekturen beschrieben, worauf Beschreibungen beispielhafter Prozessoren und Computerarchitekturen folgen.
  • BEISPIELHAFTE KERNARCHITEKTUREN
  • IN-DER-REIHE- UND AUßERHALB-DER-REIHE-KERN-BLOCKDIAGRAMM
  • 20A ist ein Blockdiagramm, das sowohl eine als Beispiel dienende In-der-Reihenfolge-Pipeline als auch eine als Beispiel dienende Register-umbenennende Außerhalb-der-Reihenfolge-Ausgabe/Ausführung-Pipeline gemäß einigen Ausführungsformen der Erfindung zeigt. 20B ist ein Blockdiagramm, das sowohl eine als Beispiel dienende Ausführungsform eines In-der-Reihenfolge-Architekturkerns als auch eines als Beispiel dienenden Register-umbenennenden Außerhalb-der-Reihenfolge-Ausgabe/Ausführung-Architekturkerns, der in einen Prozessor gemäß Ausführungsformen der Erfindung aufzunehmen ist, zeigt. Die mit durchgezogenen Linien dargestellten Kästchen in den 20A-B zeigen die In-der-Reihenfolge-Pipeline und den In-der-Reihenfolge-Kern, während die optionale Hinzufügung der mit gestrichelten Linien dargestellten Kästchen die Register-umbenennende Außerhalb-der-Reihenfolge-Ausgabe/Ausführung-Pipeline und den Register-umbenennenden Außerhalb-der-Reihenfolge-Ausgabe/Ausführung-Kern zeigt. Unter der Voraussetzung, dass der In-der-Reihenfolge-Aspekt eine Untermenge des Außerhalb-der-Reihenfolge-Aspekts ist, wird der Außerhalb-der-Reihenfolge-Aspekt beschrieben.
  • In 20A umfasst eine Prozessorpipeline 2000 eine Abrufstufe 2002, eine Längendecodierstufe 2004, eine Decodierstufe 2006, eine Zuordnungsstufe 2008, eine Umbenennungsstufe 2010, eine Planungsstufe 2012 (auch als Absende- oder Ausgabestufe bezeichnet), eine Registerlese/Speicherlese-Stufe 2014, eine Ausführungsstufe 2016, eine Rückschreib/Speicherschreib-Stufe 2018, eine Ausnahmebehandlungsstufe 2022 und eine Übergabestufe 2024.
  • 20B zeigt einen Prozessorkern 2090 mit einer Vorverarbeitungseinheit 2030, die mit einer Ausführungsmaschineneinheit 2050 gekoppelt ist, und beide sind mit einer Speichereinheit 2070 gekoppelt. Der Kern 2090 kann ein Rechenkern mit einem reduzierten Befehlssatz (RISC), ein Rechenkern mit einem komplexen Befehlssatz (CISC), ein Kern mit einem sehr langen Befehlswort (VLIW) oder ein hybrider oder alternativer Kerntyp sein. Als eine andere Option kann der Kern 2090 ein Kern für spezielle Zwecke in der Art beispielsweise eines Netz- oder Kommunikationskerns, einer Kompressionsmaschine, eines Coprozessorkerns, eines Graphikverarbeitungseinheitskerns für allgemeine Rechenzwecke (GPGPU-Kerns), eines Graphikkerns oder dergleichen sein.
  • Die Vorverarbeitungseinheit 2030 umfasst eine Zweigvorhersageeinheit 2032, die mit einer Befehls-Cache-Einheit 2034 gekoppelt ist, welche mit einem Befehlsübersetzungs-Lookaside-Puffer (TLB) 2036 gekoppelt ist, welcher mit einer Befehlsabrufeinheit 2038 gekoppelt ist, welche mit einer Decodiereinheit 2040 gekoppelt ist. Die Decodiereinheit 2040 (oder Decoder) kann Befehle decodieren und als eine Ausgabe eine oder mehrere Mikrooperationen, Mikrocode-Eintrittspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale erzeugen, welche anhand der ursprünglichen Befehle decodiert werden oder diese auf andere Weise reflektieren oder von diesen abgeleitet wurden. Die Decodiereinheit 2040 kann unter Verwendung mehrerer verschiedener Mechanismen implementiert werden. Beispiele geeigneter Mechanismen umfassen Nachschlagetabellen, Hardwareimplementationen, programmierbare Logikfelder (PLA), Mikrocode-Nurlesespeicher (ROM) usw., sind jedoch nicht darauf beschränkt. Gemäß einer Ausführungsform umfasst der Kern 2090 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für bestimmte Makrobefehle speichert (beispielsweise in der Decodiereinheit 2040 oder anderswo in der Vorverarbeitungseinheit 2030). Die Decodiereinheit 2040 ist mit einer Umbenennungs-/Zuordnungseinheit 2052 in der Ausführungsmaschineneinheit 2050 gekoppelt.
  • Die Ausführungsmaschineneinheit 2050 umfasst die Umbenennungs-/Zuordnungseinheit 2052, die mit einer Zurückzieheinheit 2054 und einem Satz einer oder mehrerer Planereinheiten 2056 gekoppelt ist. Die Planereinheit (die Planereinheiten) 2056 repräsentiert (repräsentieren) irgendeine Anzahl verschiedener Planer, einschließlich Reservierstationen, eines zentralen Befehlsfensters usw. Die Planereinheit (die Planereinheiten) 2056 ist (sind) mit der physikalischen Registerdateieinheit (den physikalischen Registerdateieinheiten) 2058 gekoppelt. Jede der physikalischen Registerdateieinheiten 2058 repräsentiert eine oder mehrere physikalische Registerdateien, von denen verschiedene einen oder mehrere verschiedene Datentypen speichern, in der Art eines skalaren ganzzahligen Typs, eines skalaren Gleitkommatyps, eines gepackten ganzzahligen Typs, eines gepackten Gleitkommatyps, eines vektoriellen ganzzahligen Typs, eines vektoriellen Gleitkommatyps, eines Status (beispielsweise eines Befehlszeigers, welche die Adresse des nächsten auszuführenden Befehls ist) usw. Gemäß einer Ausführungsform umfasst die physikalische Registerdateieinheit 2058 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und skalare Registereinheit. Diese Registereinheiten können Architekturvektorregister, Vektormaskenregister und Register für allgemeine Zwecke bereitstellen. Die physikalische Registerdateieinheit (die physikalischen Registerdateieinheiten) 2058 ist (sind) von der Zurückzieheinheit 2054 überlappt, um verschiedene Wege zu zeigen, in denen eine Registerumbenennung und eine Außerhalb-der-Reihenfolge-Ausführung implementiert werden können (beispielsweise unter Verwendung eines oder mehrerer Umordnungspuffer und einer oder mehrerer Zurückziehregisterdateien; unter Verwendung einer oder mehrerer künftiger Dateien, eines oder mehrerer Geschichtspuffer und einer oder mehrerer Zurückziehregisterdateien; unter Verwendung einer Registerkarte und eines Pools von Registern usw.). Die Zurückzieheinheit 2054 und die eine oder die mehreren physikalischen Registerdateieinheiten 2058 sind mit dem einen oder den mehreren Ausführungsclustern 2060 gekoppelt. Der eine oder die mehreren Ausführungscluster 2060 umfassen einen Satz einer oder mehrerer Ausführungseinheiten 2062 und einen Satz einer oder mehrerer Speicherzugriffseinheiten 2064. Die Ausführungseinheiten 2062 können verschiedene Operationen (beispielsweise Verschiebungen, Addition, Subtraktion, Multiplikation) auf verschiedenen Datentypen ausführen (beispielsweise einem skalaren Gleitkommatyp, einem gepackten ganzzahligen Typ, einem gepackten Gleitkommatyp, einem vektoriellen ganzzahligen Typ, einem vektoriellen Gleitkommatyp). Wenngleich einige Ausführungsformen eine Anzahl von Ausführungseinheiten aufweisen können, die für spezifische Funktionen oder Sätze von Funktionen zweckgebunden sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten aufweisen, die alle alle Funktionen ausführen. Die eine oder die mehreren Planereinheiten 2056, die eine oder die mehreren physikalischen Registerdateieinheiten 2058 und der eine oder die mehreren Ausführungscluster 2060 sind als möglicherweise mehrere Einheiten dargestellt, weil bestimmte Ausführungsformen getrennte Pipelines für bestimmte Typen von Daten/Operationen erzeugen (beispielsweise eine skalare ganzzahlige Pipeline, eine skalare Gleitkomma/gepackte ganzzahlige/gepackte Gleitkomma/vektorielle ganzzahlige/vektorielle Gleitkommapipeline und/oder eine Speicherzugriffspipeline, die jeweils ihre eigene Planereinheit, ihre eigene physikalische Registerdateieinheit und/oder ihren eigenen Ausführungscluster aufweisen, und im Fall einer getrennten Speicherzugriffspipeline werden bestimmte Ausführungsformen implementiert, bei denen nur der Ausführungscluster dieser Pipeline die eine oder die mehreren Speicherzugriffseinheiten 2064 aufweist). Es sei auch bemerkt, dass dort, wo getrennte Pipelines verwendet werden, eine oder mehrere dieser Pipelines eine Außerhalb-der-Reihenfolge-Ausgabe/Ausführung aufweisen können und dass der Rest eine In-der-Reihenfolge-Ausgabe/Ausführung aufweisen kann.
  • Der Satz von Speicherzugriffseinheiten 2064 ist mit der Speichereinheit 2070 gekoppelt, welche eine Daten-TLB-Einheit 2072 aufweist, die mit einer Daten-Cache-Einheit 2074 gekoppelt ist, welche mit einer Level-2(L2)-Cache-Einheit 2076 gekoppelt ist. Gemäß einer als Beispiel dienenden Ausführungsform können die Speicherzugriffseinheiten 2064 eine Ladeeinheit, eine Speicheradresseinheit und eine Speicherdateneinheit aufweisen, die jeweils mit der Daten-TLB-Einheit 2072 in der Speichereinheit 2070 gekoppelt sind. Die Befehls-Cache-Einheit 2034 ist ferner mit einer Level-2(L2)-Cache-Einheit 2076 in der Speichereinheit 2070 gekoppelt. Die L2-Cache-Einheit 2076 ist mit einer oder mehreren anderen Cacheebenen und schließlich mit einem Hauptspeicher gekoppelt.
  • Beispielsweise kann die als Beispiel dienende Registerumbenennungs-außerhalb-der-Reihenfolge-Ausgabe/Ausführung-Kernarchitektur die Pipeline 2000 folgendermaßen implementieren: 1) Der Befehlsabruf 2038 führt die Abruf- und Längendecodierstufen 2002 und 2004 aus; 2) die Decodiereinheit 2040 führt die Decodierstufe 2006 aus; 3) die Umbenennungs-/Zuordnungseinheit 2052 führt die Zuordnungsstufe 2008 und die Umbenennungsstufe 2010 aus; 4) die eine oder die mehreren Planereinheiten 2056 führen die Planungsstufe 2012 aus; 5) die eine oder die mehreren physikalischen Registerdateieinheiten 2058 und die Speichereinheit 2070 führen die Registerlese-/Speicherlesestufe 2014 aus, der Ausführungscluster 2060 führt die Ausführungsstufe 2016 aus; 6) die Speichereinheit 2070 und die eine oder die mehreren physikalischen Registerdateieinheiten 2058 führen die Rückschreib-/Speicherschreibstufe 2018 aus; 7) verschiedene Einheiten können an der Ausführungsbehandlungsstufe 2022 beteiligt sein; und 8) die Zurückzieheinheit 2054 und die eine oder die mehreren physikalischen Registerdateieinheiten 2058 führen die Übergabestufe 2024 aus.
  • Der Kern 2090 kann einen oder mehrere Befehlssätze unterstützen (beispielsweise den x86-Befehlssatz (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden); den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen in der Art von NEON) von ARM Holdings aus Sunnyvale, CA), einschließlich des darin beschriebenen Befehls (der darin beschriebenen Befehle). Gemäß einer Ausführungsform umfasst der Kern 2090 Logik zum Unterstützen einer PaketdatenBefehlssatzerweiterung (beispielsweise AVX1, AVX2), wodurch es ermöglicht wird, dass die von vielen Multimediaanwendungen verwendeten Operationen unter Verwendung von Paketdaten ausgeführt werden.
  • Es sei bemerkt, dass der Kern ein Multithreading unterstützen kann (eine Ausführung zweier oder mehrerer paralleler Befehlssätze oder Threads) und dies auf eine Vielzahl von Arten ausführen kann, einschließlich eines Zeitschlitz-Multithreadings, eines gleichzeitigen Multithreadings (wobei ein einziger physikalischer Kern einen logischen Kern für jeden der Threads bereitstellt, an denen der physikalische Kern gleichzeitig ein Multithreading ausführt) oder einer Kombination davon (beispielsweise eines Zeitschlitz-Abrufs und einer Zeitschlitz-Decodierung und eines anschließenden gleichzeitigen Multithreadings wie bei der Hyperthreading-Technologie von Intel®).
  • Wenngleich die Registerumbenennung in Zusammenhang mit einer Außerhalb-der-Reihenfolge-Ausführung beschrieben wird, ist zu verstehen, dass die Registerumbenennung auch in einer In-der-Reihenfolge-Architektur verwendet werden kann. Wenngleich die dargestellte Ausführungsform des Prozessors auch getrennte Befehls- und Daten-Cache-Einheiten 2034/2074 und eine geteilte L2-Cache-Einheit 2076 aufweist, können alternative Ausführungsformen einen einzigen internen Cache sowohl für Befehle als auch für Daten aufweisen, wie beispielsweise einen internen Level-1(L1)-Cache, oder mehrere Ebenen des internen Cache. Gemäß einigen Ausführungsformen kann das System eine Kombination eines internen Cache und eines externen Cache, der außerhalb des Kerns und/oder des Prozessors liegt, aufweisen. Alternativ kann der gesamte Cache außerhalb des Kerns und/oder des Prozessors liegen.
  • SPEZIFISCHE ALS BEISPIEL DIENENDE IN-DER-REIHENFOLGE-KERNARCHITEKTUR
  • Die 21A-B zeigen ein Blockdiagramm einer spezifischeren als Beispiel dienenden In-der-Reihenfolge-Kernarchitektur, wobei der Kern einer von mehreren Logikblöcken (einschließlich anderer Kerne desselben Typs und/oder anderer Typen) in einem Chip wäre. Die Logikblöcke kommunizieren über ein Zwischenverbindungsnetz (beispielsweise ein Ringnetz) hoher Bandbreite mit einer Festfunktionslogik, Speicher-E/A-Schnittstellen und anderer erforderlicher E/A-Logik, abhängig von der Anwendung.
  • 21A ist ein Blockdiagramm eines Einzelprozessorkerns zusammen mit seiner Verbindung zum auf dem Chip liegenden Zwischenverbindungsnetz 2102 und mit seiner lokalen Untermenge des Level-2(L2)-Cache 2104 gemäß einigen Ausführungsformen der Erfindung. Gemäß einer Ausführungsform unterstützt ein Befehlsdecodierer 2100 den x86-Befehlssatz mit einer Paketdatenbefehlssatzerweiterung. Ein L1-Cache 2106 ermöglicht Zugriffe geringer Latenz auf den Cachespeicher in Skalar- und Vektoreinheiten. Wenngleich gemäß einer Ausführungsform (zur Vereinfachung des Entwurfs) eine Skalareinheit 2108 und eine Vektoreinheit 2110 getrennte Registersätze verwenden (Skalarregister 2112 bzw. Vektorregister 2114) und zwischen ihnen übertragene Daten in den Speicher geschrieben werden und dann aus einem Level-1(L1)-Cache 2106 zurückgelesen werden, können alternative Ausführungsformen der Erfindung einen anderen Ansatz verwenden (beispielsweise einen einzigen Registersatz verwenden oder einen Kommunikationsweg aufnehmen, welche es ermöglichen, dass Daten zwischen den beiden Registerdateien übertragen werden, ohne geschrieben und zurückgelesen zu werden).
  • Die lokale Untermenge des L2-Cache 2104 ist Teil eines globalen L2-Cache, der in getrennte lokale Untermengen zerlegt ist, nämlich eine pro Prozessorkern. Jeder Prozessorkern hat einen direkten Zugangsweg zu seiner eigenen lokalen Untermenge des L2-Cache 2104. Durch einen Prozessorkern gelesene Daten werden in seiner L2-Cacheuntermenge 2104 gespeichert, und es kann auf sie, parallel mit anderen Prozessorkernen, die auf ihre eigenen lokalen L2-Cacheuntermengen zugreifen, schnell zugegriffen werden. Durch einen Prozessorkern geschriebene Daten werden in seiner eigenen L2-Cacheuntermenge 2104 gespeichert und aus anderen Untermengen entnommen, falls dies erforderlich ist. Das Ringnetz gewährleistet eine Kohärenz für geteilte Daten. Das Ringnetz ist bidirektional, um zu ermöglichen, dass Agenten, wie Prozessorkerne, L2-Caches und andere Logikblöcke, innerhalb des Chips miteinander kommunizieren. Jeder Ringdatenweg ist pro Richtung 1012 Bits breit.
  • 21B ist eine erweiterte Ansicht eines Teils des Prozessorkerns aus 21A gemäß einigen Ausführungsformen der Erfindung. 21B umfasst einen L1-Datencache-2106A-Teil des L1-Cache 2104 sowie weitere Einzelheiten in Bezug auf die Vektoreinheit 2110 und die Vektorregister 2114. Insbesondere ist die Vektoreinheit 2110 eine 16-breite Vektorverarbeitungseinheit (VPU) (siehe die 16-breite ALU 2128), welche einen oder mehrere von ganzzahligen Befehlen, Gleitkommabefehlen einfacher Genauigkeit und Gleitkommabefehlen doppelter Genauigkeit ausführt. Die VPU unterstützt eine Verwürfelung der Registereingaben mit der Verwürfelungseinheit 2120, eine numerische Konvertierung mit numerischen Konvertiereinheiten 2122A und 2122B und eine Replikation mit einer Replikationseinheit 2124 am Speichereingang. Schreibmaskenregister 2126 ermöglichen ein Prädizieren sich ergebender Vektorschreibvorgänge.
  • 22 ist ein Blockdiagramm eines Prozessors 2200, der mehr als einen Kern aufweisen kann, eine integrierte Speichersteuereinrichtung aufweisen kann und eine integrierte Graphik aufweisen kann, gemäß einigen Ausführungsformen der Erfindung. Die in durchgezogenen Linien dargestellten Kästchen in 22 zeigen einen Prozessor 2200 mit einem einzigen Kern 2202A, einem Systemagenten 2210, einem Satz einer oder mehrerer Bussteuereinheiten 2216, während die optionale Hinzufügung der in gestrichelten Linien dargestellten Kästchen einen alternativen Prozessor 2200 mit mehreren Kernen 2202A bis 2202N, einem Satz einer oder mehrerer integrierter Speichersteuereinheiten 2214 in der Systemagenteneinheit 2210 und eine Logik 2208 für spezielle Zwecke zeigt.
  • Demgemäß können verschiedene Implementationen des Prozessors 2200 Folgendes umfassen: 1) eine CPU mit der Logik 2208 für spezielle Zwecke, welche eine integrierte Graphik- und/oder wissenschaftliche (Durchsatz-) Logik ist (welche einen oder mehrere Kerne aufweisen kann), wobei die Kerne 2202A-N ein oder mehrere Kerne für allgemeine Zwecke sind (beispielsweise In-der-Reihenfolge-Kerne für allgemeine Zwecke, Außerhalb-der-Reihenfolge-Kerne für allgemeine Zwecke, eine Kombination der beiden); 2) einen Coprozessor, wobei die Kerne 2202A-N eine große Anzahl von Kernen für spezielle Zwecke sind, die in erster Linie für Graphik- und/oder wissenschaftliche Zwecke (Durchsatz) vorgesehen sind; und 3) einen Coprozessor, wobei die Kerne 2202A-N eine große Anzahl von In-der-Reihenfolge-Kernen für allgemeine Zwecke sind. Demgemäß kann der Prozessor 2200 ein Prozessor für allgemeine Zwecke, ein Coprozessor oder ein Prozessor für spezielle Zwecke sein, wie beispielsweise ein Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Graphikprozessor, eine GPGPU (Graphikverarbeitungseinheit für allgemeine Zwecke), ein Coprozessor mit vielen integrierten Kernen mit hohem Durchsatz (MIC) (mit 30 oder mehr Kernen), ein eingebetteter Prozessor oder dergleichen. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 2200 kann Teil eines oder mehrerer Substrate sein und/oder unter Verwendung einer beliebigen Anzahl von Prozesstechnologien, wie beispielsweise BiCMOS, CMOS oder NMOS, auf einem oder mehreren Substraten implementiert sein.
  • Die Speicherhierarchie umfasst einen oder mehrere Cacheebenen innerhalb der Kerne, einen Satz oder eine oder mehrere geteilte Cache-Einheiten 2206 und einen externen Speicher (nicht dargestellt), der mit dem Satz integrierter Speichersteuereinheiten 2214 gekoppelt ist. Der Satz geteilter Cache-Einheiten 2206 kann einen oder mehrere Mittelebenencaches in der Art von Level 2 (L2), Level 3 (L3), Level 4 (L4) oder anderer Cacheebenen, einen Last-Level-Cache (LLC) und/oder Kombinationen davon aufweisen. Wenngleich gemäß einer Ausführungsform eine ringbasierte Zwischenverbindungseinheit 2212 die integrierte Graphiklogik 2208 (die integrierte Graphiklogik 2208 ist ein Beispiel einer Logik für spezielle Zwecke und wird hier auch so bezeichnet), den Satz geteilter Cache-Einheiten 2206 und die Systemagenteneinheit 2210/die eine oder die mehreren integrierten Speichersteuereinheiten 2214 miteinander verbindet, können alternative Ausführungsformen eine beliebige Anzahl wohlbekannter Techniken zur Verbindung dieser Einheiten verwenden. Gemäß einer Ausführungsform wird die Kohärenz zwischen einer oder mehreren Cache-Einheiten 2206 und Kernen 2202A-N aufrechterhalten.
  • Gemäß einigen Ausführungsformen sind einer oder mehrere der Kerne 2202A-N zu einem Multithreading in der Lage. Der Systemagent 2210 umfasst jene Komponenten, die Kerne 2202A N koordinieren und betreiben. Die Systemagenteneinheit 2210 kann beispielsweise eine Leistungssteuereinheit (PCU) und eine Anzeigeeinheit aufweisen. Die PCU kann aus Logik und Komponenten bestehen oder diese aufweisen, welche erforderlich sind, um den Leistungszustand der Kerne 2202A-N und der integrierten Graphiklogik 2208 zu regeln. Die Anzeigeeinheit dient dem Treiben einer oder mehrerer extern angeschlossener Anzeigen.
  • Die Kerne 2202A-N können in Bezug auf den Architekturbefehlssatz homogen oder heterogen sein, so dass zwei oder mehr der Kerne 2202A-N in der Lage sein können, den gleichen Befehlssatz auszuführen, während andere in der Lage sein können, nur eine Untermenge dieses Befehlssatzes oder einen anderen Befehlssatz auszuführen.
  • BEISPIELHAFTE COMPUTERARCHITEKTUREN
  • Die 23 - 26 sind Blockdiagramme als Beispiel dienender Computerarchitekturen. Andere Systementwürfe und -konfigurationen, die auf dem Fachgebiet für Laptops, Desktops, handgehaltene PC, persönliche digitale Assistenten, Ingenieursarbeitsstationen, Server, Netzvorrichtungen, Netz-Hubs, Switches, eingebettete Prozessoren, digitale Signalprozessoren (DSP), Graphikvorrichtungen, Videospielvorrichtungen, Settopboxen, Mikrosteuereinrichtungen, Mobiltelefone, tragbare Medienabspielgeräte, handgehaltene Vorrichtungen und verschiedene andere elektronische Vorrichtungen bekannt sind, sind auch geeignet. Im Allgemeinen ist eine große Vielzahl von Systemen oder elektronischen Vorrichtungen, die in der Lage sind, einen Prozessor und/oder eine andere Ausführungslogik aufzunehmen, wie hier offenbart, allgemein geeignet.
  • 23 zeigt ein Blockdiagramm eines Systems 2300 gemäß einer Ausführungsform der vorliegenden Erfindung. Das System 2300 kann einen oder mehrere Prozessoren 2310, 2315 umfassen, die mit einem Steuereinrichtungs-Hub 2320 gekoppelt sind. Gemäß einer Ausführungsform umfasst das Steuereinrichtungs-Hub 2320 ein Graphikspeichersteuereinrichtungs-Hub (GMCH) 2390 und ein Ein-/Ausgabe-Hub (IOH) 2350 (die sich auf getrennten Chips befinden können), umfasst das GMCH 2390 Speicher- und Graphiksteuereinrichtungen, mit denen ein Speicher 2340 und ein Coprozessor 2345 gekoppelt sind, und koppelt das IOH 2350 Ein-/Ausgabe-(E/A)-Vorrichtungen 2360 mit dem GMCH 2390. Alternativ sind einer oder beide der Speicher- und Graphiksteuereinrichtungen in den Prozessor integriert (wie hier beschrieben) und sind der Speicher 2340 und der Coprozessor 2345 in einem Einzelchip mit dem IOH 2350 direkt mit dem Prozessor 2310 und dem Steuereinrichtungs-Hub 2320 gekoppelt.
  • Die optionale Natur zusätzlicher Prozessoren 2315 ist in 23 mit unterbrochenen Linien dargestellt. Jeder Prozessor 2310, 2315 kann einen oder mehrere der hier beschriebenen Prozessorkerne aufweisen und eine Version des Prozessors 2200 sein.
  • Der Speicher 2340 kann beispielsweise ein dynamischer Direktzugriffsspeicher (DRAM), ein Phasenänderungsspeicher (PCM) oder eine Kombination der beiden sein. Für wenigstens eine Ausführungsform kommuniziert das Steuereinrichtungs-Hub 2320 mit dem einen oder den mehreren Prozessoren 2310, 2315 über einen Multi-Drop-Bus in der Art eines Frontside-Busses (FSB), einer Punkt-zu-Punkt-Schnittstelle in der Art einer QuickPath-Zwischenverbindung (QPI) oder einer ähnlichen Verbindung 2395.
  • Gemäß einer Ausführungsform ist der Coprozessor 2345 ein Prozessor für spezielle Zwecke in der Art beispielsweise eines MIC-Prozessors mit einem hohen Durchsatz, eines Netz- oder Kommunikationsprozessors, einer Kompressionsmaschine, eines Graphikprozessors, einer GPGPU, eines eingebetteten Prozessors oder dergleichen. Gemäß einer Ausführungsform kann das Steuereinrichtungs-Hub 2320 einen integrierten Graphikbeschleuniger aufweisen.
  • Es kann eine Vielzahl von Unterschieden zwischen den physikalischen Ressourcen 2310, 2315 in Bezug auf ein Gütemetrikspektrum geben, einschließlich architektonischer, mikroarchitektonischer, thermischer, Leistungsverbrauchsmerkmale und dergleichen.
  • Gemäß einer Ausführungsform führt der Prozessor 2310 Befehle aus, welche Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In die Befehle können Coprozessorbefehle eingebettet sein. Der Prozessor 2310 erkennt diese Coprozessorbefehle als einem Typ angehörend, der durch den angeschlossenen Coprozessor 2345 ausgeführt werden sollte. Demgemäß gibt der Prozessor 2310 diese Coprozessorbefehle (oder Steuersignale, welche Coprozessorbefehle repräsentieren) auf einem Coprozessorbus oder einer anderen Zwischenverbindung an den Coprozessor 2345 aus. Der eine oder die mehreren Coprozessoren 2345 akzeptieren und führen die empfangenen Coprozessorbefehle aus.
  • 24 zeigt ein Blockdiagramm eines ersten spezifischeren als Beispiel dienenden Systems 2400 gemäß einer Ausführungsform der vorliegenden Erfindung. Wie in 24 dargestellt ist, ist das Mehrprozessorsystem 2400 ein Punkt-zu-Punkt-Zwischenverbindungssystem und umfasst einen ersten Prozessor 2470 und einen zweiten Prozessor 2480, die über eine Punkt-zu-Punkt-Zwischenverbindung 2450 gekoppelt sind. Jeder der Prozessoren 2470 und 2480 kann irgendeine Version des Prozessors 2200 sein. Gemäß einer Ausführungsform der Erfindung sind die Prozessoren 2470 und 2480 die Prozessoren 2310 bzw. 2315, während der Coprozessor 2438 der Coprozessor 2345 ist. Gemäß einer anderen Ausführungsform sind die Prozessoren 2470 und 2480 der Prozessor 2310 bzw. der Coprozessor 2345.
  • Die Prozessoren 2470 und 2480 sind als integrierte Speichersteuereinrichtungs(IMC)-Einheiten 2472 bzw. 2482 aufweisend dargestellt. Der Prozessor 2470 umfasst auch als Teil seiner Bussteuereinheiten Punkt-zu-Punkt(P-P)-Schnittstellen 2476 und 2478; ähnlich umfasst der zweite Prozessor 2480 P-P-Schnittstellenschaltungen 2486 und 2488. Die Prozessoren 2470, 2480 können Informationen unter Verwendung der P-P-Schnittstellenschaltungen 2478, 2488 über eine Punkt-zu-Punkt(P-P)-Schnittstelle 2450 austauschen. Wie in 24 dargestellt ist, koppeln die IMC 2472 und 2482 die Prozessoren mit jeweiligen Speichern, nämlich mit einem Speicher 2432 und einem Speicher 2434, welche Abschnitte des Hauptspeichers sein können, die lokal an den jeweiligen Prozessoren angebracht sind.
  • Die Prozessoren 2470, 2480 können jeweils Informationen mit einem Chipsatz 2490 über individuelle P-P-Schnittstellen 2452, 2454 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 2476, 2494, 2486, 2498 austauschen. Der Chipsatz 2490 kann optional über eine Hochleistungsschnittstelle 2492 Informationen mit dem Coprozessor 2438 austauschen. Gemäß einer Ausführungsform ist der Coprozessor 2438 ein Prozessor für spezielle Zwecke in der Art beispielsweise eines MIC-Prozessors mit einem hohen Durchsatz, eines Netz- oder Kommunikationsprozessors, einer Kompressionsmaschine, eines Graphikprozessors, einer GPGPU, eines eingebetteten Prozessors oder dergleichen.
  • Ein geteilter Cache (nicht dargestellt) kann entweder in einen der Prozessoren aufgenommen sein oder sich außerhalb der beiden Prozessoren befinden, jedoch über eine P-P-Zwischenverbindung mit den Prozessoren verbunden sein, so dass lokale Cacheinformationen des einen oder der beiden Prozessoren im geteilten Cache gespeichert werden können, falls ein Prozessor in einen Niederleistungsmodus versetzt wird.
  • Der Chipsatz 2490 kann über eine Schnittstelle 2496 mit einem ersten Bus 2416 gekoppelt werden. Gemäß einer Ausführungsform kann der erste Bus 2416 ein Peripheriekomponentenzwischenverbindungs(PCI)-Bus oder ein Bus in der Art eines PCI-Express-Busses oder eines anderen E/A-Zwischenverbindungsbusses der dritten Generation sein, wenngleich der Schutzumfang der vorliegenden Erfindung nicht darauf beschränkt ist.
  • Wie in 24 dargestellt ist, können verschiedene E/A-Vorrichtungen 2414 mit dem ersten Bus 2416 zusammen mit einer Busbrücke 2418, welche den ersten Bus 2416 mit einem zweiten Bus 2420 koppelt, gekoppelt sein. Gemäß einer Ausführungsform sind ein oder mehrere zusätzliche Prozessoren 2415 in der Art von Coprozessoren, MIC-Prozessoren mit einem hohen Durchsatz, GPGPU, Beschleuniger (in der Art beispielsweise von Graphikbeschleunigern oder digitalen Signalverarbeitungs(DSP)-Einheiten), feldprogrammierbarer Gate-Arrays oder eines anderen Prozessors mit dem ersten Bus 2416 gekoppelt. Gemäß einer Ausführungsform kann der zweite Bus 2420 ein Bus mit einer geringen Stiftanzahl (LPC-Bus) sein. Verschiedene Vorrichtungen können mit einem zweiten Bus 2420 gekoppelt werden, einschließlich beispielsweise einer Tastatur und/oder einer Maus 2422, von Kommunikationsvorrichtungen 2427 und einer Speichereinheit 2428 in der Art eines Plattenlaufwerks oder einer anderen Massenspeichervorrichtung, die gemäß einer Ausführungsform Befehle/Code und Daten 2430 aufweisen kann. Ferner kann eine Audio-E/A 2424 mit dem zweiten Bus 2420 gekoppelt sein. Es sei bemerkt, dass auch andere Architekturen möglich sind. Beispielsweise kann an Stelle der Punkt-zu-Punkt-Architektur aus 24 ein System einen Multi-Drop-Bus oder eine andere derartige Architektur implementieren.
  • 25 zeigt ein Blockdiagramm eines zweiten spezifischeren als Beispiel dienenden Systems 2500 gemäß einer Ausführungsform der vorliegenden Erfindung. Gleiche Elemente in den 24 und 24 weisen die gleichen Bezugszahlen auf, und bestimmte Aspekte aus 24 wurden aus 25 fortgelassen, um zu vermeiden, dass andere Aspekte von 25 unklar werden.
  • 25 zeigt, dass die Prozessoren 2470, 2480 eine integrierte Speicher- und E/A-Steuerlogik („CL“) 2572 bzw. 2582 aufweisen können. Demgemäß umfassen CL 2572, 2582 integrierte Speichersteuereinheiten und eine E/A-Steuerlogik. 25 zeigt, dass nicht nur die Speicher 2432, 2434 mit der CL 2572, 2582 gekoppelt sind, sondern auch dass E/A-Vorrichtungen 2514 mit der Steuerlogik 2572, 2582 gekoppelt sind. Legacy-E/A-Vorrichtungen 2515 sind mit dem Chipsatz 2490 gekoppelt.
  • 26 zeigt ein Blockdiagramm eines SoCs 2600 gemäß einer Ausführungsform der vorliegenden Erfindung. Ähnliche Elemente in 22 weisen die gleichen Bezugszahlen auf. Auch sind mit gestrichelten Linien dargestellte Kästchen optionale Merkmale an höher entwickelten SoC. In 26 sind eine oder mehrere Zwischenverbindungseinheiten 2602 mit Folgenden gekoppelt: einem Anwendungsprozessor 2610, der einen Satz eines oder mehrerer Cache-Einheiten 2204A-N aufweisender Kerne 2202A-N und eine oder mehrere geteilte Cache-Einheiten 2206 aufweist, einer Systemagenteneinheit 2210, einer oder mehreren Bussteuereinheiten 2216, einer oder mehreren integrierten Speichersteuereinheiten 2214, einem Satz eines oder mehrerer Coprozessoren 2620, welche eine integrierte Graphiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor aufweisen können, einer statischen Direktzugriffsspeicher(SRAM)-Einheit 2630, einer Direktspeicherzugriffs(DMA)-Einheit 2632 und einer Anzeigeeinheit 2640 zum Koppeln der einen oder der mehreren externen Anzeigen. Gemäß einer Ausführungsform umfassen der eine oder die mehreren Coprozessoren 2620 einen Prozessor für spezielle Zwecke in der Art beispielsweise eines Netz- oder Kommunikationsprozessors, einer Kompressionsmaschine, einer GPGPU, eines MIC-Prozessors mit einem hohen Durchsatz, eines eingebetteten Prozessors oder dergleichen.
  • Ausführungsformen der hier offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination solcher Implementationsansätze implementiert werden. Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert werden, die auf programmierbaren Systemen ausgeführt werden, welche wenigstens einen Prozessor, ein Speichersystem (einschließlich eines flüchtigen und nichtflüchtigen Speichers und/oder Speicherelemente), wenigstens eine Eingabevorrichtung und wenigstens eine Ausgabevorrichtung umfassen.
  • Programmcode in der Art des in 24 dargestellten Codes 2430 kann angewendet werden, um Befehle zum Ausführen der hier beschriebenen Funktionen und zum Erzeugen von Ausgangsinformationen einzugeben. Die Ausgangsinformationen können in einer bekannten Weise auf eine oder mehrere Ausgangsvorrichtungen angewendet werden. Für die Zwecke dieser Anmeldung umfasst ein Verarbeitungssystem ein beliebiges System, das einen Prozessor aufweist, wie beispielsweise einen digitalen Signalprozessor (DSP), eine Mikrosteuereinrichtung, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor.
  • Der Programmcode kann in einer prozeduralen oder objektorientierten Programmiersprache hoher Ebene implementiert werden, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann auch in Assembler oder Maschinensprache implementiert werden, falls dies erwünscht ist. Tatsächlich sind die hier beschriebenen Mechanismen in ihrem Umfang nicht auf eine bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder eine interpretierte Sprache sein.
  • Ein oder mehrere Aspekte wenigstens einer Ausführungsform können durch repräsentative Befehle implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, welches verschiedene Logiken innerhalb des Prozessors repräsentiert, welche, wenn sie von einer Maschine gelesen werden, die Maschine veranlassen, Logik zur Ausführung der hier beschriebenen Techniken zu bilden. Diese als „IP-Kerne“ bekannten Repräsentationen können auf einem physischen maschinenlesbaren Medium gespeichert werden und verschiedenen Kunden oder Herstellungseinrichtungen zugeführt werden, um sie in die Herstellungsmaschinen zu laden, welche tatsächlich die Logik oder den Prozessor bilden.
  • Solche maschinenlesbaren Speichermedien können ohne Einschränkung nichtflüchtige, reale Anordnungen von durch eine Maschine oder Vorrichtung hergestellten oder gebildeten Artikeln einschließen, einschließlich Speichermedien in der Art von Festplatten, eines anderen Plattentyps, einschließlich Disketten, optischer Platten, Compact-Disk-Nurlesespeicher (CDROM), wiederbeschreibbarer Compact-Disks (CD-RW) und magnetooptischer Platten, Halbleitervorrichtungen in der Art von Nurlesespeichern (ROM), Direktzugriffsspeichern (RAM) in der Art dynamischer Direktzugriffsspeicher (DRAM), statischer Direktzugriffsspeicher (SRAM), löschbare, programmierbare Nurlesespeicher (EPROM), Flash-Speicher, elektrisch löschbare, programmierbare Nurlesespeicher (EEPROM), einen Phasenänderungsspeicher (PCM), magnetische oder optische Karten oder ein beliebiger anderer Typ eines Mediums, das dafür geeignet ist, elektronische Befehle zu speichern.
  • Dementsprechend umfassen Ausführungsformen der Erfindung auch nichtflüchtige, reale maschinenlesbare Medien, die Befehle oder Entwurfsdaten enthalten, wie die Hardware Description Language (HDL), welche hier beschriebene Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert. Diese Ausführungsformen können auch als Programmprodukte bezeichnet werden.
  • EMULATION (EINSCHLIEßLICH BINÄRÜBERSETZUNG, CODE-MORPHING USW.)
  • In einigen Fällen kann ein Befehlswandler verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz umzuwandeln. Beispielsweise kann der Befehlswandler einen Befehl zu einem oder mehreren anderen Befehlen, die durch den Kern zu verarbeiten sind, übersetzen (beispielsweise unter Verwendung einer statischen Binärübersetzung, einer dynamischen Binärübersetzung einschließlich einer dynamischen Kompilation), morphen, emulieren oder auf andere Weise umwandeln. Der Befehlswandler kann in Software, Hardware, Firmware oder einer Kombination davon implementiert sein. Der Befehlswandler kann sich an einem Prozessor, außerhalb eines Prozessors oder teilweise an und außerhalb eines Prozessors befinden.
  • 27 ist ein Blockdiagramm, das die Verwendung eines Softwarebefehlswandlers zur Umwandlung binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz zeigt, gemäß einigen Ausführungsformen der Erfindung. Gemäß der dargestellten Ausführungsform ist der Befehlswandler ein Softwarebefehlswandler, wenngleich der Befehlswandler alternativ auch in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 27 zeigt ein Programm in einer Sprache 2702 hoher Ebene, das unter Verwendung eines x86-Compilers 2704 kompiliert werden kann, um einen x86-Binärcode 2706 zu erzeugen, der nativ durch einen Prozessor ausgeführt werden kann, der durch wenigstens einen Kern 2716 mit einem x86-Befehlssatz ausgeführt werden kann. Der Prozessor mit wenigstens einem Kern 2716 mit einem x86-Befehlssatz repräsentiert einen Prozessor, der im Wesentlichen die gleichen Funktionen ausführen kann wie ein Intel-Prozessor mit wenigstens einem Kern mit einem x86-Befehlssatz, indem er (1) einen erheblichen Teil des Befehlssatzes des Intel-Kerns mit einem x86-Befehlssatz oder (2) Objektcodeversionen von Anwendungen oder anderer Software, die dafür vorgesehen sind, auf einem Intel-Prozessor mit wenigstens einem Kern mit einem x86-Befehlssatz zu laufen, kompatibel ausführt oder auf andere Weise verarbeitet, um im Wesentlichen das gleiche Ergebnis zu erreichen wie ein Intel-Prozessor mit wenigstens einem Kern mit einem x86-Befehlssatz. Der x86-Compiler 2704 repräsentiert einen Compiler, der arbeiten kann, um einen x86-Binärcode 2706 (beispielsweise Objektcode) zu erzeugen, der mit oder ohne eine zusätzliche Verknüpfungsverarbeitung auf dem Prozessor mit wenigstens einem Kern 2716 mit einem x86-Befehlssatz auszuführen ist. Ähnlich zeigt 27 das Programm in der Sprache 2702 hoher Ebene, das unter Verwendung eines alternativen Befehlssatzcompilers 2708 kompiliert werden kann, um einen alternativen Befehlssatz-Binärcode 2710 zu erzeugen, der durch einen Prozessor mit wenigstens einem Kern 2714 mit einem x86-Befehlssatz nativ ausgeführt werden kann (beispielsweise einen Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, CA ausführen und/oder den ARM-Befehlssatz von ARM Holdings aus Sunnyvale, CA ausführen). Der Befehlswandler 2712 wird verwendet, um den x86-Binärcode 2706 in Code umzuwandeln, der durch den Prozessor ohne einen Kern 2714 mit einem x86-Befehlssatz nativ ausgeführt werden kann. Dieser umgewandelte Code ist wahrscheinlich nicht der gleiche wie der alternative Befehlssatz-Binärcode 2710, weil ein Befehlswandler, der dazu in der Lage ist, schwer zu bilden ist, der umgewandelte Code schafft jedoch die allgemeine Operation und kann aus Befehlen des alternativen Befehlssatzes bestehen. Demgemäß repräsentiert der Befehlswandler 2712 Software, Firmware, Hardware oder eine Kombination davon, wodurch es einem Prozessor oder einer anderen elektronischen Vorrichtung, die keinen Prozessor oder Kern mit einem x86-Befehlssatz aufweist, durch Emulation, Simulation oder einen anderen Prozess ermöglicht wird, den x86-Binärcode 2706 auszuführen.
  • WEITERE BEISPIELE
  • Beispiel 1 sieht ein beispielhaftes System vor, welches Folgendes umfasst: mehrere Kerne, wenigstens eine Mehrschlüssel-Gesamtspeicherverschlüsselungsschaltungen(MK-TME)-Schaltung, wenigstens eine p-Speichersteuereinrichtung und einen Vertrauenswürdige-Domänen-Insel-Ressourcenmanager (TDIRM), um Folgendes auszuführen: Initialisieren einer Vertrauenswürdige-Domänen-Insel-Steuerstruktur (TDICS) in Zusammenhang mit einer TD-Insel, Initialisieren eines geschützten TD-Insel-Speichers (TDIPM) in Zusammenhang mit der TD-Insel, Identifizieren einer Host-Schlüsselkennung (HKID) in einer Schlüsseleigentümerschaftstabelle (KOT), Zuweisen der HKID zu einem kryptographischen Schlüssel in einer MK-TME-Schaltung und Speichern der HKID in der TDICS, Assoziieren eines ersten der mehreren Kerne mit der TD-Insel, Hinzufügen einer Speicherseite von einem Adressraum des ersten Kerns zum TDIPM und Übertragen der Ausführungssteuerung auf den ersten Kern zur Ausführung der TD-Insel, und wobei der Geltungsbereich des TDIPMs auf die Grenzen der TD-Insel beschränkt wird.
  • Beispiel 2 weist den Gegenstand des beispielhaften Systems aus Beispiel 1 auf, wobei jede TD-Insel auf einen der mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets im System multipliziert mit der Anzahl der KOT-Einträge ist.
  • Beispiel 3 weist den Gegenstand des beispielhaften Systems aus Beispiel 1 auf, wobei jede TD-Insel auf eine von mehreren Speichersteuereinrichtungen in jedem der mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Speichersteuereinrichtungen in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  • Beispiel 4 weist den Gegenstand des beispielhaften Systems aus Beispiel 1 auf, wobei jede TD-Insel auf einen der mehreren Kerne in jedem der mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Kerne in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  • Beispiel 5 weist den Gegenstand des beispielhaften Systems aus Beispiel 1 auf, wobei jeder der mehreren Sockets ferner einen Hypervisor umfasst und wobei jeder der mehreren Kerne eine virtuelle Maschine ist.
  • Beispiel 6 weist den Gegenstand des beispielhaften Systems aus Beispiel 1 auf, welches ferner einen Speicher für eine Hardwarekonfigurations-Datenstruktur zum Identifizieren der Sockets, der mehreren MK-TME-Schaltungen und der Speichersteuereinrichtungen im System umfasst, wobei der TDIRM auf die Hardwarekonfiguration zugreifen soll, wenn die TD-Insel initialisiert wird.
  • Beispiel 7 weist den Gegenstand des beispielhaften Systems aus Beispiel 1 auf, wobei die mehreren MK-TME-Schaltungen, wenn sie eine Verschlüsselung und Entschlüsselung ausführen, einen Ciphertext-Stealing-Advanced-Verschlüsselungsstandard (XTS-AES) gemäß dem Institute of Electronics and Electrical Engineers (IEEE) 1619 verwenden sollen.
  • Beispiel 8 sieht ein beispielhaftes Verfahren vor, das von einem Vertrauenswürdige-Domänen-Insel(TDI)-Ressourcenmanager (TDIRM) in einem System ausgeführt wird, das mehrere Sockets umfasst, die jeweils mehrere Kerne und mehrere Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TME)-Schaltungen umfassen, wobei das Verfahren Folgendes umfasst: Initialisieren einer TDI-Steuerstruktur (TDICS) in Zusammenhang mit einer ersten TDI, Initialisieren eines geschützten TDI-Speichers (TDIPM) in Zusammenhang mit der ersten TDI, Identifizieren einer Host-Schlüsselkennung (HKID) in einer Schlüsseleigentümerschaftstabelle (KOT), Zuweisen der HKID zu einem kryptographischen Schlüssel und Speichern der HKID in der TDICS und Assoziieren eines ersten Kerns mit der ersten TDI, Hinzufügen einer Speicherseite aus einem Adressraum des ersten Kerns zum TDIPM und Übertragen der Ausführungssteuerung auf den ersten Kern zur Ausführung der ersten TDI, wobei der Geltungsbereich des TDIPMs auf die Grenzen der ersten TDI begrenzt wird.
  • Beispiel 9 weist den Gegenstand des beispielhaften Verfahrens aus Beispiel 8 auf, wobei jede TD-Insel auf einen der mehreren Sockets abgebildet wird und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets im System multipliziert mit der Anzahl der KOT-Einträge ist.
  • Beispiel 10 weist den Gegenstand des beispielhaften Verfahrens aus Beispiel 8 auf, wobei jede TD-Insel auf eine von mehreren Speichersteuereinrichtungen in jedem der mehreren Sockets abgebildet wird und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Speichersteuereinrichtungen in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  • Beispiel 11 weist den Gegenstand des beispielhaften Verfahrens aus Beispiel 8 auf, wobei jede TD-Insel auf einen der mehreren Kerne in jedem der mehreren Sockets abgebildet wird und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Kerne in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  • Beispiel 12 weist den Gegenstand des beispielhaften Verfahrens aus Beispiel 8 auf, wobei jeder der mehreren Sockets ferner einen Hypervisor umfasst und wobei jeder der mehreren Kerne eine virtuelle Maschine ist.
  • Beispiel 13 weist den Gegenstand des beispielhaften Verfahrens aus Beispiel 8 auf, wobei der TDIRM ferner eine Hardwarekonfigurationsstruktur anspricht, welche die Sockets, die mehreren MK-TME-Schaltungen und die Speichersteuereinrichtungen im System identifiziert, wenn die TD-Insel initialisiert wird.
  • Beispiel 14 weist den Gegenstand des beispielhaften Verfahrens aus Beispiel 8 auf, wobei die mehreren MK-TME-Schaltungen einen Ciphertext-Stealing-Advanced-Verschlüsselungsstandard (XTS-AES) gemäß IEEE 1619, einem Standard des Institute of Electronics and Electrical Engineers, verwenden.
  • Beispiel 15 sieht eine beispielhafte Vorrichtung vor, welche Folgendes umfasst: wenigstens eine Mehrschlüssel-Gesamtspeicherverschlüsselungsschaltungen (MK-TME)-Schaltung und einen Vertrauenswürdige-Domänen-Insel-Ressourcenmanager (TDIRM), um Folgendes auszuführen: Initialisieren einer Vertrauenswürdige-Domänen-Insel-Steuerstruktur (TDICS) in Zusammenhang mit einer TD-Insel, Initialisieren eines geschützten TD-Insel-Speichers (TDIPM) in Zusammenhang mit der TD-Insel, Identifizieren einer Host-Schlüsselkennung (HKID) in einer Schlüsseleigentümerschaftstabelle (KOT), Zuweisen der HKID zu einem kryptographischen Schlüssel in einer MK-TME-Schaltung und Speichern der HKID in der TDICS, Assoziieren eines ersten der mehreren Kerne mit der TD-Insel, Hinzufügen einer Speicherseite von einem Adressraum des ersten Kerns zum TDIPM und Übertragen der Ausführungssteuerung auf den ersten Kern zur Ausführung der TD-Insel, und wobei der Geltungsbereich des TDIPMs auf die Grenzen der TD-Insel beschränkt wird.
  • Beispiel 16 weist den Gegenstand der beispielhaften Vorrichtung aus Beispiel 15 auf, wobei jede TD-Insel auf einen von mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets in der Vorrichtung multipliziert mit der Anzahl der KOT-Einträge ist.
  • Beispiel 17 weist den Gegenstand der beispielhaften Vorrichtung aus Beispiel 15 auf, wobei jede TD-Insel auf wenigstens eine der Speichersteuereinrichtungen abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Speichersteuereinrichtungen in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  • Beispiel 18 weist den Gegenstand des beispielhaften Systems aus Beispiel 15 auf, wobei jede TD-Insel auf wenigstens einen Kern in jedem von mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Kerne in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  • Beispiel 19 weist den Gegenstand des beispielhaften Systems aus Beispiel 15 auf, welches ferner einen Speicher für eine Hardwarekonfigurations-Datenstruktur zum Identifizieren von Sockets, der wenigstens einen MK-TME-Schaltung und der Speichersteuereinrichtung umfasst, wobei der TDIRM auf die Hardwarekonfiguration zugreifen soll, wenn die TD-Insel initialisiert wird.
  • Beispiel 20 weist den Gegenstand des beispielhaften Systems aus Beispiel 15 auf, wobei die wenigstens eine MK-TME-Schaltung bei der Ausführung einer Verschlüsselung und Entschlüsselung einen Ciphertext-Stealing-Advanced-Verschlüsselungsstandard (XTS-AES) gemäß dem Institute of Electronics and Electrical Engineers (IEEE) 1619 verwenden soll.

Claims (25)

  1. System, welches Folgendes umfasst: mehrere Kerne, wenigstens eine Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TME)-Schaltung, wenigstens eine p-Speichersteuereinrichtung und einen Vertrauenswürdige-Domänen-Insel-Ressourcenmanager (TDIRM), um Folgendes auszuführen: Initialisieren einer Vertrauenswürdige-Domänen-Insel-Steuerstruktur (TDICS) in Zusammenhang mit einer TD-Insel, Initialisieren eines geschützten TD-Insel-Speichers (TDIPM) in Zusammenhang mit der TD-Insel, Identifizieren einer Host-Schlüsselkennung (HKID) in einer Schlüsseleigentümerschaftstabelle (KOT), Zuweisen der HKID zu einem kryptographischen Schlüssel in einer MK-TME-Schaltung und Speichern der HKID in der TDICS, Assoziieren eines ersten der mehreren Kerne mit der TD-Insel, Hinzufügen einer Speicherseite von einem Adressraum des ersten Kerns zum TDIPM und Übertragen der Ausführungssteuerung auf den ersten Kern zur Ausführung der TD-Insel, und wobei der Geltungsbereich des TDIPMs auf die Grenzen der TD-Insel beschränkt wird.
  2. System nach Anspruch 1, wobei jede TD-Insel auf einen der mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets im System multipliziert mit der Anzahl der KOT-Einträge ist.
  3. System nach Anspruch 1, wobei jede TD-Insel auf eine von mehreren Speichersteuereinrichtungen in jedem der mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Speichersteuereinrichtungen in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  4. System nach Anspruch 1, wobei jede TD-Insel auf einen der mehreren Kerne in jedem der mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Kerne in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  5. System nach einem der Ansprüche 1-4, wobei jeder der mehreren Sockets ferner einen Hypervisor umfasst und wobei jeder der mehreren Kerne eine virtuelle Maschine ist.
  6. System nach einem der Ansprüche 1-4, welches ferner einen Speicher für eine Hardwarekonfigurations-Datenstruktur zum Identifizieren der Sockets, der mehreren MK-TME-Schaltungen und der Speichersteuereinrichtungen im System umfasst, wobei der TDIRM auf die Hardwarekonfiguration zugreifen soll, wenn die TD-Insel initialisiert wird.
  7. System nach einem der Ansprüche 1-4, wobei die mehreren MK-TME-Schaltungen, wenn sie eine Verschlüsselung und Entschlüsselung ausführen, einen Ciphertext-Stealing-Advanced-Verschlüsselungsstandard (XTS-AES) gemäß dem Institute of Electronics and Electrical Engineers (IEEE) 1619 verwenden sollen.
  8. Verfahren, das von einem Vertrauenswürdige-Domänen-Insel(TDI)-Ressourcenmanager (TDIRM) in einem System ausgeführt wird, das mehrere Sockets umfasst, die jeweils mehrere Kerne und mehrere Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TME)-Schaltungen umfassen, wobei das Verfahren Folgendes umfasst: Initialisieren einer TDI-Steuerstruktur (TDICS) in Zusammenhang mit einer ersten TDI, Initialisieren eines geschützten TDI-Speichers (TDIPM) in Zusammenhang mit der ersten TDI, Identifizieren einer Host-Schlüsselkennung (HKID) in einer Schlüsseleigentümerschaftstabelle (KOT), Zuweisen der HKID zu einem kryptographischen Schlüssel und Speichern der HKID in der TDICS und Assoziieren eines ersten Kerns mit der ersten TDI, Hinzufügen einer Speicherseite aus einem Adressraum des ersten Kerns zum TDIPM und Übertragen der Ausführungssteuerung auf den ersten Kern zur Ausführung der ersten TDI, wobei der Geltungsbereich des TDIPMs auf die Grenzen der ersten TDI begrenzt wird.
  9. Verfahren nach Anspruch 8, wobei jede TD-Insel auf einen der mehreren Sockets abgebildet wird und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets im System multipliziert mit der Anzahl der KOT-Einträge ist.
  10. Verfahren nach Anspruch 8, wobei jede TD-Insel auf eine von mehreren Speichersteuereinrichtungen in jedem der mehreren Sockets abgebildet wird und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Speichersteuereinrichtungen in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  11. Verfahren nach Anspruch 8, wobei jede TD-Insel auf einen der mehreren Kerne in jedem der mehreren Sockets abgebildet wird und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Kerne in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  12. Verfahren nach einem der Ansprüche 8-11, wobei jeder der mehreren Sockets ferner einen Hypervisor umfasst und wobei jeder der mehreren Kerne eine virtuelle Maschine ist.
  13. Verfahren nach einem der Ansprüche 8-12, wobei der TDIRM ferner eine Hardwarekonfigurationsstruktur anspricht, welche die Sockets, die mehreren MK-TME-Schaltungen und die Speichersteuereinrichtungen im System identifiziert, wenn die TD-Insel initialisiert wird.
  14. Verfahren nach einem der Ansprüche 8-13, wobei die mehreren MK-TME-Schaltungen einen Ciphertext-Stealing-Advanced-Verschlüsselungsstandard (XTS-AES) gemäß IEEE 1619, einem Standard des Institute of Electronics and Electrical Engineers, verwenden.
  15. Vorrichtung, welche Folgendes umfasst: wenigstens eine Mehrschlüssel-Gesamtspeicherverschlüsselungsschaltung (MK-TME) - Schaltung und einen Vertrauenswürdige-Domänen-Insel-Ressourcenmanager (TDIRM), um Folgendes auszuführen: Initialisieren einer Vertrauenswürdige-Domänen-Insel-Steuerstruktur (TDICS) in Zusammenhang mit einer TD-Insel, Initialisieren eines geschützten TD-Insel-Speichers (TDIPM) in Zusammenhang mit der TD-Insel, Identifizieren einer Host-Schlüsselkennung (HKID) in einer Schlüsseleigentümerschaftstabelle (KOT), Zuweisen der HKID zu einem kryptographischen Schlüssel in einer MK-TME-Schaltung und Speichern der HKID in der TDICS, Assoziieren eines ersten der mehreren Kerne mit der TD-Insel, Hinzufügen einer Speicherseite von einem Adressraum des ersten Kerns zum TDIPM und Übertragen der Ausführungssteuerung auf den ersten Kern zur Ausführung der TD-Insel, und wobei der Geltungsbereich des TDIPMs auf die Grenzen der TD-Insel beschränkt wird.
  16. Vorrichtung nach Anspruch 15, wobei jede TD-Insel auf einen von mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets in der Vorrichtung multipliziert mit der Anzahl der KOT-Einträge ist.
  17. Vorrichtung nach Anspruch 15, wobei jede TD-Insel auf wenigstens eine der Speichersteuereinrichtungen abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Speichersteuereinrichtungen in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  18. Vorrichtung nach Anspruch 15, wobei jede TD-Insel auf wenigstens einen Kern in jedem von mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Kerne in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  19. Vorrichtung nach einem der Ansprüche 15-18, welche ferner einen Speicher für eine Hardwarekonfigurations-Datenstruktur zum Identifizieren von Sockets, der wenigstens einen MK-TME-Schaltung und der Speichersteuereinrichtung umfasst, wobei der TDIRM auf die Hardwarekonfiguration zugreifen soll, wenn die TD-Insel initialisiert wird.
  20. Vorrichtung nach einem der Ansprüche 15-19, wobei die wenigstens eine MK-TME-Schaltung bei der Ausführung einer Verschlüsselung und Entschlüsselung einen Ciphertext-Stealing-Advanced-Verschlüsselungsstandard (XTS-AES) gemäß dem Institute of Electronics and Electrical Engineers (IEEE) 1619 verwenden soll.
  21. Vorrichtung, welche Folgendes umfasst: wenigstens ein Mehrschlüssel-Gesamtspeicherverschlüsselungs(MK-TME)-Mittel und ein Vertrauenswürdige-Domänen-Insel-Ressourcenmanager(TDIRM)-Mittel, um Folgendes auszuführen: Initialisieren einer Vertrauenswürdige-Domänen-Insel-Steuerstruktur (TDICS) in Zusammenhang mit einer TD-Insel, Initialisieren eines geschützten TD-Insel-Speichers (TDIPM) in Zusammenhang mit der TD-Insel, Identifizieren einer Host-Schlüsselkennung (HKID) in einer Schlüsseleigentümerschaftstabelle (KOT), Zuweisen der HKID zu einem kryptographischen Schlüssel in einer MK-TME-Schaltung und Speichern der HKID in der TDICS, Assoziieren eines ersten der mehreren Kerne mit der TD-Insel, Hinzufügen einer Speicherseite von einem Adressraum des ersten Kerns zum TDIPM und Übertragen der Ausführungssteuerung auf den ersten Kern zur Ausführung der TD-Insel, und wobei der Geltungsbereich des TDIPMs auf die Grenzen der TD-Insel beschränkt wird.
  22. Vorrichtung nach Anspruch 21, wobei jede TD-Insel auf einen von mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets in der Vorrichtung multipliziert mit der Anzahl der KOT-Einträge ist.
  23. Vorrichtung nach Anspruch 21, wobei jede TD-Insel auf wenigstens eine der Speichersteuereinrichtungen abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Speichersteuereinrichtungen in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  24. Vorrichtung nach Anspruch 21, wobei jede TD-Insel auf wenigstens einen Kern in jedem von mehreren Sockets abzubilden ist und wobei die Anzahl der HKIDs im System gleich der Anzahl der Sockets multipliziert mit der Anzahl der Kerne in jedem Socket multipliziert mit der Anzahl der Einträge in der KOT ist.
  25. Vorrichtung nach einem der Ansprüche 21-24, welche ferner einen Speicher für eine Hardwarekonfigurations-Datenstruktur zum Identifizieren von Sockets, der wenigstens einen MK-TME-Schaltung und der Speichersteuereinrichtung umfasst, wobei der TDIRM auf die Hardwarekonfiguration zugreifen soll, wenn die TD-Insel initialisiert wird.
DE102020128050.5A 2019-12-26 2020-10-26 Tdx-inseln mit in sich abgeschlossenem geltungsbereich, wodurch eine tdx-schlüsselkennungsskalierung ermöglicht wird Pending DE102020128050A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/727,608 US11436342B2 (en) 2019-12-26 2019-12-26 TDX islands with self-contained scope enabling TDX KeyID scaling
US16/727,608 2019-12-26

Publications (1)

Publication Number Publication Date
DE102020128050A1 true DE102020128050A1 (de) 2021-07-01

Family

ID=76310532

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020128050.5A Pending DE102020128050A1 (de) 2019-12-26 2020-10-26 Tdx-inseln mit in sich abgeschlossenem geltungsbereich, wodurch eine tdx-schlüsselkennungsskalierung ermöglicht wird

Country Status (3)

Country Link
US (1) US11436342B2 (de)
CN (1) CN113051192A (de)
DE (1) DE102020128050A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10803087B2 (en) * 2018-10-19 2020-10-13 Oracle International Corporation Language interoperable runtime adaptable data collections
US11595192B2 (en) * 2020-04-24 2023-02-28 Dell Products L.P. System and method of migrating one or more storage class memories from a first information handling system to a second information handling system
US11327908B2 (en) * 2020-07-14 2022-05-10 Nxp Usa, Inc. Method and system for facilitating communication between interconnect and system memory on system-on-chip

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6959384B1 (en) 1999-12-14 2005-10-25 Intertrust Technologies Corporation Systems and methods for authenticating and protecting the integrity of data streams and other data
US6950517B2 (en) 2002-07-24 2005-09-27 Qualcomm, Inc. Efficient encryption and authentication for data processing systems
US7305084B2 (en) 2002-07-24 2007-12-04 Qualcomm Incorporated Fast encryption and authentication for data processing systems
US7836387B1 (en) * 2005-04-29 2010-11-16 Oracle America, Inc. System and method for protecting data across protection domain boundaries
US20080044012A1 (en) 2006-08-15 2008-02-21 Nokia Corporation Reducing Security Protocol Overhead In Low Data Rate Applications Over A Wireless Link
GB2443244A (en) 2006-10-05 2008-04-30 Hewlett Packard Development Co Authenticated Encryption Method and Apparatus
WO2010032161A1 (en) 2008-09-19 2010-03-25 Philips Intellectual Property & Standards Gmbh A method for secure communication in a network, a communication device, a network and a computer program therefor
US8719580B2 (en) 2009-06-26 2014-05-06 Trusted Logic Data verification method
US8700919B2 (en) 2010-05-25 2014-04-15 Via Technologies, Inc. Switch key instruction in a microprocessor that fetches and decrypts encrypted instructions
US20110314303A1 (en) 2010-06-21 2011-12-22 Shevchenko Oleksiy Yu Computing device configured for operating with instructions in unique code
US20120047580A1 (en) 2010-08-18 2012-02-23 Smith Ned M Method and apparatus for enforcing a mandatory security policy on an operating system (os) independent anti-virus (av) scanner
US9164924B2 (en) 2011-09-13 2015-10-20 Facebook, Inc. Software cryptoprocessor
FR2980285B1 (fr) 2011-09-15 2013-11-15 Maxim Integrated Products Systemes et procedes de gestion de cles cryptographiques dans un microcontroleur securise
JP5573829B2 (ja) 2011-12-20 2014-08-20 富士通株式会社 情報処理装置およびメモリアクセス方法
US9213653B2 (en) 2013-12-05 2015-12-15 Intel Corporation Memory integrity
US9882720B1 (en) 2014-06-27 2018-01-30 Amazon Technologies, Inc. Data loss prevention with key usage limit enforcement
JP6484519B2 (ja) 2015-07-15 2019-03-13 日立オートモティブシステムズ株式会社 ゲートウェイ装置およびその制御方法
US10521618B1 (en) 2015-10-20 2019-12-31 Marvell International Ltd. Methods and apparatus for secure root key provisioning
US10102151B2 (en) 2015-11-06 2018-10-16 International Business Machines Corporation Protecting a memory from unauthorized access
US10382410B2 (en) 2016-01-12 2019-08-13 Advanced Micro Devices, Inc. Memory operation encryption
US11989332B2 (en) * 2016-08-11 2024-05-21 Intel Corporation Secure public cloud with protected guest-verified host control
US10255202B2 (en) 2016-09-30 2019-04-09 Intel Corporation Multi-tenant encryption for storage class memory
US20180165224A1 (en) 2016-12-12 2018-06-14 Ati Technologies Ulc Secure encrypted virtualization
GB2563879B (en) 2017-06-28 2019-07-17 Advanced Risc Mach Ltd Realm identifier comparison for translation cache lookup
US10949546B2 (en) 2017-08-02 2021-03-16 Samsung Electronics Co., Ltd. Security devices, electronic devices and methods of operating electronic devices
US10733313B2 (en) 2018-02-09 2020-08-04 Arm Limited Counter integrity tree for memory security
US10657071B2 (en) 2017-09-25 2020-05-19 Intel Corporation System, apparatus and method for page granular, software controlled multiple key memory encryption
FR3076151B1 (fr) 2017-12-22 2020-11-06 Oberthur Technologies Procede de determination d’une somme d’integrite, programme d’ordinateur et entite electronique associes
US11520913B2 (en) 2018-05-11 2022-12-06 International Business Machines Corporation Secure execution support for A.I. systems (and other heterogeneous systems)
US11121856B2 (en) 2018-06-15 2021-09-14 Intel Corporation Unified AES-SMS4—Camellia symmetric key block cipher acceleration
US10846437B2 (en) 2018-06-28 2020-11-24 Intel Corporation Compressed integrity check counters in memory
US11075753B2 (en) 2018-07-11 2021-07-27 Akeyless Security LTD. System and method for cryptographic key fragments management
US10725849B2 (en) * 2018-07-27 2020-07-28 Intel Corporation Server RAS leveraging multi-key encryption
US11520611B2 (en) 2018-08-20 2022-12-06 Intel Corporation Secure public cloud using extended paging and memory integrity
US11144631B2 (en) 2018-09-11 2021-10-12 Apple Inc. Dynamic switching between pointer authentication regimes
US11017092B2 (en) * 2018-09-27 2021-05-25 Intel Corporation Technologies for fast launch of trusted containers
US10761996B2 (en) * 2018-09-28 2020-09-01 Intel Corporation Apparatus and method for secure memory access using trust domains
US11829517B2 (en) * 2018-12-20 2023-11-28 Intel Corporation Method and apparatus for trust domain creation and destruction
US20200201787A1 (en) 2018-12-20 2020-06-25 Intel Corporation Scalable multi-key total memory encryption engine
US11461244B2 (en) * 2018-12-20 2022-10-04 Intel Corporation Co-existence of trust domain architecture with multi-key total memory encryption technology in servers
US11138320B2 (en) * 2018-12-20 2021-10-05 Intel Corporation Secure encryption key management in trust domains
US11669335B2 (en) * 2019-03-28 2023-06-06 Intel Corporation Secure arbitration mode to build and operate within trust domain extensions
US11030120B2 (en) * 2019-06-27 2021-06-08 Intel Corporation Host-convertible secure enclaves in memory that leverage multi-key total memory encryption with integrity
US11343090B2 (en) 2019-06-27 2022-05-24 Intel Corporation Device ID for memory protection
US11593529B2 (en) * 2019-07-29 2023-02-28 Intel Corporation Device interface security management for computer buses
US11575672B2 (en) * 2019-12-20 2023-02-07 Intel Corporation Secure accelerator device pairing for trusted accelerator-to-accelerator communication

Also Published As

Publication number Publication date
US20210200879A1 (en) 2021-07-01
US11436342B2 (en) 2022-09-06
CN113051192A (zh) 2021-06-29

Similar Documents

Publication Publication Date Title
DE202019005671U1 (de) Koexistenz von Vertrauensdomänenarchitektur mitMehrschlüssel-Gesamtspeicherverschlüsselungstechnologieauf Servern
DE112012007063B4 (de) Zusammenfügen von benachbarten Sammel-/Streuoperationen
DE112017001804T5 (de) Vorrichtung und Verfahren für träge synchrone Seitentabellenaktualisierungen mit geringem Aufwand
DE10195999B3 (de) Computersystem mit einer in einem Chipsatz enthaltenen Speichersteuereinrichtung zum Kontrollieren von Zugriffen auf einen isolierten Speicher für eine isolierte Ausführung
DE102018005180A1 (de) Flexible Bescheinigung von Containern
DE102018126731A1 (de) Freigabeanweisung, um Seitenblock während des Auslagerns umzukehren
DE112017004017T5 (de) Sichere öffentliche cloud
DE102018005977A1 (de) Gleitkomma- zu festkomma-umwandlung
DE102014004563A1 (de) Befehle und Logik zur Bereitstellung verbesserter Paging-Fähigkeiten für Secure Enclave-Seitencaches
DE102018000886A1 (de) Virtuelle Maschinenkommunikation auf Hardware-Basis
DE102020128050A1 (de) Tdx-inseln mit in sich abgeschlossenem geltungsbereich, wodurch eine tdx-schlüsselkennungsskalierung ermöglicht wird
DE102018125747A1 (de) Unterstützung für eine höhere anzahl von gleichzeitigenschlüsseln in einer kryptografie-engine mit mehrerenschlüsseln
DE102020126293A1 (de) Vorrichtungen, verfahren und systeme für anweisungen für kryptografisch an daten gebundene nutzungsbeschränkungen
DE112017003483T5 (de) Eingeschränkte adressumsetzung zum schutz vor vorrichtungs-tlb-anfälligkeiten
DE112016004330T5 (de) Prozessoren, Verfahren, Systeme und Befehle zum Zulassen sicherer Kommunikationen zwischen einem geschützten Containerspeicher und Eingabe-/Ausgabegeräten
DE112015006934T5 (de) Verschachtelte Virtualisierung für virtuelle Maschinenexits
DE102015002124A1 (de) Rücksprungzielbeschränkte Prozedurrücksprungbefehle, Prozessoren, Verfahren und Systeme
DE102015002215A1 (de) Sortierbeschleunigungsprozessor, -Verfahren, -Systeme und -Befehle
DE112012007119T5 (de) Threadmigration-Unterstützung für Kerne unterschiedlicher Architektur
DE102019109845A1 (de) Vereinheitlichte Beschleunigung eines Blockgeheimcodes eines symmetrischen Schlüssels für AES-SMS4-Camellia
DE102018125817A1 (de) Systeme und Verfahren zum Laden eines Kachelregisterpaars
DE112013004798T5 (de) Befehlssatz zur Nachrichtenplanung des SHA256-Algorithmus
DE202019005682U1 (de) Hardwaregestützte Paging-Mechanismen
DE102018132521A1 (de) Vorrichtung und verfahren zur verflachung und reduktion von schleifen in einer single instruction, multiple data- (simd-) pipeline
DE112014000252T5 (de) Anweisung "Vector floating point test data class immediate"