DE202019005671U1 - Koexistenz von Vertrauensdomänenarchitektur mitMehrschlüssel-Gesamtspeicherverschlüsselungstechnologieauf Servern - Google Patents

Koexistenz von Vertrauensdomänenarchitektur mitMehrschlüssel-Gesamtspeicherverschlüsselungstechnologieauf Servern Download PDF

Info

Publication number
DE202019005671U1
DE202019005671U1 DE202019005671.8U DE202019005671U DE202019005671U1 DE 202019005671 U1 DE202019005671 U1 DE 202019005671U1 DE 202019005671 U DE202019005671 U DE 202019005671U DE 202019005671 U1 DE202019005671 U1 DE 202019005671U1
Authority
DE
Germany
Prior art keywords
key
memory
physical
address
page
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.)
Active
Application number
DE202019005671.8U
Other languages
English (en)
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 DE202019005671U1 publication Critical patent/DE202019005671U1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/79—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in semiconductor storage media, e.g. directly-addressable memories
    • 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/1408—Protection against unauthorised use of memory or access to memory by using cryptography
    • 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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0745—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in an input/output transactions management context
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G06F12/0817—Cache consistency protocols using directory methods
    • G06F12/0828—Cache consistency protocols using directory methods with concurrent directory accessing, i.e. handling multiple concurrent coherency transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1009—Address translation using page tables, e.g. page table structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G06F12/1036—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] for multiple virtual address spaces, e.g. segmentation
    • 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/1425—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 physical, e.g. cell, word, block
    • G06F12/1441—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 physical, e.g. cell, word, block for a range
    • 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
    • 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/1483—Protection against unauthorised use of memory or access to memory by checking the subject access rights using an access-table, e.g. matrix or list
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • 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
    • 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/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • 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/45583—Memory management, e.g. access or allocation
    • 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
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/151—Emulated environment, e.g. virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/20—Employing a main memory using a specific memory technology
    • G06F2212/202—Non-volatile memory
    • G06F2212/2022—Flash memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/40—Specific encoding of data in memory or cache
    • G06F2212/402—Encrypted data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/651—Multi-level translation tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/68—Details of translation look-aside buffer [TLB]
    • G06F2212/683—Invalidation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7201—Logical to physical mapping or translation of blocks or pages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7202—Allocation control and policies

Landscapes

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

Abstract

Verarbeitungsvorrichtung, die Folgendes umfasst:
einen Prozessorkern zum Ausführen eines Hypervisors, wobei der Prozessorkern ein Hardware-Register umfasst, um Folgendes zu speichern:
einen Bitbereich zum Identifizieren einer ersten Anzahl von Adressbits von physischen Speicheradressen, die Schlüsselkennungen (Schlüssel-IDs) definieren; und
eine Aufteilungsschlüssel-ID der Schlüssel-IDs, um eine Grenze zwischen nicht beschränkten Schlüssel-IDs und beschränkten Schlüssel-IDs der Schlüssel-IDs zu identifizieren; und
wobei der Prozessorkern Folgendes ausführen soll:
Zuweisen mindestens einer der nicht beschränkten Schlüssel-IDs zur Verwendung durch den Hypervisor; und
Zuweisen einer ersten Schlüssel-ID der Schlüssel-IDs zu einer ersten Vertrauensdomäne einer Vertrauensdomäneninfrastruktur, wobei die erste Schlüssel-ID eine der beschränkten Schlüssel-IDs ist; und
einen Speicher-Controller, der mit dem Prozessorkern gekoppelt ist, um der ersten Vertrauensdomäne eine erste physische Seite eines Speichers zuzuweisen, wobei Daten der ersten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der ersten Schlüssel-ID zugeordnet ist.

Description

  • Technisches Gebiet
  • Die Offenbarung bezieht sich auf Computersysteme; und insbesondere auf ein Sicherstellen einer Koexistenz einer Vertrauensdomänenarchitektur mit einer Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie auf Servern.
  • Hintergrund
  • Moderne Verarbeitungsvorrichtungen verwenden Laufwerksverschlüsselung, um ruhende Daten zu schützen. Daten im Speicher liegen jedoch im Klartext vor und sind anfällig für Angriffe. Angreifer können eine Vielzahl von Techniken verwenden, einschließlich software- und hardwarebasierter Busabtastung, Speicherabtastung, Hardware-Sondierung und dergleichen, um Daten aus dem Speicher abzurufen. Diese Daten aus dem Speicher können vertrauliche Daten umfassen, z. B. datenschutzrelevante Daten, IP-sensible Daten sowie Schlüssel, die für die Dateiverschlüsselung oder Kommunikation verwendet werden. Die Offenlegung von Daten wird durch den aktuellen Trend, Daten und Arbeitslasten von Unternehmen mithilfe von virtualisierungsbasierten Hosting-Diensten, die von Cloud-Dienstanbietern bereitgestellt werden, in die Cloud zu verlagern, weiter verschärft.
  • Figurenliste
    • 1A ist ein Blockdiagramm, das ein beispielhaftes Rechensystem darstellt, das die Koexistenz der Vertrauensdomänenarchitektur (TD-Architektur) mit der Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie (MK-TME-Technologie) in virtualisierten Systemen gemäß einer Implementierung ermöglicht.
    • 1B ist ein Blockdiagramm, das einen beispielhaften Prozessorkern eines Prozessors des Rechensystems, der die Koexistenz der TD-Architektur mit der MK-TME-Technologie ermöglicht, gemäß einer Implementierung darstellt.
    • 1C ist ein Blockdiagramm, das ein beispielhaftes Rechensystem, das die Koexistenz der TD-Architektur mit der MK-TME-Technologie in einem Rechensystem ohne Virtualisierung ermöglicht, gemäß einer anderen Implementierung darstellt.
    • 2A ist ein Diagramm, das die Aufteilung des Raums der Kryptographieschlüsselkennungen (Kryptographieschlüssel-IDs) in TD- und MK-TME-Schlüssel-IDs gemäß einer Implementierung darstellt.
    • 2B ist ein Diagramm, das die Codierung und Aufteilung von Kryptographieschlüssel-IDs in TDX- und MK-TME-Schlüssel-IDs unter Verwendung von M Bits von mit der physischen Speicheradresse verkettetem Adressraum gemäß einer Implementierung veranschaulicht.
    • 2C ist eine Darstellung einer Mikroarchitektur-Schlüsselkryptographietabelle, die durch die Schlüssel-ID indiziert ist und Zuordnungen von Schlüssel-IDs zu Kryptographieschlüsseln speichert, gemäß einer Implementierung.
    • 2D ist eine Darstellung einer Mikroarchitektur-Schlüsselbesitztabelle, die durch die Schlüssel-ID indiziert ist und Zuweisungen von Schlüssel-IDs zu verschiedenen Vertrauensdomänen speichert, gemäß einer Implementierung.
    • 2E ist eine Darstellung einer Mikroarchitektur-Speicherbesitztabelle, die Metadatenattribute für physische Speicherseiten speichert, gemäß einer Implementierung.
    • 3 ist ein Blockdiagramm einer Gate-Architektur, die einen Abschnitt der Speicherverschlüsselungsmaschine darstellt, gemäß einer Implementierung.
    • 4A ist ein Blockdiagramm, das die Übersetzung einer virtuellen Gastadresse in eine physische Gastadresse und einer physischen Gastadresse in eine physische Hostadresse gemäß einer Implementierung darstellt.
    • 4B ist ein Blockdiagramm, das die Verwendung von erweiterten Seitentabellen (EPT) zum Übersetzen der physischen Gastadresse in die physische Hostadresse gemäß einer Implementierung darstellt.
    • 4C ist ein Blockdiagramm von Speicheradressauswahl-Hardware zum Zuordnen einer physischen Gastadresse zu einer physischen Hostadresse unter Verwendung erweiterter Seitentabellen, wenn sowohl die TD- als auch die MK-TME-Architektur aktiviert sind, gemäß einer Implementierung.
    • 5 ist ein Ablaufdiagramm eines beispielhaften Verfahrens zum Ermöglichen der Koexistenz von TD-Architektur und MK-TME-Technologie gemäß einer Implementierung.
    • 6 ist ein Ablaufdiagramm eines beispielhaften Verfahrens zum Ermöglichen der Koexistenz von TD- und MK-TME-Technologie, das ferner Speicher-Paging ermöglicht, gemäß einer Implementierung.
    • 7A ist ein Blockdiagramm, das eine Mikroarchitektur für einen Prozessor darstellt, in der eine Implementierung der Offenbarung verwendet werden kann.
    • 7B ist ein Blockdiagramm, das eine reihenfolgetreue Pipeline und nicht reihenfolgetreue Ausgabe-/Ausführungspipeline mit Registerumbenennungsstufe darstellt, die gemäß mindestens einer Implementierung der Offenbarung implementiert sind.
    • 8 zeigt ein Blockdiagramm der Mikroarchitektur für eine Verarbeitungsvorrichtung, die Logikschaltungen aufweist, um die Koexistenz einer Vertrauensdomänenarchitektur mit einer Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie in virtualisierten Systemen unter Verwendung von Vertrauensdomänen gemäß einer Implementierung bereitzustellen.
    • 9 ist ein Blockdiagramm eines Computersystems gemäß einer Implementierung.
    • 10 ist ein Blockdiagramm eines Computersystems gemäß einer weiteren Implementierung.
    • 11 ist ein Blockdiagramm eines Ein-Chip-Systems gemäß einer Implementierung.
    • 12 zeigt eine weitere Implementierung eines Blockdiagramms für ein Rechensystem.
    • 13 zeigt eine weitere Implementierung eines Blockdiagramms für ein Rechensystem.
  • Genaue Beschreibung
  • Aspekte der vorliegenden Offenbarung zielen darauf ab, auf Hardware-Ebene eine Koexistenz der Vertrauensdomäneninfrastuktur (TD-Infrastruktur) mit der Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie (MK-TME-Technologie) zu ermöglichen. Die MK-TME-Technologie bezieht sich auf das Bereitstellen einer Fähigkeit für ein Betriebssystem (oder einen Hypervisor in einer virtuellen Rechenumgebung), verschiedene Kryptographieschlüssel zum Verschlüsseln von Seiten von physischem Speicher zu verwenden, die verschiedenen Clients/Anwendungen zugeordnet sind. Eine TD-Infrastruktur bezieht sich darauf, dass ermöglicht wird, dass Clients/Anwendungen in hochsicheren Umgebungen von TDs ausgeführt werden können, in denen selbst das Betriebssystem (oder der Hypervisor) möglicherweise keinen Zugriff auf physische Speicherseiten hat, die TDs zugeordnet sind.
  • Eine herkömmliche Cloud-Server-Rechenumgebung und eine virtuelle Rechenumgebung bieten Fern-Rechenbetriebsmittel und Fern-Datenspeicherbetriebsmittel für verschiedene Vorrichtungen. Berechnungen und Datenspeicherung in der Ferne machen es besonders wichtig, Daten vor dem Zugriff durch Unbefugte und schädlicher Software zu schützen. Unverschlüsselte Klartextdaten, die sich im Speicher befinden, sowie Daten, die sich zwischen dem Speicher und einem Prozessor bewegen, sind möglicherweise anfällig für Abtastangriffe. Angreifer können eine Vielzahl von Techniken verwenden, einschließlich Busabtastung, Speicherabtastung und dergleichen, um Daten aus dem Speicher abzurufen. Solche Daten könnten sogar Schlüssel enthalten, die zur Verschlüsselung verwendet werden. Dementsprechend sind selbst mit einem Kryptographieschlüssel verschlüsselte Daten nicht sicher, wenn die Möglichkeit besteht, dass Angreifer oder nicht autorisierte Software in den Besitz eines solchen Schlüssels gelangen.
  • Eine Möglichkeit zum Schutz von Daten im Speicher besteht in der Gesamtspeicherverschlüsselungstechnologie (TME-Technologie), bei der Speicherzugriffe durch Software, die auf einem Prozessorkern ausgeführt wird, mit einem Kryptographieschlüssel verschlüsselt werden können. Beispielsweise kann der Kryptographieschlüssel ein 128-Bit-Schlüssel sein, der vom Prozessor beim Hochfahren erzeugt und zum Verschlüsseln von Daten verwendet wird, die auf den externen Speicherbussen gesendet werden. Insbesondere dann, wenn der Prozessor eine Schreibanforderung an den Speicher stellt, können die Daten von einer Speicherverschlüsselungsmaschine verschlüsselt werden, bevor sie an den Speicher gesendet werden, wo sie in einer verschlüsselten Form gespeichert werden. Wenn die Daten aus dem Speicher gelesen werden, werden sie in verschlüsselter Form an den Prozessor gesendet. Sobald die Daten den Prozessor erreicht haben, werden sie mit dem Kryptographieschlüssel entschlüsselt. Da Daten in Form von Klartext im Prozessor verbleiben, erfordert die TME-Technologie keine Änderung der vorhandenen Software und der Interaktion der vorhandenen Software mit dem Prozessor.
  • Die Mehrschlüssel-TME-Technologie (MK-TME) ist eine Erweiterung der TME-Technologie, die Unterstützung für mehrere Kryptographieschlüssel bietet und eine aufgeteilte Speicherverschlüsselung ermöglicht. Beispielsweise kann die Prozessorarchitektur ein Erzeugen mehrerer Kryptographieschlüssel beim Hochfahren ermöglichen, um verschiedene Speicherseiten mit verschiedenen MK-TME-Schlüsseln zu verschlüsseln. Die Mehrschlüssel-Erweiterung eignet sich besonders für die Arbeit mit Mehrdomänen-Architekturen, wie sie beispielsweise von CSPs verwendet werden, da die Anzahl der unterstützten Schlüssel möglicherweise implementierungsabhängig ist. Der Prozessor kann eine MK-TME-Maschine verwenden, um zu bewirken, dass verschiedene Seiten mit verschiedenen MK-TME-Schlüsseln verschlüsselt werden.
  • In einigen Implementierungen haben CSPs die Wahl, Seiten einer virtuellen Maschine (VM) festlegen, die mit demselben VM-spezifischen Schlüssel verschlüsselt werden sollen. In anderen Fällen kann ein CSP bestimmte VM-Seiten wählen, die im Klartext bleiben sollen oder mit verschiedenen kurzlebigen Schlüsseln, die für Software möglicherweise undurchsichtig sind, verschlüsselt werden sollen. Die MK-TME-Maschine unterstützt möglicherweise mindestens einen Schlüssel pro Domäne und erreicht so die kryptographische Isolation zwischen verschiedenen Arbeitslasten, die auf einem CSP vorhanden sind. Eine Arbeitslast kann einem Mandanten oder Besitzer zugeordnet sein, z. B. einer Entität, die die Nutzung des Host-Servers von dem CSP aus vermietet.
  • Bei der TD-Erweiterungs-Architektur (TDX-Architektur) können mehrere sichere TDs vorhanden sein, die verschiedenen Client-Maschinen (z. B. virtuellen Maschinen), Gastbetriebssystemen, Hostbetriebssystemen, Hypervisoren oder dergleichen entsprechen. Darüber hinaus können sogar verschiedene Anwendungen, die von demselben Client innerhalb desselben Gastbetriebssystems ausgeführt werden, sicher ausgeführt werden. Um die Skalierbarkeit des sicheren Rechnens sicherzustellen, wenn mehrere TDs vorhanden sind, kann jede TD einen oder mehrere private Schlüssel verwenden, die für Software, die außerhalb der TD betrieben wird, nicht verfügbar sind. In einigen Fällen kann Software, die in einer sicheren Domäne ausgeführt wird, Zugriff auf private Schlüssel, die für diese bestimmte Domäne spezifisch sind, sowie auf gemeinsam genutzte Schlüssel, die von mehreren Domänen verwendet werden können, haben. Beispielsweise kann eine Software, die in einer sicheren Domäne ausgeführt wird, einen privaten Schlüssel für ihre sichere Ausführung verwenden, z. B. Lese-, Schreib- oder Ausführungsvorgänge. Andererseits kann dieselbe Software einen gemeinsam genutzten Schlüssel verwenden, um auf Strukturen oder Vorrichtungen zuzugreifen, die für andere Domänen freigegeben sind, z. B. einen Drucker, eine Tastatur, eine Maus, einen Monitor, einen Netzadapter, einen Router und dergleichen.
  • Ein TD kann sogar vor privilegierten Anwendern wie dem Betriebssystem OS (entweder Host oder Gast), dem Monitor der virtuellen Maschine (Hypervisor), der Firmware des grundlegenden Eingabe/Ausgabe-Systems (BIOS-Firmware), dem Systemverwaltungsmodus und dergleichen geschützt werden. Dementsprechend bleiben vertrauliche Daten, die von der TD im Speicher gespeichert werden, selbst dann geschützt, wenn schädliche Software eine privilegierte Domäne wie das Betriebssystem übernimmt. Solche Daten können medizinische Aufzeichnungen, biometrische Faktoren, persönliche ID-Informationen, geistiges Eigentum, Passwörter, Kryptographieschlüssel oder andere sensible Daten umfassen.
  • Jede TD kann unabhängig von anderen TDs arbeiten und logische Prozessoren, Speicher und E/A verwenden, die von einem Vertrauensdomänen-Betriebsmittelverwalter (TDRM) zugewiesen werden, der als Teil des Hostbetriebssystems, des Hypervisors oder als separates Softwareprogramm arbeitet. Jede TD kann unter Verwendung mindestens eines exklusiven Kryptographieschlüssels der MK-TME-Maschine zum Verschlüsseln des der TD zugeordneten Speichers (mit Code und/oder Daten) kryptografisch im Speicher isoliert werden.
  • Auf einem CSP-Hostserver, der die Virtualisierungsarchitektur ausführt, müssen möglicherweise sowohl die MK-TME-Technologie als auch die TDX-Architektur ausgeführt werden, damit Client-/Mandantenanwendungen effizient ausgeführt werden können. Beispielsweise kann der Hostserver hochsensible Anwendungen innerhalb von TDs ausführen, so dass der Hypervisor, der VMs ausführt, keinen Zugriff auf die Speicherseiten und Kryptographieschlüssel hat, die einer TD und ihrer vertrauenswürdigen Rechenbasis (TCB) zugewiesen sind. Gleichzeitig kann der Hostserver mithilfe der MK-TME-Technologie Anwendungen ausführen, die weniger Sicherheit und Isolation erfordern, wobei der Hypervisor die Steuerung über Speicherseiten und Kryptographieschlüssel behält, die in diesen weniger sensiblen Anwendungen verwendet werden. Der Hypervisor kann dann verschiedene Anwendungen unter Verwendung verschiedener MK-TME-Schlüssel voneinander isolieren, jedoch weiterhin in der TCB jeder Anwendung bleiben.
  • Aspekte der vorliegenden Offenbarung befassen sich in verschiedenen Implementierungen mit der Notwendigkeit, die Koexistenz der MK-TME-Technologie und der TDX-Architektur zu ermöglichen. In einigen Implementierungen kann das offenbarte Rechensystem sicherstellen, dass den TDs zugewiesene Schlüssel-IDs nicht von MK-TME-Software wie z. B. dem Hypervisor oder VMs, die außerhalb der TCB der TD ausgeführt werden, verwendet werden können. In verwandten Implementierungen können die offenbarten Architekturen sicherstellen, dass keine Schlüssel-IDs, die als beschränkte Schlüssel-IDs für die TD festgelegt sind, gleichzeitig von zwei aktiven TDs verwendet werden können. Für zusätzliche Sicherheit der in TDs gespeicherten Daten kann es auch wünschenswert sein, dass Schlüssel-IDs von erloschenen TDs anderen TDs neu zugewiesen werden, nachdem alle der erloschenen TD zugeordneten Cache-Daten gelöscht wurden.
  • Darüber hinaus muss ein Client selbst innerhalb einer hochsicheren TD möglicherweise mit gemeinsam genutzten Strukturen, z. B. gemeinsam genutzten Hardware-Vorrichtungen, kommunizieren. Beispielsweise können Eingabe-Ausgabe-Vorrichtungen (E/A-Vorrichtungen), Drucker, Netzadapter, Router oder andere Verarbeitungsvorrichtungen und dergleichen von mehreren TDs und von dem Hypervisor, auf dem VMs unter Verwendung des MK-TME-Schutzes ausgeführt werden, verwendet werden. In Implementierungen muss der Zugriff auf solche gemeinsam genutzten Strukturen möglicherweise noch weiter gesichert werden (vor anderen Anwendungen oder externen böswilligen Angriffen), indem Speichertransaktionen verschlüsselt werden, die sich auf Operationen der gemeinsam genutzten Strukturen beziehen. Dementsprechend muss eine TD möglicherweise in der Lage sein, verschiedene Kryptographieschlüssel zu verwenden - mindestens einen beschränkten Schlüssel für ihre sicheren Operationen und den Zugriff auf die privaten Speicherseiten des TD und mindestens einen nicht beschränkten Schlüssel für die Kommunikation der TD mit den gemeinsam genutzten Strukturen. Software, die in einer vertrauenswürdigen Rechenbasis einer TD arbeitet, versucht möglicherweise, einen nicht beschränkten Schlüssel für Speichertransaktionen mit privaten Speicherseiten zu verwenden. Beispielsweise kann vertrauenswürdige Software versuchen, Daten mit einem nicht beschränkten Schlüssel in eine private Speicherseite zu schreiben. In Abwesenheit eines Hardware-Schutzes, der in der vorliegenden Schrift offenbart ist, können solche Daten für einen Software-Zugriff (z. B. einen Lesevorgang) aus einem Programm außerhalb der TCB anfällig sein, der Zugriff auf den gemeinsam genutzten nicht beschränkten Schlüssel erhalten kann.
  • 1A zeigt ein beispielhaftes Rechensystem 100, das die Koexistenz von TDX- und MKTME-Technologie auf einem Virtualisierungsserver 110 ermöglicht, der mehrere Client-Vorrichtungen 102A, 102B und 102C unterstützt. Das Rechensystem 100 kann ferner eine Netzschnittstelle 104 und gemeinsam genutzte Hardware-Vorrichtungen 160A und 160B umfassen. Der Virtualisierungsserver 110 kann einen Prozessor 112, eine Speichervorrichtung 130 und eine oder mehrere TDs 150A, 150B und 150C umfassen, ist aber nicht darauf beschränkt. Der Prozessor 112 kann einen Überwacher virtueller Maschinen (VMM) oder einen Hypervisor 140, einen TD-Betriebsmittelverwalter (TDRM) 142, der wiederum eine oder mehrere virtuelle Maschinen (VMs) 155 ausführen kann, ausführen. In verschiedenen Implementierungen kann der Prozessor 112 einen oder mehrere Prozessorkerne 114, ein oder mehrere Register 116 (z. B. Hardware-Register), Cache 118, einen Speicher-Controller 120, eine Schlüsselkryptographietabelle (KET) 122, eine Schlüsselbesitztabelle (KOT) 124 und eine Speicherbesitztabelle (MOT) 126 umfassen. Der Speicher-Controller 120 kann ferner eine Speicherverschlüsselungsmaschine wie etwa eine MK-TME-Maschine 136 umfassen. Die Speichervorrichtung 130 kann einen dynamischen Direktzugriffsspeicher (DRAM), einen synchronen DRAM (SDRAM), einen statischen Speicher wie etwa statischen Direktzugriffsspeicher (SRAM), einen Flash-Speicher, eine Datenspeichervorrichtung oder andere Arten von Speichervorrichtungen umfassen. Der Kürze halber wird die Speichervorrichtung 130 im Folgenden als Speicher 130 bezeichnet.
  • Jede Client-Vorrichtung kann ein Fern-Schreibtisch-Computer, ein Tablet, ein Smartphone, ein anderer Server, ein schlanker/magerer Client und dergleichen sein. Jede Client-Vorrichtung kann Anwendungen auf dem Virtualisierungsserver 110 in einer oder mehreren der TDs 150A, 150B und 150C und einer oder mehreren VMs 155 ausführen, wobei die VMs außerhalb der TCB der jeweiligen TD ausgeführt werden. Ein Hypervisor 140 kann eine Umgebung für virtuelle Maschinen ausführen, in der der Hypervisor die Hardware-Funktionen eines Hosts nutzt und ein oder mehrere Gastbetriebssysteme ausführen soll, die Client-Anwendungen unterstützen, die von separaten Client-Vorrichtungen 102A, 102B und 102C ausgeführt werden. Eine einzelne TD wie die TD 150A kann in einer Implementierung einem einzelnen Client 102A eine sichere Ausführungsumgebung bieten und ein einzelnes Gastbetriebssystem unterstützen. In einer weiteren Implementierung kann eine TD mehrere Mandanten unterstützen, auf denen jeweils eine separate virtuelle Maschine ausgeführt wird, und dies wird durch einen Mandanten-Überwacher virtueller Maschinen (Mandanten-VMM) unterstützt, der innerhalb der TD ausgeführt wird. Der Mandanten-VMM (in 1 nicht explizit dargestellt) kann mit dem Hypervisor (Host-VMM) 140 kommunizieren, um auf den Speicher 130 und den Prozessor 112 zuzugreifen. Der Ausführungsstatus der TDs 150A-C kann durch den TDRM 142 weiter befähigt werden. Der TDRM 142 kann eine Erweiterung des Hypervisors 140 oder ein separates Betriebsmittel, das von dem Hypervisor 140 unterstützt wird, sein.
  • Der TDRM 142 und der Hypervisor 140 können als Host für TDs fungieren und den Zugriff von TDs auf den Prozessor 112 und andere System-Hardware steuern. Der Prozessor 112 kann einen oder mehrere Prozessorkerne 114, Hardware-Register 116 und einen Cache 118 aufweisen. Der Prozessor 112 kann ferner einen Speicher-Controller (eine Speicherverwaltungseinheit) 120 aufweisen, um den Speicherbetrieb zu steuern. Der Speicher-Controller kann eine Speicherverschlüsselungsmaschine wie etwa eine MK-TME-Maschine 136 aufweisen, um Speichervorgänge mit geeigneten Kryptographieschlüsseln zu verschlüsseln/entschlüsseln. Der Prozessor 112 kann die Fähigkeit haben, in einen TDX-Modus einzutreten, in dem TDX-Befehle in Hardware-Register 116 (wie Steuerregister oder modellspezifische Register) des Prozessors 112 geladen werden, um die Isolierung des Speichers von jeglicher Software, die nicht zu der TCB der TD gehört, zu erleichtern. Der TDRM kann die Fähigkeit besitzen, in den TDX-Modus einzutreten und diesen zu verlassen.
  • Der TDRM 142 kann als Host fungieren und die Steuerung des Prozessors und anderer Plattform-Hardware übernehmen. Ein TDRM 142 kann Software in einer TD (z. B. TD 150A) logischen Prozessoren zuweisen, kann jedoch nicht auf den Ausführungsstatus einer TD auf den zugewiesenen logischen Prozessoren zugreifen. In ähnlicher Weise kann der TDRM 142 einer TD physischen Speicher und E/A-Betriebsmittel zuweisen, kann jedoch aufgrund separater Kryptographieschlüssel und anderer Integritäts-/Wiedergabekontrollen im Speicher nicht auf den Speicherstatus einer TD zugreifen bzw. diesen fälschen.
  • Eine TD stellt eine Software-Umgebung dar, die einen Software-Stapel unterstützen kann, der VMMs, Gastbetriebssysteme und verschiedene Anwendungs-Software, die von den Gastbetriebssystemen gehostet werden, umfasst. Jede TD kann unabhängig von anderen TDs arbeiten und von dem TDRM zugewiesene logische Prozessoren, Speicher und E/A verwenden. Software, die in einer TD ausgeführt wird, kann mit reduzierten Berechtigungen arbeiten, so dass der TDRM die Kontrolle über die Plattformbetriebsmittel behalten kann. Andererseits kann der TDRM nicht auf Daten zugreifen, die einer TD zugeordnet sind, oder auf andere Weise die Vertraulichkeit oder Integrität einer TD beeinträchtigen.
  • Der TDRM 142 (oder ein Hypervisor-Abschnitt des TDRM) kann die Verwaltung der Kryptographieschlüssel erledigen. Beispielsweise kann der TDRM verschiedenen TDs unterschiedliche Schlüssel zuweisen, Schlüssel in den Speicherverschlüsselungsmodulen konfigurieren, die Ausführung der Cache-Leerung anfordern, wenn Schlüssel verschiedenen TDs neu zugewiesen werden sollen, und dergleichen. In Implementierungen der Offenbarung fungiert der TDRM 142 in der TD-Architektur als Host für die TDs und hat die vollständige Kontrolle über die Kerne und andere Plattform-Hardware. Ein TDRM 142 weist Software in einer TD logischen Prozessoren zu. Der TDRM 142 hat jedoch möglicherweise keinen Zugriff auf den Ausführungsstatus einer TD auf den zugewiesenen logischen Prozessoren. In ähnlicher Weise weist ein TDRM 142 den TDs physischen Speicher und E/A-Betriebsmittel zu, kann jedoch aufgrund der Verwendung separater Kryptographieschlüssel, die von dem Prozessor je TD erzwungen wird, und anderer Integritäts- und Wiedergabekontrollen möglicherweise nicht auf den Speicherstatus einer TD im Speicher zugreifen. Software, die in einer TD ausgeführt wird, arbeitet mit reduzierten Berechtigungen, so dass der TDRM 142 die Kontrolle über Plattformbetriebsmittel behalten kann. Es darf jedoch dem TDRM 142 nicht erlaubt werden, die Vertraulichkeit oder Integrität der TD zu gefährden, indem er Zugriff auf die vertrauenswürdige Rechenbasis der TD erhält.
  • Um die Sicherheit von Daten in TDs weiter zu verbessern, kann die TDX-Architektur K Kryptographieschlüssel verwenden, die sicher erzeugt werden. In einer Implementierung kann der TDRM 142 (beispielsweise unter Verwendung des Befehls TDCREATE wie nachstehend ausführlich beschrieben) veranlassen, dass der Prozessor 112 einen kurzlebigen Speicherkryptographieschlüssel und eine entsprechende Schlüsselkennung (Schlüssel-ID) für jede TD erzeugt. Die Kryptographieschlüssel (z. B. K Kryptographieschlüssel) können für Software, die auf dem Prozessor ausgeführt wird, durch eindeutige Schlüssel-IDs identifiziert werden. In einer Implementierung kann eine Schlüssel-ID für eine TD an die physischen Speicheradressen, die dieser TD zugeordnet sind, angehängt sein. Das BIOS (oder eine andere Hochfahr-Firmware) kann während des Hochfahrens einen Bereich von Bits innerhalb der physischen Speicheradressen für eine bestimmte Anzahl von Schlüssel-IDs zuweisen. Beispielsweise kann das BIOS einen Bereich von Bits in dem Hardware-Register 116 speichern, beispielsweise einem modellspezifischen Register (MSR) in einer Implementierung. Nach dem Hochfahren kann das Rechensystem 100 den Bitbereich aus dem MSR abrufen und diese Bits verwenden, um die Schlüssel-IDs in den physischen Speicheradressen zu codieren.
  • In verschiedenen Implementierungen könnte jede Schlüssel-ID eine beliebige Zahl in einer binären Darstellung sein. Beispielsweise kann in einer Implementierung ein Bereich von K aufeinanderfolgenden Zahlen, beginnend mit 0 und endend mit K - 1, verwendet werden. In einer weiteren Implementierung kann der Bereich der Zahlen, die für die Darstellung von Kryptographieschlüssel-IDs verwendet werden, bei einer anderen Zahl beginnen. Der Bereich muss in einigen Implementierungen nicht zusammenhängend sein. Eine binäre Codierung der Kryptographieschlüssel-IDs kann M Bits umfassen, wobei M eine ganze Zahl sein kann, so dass M ≥ log2 K ist, um sicherzustellen, dass die Gesamtzahl 2M verschiedener Kombinationen von M Bits nicht kleiner als die Anzahl K verschiedener Kryptographieschlüssel ist.
  • Physische Seiten des Speichers 130 können mit einem der Kryptographieschlüssel verschlüsselt werden. Wie es erörtert wurde, kann die Schlüssel-ID, die dem für die Speicherverschlüsselung verwendeten Kryptographieschlüssel entspricht, zu der physischen Speicheradresse der physischen Seite des Speichers, z. B. zu dem physischen Speicher des Hostservers, hinzugefügt werden was nachstehend ausführlicher erläutert wird. Wenn die Schlüssel-IDs an die physischen Speicheradressen angehängt sind, kann eine von der Software angeforderte Speichertransaktion fehlschlagen, es sei denn, die Speichertransaktionsanforderung enthält sowohl die physische Speicheradresse der Seite als auch die richtige Schlüssel-ID für den Kryptographieschlüssel, der zum Ver-/Entschlüsseln der physischen Seite des Speichers verwendet wird. Die Speichertransaktion kann ein „Lese“-, „Schreib“- oder „Ausführungs“-Vorgang sein, an dem die physische Seite des Speichers beteiligt ist.
  • Die Verkettung der beschränkten Schlüssel-ID mit den physischen Speicheradressen des physischen Speichers, der der TD für den privaten Gebrauch zugewiesen wurde, kann unbefugte oder ungesicherte Zugriffe auf diesen Speicher verhindern. Um die Hardware-Isolation der beschränkten Kryptographieschlüssel von nicht beschränkten Kryptographieschlüsseln aufrechtzuerhalten, muss der Prozessor 112 möglicherweise die Aufteilung von Schlüssel-IDs in beschränkte TD-Schlüssel-IDs (z. B. TDX zugewiesen) und nicht beschränkte MK-TME-Schlüssel-IDs (z. B. dem Hypervisor, TDRM, Betriebssystem oder einer anderen Software außerhalb der TCB von TDs zugewiesen) ermöglichen und diese Aufteilung während der Ausführung der TDX-Architektur in einer oder mehreren in dem Prozessor gespeicherten Mikroarchitekturtabellen pflegen. In einigen Implementierungen kann eine Hochfahr-Software oder -Firmware (z. B. ein BIOS) eine solche Aufteilung einrichten und eine Kennung der Aufteilung in dem Hardware-Register 116 des Prozessors 112 speichern, die möglicherweise nach dem Hochfahren des Rechensystems 100 für Software zugänglich sein kann. Dies ermöglicht es dem System, sowohl die TD-Architektur als auch die MK-TME-Technologie auf dem Host-Server auszuführen, um hochsichere virtuelle Maschinen, die in TDs ausgeführt werden, sowie nicht modifizierte VMs, die durch die MK-TME-Mechanismen geschützt sind, zu ermöglichen.
  • Um die Isolation gegen Software (wie dem Hypervisor 140) aufrechtzuerhalten, kann die Aufteilung von Schlüssel-IDs in beschränkte und nicht beschränkte in einer Implementierung statisch sein. Wenn während der Ausführung nach dem Hochfahren festgestellt wird, dass vielleicht eine andere Aufteilung von Schlüssel-IDs optimal ist, kann eine Software nach dem Hochfahren (z. B. der Hypervisor 140) eine Neuaufteilung der Schlüssel-IDs anfordern. Dies kann beispielsweise dann von Vorteil sein, wenn die Anzahl der Anwendungen, die eine hochsichere Ausführung erfordern, gestiegen ist. In einigen Implementierungen kann dies durch die Software nach dem Hochfahren erfolgen, die einen Handshake-Mechanismus mit der Hochfahr-Firmware/- Software initiiert, um eine Änderung der Schlüssel-ID-Aufteilung anzufordern. Nach Abschluss des Handshakes und Bestimmen der gewünschten neuen Aufteilung des Schlüssel-ID-Bereichs kann der TDRM 142 einen Ausführungsstatus von TDs, die derzeit auf dem Prozessor ausgeführt werden, unter Verwendung der Schlüssel-IDs speichern und einen Systemneustart durchführen. Dies bietet möglicherweise Flexibilität beim Definieren der Aufteilung von Schlüssel-IDs zwischen MK-TME und TDX basierend auf der Arbeitslast und dem aktuellen Status des Rechensystems.
  • Der Hypervisor 140 kann TDs logische Prozessoren, physischen Speicher, Kryptographieschlüssel-IDs, E/A-Vorrichtungen und dergleichen zuweisen, kann jedoch nicht auf den Ausführungsstatus von TDs und/oder Daten, die in einer TDs zugewiesenen physischen Speicher gespeichert sind, zugreifen. Der Prozessor 112 kann die MK-TME-Maschine 136 verwenden, um beschränkte Kryptographieschlüssel zu verwenden, um eine sichere Datenspeicherung und -verarbeitung zu ermöglichen. Beispielsweise kann die MK-TME-Maschine 136 Daten verschlüsseln, bevor sie aus einem oder mehreren Registern 116 oder dem Cache 118 in den Speicher 130 verschoben werden, wenn ein „Schreib“-Code ausgeführt wird. Umgekehrt kann die MK-TME-Maschine Daten entschlüsseln, wenn die Daten nach einem „Lese“- oder „Ausführ“-Befehl aus dem Speicher 130 in den Prozessor 112 verschoben werden.
  • Jeder Prozessorkern 114 des Prozessors 112 kann einen oder mehrere Hardware-Stränge unterstützen, die logischen Prozessoren entsprechen. Die von den Prozessorkernen 114 unterstützten logischen Prozessoren können in einigen Implementierungen von dem TDRM 142 den TDs 150A-C zugewiesen werden. Zusätzlich zu der TDX-basierten Implementierung von virtuellen Client-Maschinen kann der Virtualisierungsserver 110 eine oder mehrere VMs 155 außerhalb von TDs für eine oder mehrere Client-Vorrichtungen 102A-C ausführen. Während Software außerhalb der vertrauenswürdigen Rechenbasis der TDs - wie dem TDRM 142 und dem Hypervisor 140 - möglicherweise keinen Zugriff auf physische Speicherseiten hat, die TDs und/oder dem Ausführungsstatus von TDs zugewiesen sind, sind die virtuellen Maschinen, die außerhalb von TDs arbeiten, in einer Implementierung möglicherweise nicht gegen Zugriffe durch den Hypervisor 140 sicher. Nichtsdestotrotz können die virtuellen Maschinen, die außerhalb der TCB jeder TD arbeiten, weiterhin vor Software-Zugriffen geschützt sein, die von TDs oder anderen virtuellen Maschinen stammen. In einigen Implementierungen kann ein solcher Zugriff durch die MK-TME-Maschine 136 verhindert werden, die Daten verschlüsselt, die sich zwischen dem Prozessor 112 und dem Speicher 130 mit einem oder mehreren nicht beschränkten Kryptographieschlüsseln unter Verwendung der MK-TME-Maschine 136 bewegen. Der Begriff „nicht beschränkt“ soll einen Schlüssel bezeichnen, auf den der Hypervisor 140 zugreifen kann. Andererseits kann es den nicht autorisierten TDs und VMs in einigen Implementierungen untersagt sein, solche Schlüssel für Speichertransaktionen zu verwenden.
  • Zusätzlich können in mindestens einigen Implementierungen einer oder mehrere der nicht beschränkten Schlüssel gemeinsam genutzt werden. Gemeinsam genutzte Schlüssel können für zwei oder mehr Entitäten, z. B. TDs und VMs, die außerhalb der TDX-Umgebung ausgeführt werden, zugänglich sein. Gemeinsam genutzte Schlüssel können verwendet werden, um auf eine oder mehrere gemeinsam genutzte Strukturen zuzugreifen, wie beispielsweise gemeinsam genutzte Hardware-Vorrichtungen 160A und 160B, bei denen es sich um einen Drucker, eine Tastatur, eine Maus, einen Monitor, einen Netzadapter, einen Router und dergleichen handeln kann. Um beispielsweise ein Bild oder eine Textseite zu drucken, muss eine in einer TD 150A arbeitende Software möglicherweise Daten mit einem gemeinsam genutzten Schlüssel verschlüsseln und die verschlüsselten Daten in dem Speicher 130 speichern, bevor die Daten an eine gemeinsam genutzte Hardware-Vorrichtung gesendet werden. Eine gemeinsam genutzte Hardware-Vorrichtung 160A kann in einer Implementierung über eine Netzschnittstelle 104 mit dem Virtualisierungsserver 110 verbunden sein. In einer weiteren Implementierung kann eine gemeinsam genutzte Hardware-Vorrichtung lokal für den Virtualisierungsserver 110 sein, wie beispielsweise durch die gemeinsam genutzte Hardware-Vorrichtung 160B veranschaulicht.
  • Der Speicher-Controller 120 dient zum Steuern des Datenaustauschs zwischen dem einen oder den mehreren Prozessorkernen 114, den Registern 116, dem Cache 118 und dem Speicher 130. In einigen Implementierungen kann der Speicher-Controller 120 mit der KET 122, die zum Speichern von Kryptographieschlüsseln und Schlüssel-IDs verwendet wird, und der KOT 124, die zum Speichern von Zuweisungen der Schlüssel-IDs zu TDs verwendet wird, gekoppelt sein. Der Speicher-Controller 120 kann auch mit den VMs, die außerhalb der TDX-Architektur laufen, und mit der MOT 126, die zum Speichern von Attributen der physischen Speicherseiten wie beispielsweise Zuweisungen von physischen Speicherseiten zu den TDs und VMs verwendet wird, gekoppelt sein. Der Speicher-Controller 120 kann die MK-TME-Maschine 136 umfassen, um das Vorhandensein mehrerer Kryptographieschlüssel zu ermöglichen, die zum Ver-/Entschlüsseln von Daten verwendet werden, die in den bzw. aus dem Speicher 130 verschoben werden.
  • Um Implementierungen von virtuellem Speicher zu ermöglichen, kann der Speicher 130 Gastseitentabellen 132 und erweiterte Seitentabellen (EPT) 134 speichern, die von VMs zur Verwendung durch den Hypervisor 140 eingerichtet werden. Beispielsweise kann eine Mandantensoftware (z. B. ein Gastbetriebssystem) eine lineare Adresse wie z. B. eine virtuelle Gastadresse (GVA) referenzieren, wenn eine Speichertransaktion ausgeführt wird. Als Antwort kann der Prozessor 112 einen Seitenlauf in den Gastseitentabellen 132 ausführen, um eine physische Gastadresse (GPA) zu identifizieren, die der referenzierten linearen Adresse zugeordnet ist. Die GPA kann immer noch eine virtuelle Adresse für einen Hostserver wie beispielsweise den Virtualisierungsserver 110 sein. Um die physische Hostspeicheradresse (HPA) für die bestimmte GPA zu identifizieren, kann der Prozessor 112 einen weiteren Seitenlauf in der EPT 134 ausführen. Die Daten, die auf der physischen Speicherseite gespeichert sind, auf die in der bestimmten HPA verwiesen wird, kann dann unter Verwendung der Schlüssel-ID, die zum Verschlüsseln der bestimmten Speicherseite verwendet wird, die der bestimmten HPA zugeordnet ist, entschlüsselt werden. In einer Implementierung werden die Schlüssel-ID-Zuordnungen zu den HPAs in der MOT 126 gespeichert.
  • 1B ist ein Blockdiagramm, das einen beispielhaften Prozessorkern eines Prozessors eines Rechensystems, der die Koexistenz der TD-Architektur mit der MK-TME-Technologie ermöglicht, gemäß einer Implementierung darstellt. In der in 1B gezeigten Implementierung kann jeder Prozessorkern 114 einen Cache 118A, eine Hardware-Virtualisierungsunterstützungsschaltung 117 und Hardware-Register 116A umfassen. Die Hardware-Register 116A können beispielsweise eine Anzahl von modellspezifischen Registern 116B (oder MSRs) und Steuerregistern 116C (z. B. CR1, CR2, CR3 und dergleichen) umfassen. Wenn in Implementierungen hierin auf den Cache 118 und die Hardware-Register 116 Bezug genommen wird, können die Implementierungen so verstanden werden, dass sie zusätzlich oder alternativ den Cache 118A und die Hardware-Register 116A eines oder mehrerer der Prozessorkerne 114 umfassen.
  • Der Prozessorkern 114 kann Befehle ausführen, um eine Anzahl von Hardware-Strängen auszuführen, die auch als logische Prozessoren bekannt sind, einschließlich des ersten logischen Prozessors 119A, eines zweiten logischen Prozessors 119B usw. bis eines N-ten logischen Prozessors 119N. In einer Implementierung ist der erste logische Prozessor 119A ein Hypervisor 140. Eine Anzahl von VMs 155 kann von dem Hypervisor 140 ausgeführt und gesteuert werden. Zusätzlich kann der Hypervisor 140 verschiedenen TDs, die auf dem Rechensystem 100 arbeiten, Schlüssel-IDs zuweisen, die entsprechenden Kryptographieschlüsseln zugeordnet sind.
  • 1C ist ein Blockdiagramm, das ein beispielhaftes Rechensystem 101, das die Koexistenz der TD-Architektur mit der MK-TME-Technologie in einem Rechensystem 101 ohne Virtualisierung, die direkt auf dem Betriebssystem 180 der Verarbeitungsvorrichtung 170 ausgeführt wird, ermöglicht, gemäß verschiedenen Implementierungen darstellt. Eine TD 150 kann zusammen mit der MK-TME-Maschine 136 ausgeführt werden, um das Betriebssystem 180 aus der TCB der TD 150A zu entfernen. Der Hypervisor 140 (der Implementierung von 1A) oder das Betriebssystem (der Implementierung von 2B) 180 können der TD 150A mehrere Kryptographieschlüssel zuweisen, einschließlich: eines oder mehrerer beschränkter Schlüssel für den sicheren Zugriff auf die privaten Speicherseiten von TDs und einen oder mehrere nicht beschränkte Schlüssel für den Zugriff auf die gemeinsam genutzten Hardware-Vorrichtungen 160A-B (1A), die mit anderen Verarbeitungsvorrichtungen gemeinsam genutzt werden können.
  • In einer Implementierung kann die Verarbeitungsvorrichtung 170 ein Personalcomputer oder eine andere Verarbeitungsvorrichtung sein, die keine Cloud-Datenverarbeitung verwendet. Die Anforderungen der sicheren Ausführung verschiedener Anwendungen auf der Verarbeitungsvorrichtung 170 können es dennoch vorteilhaft machen, mehrere TDs auszuführen, um den Zugriff von Anwendungen, die innerhalb der TD 150A ausgeführt werden, auf die sicheren Daten auf den der TD 150B zugewiesenen Speicherseiten zu verhindern. Beispielsweise kann die Verarbeitungsvorrichtung ein Computer für Aufzeichnungen in einer Arztpraxis oder einer Klinik sein. Eine Anwendung, die in der TD 150A ausgeführt wird, kann die Krankengeschichte von Patienten speichern, während eine andere Anwendung, die in der TD 150B ausgeführt wird, ihre persönlichen Daten speichern kann. Die Arztpraxis oder Klinik möchte die persönlichen Daten möglicherweise auch dann schützen, wenn irgendeine schädliche Software Zugriff auf die der TD 150A zugewiesenen Kryptographieschlüssel erhält und auf die Krankengeschichte des Patienten zugreift. Dementsprechend kann der Hypervisor 140 oder das Betriebssystem 180 der TD 150B einen oder mehrere beschränkte Kryptographieschlüssel zuweisen, die sich von den der TD 150A zugewiesenen beschränkten Kryptographieschlüsseln unterscheiden. Der Hypervisor 140 oder das Betriebssystem 180 behalten möglicherweise die Kontrolle über andere - nicht beschränkte - Schlüssel für andere Anwendungen, die außerhalb der TDs 150A und 150B ausgeführt werden. Der Hypervisor 140 erlaubt aus Sicherheitsgründen möglicherweise keinen Zugriff für die TDs 150A und 150B auf solche nicht beschränkten Schlüssel. In einigen Implementierungen kann der Hypervisor 140 einige seiner nicht beschränkten Schlüssel mit der TD 150A und/oder der TD 150B für Speichertransaktionen teilen, die mit dem Zugriff auf gemeinsam genutzte Hardware-Vorrichtungen 160A und/oder 160B verbunden sind, die ein Drucker, eine E/A-Vorrichtung, ein Monitor, ein Netzadapter und dergleichen sein könnten. Einige dieser Vorrichtungen - z. B. eine Hardware-Vorrichtung 160A - können über die Netzschnittstelle 104 mit der Verarbeitungsvorrichtung 170 verbunden sein.
  • In verschiedenen Implementierungen kann die Vertrauensdomäneninfrastruktur unter Verwendung der geeigneten Befehlssatzarchitektur des Prozessors 112 wie beispielsweise der Vertrauensdomänenerweiterungs-Implementierung (TDX-Implementierung) implementiert werden. In einer Implementierung kann eine TD 150A von dem TDRM 142 erstellt und gestartet werden, der eine Programmierschnittstelle zum Verwalten des Betriebs von TDs bereitstellen kann. Der TDRM 142 kann eine TD 150A unter Verwendung eines TD-Erstellungsbefehls, z. B. TDCREATE, erzeugen. Der TDRM 142 kann einen Bereich von physischem Speicher (z. B. einen ausgerichteten 4-KB-Bereich) auswählen und diesen als Parameter an den TD-Erstellungsbefehl liefern. Dieser Speicherbereich kann als TD-Steuerstruktur (TDCS) für die TD 150A verwendet werden. In einigen Implementierungen belegt die TDCS einen natürlich ausgerichteten Speicherbereich von 4 KB. Eine Seite, die in der MOT als TDCS für die TD 150A identifiziert ist, kann für Software-Lese- und Schreibvorgänge gesperrt werden und auf diese Weise für die Verwendung innerhalb der TDX-Architektur geschützt werden. Die TDCS kann beispielsweise eine TD-Kennung, einen der TD zugewiesenen Kryptographieschlüssel und die dem Kryptographieschlüssel zugeordnete Schlüssel-ID halten. Bei Ausführung kann der TDCREATE-Befehl den Prozessor 112 dazu veranlassen, zu überprüfen, ob die Ziel-4-KB-Seite der TD zugewiesen ist (unter Verwendung der MOT 126). Der TDCREATE-Befehl kann ferner veranlassen, dass der Prozessor 112 einen Kryptographieschlüssel und eine zugehörige Schlüssel-ID für die TD 150A erzeugt. Der Prozessor 112 kann dann den Seiteninhalt auf der Zielseite unter Verwendung des der TD zugewiesenen Kryptographieschlüssels initialisieren. Der TDCREATE-Befehl kann auch veranlassen, dass der Prozessor 112 einen Hash für eine in der TDCS zu speichernde TD-Messung initialisiert.
  • In einer Implementierung kann der TDRM 142 den anfänglichen Blockcode und Daten für die TD 150A unter Verwendung eines TDADDPAGE-Befehls einrichten, der die Adresse der TDCS-Seite als Parameter, eine Adresse einer Code- (oder Daten-) Seite für das TD-Abbild in dem TDRM-Adressraum und die der TD 150A zugewiesene physische Seite angibt. Der Prozessor 112 kann dann überprüfen, ob die Ziel-4-KB-Seite der TD 150A zugewiesen ist. Nach der Überprüfung erweitert der Prozessor 112 den Hash für die TD 150A in der TDCS. Anschließend kopiert der Prozessor den Seiteninhalt von der Quell- zu der Zielseite unter Verwendung des der TD 150A zugewiesenen eindeutigen Kryptographieschlüssels. Ein ähnliches Verfahren kann befolgt werden, um andere TDs 150B-C zu instanziieren, und zwar so viele wie erforderlich sind und von dem Prozessor 112 und dem Speicher 130 unterstützt werden.
  • Die den Kryptographieschlüsseln zugeordneten Kryptographieschlüssel und Schlüssel-IDs können durch die von dem BIOS konfigurierte MK-TME-Maschine 136 beim Hochfahren des Rechensystems 100 oder durch die Verarbeitungsvorrichtung 170 unter Verwendung eines TME-Aktivierungs-MSR (TME_ACTIVATE) innerhalb des Hardware-Register 116 (z. B. MSRs) aktiviert werden. Um MKTME zu ermöglichen, kann das TME-Freigabe-RWL-Bit in dem TME ACTIVATE-MSR gesetzt werden und die Bits 35:32 können auf Werte ungleich Null gesetzt werden (die die Anzahl der für MK-TME konfigurierten Schlüssel-ID-Bits angeben). Diese MK_TME_KEYID_BITS sind die Anzahl der Schlüssel-ID-Bits, die der MK-TME-Verwendung zugewiesen werden sollen. Ähnlich wie bei der Aufzählung ist dies ein codierter Wert. Das Schreiben eines Werts, der größer als die aufgezählte Anzahl der maximal unterstützten Schlüssel-ID-Bits ist, kann zu einem allgemeinen Schutzfehler (#GP) führen. Das Schreiben eines Werts ungleich Null in dieses Feld kann auch zu einem allgemeinen Schutzfehler führen, wenn Bit 1 von EAX (TME-Freigabe) nicht ebenfalls auf „1“ gesetzt ist, da TME für die Verwendung von MK-TME aktiviert werden soll. Das TME_ACTIVATE-MSR kann auch verwendet werden, um andere TME-bezogene MSRs (z. B. EXCLUD_MASK, EXCLUDE_BASE) zu sperren, so dass jegliches Schreiben in die Register nach dem Sperren ignoriert wird. Die Sperre kann zurückgesetzt werden, wenn das Rechensystem 100 zurückgesetzt wird.
  • In einigen Implementierungen kann das BIOS beim Hochfahren des Rechensystems 100 bestimmte Informationen in dem TME_ACTIVATE-MSR für spätere Verwendung durch den Prozessor 112 (z. B. den Speicher-Controller 120) zum Beschränken des Zugriffs auf die beschränkten Kryptographieschlüssel und Schlüssel-IDs speichern. Diese Informationen können einen Wert für eine Anzahl von Adressbits von physischen Speicheradressen (z. B. physischen Hostadressen), die für Schlüssel-IDs verwendet werden, umfassen. Die speziellen Informationen, die vom BIOS in dem TME_ACTIVATE-MSR gespeichert werden, können ferner eine Aufteilungskennung (z. B. eine Aufteilungsschlüssel-ID) umfassen, um Schlüssel-IDs in nicht beschränkte Schlüssel-IDs und beschränkte Schlüssel-IDs aufzuteilen. Darüber hinaus kann in einer Implementierung eine zweite Anzahl von beschränkten Bits der physischen Speicheradressen in dem TME ACTIVATE-MSR gespeichert werden, die angibt, wie die beschränkten Schlüssel-IDs von den nicht beschränkten Schlüssel-IDs getrennt sind.
  • 2A zeigt die Aufteilung des Kryptographieschlüssel-ID-Raums 200 in TDX- und MK-TME-Schlüssel-IDs in einer Implementierung mit einer einzigen Grenze, die nicht beschränkte Schlüssel-IDs von beschränkten Schlüssel-IDs trennt. Beim Hochfahren kann der Prozessor 112 innerhalb des MSR einen Bitbereich für die Schlüssel-ID-Codierung speichern. Der Bitbereich unterstützt möglicherweise K Schlüssel-IDs zur Identifizierung von K Kryptographieschlüsseln. Der Prozessor 112 kann ferner innerhalb des MSR die Aufteilung 200 des Schlüssel-ID-Raums identifizieren. In einer Implementierung können K Schlüssel-IDs in KMK nicht beschränkte Schlüssel-IDs und KTD nicht beschränkte Schlüssel-IDs aufgeteilt werden, so dass KMK + KTD = K. Die nicht beschränkten Schlüssel-IDs können MK-TME-Schlüssel-IDs sein, die in einer in 1A dargestellten Virtualisierungsimplementierung dem Hypervisor 140 (z. B. zur Zuweisung an gemeinsam genutzte Vorrichtungen) zugewiesen sind. Die MK-TME-Schlüssel-IDs können ferner in einer Nicht-Virtualisierungsimplementierung, die in 1C dargestellt ist, dem Betriebssystem 180 (oder dem TDRM 142) zugewiesen sein. Die beschränkten Schlüssel-IDs können der TD-Infrastruktur zugewiesen und dann weiter einer oder mehreren TDs 150A-C zugewiesen sein.
  • In einer Implementierung können Schlüssel-IDs auf ein zusammenhängendes Intervall von Ganzzahlen im Bereich von 0 bis K-1 abgebildet werden. Die nicht beschränkten Schlüssel-IDs können auf die niedrigere Menge zusammenhängender Zahlen im Bereich von 0 bis KMK-1 abgebildet werden, während die beschränkten Schlüssel-IDs auf den höheren Satz zusammenhängender Zahlen im Bereich von KMK bis K-1 abgebildet werden. In der in 2A gezeigten Implementierung ist eine Grenze zwischen beschränkten und nicht beschränkten Schlüssel-IDs definiert, z. B. unterhalb der Linie Schlüssel-ID = KMK. Obwohl das Aufteilen des Schlüssel-ID-Raums in zwei zusammenhängende Bereiche in einigen Fällen vorteilhaft sein kann, können in anderen Implementierungen mehrere Grenzen definiert werden, so dass mehrere Bereiche nicht beschränkter Schlüssel-IDs sich mit Bereichen beschränkter Schlüssel-IDs abwechseln.
  • 2B zeigt eine mögliche Codierung und Aufteilung der Kryptographieschlüssel-ID 205 in TDX- und MK-TME-Schlüssel-IDs unter Verwendung von M Bits Adressraum, die mit der physischen Speicheradresse verkettet sind. In einer Implementierung repräsentiert ein Wert M die Anzahl von Adressbits, die mit der physischen Speicheradresse 210 einer physischen Speicherseite verkettet (oder an diese angehängt) sind. Die physische Speicherseite kann in einigen Implementierungen eine 4-KB-Seite sein und kann einer der TDs 150A-C zugewiesen werden, um mit einem der beschränkten Kryptographieschlüssel verschlüsselt zu werden. (In anderen Implementierungen können andere Seitengrößen durch eine hierarchische Struktur wie eine Seitentabelle unterstützt werden.) Alternativ kann die physische Speicherseite dem Hypervisor 140 zugewiesen werden, um mit einem der nicht beschränkten Schlüssel für nicht gemeinsame Verwendung durch den Hypervisor oder durch eine der den Hypervisor aktivierten Anwendungen einschließlich VMs 155, die außerhalb der TDX-Architektur ausgeführt werden, verschlüsselt zu werden. Alternativ kann die physische Speicherseite mit einem der nicht beschränkten Schlüssel verschlüsselt werden, die dem Hypervisor 140 zugewiesen sind und von dem Hypervisor weiter mehreren TDs für Speichertransaktionen die der Verwendung gemeinsam genutzter Strukturen wie beispielsweise den gemeinsam genutzten Hardware-Vorrichtungen 160A-B zugeordnet sind, zugewiesen sind.
  • Um zum Codieren von K Schlüssel-IDs ausreichend zu sein, muss die Anzahl der Adressbits M mindestens gleich log2 K sein. In einer beispielhaft dargestellten Implementierung ist ohne Einschränkung darauf M = 7, und eine solche Anzahl von Adressbits kann bis 27 = 128 verschiedene Schlüssel-IDs unterstützen. Der erste Schlüssel (Schlüssel-ID = 0) kann ein TME-Schlüssel sein, d. h. ein Schlüssel, der dem Hypervisor 140 zugewiesen ist, um Speichertransaktionen zu verschlüsseln, die dem Hypervisor gehören. Beispielsweise kann die physische Speicheradresse 210 verwendet werden, um die Konfiguration des Hypervisors zu speichern, die nicht mit TDs und/oder VMs, die von dem Hypervisor aktiviert werden, geteilt werden soll.
  • Um die Aufteilung von Schlüssel-IDs in beschränkte und nicht beschränkte Schlüssel-IDs zu erleichtern, kann ein zweiter Wert L der Anzahl von Adressbits definiert werden. Um zum Codieren von KMK nicht beschränkten Schlüssel-IDs ausreichend zu sein, ist L mindestens gleich log2 KMK. Um beispielsweise KMK = 20 nicht beschränkte Schlüssel-IDs zu codieren, muss L mindestens 5 sein. Es ist zu beachten, dass der gleiche Wert L = 5 ausreichen würde, um bis zu 32 nicht beschränkte Schlüssel-IDs zu codieren.
  • Die niedrigeren L Bits der M Adressbits können als Bit-Unterbereich von nicht beschränkten Bits (oder allgemeinen Bits) bezeichnet werden, die verbleibenden höheren M-L Bits können als Unterbereich von beschränkten Bits bezeichnet werden. In einer Implementierung haben die Adressbits für alle nicht beschränkten Schlüssel-ID-Codierungen den gleichen Wert 0. Beispielsweise bezieht sich eine physische Speicheradresse 220 auf eine Seite des physischen Speichers, die mit einem Kryptographieschlüssel verschlüsselt ist, der einer Schlüssel-ID gleich 22 zugeordnet ist. Da die ersten (beschränkten) M-L Bits den gleichen Wert 0 haben, ist die Schlüssel-ID eine nicht beschränkte MK-TME-Schlüssel-ID, die dem Hypervisor zugewiesen ist.
  • In der gleichen Implementierung wird die Schlüssel-ID beschränkt und einer der TDs der Vertrauensdomäneninfrastruktur zugewiesen, wenn eines der M-L beschränkten Bits gesetzt ist (d. h. einen Wert von eins („1“) hat). Beispielsweise bezieht sich eine physische Speicheradresse 230 auf eine Seite des physischen Speichers, die mit einem Kryptographieschlüssel verschlüsselt ist, der einer Schlüssel-ID von 51 zugeordnet ist. In einer Implementierung kann diese Schlüssel-ID von der TD 150A verwendet werden. Als weiteres Beispiel bezieht sich eine physische Speicheradresse 240 auf eine Seite des physischen Speichers, die mit einem Kryptographieschlüssel verschlüsselt ist, der einer Schlüssel-ID von 82 zugeordnet ist. In einer Implementierung kann diese Schlüssel-ID von der TD 150B verwendet werden.
  • Es ist zu beachten, dass, während L allgemeine (nicht beschränkte) Bits verwendet werden, um nicht beschränkte Schlüssel-IDs zu codieren, wobei M-L beschränkte Bits gelöscht sind (d. h. den Wert null („0“) haben), in einer Implementierung sowohl die allgemeinen Bits als auch die beschränkten Bits verwendet werden, um beschränkte Schlüssel-IDs zu codieren. Die Gesamtzahl der beschränkten Schlüssel-IDs, die von der in 2B dargestellten Aufteilung unterstützt werden, ist 27-25 = 96.
  • In einigen Implementierungen haben zum Codieren nicht beschränkter Schlüssel-IDs die oberen allgemeinen Bits den Wert eins („1“) anstelle des Werts null („0“). In solchen Implementierungen sind die unteren 2M-2L Schlüssel-IDs beschränkte Schlüssel-IDs, während die oberen 2L Schlüssel-IDs nicht beschränkt sind.
  • In der in 2B dargestellten Aufteilung sind die allgemeinen Bits zusammenhängend, ebenso wie die beschränkten Bits (z. B. RRGGGGG), wobei die beschränkten Bits die M-L oberen Bits der Schlüssel-ID-Codierung und die allgemeinen Bits die unteren L Bits sind. In einigen Implementierungen können nicht zusammenhängende allgemeine und beschränkte Bits verwendet werden. Beispielsweise kann für die gleiche Situation von L = 5 allgemeinen Bits und M-L = 2 beschränkten Bits die Abbildung von Bits nicht zusammenhängend sein, z. B. RGRGGGG. Vorausgesetzt, dass nicht beschränkte Schlüssel-IDs solche sind, bei denen alle R=0 sind, würde der Schlüssel-ID-Bereich wie folgt aussehen:
    • 0 ≤ Schlüssel-ID ≤ 15: nicht beschränkter (MK-TME-) Schlüssel,
    • 16 ≤ Schlüssel-ID ≤ 31: beschränkter (TDX-)Schlüssel,
    • 32 ≤ Schlüssel ID ≤ 47: nicht beschränkter (MK-TME-) Schlüssel,
    • 48 ≤ Schlüssel ID ≤ 127: beschränkter (TDX-)Schlüssel. Entsprechend würden drei Grenzen zwischen beschränkten und nicht beschränkten Schlüssel-IDs implementiert.
  • Die Anzahl der Grenzen kann für andere Aufteilungsimplementierungen sogar noch größer sein. In einer Implementierung können beschränkte Schlüssel nacheinander mit nicht beschränkten Schlüssel-IDs abwechselnd angeordnet sein. Dies kann beispielsweise passieren, wenn nur das niedrigste Bit der M Bits, die für die Schlüssel-ID-Codierung verwendet werden, ein beschränktes Bit ist. Vorausgesetzt, dieses niedrigste Bit wird für beschränkte Schlüssel-IDs gesetzt und für nicht beschränkte Schlüssel-IDs gelöscht, ist jede gerade (und 0.) Schlüssel-ID eine nicht beschränkte Schlüssel-ID und jede ungerade Schlüssel-ID eine beschränkte Schlüssel-ID. In einer solchen Implementierung entspricht die Anzahl der beschränkten Schlüssel-IDs der Anzahl der nicht beschränkten Schlüssel-IDs.
  • In der MK-TME-Architektur (mit oder ohne TDX) kann jede Speicherseite mit einem der Kryptographieschlüssel verschlüsselt werden. Der Prozessor 112 kann in einer Implementierung die Verwendung von Kryptographieschlüsseln über den Speicher-Controller 120 erzwingen. Der Speicher-Controller 120 kann mit einer Reihe von Tabellen gekoppelt sein, die in 2C 2E dargestellt sind, um eine solche Erzwingung zu ermöglichen. Beispielsweise kann der Speicher-Controller die KET 122, die Zuordnungen von Kryptographieschlüsseln zu Schlüssel-IDs speichert, wie es in 2C dargestellt ist, für eine Implementierung mit insgesamt K = 128 Schlüsseln und KTDX = 96 beschränkten Schlüsseln umfassen. In einer Implementierung können die Kryptographieschlüssel 255 128-Bit-Schlüssel sein. Die KET 122 kann durch die Schlüssel-IDs 250 indiziert sein. Die Aufteilung der Schlüssel-IDs (und damit der Kryptographieschlüssel) kann wie oben beschrieben implementiert sein. Wenn eine Speichertransaktion auf eine physische Speicheradresse einer physischen Seite des Speichers gerichtet ist, kann der Prozessor die Schlüssel-ID aus den oberen M Bits der physischen Speicheradresse extrahieren, die für die Schlüssel-ID-Codierung verwendet wird. Der Prozessor kann dann auf die KET 122 zurückgreifen, um zu bestimmen, welcher Kryptographieschlüssel zum Entschlüsseln oder Verschlüsseln der physischen Seite des Speichers verwendet werden soll.
  • Die KET 122 (2C) ist eine Mikroarchitektur-Hardware-Tabelle zum Konfigurieren der Verschlüsselungsmaschinen, wie beispielsweise der MK-TME-Maschine 136. Die Aufteilung der KET 122 in TDX-Schlüssel und MK-TME-Schlüssel kann durch den Befehl TDCONFIGKEY ausgeführt werden.
  • Der Speicher-Controller 120 kann mit der KOT 124 (2D) gekoppelt sein. Die KOT 124 kann die Zuweisungen 265 der Schlüssel-IDs 250 zu verschiedenen TDs und Software, die außerhalb der TCB der jeweiligen TD läuft, wie beispielsweise dem Hypervisor speichern. Die KOT kann in einer Implementierung durch die Schlüssel-ID 250 indiziert sein. Für jede Schlüssel-ID 250 kann die KOT 124 einen Verweis auf eine Entität speichern, der die Schlüssel-ID 250 derzeit zugewiesen ist. Beispielsweise kann dem Hypervisor 140 die erste nicht beschränkte Schlüssel-ID = 0 zugewiesen sein, um die in Hypervisor-Root-Operationen verwendeten physischen Speicherseiten zu verschlüsseln. Eine Anzahl anderer nicht beschränkter Schlüssel-IDs 250 kann ferner dem Hypervisor 140 zugewiesen sein oder von diesem verwendet werden. Der Hypervisor kann ferner einige der nicht beschränkten Schlüssel-IDs 250 anderen Anwendungen zuweisen, wie beispielsweise den VMs 155, die außerhalb der TDX-Architektur ausgeführt werden. Die KOT 124 kann auch die Zuweisung von beschränkten Schlüssel-IDs zu verschiedenen ausgeführten TDs speichern: TD1, TD2, TD3 usw. Mehr als eine beschränkte Schlüssel-ID 250 kann derselben TD zugewiesen werden. Einige der beschränkten Schlüssel-IDs 250 können möglicherweise keiner TD zugewiesen werden, können jedoch bei Bedarf für eine spätere Verwendung reserviert werden.
  • Die KOT 124 ist eine Mikroarchitektur-Hardware-Tabelle zum Verwalten des TDX- und MK-TME-Inventars, insbesondere zum Zuweisen der Schlüssel-IDs 250 zu den TDs 150A-C, zum Widerrufen der Schlüssel-IDs 250 und zum Steuern des Leerens des Caches 118, bevor die Schlüssel-IDs 250 verschiedenen TDs zugewiesen werden. Die KOT 124 bietet Hardware-Schutz gegen mehrere gleichzeitige Zuweisungen derselben TDX-Schlüssel-IDs zu verschiedenen TDs.
  • Da die KET 122 und die KOT 124 in der Hardware des Prozessors 112 implementiert sind, sind diese Tabellen für Software nicht direkt zugänglich. Dies ermöglicht es dem Prozessor 112, den ordnungsgemäßen Betrieb der Software zu verfolgen und die TDX-Sicherheitsziele zu garantieren.
  • Wie in 2E dargestellt ist, kann der Speicher-Controller 120 ferner mit der Speicherbesitztabelle (MOT) 126 gekoppelt sein, die von dem Prozessor 112 verwaltet wird, um die Zuweisung von physischen Speicherseiten zu ausführenden TDs wie der TD 150A zu erzwingen. Der Prozessor 112 verwendet auch die MOT 126, um zu erzwingen, dass die physischen Adressen, auf die durch Software verwiesen wird, in einer Implementierung ausgeführt werden, in der eine TD 150A oder der TDRM 142 nicht auf Speicher zugreifen können, der ihnen nicht explizit zugewiesen ist.
  • Die MOT 126 kann die folgenden Eigenschaften erzwingen. Erstens darf Software außerhalb einer TD 150A nicht im Klartext auf einen Speicher zugreifen (lesen/schreiben/ausführen), der zu einer anderen TD gehört (dies schließt den TDRM 142 als Sicherheitsdomäne ein). Zweitens können Speicherseiten, die über die MOT 126 bestimmten TDs zugewiesen sind, wie z. B. der TD 150A, in einer Implementierung von jedem logischen Prozessor in dem System (wenn der logische Prozessor die TD ausführt, der der Speicher zugewiesen ist) zugänglich sein.
  • Die Struktur der MOT 126 kann verwendet werden, um Metadatenattribute für jede 4-KB-Speicherseite zu speichern. Für zusätzliche Seitengrößen (2 MB, 1 GB) können zusätzliche Strukturen definiert werden. Die Metadaten für jede 4-KB-Speicherseite werden direkt durch die physische Seitenadresse indiziert. In anderen Implementierungen können andere Seitengrößen durch eine hierarchische Struktur (wie eine Seitentabelle) unterstützt werden. Eine 4-KB-Seite, auf die in der MOT 126 verwiesen wird, kann zu einer laufenden Instanz einer TD 150A gehören. 4-KB-Seiten, auf die in der MOT 126 verwiesen wird, können entweder ein gültiger Speicher sein oder als ungültig markiert sein.
  • In einer Implementierung ist die MOT 126 an einer 4-KB-Speichergrenze ausgerichtet und belegt einen physisch zusammenhängenden Speicherbereich, der nach der Plattforminitialisierung vor dem Zugriff durch Software geschützt ist. In einer Implementierung ist die MOT eine mikroarchitektonische Struktur und es kann von Software nicht direkt darauf zugegriffen werden. Architektonisch kann die MOT 126 die folgenden Attribute für jede 4-KB-Seite des physischen Hostspeichers enthalten: physische Hostadresse 282 einer physischen Hostspeicherseite, Seitenstatus 284 (gibt an, ob die Seite eine gültige Speicherseite ist), Seitenstatus 286 (gibt an, ob die Seite zugewiesen ist, gerade einer TD zugewiesen/freigegeben/neu zugewiesen wird usw.), TD-Kennung (TDID) 288 (gibt an, welcher bestimmten TD die Seite zugewiesen ist) und Schlüssel-ID 250 des Kryptographieschlüssels zum Ver-/Entschlüsseln der physischen Hostspeicherseite.
  • Die MOT 126 kann aktiviert werden, wenn TDX in dem Prozessor 112 aktiviert ist (z. B. über das CR4-Freigabebit nach einer CPUID-basierten Aufzählung). Sobald die MOT 126 aktiviert ist, kann die MOT 126 von dem Prozessor 112 verwendet werden, um die Speicherzugriffssteuerung für physische Speicherzugriffe zu erzwingen, die von Software einschließlich des TDRM 142 initiiert werden.
  • In Implementierungen verwaltet der TDRM 142 Speicherbetriebsmittel über die MOT 126 unter Verwendung eines MOT-Betriebsbefehls (TDMOTOP) mit den folgenden Unterbefehlen:
  • Füge Seite zu MOT hinzu (TDMOTADDPAGE):
    • markiert einen freien Eintrag in der MOT 126, der einer physischen Hostadresse (HPA) entspricht, als einer von einer TDID 288 angegebenen TD 150A (ausschließlich) zugewiesen. Jeder andere vorherige Seitenstatus kann einen Fehler verursachen. Dieser Befehl erzwingt einen strangübergreifenden Übersetzungsnachschlagepufferabschuss (TLB-Abschuss), um zu bestätigen, dass keine andere TD 150B eine Zuordnung zu dieser HPA zwischenspeichert. Insbesondere kann ein TLB-Abschuss als Ungültigmachung eines TLB-Eintrags über alle Prozessorkerne 114 des Prozessors 112 hinweg verstanden werden. Der TDMOTADDPAGE-Befehl kann von dem TDRM 142 aufgerufen werden. Wenn der TDRM 142 eine erweiterte MOT aktiviert hat, dann kann der Befehl die anfängliche physische Gastadresse (GPA) angeben, die der angegebenen HPA zugeordnet ist. Der Prozessor 112 verifiziert, ob die GPA der HPA zugeordnet ist, indem er die von dem TDRM 142 verwaltete EPT 134 durchgeht. Eine Variante des TDMOTADDPAGE-Befehls kann implementiert werden, die einer TD eine Seite zuweist (TDMOTAUGPAGE), jedoch möglicherweise keine Messung der Seite erfasst.
  • Widerrufe Seite aus MOT widerrufen (TDMOTREVOKEPAGE): markiert eine zugewiesene Seite als freie Seite. Dieser Befehl erzwingt einen strangübergreifenden TLB-Abschuss, um zu bestätigen, dass nachfolgende TD-150A-Zugriffe auf HPA-Besitz prüfen und dass der Seiteninhalt von dem Prozessor 112 gelöscht wird. Ein TD-150A-Zugriff, bei dem während des TLB-Füllens ein MOT-126-Seitenfehler auftritt, veranlasst den Prozessor 112 dazu, die TDCS ungültig zu machen, wodurch verhindert wird, dass weitere TD in die TD 150A eintreten. Dieses Befehlsblatt kann von dem TDRM 142 aufgerufen werden.
  • Sperre Seite in MOT (TDMOTBLOCKPAGE): markiert einen freien oder zugewiesenen Eintrag der MOT 126, der einer HPA entspricht, als für die Software-Nutzung gesperrt. Jeder andere vorherige Seitenzustand verursacht einen TDRM-142-Fehler. Dieser Befehl erzwingt einen strangübergreifenden TLB-Abschuss, um zu bestätigen, dass nachfolgende TD-150A-Zugriffe auf HPA-Besitz prüfen. Dieses Befehlsblatt kann von dem TDRM 142 aufgerufen werden.
  • Entsperre Seite in MOT (TDMOTUNBLOCKPAGE):
    • markiert einen gesperrten MOT-126-Eintrag, der einer HPA entspricht, als gültig für die Software-Nutzung/Zuweisung. Jeder andere Status der vorherigen Seite verursacht einen Fehler. Der TDMOTBLOCKPAGE-Befehl kann von dem TDRM 142 aufgerufen werden.
  • In einigen Implementierungen und mit zusätzlichem Fokus auf 2E kann der Speicher-Controller 120 der TD 150A eine oder mehrere physische Seiten des Speichers 130 zur privaten Nutzung von Softwareprogrammen und Anwendungen zuweisen, die innerhalb der TD 150A ausgeführt werden. Der Speicher-Controller 120 kann dann die Metadatenattribute jeder der zugewiesenen physischen Seiten des Speichers in der MOT 126 aktualisieren, einschließlich einiger der folgenden (aber nicht darauf beschränkt): physische Hostadresse 282, Seitenstatus 284, Seitenstatus 286, TDID 288 der Seite und die beschränkte Schlüssel-ID 250, die dem Kryptographieschlüssel zugeordnet ist, der von dem Speicher-Controller 120 zum Ver-/Entschlüsseln von Daten verwendet werden soll, die auf der physischen Seite des Speichers gespeichert sind.
  • In einigen Implementierungen können zusätzliche TDs durch den Prozessor 112 aktiviert werden und der Hypervisor 140 (oder TDRM 142) kann solchen zusätzlichen TDs nach Bedarf zusätzliche Schlüssel-IDs aus der Liste der beschränkten Schlüssel-IDs zuweisen. In solchen Implementierungen muss der Speicher-Controller 120 möglicherweise verschiedenen TDs separate physische Speicherseiten zuweisen und die MOT 126 entsprechend aktualisieren.
  • In einigen Implementierungen kann eine von dem Speicher-Controller 120 zugewiesene physische Speicherseite von einer oder mehreren TDs und/oder dem Hypervisor 140 gemeinsam genutzt werden. In solchen Implementierungen kann der Speicher-Controller 120 im Wesentlichen die gleichen Operationen wie oben beschrieben ausführen, jedoch den Seitenstatus 286 für diese Seite als gemeinsam genutzt festlegen. Der Speicher-Controller 120 kann dann mehrere TDIDs für TDs speichern, die Zugriff auf die gemeinsam genutzte Seite haben können. Der Speicher-Controller kann eine gemeinsam genutzte nicht beschränkte Schlüssel-ID 250 speichern, die dem Kryptographieschlüssel zugeordnet ist, der von dem Speicher-Controller 120 zum Ver-/Entschlüsseln von Daten verwendet werden soll, die auf der gemeinsam genutzten Seite des Speichers gespeichert sind.
  • Wenn der Speicher-Controller 120 eine Speichertransaktion detektiert, die auf eine physische Seite des Speichers gerichtet ist, die einer bestimmten TD zugeordnet ist, kann der Speicher-Controller 120 in einer Reihe von Situationen eine Fehler- und/oder Abbruchprozedur erzeugen, was ohne Einschränkung darauf umfasst:
    • • eine Speichertransaktion, die eine nicht beschränkte ID enthält, die mit der physischen Speicheradresse verkettet ist, während die physische Seite des Speichers eine private Seite ist, die einer TD zugewiesen ist.
    • • eine Speichertransaktion, die eine falsche beschränkte Schlüssel-ID enthält, die mit der physischen Speicheradresse verkettet ist, für die eine andere beschränkte Schlüssel-ID erwartet wird.
    • • eine Speichertransaktion, die eine korrekte beschränkte Schlüssel-ID enthält, die mit der physischen Speicheradresse verkettet ist, wobei die Speichertransaktion jedoch von einem Software-Programm außerhalb der TCB der TD initiiert wird, der die beschränkte Schlüssel-ID zugewiesen ist (z. B. wird die Speichertransaktion, die von dem Hypervisor 140 oder von einem Software-Programm, das in einer anderen TD ausgeführt wird, initiiert wird).
  • Insbesondere kann in der ersten Situation eine vertrauenswürdige Software, die in der TD 150A ausgeführt wird, fälschlicherweise eine nicht beschränkte (entweder gemeinsam genutzte oder nicht gemeinsam genutzte) MK-TME-Anforderungsschlüssel-ID mit der physischen Speicheradresse einer privaten physischen Seite des Speichers verketten, die mit einem der der TD 150A zugewiesenen beschränkten TDX-Schlüssel verschlüsselt ist (oder voraussichtlich verschlüsselt wird - im Falle eines Schreibvorgangs). In diesem Fall kann der Speicher-Controller 120 über die MK-TME-Maschine 136 in einer Implementierung detektieren, dass keines der beschränkten Bits der Anforderungsschlüssel-ID gesetzt ist und dass daher die Anforderungsschlüssel-ID keine der beschränkten Schlüssel-IDs ist. Entsprechend kann der Speicher-Controller 120 als Antwort auf eine Bestimmung, dass mindestens eines der beschränkten Bits der Anforderungsschlüssel-ID gesetzt ist (oder in einigen Implementierungen, wie oben erläutert, gelöscht ist), einen Fehler erzeugen, z. B. einen nicht beschränkten Schlüsselseitenfehler. Der Fehler kann verwendet werden, um das Software-Programm, das die Speichertransaktion initiiert hat, darüber zu informieren, dass ein nicht beschränkter Schlüssel an einer Stelle verwendet wurde, an der ein beschränkter Schlüssel erwartet wird. In einigen Implementierungen kann der Speicher-Controller 120 ferner detektieren, dass die Speichertransaktion von außerhalb einer vertrauenswürdigen Rechenbasis der TD 150A stammt (zum Beispiel eine Transaktion aus einer der TDs 150 B-C, einer der VMs 155, die außerhalb einer TD arbeitet, einem Hypervisor 140 usw.), und eine stille Seitenabbruchsemantik erzeugen. In einigen Implementierungen kann dies bedeuten, dass Schreibvorgänge stillschweigend ignoriert werden, während Lesevorgänge den Wert 1 (oder 0) für alle Bits zurückgeben.
  • 3 ist ein Blockdiagramm der Gate-Architektur 300, die einen Abschnitt der MK-TME-Maschine 136 des Systems 100 oder 101 gemäß einigen Implementierungen darstellt. Die MK-TME-Maschine 136 kann ein ODER-Gatter 310, einen Komparator 320, ein erstes UND-Gatter 330 und ein zweites UND-Gatter 340 umfassen. 3 zeigt einen Hardware-Mechanismus zum Erzwingen der angemessenen Verwendung von beschränkten Schlüssel-IDs in einer Implementierung. Dieser Hardware-Mechanismus kann mehrere Prozessorkerne 114 oder logische Prozessoren bedienen, die verschiedenen TDs 150A-C zugewiesen sind. In einigen Implementierungen kann dieser Hardware-Mechanismus für mehrere (oder alle) Prozessorkerne/logische Prozessoren repliziert sein.
  • In verschiedenen Implementierungen kann der Speicher-Controller 120 diese Transaktion verarbeiten, wenn ein Softwareprogramm - ein Hypervisor oder ein Programm, das innerhalb einer der TDs 150A-C oder innerhalb einer der VMs 155, die außerhalb der TDs ausgeführt werden, ausgeführt wird
    • - eine Speichertransaktion ausgibt. Das ODER-Gatter 310 kann eine Ausgabe auslösen, wenn die Speichertransaktion einen Seitenlauf (ausführlicher unter Bezugnahme auf 4A-4B erörtert) oder einen Codeabrufzugriff umfasst. Ein Codeabrufzugriff kann ein Teil eines Abruf-Ausführungs-Zyklus sein, in dem der Prozessor 112 einen Programmbefehl aus dem Speicher 130 abrufen kann. Wenn der Speicher-Controller 120 eine Speichertransaktion detektiert, kann der Speicher-Controller die Anforderungsschlüssel-ID aus den Bits in der physischen Speicheradresse, die zum Codieren der Anforderungsschlüssel-ID verwendet wird, extrahieren. Der Komparator 320 kann dann durch Vergleichen der Schlüssel-ID-Aufteilungskennung mit der Anforderungsschlüssel-ID bestimmen, dass die Anforderungsschlüssel-ID eine nicht beschränkte Schlüssel-ID ist. Beispielsweise kann in einer Implementierung die Schlüssel-ID-Aufteilungskennung eine Aufteilungsschlüssel-ID sein, die verwendet wird, um eine Grenze zwischen nicht beschränkten Schlüssel-IDs und beschränkten Schlüssel-IDs zu identifizieren. In einer weiteren Implementierung kann die Aufteilungskennung die Anzahl der beschränkten Bits der physischen Speicheradresse sein. Der Komparator 320 kann die Bestimmung, dass die Anforderungsschlüssel-ID innerhalb der nicht beschränkten Schlüssel-IDs liegt, an das UND-Gatter 330 ausgeben. Das erste UND-Gatter 330 kann als seine zweite Eingabe eine Angabe von einem oder mehreren Hardware-Registern 116 empfangen, dass ein der Speicheranforderung zugeordneter logischer Prozessor in einem TD-Modus ausgeführt wird. Beispielsweise kann in einer Implementierung derselbe logische Prozessor der TD 150A und einer der außerhalb der TD-Infrastruktur ausgeführten VMs 155 zugewiesen werden. In einer weiteren Implementierung kann ein der TD 150A zugeordneter logischer Prozessor zwei Betriebsmodi aufweisen. Wenn der TDRM 142 einen TD-Eintrittsbefehl auf dem zugewiesenen logischen Prozessor ausführt, kann der logische Prozessor eine Ausführung in einem Modus für vertrauenswürdige Domänen beginnen und auf Speicherseiten zugreifen, die mit dem der TD 150A zugewiesenen beschränkten Schlüssel verschlüsselt sind. Wenn der TDRM 142 einen TD-Austrittsbefehl ausführt, kann der logische Prozessor die Ausführung der TD 150A unterbrechen, den aktuellen Ausführungsstatus der TD 150A mit der der TD 150A zugewiesenen beschränkten Schlüssel-ID verschlüsseln und diesen Ausführungsstatus in dem Speicher 130 speichern. Anschließend und bis zum nächsten TD-Eintrittsbefehl kann der logische Prozessor in einer Implementierung im nicht vertrauenswürdigen Modus außerhalb der TCB der TD 150A arbeiten und Befehle von dem TDRM 142 oder Hypervisor 140 ausführen. Im nicht vertrauenswürdigen Modus kann der logische Prozessor möglicherweise nicht auf Speicherseiten zugreifen, die mit dem der TD 150A zugewiesenen Schlüssel verschlüsselt sind.
  • An dem ersten UND-Gatter 330 kann der Prozessorkern 114 durch Zugreifen auf die Hardware-Register 116 bestätigen, dass der logische Prozessor eine Speichertransaktion ausführt, während er sich in einem Modus für vertrauenswürdige Domänen befindet. Die Ausgabe des ersten UND-Gatters 330 kann dann zusammen mit der Ausgabe des ODER-Gatters 310 in das zweite UND-Gatter 340 eingegeben werden, um eine endgültige Ausgabe zu erzeugen, die einen Fehler nicht beschränkter Schlüssel signalisieren kann. Der Fehler nicht beschränkter Schlüssel kann von dem Prozessorkern 114 (oder einem der logischen Prozessoren) gemäß einer Fehlerprozedur behandelt werden. In einigen Implementierungen ist der Fehler nicht beschränkter Schlüssel analog zu einem Befehlssatzarchitekturfehler (ISA-Fehler) wie beispielsweise einem Seitenfehler reserviertes Bit. In einigen Implementierungen kann der Speicher-Controller 120 eine stille Seitenabbruchsemantik ausführen, wie es oben erläutert ist.
  • In der zweiten Situation kann ein Speicher-Controller eine Speichertransaktion detektieren, die auf eine physische Seite des Speichers gerichtet ist, die der TD 150A zugewiesen ist und mit einem ersten beschränkten Schlüssel, der der TD 150A zugewiesen ist, verschlüsselt ist (oder voraussichtlich verschlüsselt wird - im Fall von Schreibvorgängen). Die Speichertransaktion kann eine physische Speicheradresse der physischen Seite des Speichers und eine zweite beschränkte Schlüssel-ID, die einer anderen TD wie der TD 150B zugewiesen ist, enthalten. Nachdem bestimmt wurde, dass die Speichertransaktion eine mit einem nicht beschränkten Schlüssel verschlüsselte Speicherseite adressiert und eine nicht beschränkte Schlüssel-ID (wenn auch eine falsche Schlüssel-ID) enthält, kann der Speicher-Controller 120 vielleicht keinen Fehler nicht beschränkter Schlüssel erzeugen. Stattdessen kann der Speicher-Controller 120 in einigen Implementierungen auf die MOT zurückgreifen, um zu bestimmen, dass die zweite Schlüssel-ID kein korrektes Attribut der physischen Seite des Speichers ist. Beispielsweise kann der Speicher-Controller 120 die physische Hostadresse (physische Speicheradresse) 282 innerhalb der MOT 126 lokalisieren und bestimmen, dass die der physischen Hostadresse 282 zugeordnete Schlüssel-ID 250 tatsächlich die erste beschränkte Schlüssel-ID und nicht die zweite beschränkte Schlüssel-ID (wie angefordert) ist. Entsprechend kann der Speicher-Controller 120 einen Fehler (z. B. einen Fehler „beschränkter Schlüssel“) als Antwort auf eine Bestimmung erzeugen, dass eine falsche beschränkte Schlüssel-ID verwendet wurde. Der Fehler kann verwendet werden, um das Software-Programm, das die Speichertransaktion initiiert hat, über die Verwendung eines falschen beschränkten Schlüssels zu informieren. In einigen Implementierungen kann der Speicher-Controller 120 ferner detektieren, ob die Speichertransaktion von außerhalb der TCB der TD 150A stammt (z. B. eine Transaktion aus einer der anderen TDs 150 B-C) und eine Seitenabbruchsemantik erzeugen, wie es oben erläutert ist.
  • In der dritten Situation kann ein Speicher-Controller eine Speichertransaktion detektieren, die auf eine physische Seite des Speichers gerichtet und der TD 150A zugeordnet ist, wobei die Speichertransaktion aus einer anderen TD wie der TD 150B stammt und eine Speicheradresse der physischen Seite des Speichers und die erste beschränkte Schlüssel-ID enthält. Nachdem bestimmt wurde, dass die Speichertransaktion eine mit einem nicht beschränkten Schlüssel verschlüsselte Speicherseite adressiert und eine nicht beschränkte Schlüssel-ID enthält, kann der Speicher-Controller 120 vielleicht keinen Fehler nicht beschränkter Schlüssel erzeugen. Nachdem bestimmt wurde, dass die Speichertransaktion eine physische Speicherseite adressiert, die mit dem ersten Schlüssel (z. B. dem richtigen Schlüssel für die Speicherseite) verschlüsselt ist, kann der Speicher-Controller 120 vielleicht ebenfalls keinen Fehler beschränkter Schlüssel erzeugen. Stattdessen kann der Speicher-Controller 120 in einigen Implementierungen bestimmen, dass die Speichertransaktion aus der TD 150B stammt, und auf die KOT zurückgreifen, um zu bestimmen, dass die erste Schlüssel-ID nicht der TD 150B zugewiesen ist. Beispielsweise kann der Speicher-Controller 120 die Schlüssel-ID 250 innerhalb der KOT 124 lokalisieren und bestimmen, dass die Schlüssel-ID 250 der TD 150A zugewiesen ist. Entsprechend kann der Speicher-Controller 120 einen Fehler (z. B. einen Fehler „fremde TD“) als Antwort auf eine Bestimmung erzeugen, dass eine fremde TD versucht hat, eine ihr nicht zugewiesene Schlüssel-ID zu verwenden. Der Fehler fremde TD kann verwendet werden, um das Software-Programm, das die Speichertransaktion initiiert hat, über seinen Versuch zu informieren, eine falsche physische Speicherseite zu adressieren, die keiner TD zugewiesen ist, auf der die Software ausgeführt wird. In einigen Implementierungen kann der Speicher-Controller 120 eine Seitenabbruchsemantik erzeugen, wie es oben erläutert ist.
  • In einigen Implementierungen, in denen virtueller Speicher verwendet wird, kann eine Speichertransaktion eine Transaktion sein, die einen Seitenlauf verwendet. Eine Speichertransaktion kann ein Verweis auf eine lineare Adresse (z. B. eine virtuelle Adresse) sein, die dann durch Paging mit einer physischen Speicheradresse verbunden wird. Beispielsweise kann in solchen Implementierungen, in denen die Architektur einer virtuellen Maschine verwendet wird, eine lineare Adresse eine von dem Hypervisor erzeugte virtuelle Gastadresse (GVA) sein. Eine GVA kann in einigen Implementierungen durch Gastseitentabellen 132 einer physischen Gastadresse (GPA) zugeordnet werden, die selbst eine virtuelle Hostadresse sein kann. Der GPA kann durch die EPT 134 weiter einer physischen Hostadresse (HPA) zugeordnet werden. Die Zuordnung von GPA zu HPA kann dadurch ermöglicht werden, dass der Hypervisor 140 einen Lauf in der EPT durchführt.
  • Hinsichtlich der Architekturen von virtuellem Speicher und virtuellen Maschinen hat eine in einer TD arbeitende Software möglicherweise keinen direkten Zugriff auf HPAs der physischen Speicherseiten, die der TD von dem Speicher-Controller 120 zugewiesen sind. Der Hypervisor kann der TD eine nicht beschränkte Schlüssel-ID zur Verschlüsselung von gemeinsam genutzten Speicherseiten der TD zuweisen. Der Hypervisor kann in einer Implementierung GPAs/Gastseitentabellen 132 für eine gegebene TD erzeugen. In einer weiteren Implementierung kann der TDRM 142 GPAs/Gastseitentabellen 132 für eine gegebene TD erzeugen. In einer weiteren Implementierung kann ein Überwacher virtueller Maschinen, der innerhalb der TD arbeitet, GPAs/Gastseitentabellen 132 für die TD erzeugen.
  • 4A ist ein Blockdiagramm 400, das eine Übersetzung einer virtuellen Gastadresse (GVA) in eine physische Gastadresse (GPA) und der GPA in eine physische Hostadresse (HPA) oder eine physische Speicheradresse gemäß einer Implementierung darstellt. In einer Implementierung muss der Hypervisor 140 möglicherweise eine lineare Adresse (z. B. eine GVA), die von dem Befehl verwendet wird, in eine physische Speicheradresse übersetzen, damit der Hypervisor auf Daten an dieser physischen Adresse zugreifen kann, um einen Befehl im Namen einer virtuellen Maschine zu emulieren.
  • Um diese Übersetzung durchzuführen, muss der Hypervisor 140 möglicherweise zuerst das Paging und die Segmentierung, was ein Untersuchen eines Segmentierungszustands der virtuellen Maschine umfasst. Die virtuelle Maschine wird möglicherweise innerhalb eines TD ausgeführt. Der Hypervisor kann auch einen Paging-Modus der virtuellen Maschine zu der Zeit des Befehlsaufrufs bestimmen, was ein Untersuchen von von der virtuellen Maschine eingerichteten Seitentabellen und ein Untersuchen der von dem Hypervisor 140 programmierten Hardware-Register 116 (z. B. Steuerregister und MSRs) umfasst. Bei Entdeckung von Paging- und Segmentierungsmodi kann der Hypervisor eine GVA für eine logische Adresse erzeugen und Segmentierungsfehler erkennen.
  • Unter der Annahme, dass keine Segmentierungsfehler detektiert werden, kann der Hypervisor die GVA in eine GPA und die GPA in eine HPA übersetzen, was ein Durchführen eines Seitentabellenlaufs in Software umfasst. Um diese Übersetzungen in Software durchzuführen, kann der Hypervisor eine Anzahl von Paging-Struktureinträgen und EPT-Einträgen, die ursprünglich von der virtuellen Maschine eingerichtet wurden, in Allzweck-Hardware-Register oder Speicher laden. Sobald diese Paging- und EPT-Einträge geladen sind, kann der Hypervisor die Übersetzungen durchführen, indem er Übersetzungsschaltungen wie einen Page-Fehltreffer-Behandler (PMH) modelliert.
  • Insbesondere kann der Hypervisor 140 unter Bezugnahme auf 4A mehrere Gastseitentabelleneinträge 132A aus den Gastseitentabellen 132 und mehrere Einträge erweiterter Seitentabellen 134A aus der EPT 134 laden, die von der virtuellen Maschine eingerichtet wurden. Der Hypervisor kann dann eine Übersetzung durchführen, indem er durch die Gästeseitentabelleneinträge 132A läuft (z. B. sequentiell durchsucht), um aus der GVA eine GPA zu erzeugen. Der Hypervisor kann dann die GPA verwenden, um die EPT 134 zu durchlaufen (z. B. sequentiell zu suchen), um die der GPA zugeordnete HPA zu erzeugen. Die Verwendung der EPT 134 ist eine Funktion, die zur Unterstützung der Virtualisierung des physischen Speichers verwendet werden kann. Wenn EPT verwendet wird, werden bestimmte Adressen, die normalerweise als physische Adressen behandelt werden (und für den Zugriff auf den Speicher verwendet werden), stattdessen als physische Gastadressen behandelt. Physische Gastadressen werden übersetzt, indem eine Menge von EPT-Paging-Strukturen durchlaufen wird, um physische Adressen zu erzeugen, die für den Zugriff auf physischen Speicher verwendet werden.
  • 4B ist ein Blockdiagramm 420, das die Verwendung von EPT zum Übersetzen der GPA in die HPA gemäß einer Implementierung zeigt. Beispielsweise kann die physische Gastadresse (GPA) in eine Reihe von Versätze unterteilt werden, um jeweils innerhalb einer Tabellenstruktur einer Hierarchie der EPT-Einträge 134A zu suchen. In diesem Beispiel enthält die EPT, aus der die EPT-Einträge abgeleitet sind, eine vierstufige hierarchische Tabelle von Einträgen, einschließlich einer Seitenzuordnungsebene-4-Tabelle, einer Seitenverzeichniszeigertabelle, einer Seitenverzeichniseintragstabelle und einer Seitentabelleneintragstabelle. (In anderen Implementierungen kann eine andere Anzahl von Hierarchieebenen innerhalb der EPT existieren und daher sollen die offenbarten Implementierungen nicht durch eine bestimmte Implementierung der EPT beschränkt sein.) Ein Ergebnis jeder Suche auf einer Ebene der EPT-Hierarchie kann dem Versatz für die nächste Tabelle hinzugefügt werden, um ein nächstes Ergebnis der Tabelle der nächsten Ebene in der EPT-Hierarchie zu finden. Das Ergebnis der vierten Tabelle (Seitentabelleneintragstabelle) kann mit einem Seitenversatz kombiniert werden, um eine 4-KB-Seite (beispielsweise) in physischem Speicher zu lokalisieren, wobei es sich um die physische Hostadresse handelt.
  • 4C ist ein Blockdiagramm der Speicheradressauswahl-Hardware 440 zum Zuordnen einer physischen Gastadresse (GPA) zu einer physischen Hostadresse (HPA) unter Verwendung der EPT 134, wenn sowohl die TD- als auch die MK-TME-Architektur gemäß einer Implementierung aktiviert sind. In den Implementierungen, die eine Koexistenz von TDX- und MK-TME-Architektur ermöglichen, können die TD, der TDRM oder der Hypervisor eine von der TD verwendete Speicherseite entweder als gemeinsam genutzt oder privat identifizieren, indem ein s-Bit in den GPAs der Gastseitentabellen 132 gesetzt wird, wie es in 4C gezeigt ist. Das s-Bit darf nicht als Teil einer tatsächlichen Adresse verwendet werden, sondern dient stattdessen als Status-Etikett (gemeinsam genutzt/privat) für die Speicherseite. Ein s-Bit in der GPA mit einem Wert von eins („1“) kann die GPA als privat für die TD festlegen. Umgekehrt kann ein s-Bit der GPA mit dem Wert eins die GPA als von der TD gemeinsam genutzt festlegen. (In einer weiteren Implementierung können die Werte vertauscht sein, wobei der Wert null („0“) die GPA als privat festlegt und eins („1“) die GPA als gemeinsam genutzt festlegt.) Das s-Bit in der GPA kann in einer Implementierung auch in der zugehörigen GVA repliziert werden. In anderen Implementierungen enthält die GVA möglicherweise das s-Bit nicht. Stattdessen können die Informationen über den Status der Speicherseite in Gastseitentabellen 132 gespeichert und an die GPA angehängt werden, auf die während eines Seitenlaufs zugegriffen werden kann.
  • Der Hypervisor kann der TD 150A eine erste beschränkte Schlüssel-ID zuweisen. Der Hypervisor 140 kann derselben TD 150A auch eine zweite nicht beschränkte Schlüssel-ID zuweisen. Die TD kann den Kryptographieschlüssel, der der ersten (beschränkten, TDX-) Schlüssel-ID zugeordnet ist, verwenden, um private Speichertransaktionen zu ver-/entschlüsseln. Die erste TD kann den Kryptographieschlüssel, der dem zweiten (nicht beschränkten MK-TME-) Schlüssel zugeordnet ist, verwenden, um gemeinsam genutzte Speichertransaktionen zu ver-/entschlüsseln, z. B. Speichertransaktionen, die gemeinsam genutzten Hardware-Vorrichtungen zugeordnet sind.
  • Der Hypervisor 140 kann eine physische Seite, die einer physischen Speicheradresse (z. B. einer HPA) des Speichers zugeordnet ist, innerhalb einer Menge von Gastseitentabellen 132 für die TD mit einem Wert eines gemeinsam genutzten Bits (s-Bits) in einem Eintrag für eine virtuelle Gastadresse (z. B. eine GVA), die der physischen Seite zugeordnet ist, als privat oder gemeinsam genutzt markieren. Auf die GVA kann in den Seitentabellen 132 verwiesen werden, um sie der GPA zuzuordnen, und auf die GPA kann in der EPT 134 verwiesen werden, um sie der HPA der physischen Seite des Speichers zuzuordnen. Der Hypervisor kann unter Verwendung der Menge von Gastseitentabellen 132 die GVA in die GPA übersetzen, wobei die nach der Übersetzung erhaltene GPA auch das s-Bit mit dem gleichen Wert wie in der GVA enthält.
  • Wie es in 4C gezeigt ist, kann der Hypervisor 140 in einer Implementierung unter Verwendung der EPT 134 die GPA in die physische Speicheradresse HPA übersetzen. Der Hypervisor kann in einer Implementierung den Wert des s-Bits als gesetzt bestimmen (d. h. die Speicherseite wird gemeinsam genutzt) und folglich eine Speichertransaktion erzeugen, die die zweite (nicht beschränkte MK-TME-) Schlüssel-ID und die physische Hostspeicheradresse HPA enthält. Der Hypervisor kann den Wert des s-Bits als gelöscht bestimmen (d. h. die Speicherseite ist privat) und die erste (beschränkte) Schlüssel-ID aus einem sicheren Speicher des Prozessors 112 (z. B. dem Hardware-Register 116 oder Cache 118) abrufen. Der Hypervisor kann dann in einer Implementierung eine Speichertransaktion erzeugen, die die erste Schlüssel-ID und die physische Speicheradresse HPA enthält.
  • In einer Implementierung kann ein Multiplexer 450 verwendet werden, um basierend auf dem Wert des s-Bits zwischen der ersten Schlüssel-ID und einer zweiten Schlüssel-ID zu wählen, wobei die zweite Schlüssel-ID eine nicht beschränkte Schlüssel-ID umfasst und an die zweite physische Speicheradresse innerhalb eines Eintrags der EPT angehängt ist. Die erste Schlüssel-ID aus dem Hardwareregister 116 oder dem Cache 118 (1A) und die zweite Schlüssel-ID aus dem Hypervisor können in den Multiplexer 450 eingegeben werden, wobei der Wert des s-Bits der Steuerparameter ist. In einer Implementierung kann der Multiplexer 450 als Teil der Hardware des Prozessors 112 implementiert sein, wie beispielsweise als Teil des Speicher-Controllers 120 oder der MK-TME-Maschine 136.
  • In einigen Implementierungen wird die MK-TME-Schlüssel-ID an die ersten M Adressbits angehängt, wobei die ersten M-L beschränkten Bits einen Wert von null haben. In anderen Implementierungen, die andere Schlüssel-ID-Aufteilungen verwenden können, kann der MK-TME-Schlüssel in der Weise angehängt werden, die mit den Besonderheiten der verwendeten Schlüssel-ID-Aufteilung konsistent ist.
  • Der Hypervisor 140, der einen Durchlauf in der EPT 134 durchführt, kann bestimmen, dass die einer angeforderten Speichertransaktion zugeordnete Schlüssel-ID eine der TDX-Schlüssel-IDs ist. In einer Implementierung kann der Hypervisor dies bestimmen, indem er detektiert, dass eines der ersten M-L beschränkten Bits gesetzt ist. Der Hypervisor 140 kann dann versuchen, auf die physische Seite des Speichers zuzugreifen. Der Speicher-Controller 120 kann einen solchen Zugriff unterbrechen, wenn bestimmt wird, dass nicht vertrauenswürdige Software (z. B. der Hypervisor) versucht, eine Speichertransaktion mit einer beschränkten Schlüssel-ID auszuführen.
  • Wenn das s-Bit in der GPA gelöscht ist (wobei eine private Seite möglicherweise eine geheime Seite angibt), ist die Speichertransaktionsschlüssel-ID eine der TDX-Schlüssel-IDs, die der TD bei der TD-Erstellung zugewiesen wurden. Wie es oben unter Bezugnahme auf 2A-2E erläutert wurde, ist garantiert, dass eine solche Schlüssel-ID in dem Bereich der beschränkten Schlüssel-IDs liegt. Daher werden die privaten Seiten der TD mit einem privaten TD-Kryptographieschlüssel verschlüsselt, der der der TD zugewiesenen TDX-Schlüssel-ID zugeordnet ist. Wenn detektiert wird, dass das s-Bit in GPA gelöscht ist, und nachdem von der GVA auf die HPA abgebildet wurde, kann der Hypervisor 140 eine Speichertransaktion erzeugen, die die beschränkte TDX-Schlüssel-ID und die physische Hostspeicheradresse enthält.
  • Unter erneuter Bezugnahme auf 3 kann ein Seitenfehler nicht beschränkter Schlüssel ebenfalls von der Gate-Architektur 300 erzeugt werden, wenn der Prozessor 112 in einem Vertrauensdomänenmodus detektiert, dass ein Seitentabellendurchlauf - z. B. ein Durchlauf der Gastseitentabellen 132 oder der EPT 134 - mit einer nicht beschränkten Schlüssel-ID vorgenommen wird. Das ODER-Gatter 310 kann von dem Speicher-Controller 120 eine Angabe empfangen, dass die physische Speicheradresse HPA von einer Speichertransaktion erhalten wird, die einen Seitenlauf verwendet, d. h. einer Transaktion, die die Gastseitentabellen 132 und die EPT 134 zur Adressübersetzung verwendet. Wenn der Komparator 320 verifiziert, dass die Anforderungsschlüssel-ID zu dem nicht beschränkten Bereich von Schlüssel-IDs gehört, und das erste UND-Gatter 330 ferner detektiert, dass der Prozessor 112 in dem TD-Modus arbeitet, wird die Ausgabe des zweiten UND-Gatters 340 dementsprechend ein Fehler nicht beschränkte Seite sein. Der hier beschriebene Mechanismus stellt sicher, dass in einer Implementierung in dem TD-Modus nur Seitentabellen verwendet werden können, die mit beschränkten TDX-Schlüsseln verschlüsselt sind. Eine andere Implementierung dieses Mechanismus kann den beschränkten Schlüssel-ID-Bereich noch weiter aufteilen, beispielsweise durch Zuweisen einer bestimmten beschränkten Schlüssel-ID für Code, eine separate beschränkte Schlüssel-ID für Seitentabellen und eine andere Schlüssel-ID für den allgemeinen privaten Speicher, der der TD zugewiesen ist. Andere Implementierungen dieses Mechanismus können unter diesen Bedingungen andere Architekturfehler erzeugen, z. B. einen allgemeinen Schutzfehler (#GP-Fehler).
  • 5 zeigt ein beispielhaftes Verfahren zum Ermöglichen einer Koexistenz von TDX- und MK-TME-Architektur auf derselben Rechenvorrichtung, wie beispielsweise einem System 100, das virtuelle Maschinen unterstützt, oder einem Rechensystem 101 ohne Virtualisierung, wobei erneut auf 1A und 1C Bezug genommen wird. Das Verfahren 500 kann durch Verarbeiten von Logik ausgeführt werden, die Hardware (z. B. Schaltungen, dedizierte Logik, programmierbare Logik, Mikrocode usw.), Software (wie etwa Operationen, die von dem TDRM oder VMM ausgeführt werden), Firmware oder eine Kombination davon umfassen kann. In einer Implementierung wird das Verfahren 500 von dem Prozessor 112 von 1 ausgeführt. In einer weiteren Implementierung wird das Verfahren 500 von einer beliebigen der Verarbeitungsvorrichtungen ausgeführt, die in Bezug auf 7A-13 beschrieben sind. Alternativ können andere Komponenten des Systems 100 (oder Software, die auf dem Prozessor 112 ausgeführt wird) einige oder alle Operationen des Verfahrens 500 ausführen.
  • Unter weiterer Bezugnahme auf 5 kann das Verfahren 500 mit der Verarbeitungslogik beginnen, die einen ersten Wert für eine erste Anzahl von Adressbits von physischen Speicheradressen speichert, die für Schlüssel-IDs in einem Hardware-Register verwendet werden, z. B. in einem der Hardwareregister 116 (1A) (510). In einer Implementierung sind die Schlüssel-IDs Kryptographieschlüsseln zugeordnet. In einer Implementierung kann die erste Anzahl von Adressbits die Gesamtzahl von Adressbits M sein, wie es oben erläutert ist.
  • Das Verfahren 500 kann mit der Verarbeitungslogik fortfahren, die in dem Hardware-Register eine Aufteilungskennung zum Aufteilen von Schlüssel-IDs in nicht beschränkte Schlüssel-IDs und beschränkte Schlüssel-IDs speichert (520). Die Aufteilungskennung kann eine Aufteilungsschlüssel-ID sein, die verwendet wird, um eine Grenze zwischen nicht beschränkten Schlüssel-IDs und beschränkten Schlüssel-IDs zu identifizieren. In einigen Implementierungen kann die Aufteilungskennung eine Anzahl von beschränkten Bits M-L enthalten und ferner die Position der beschränkten Bits enthalten. In einer Implementierung sind die beschränkten Bits die oberen M-L-Bits der gesamten M Bits, die für die Schlüssel-ID-Codierung verwendet werden. In einer weiteren Implementierung sind die beschränkten Bits nicht zusammenhängend. In einer weiteren Implementierung gibt es nur ein beschränktes Bit, das das niedrigste der M Bits sein kann.
  • Das Verfahren 500 kann mit der Verarbeitungslogik fortfahren, die einen Hypervisor (530) ausführt. Der Hypervisor kann ein Softwareprogramm sein, das von dem Betriebssystem des Hostrechensystems unterstützt wird und wiederum die Umgebung für virtuelle Maschinen ermöglicht. Das Verfahren 500 kann mit der Verarbeitungslogik fortfahren, die die nicht beschränkten Schlüssel-IDs dem Hypervisor 140 zuweist. Die nicht beschränkten Schlüssel-IDs können den Kryptographieschlüsseln entsprechen, die von der MK-TME-Maschine 136 des Prozessors 112 aktiviert und von dem Hypervisor 140 zum Verschlüsseln von Daten, die sich auf den physischen Speicherseiten befinden, die dem Hypervisor zugewiesen sind, verwendet werden und von dem Hypervisor zum Ausführen von VMs 155, die außerhalb von TDs ausgeführt werden, verwendet werden.
  • Das Verfahren 500 kann mit der Verarbeitungslogik fortfahren, die einer ersten TD einer TD-Infrastruktur eine erste Schlüssel-ID zuweist, wobei die erste Schlüssel-ID eine der beschränkten Schlüssel-IDs ist (550). Das Verfahren 500 kann mit dem Zuweisen einer ersten physischen Seite des Speichers 130 zu der ersten TD fortfahren, wobei Daten auf der ersten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der ersten Schlüssel-ID zugeordnet ist.
  • 6 zeigt ein beispielhaftes Verfahren zum Ermöglichen einer Koexistenz von TD- und MK-TME-Technologie, die ferner ein Speicher-Paging ermöglicht. Das Verfahren 600 kann durch Verarbeitungslogik ausgeführt werden, die Hardware (z. B. Schaltungen, dedizierte Logik, programmierbare Logik, Mikrocode usw.), Software (wie etwa Operationen, die von dem TDRM oder VMM ausgeführt werden), Firmware oder eine Kombination davon umfassen kann. Das Verfahren 600 kann mit der Verarbeitungslogik beginnen, die die oben beschriebenen Schritte 510 bis 560 des Verfahrens 600 ausführt. Beispielsweise kann die Verarbeitungslogik einer TD eine erste Schlüssel-ID zuweisen, wobei die erste Schlüssel-ID eine der beschränkten Schlüssel-IDs ist, ähnlich wie in Schritt 550 des Verfahrens 500. Andere Schritte des Verfahrens 500 werden in 6 um der Kürze halber nicht explizit wiederholt, kann aber davon ausgegangen werden, dass sie auch innerhalb des Verfahrens 600 von 6 implementiert werden.
  • Das Verfahren 600 kann mit der Verarbeitungslogik fortfahren, die beispielsweise durch den Hypervisor 140 der ersten TD eine zweite Schlüssel-ID zuweist, wobei die zweite Schlüssel-ID eine der nicht beschränkten Schlüssel-IDs ist (610). Die erste TD kann den der ersten Schlüssel-ID zugeordneten Kryptographieschlüssel verwenden, um private Speichertransaktionen zu ver-/entschlüsseln. Die erste TD kann den der zweiten Schlüssel-ID zugeordneten Kryptographieschlüssel verwenden, um gemeinsam genutzte Speichertransaktionen zu ver-/entschlüsseln, z. B. Speichertransaktionen, die gemeinsam genutzten Hardware-Vorrichtungen zugeordnet sind.
  • Das Verfahren 600 kann mit der Verarbeitungslogik fortfahren, die eine physische Seite, die einer physischen Speicheradresse (z. B. einer HPA) des Speichers zugeordnet ist, mit dem Wert einer gemeinsam genutzten Bits (s-Bit) in einem Eintrag für eine physische Gastadresse (z. B. einen GPA), die der physischen Seite zugeordnet ist, als privat oder gemeinsam genutzt innerhalb einer Menge von Gastseitentabellen für die TD markiert (620). Auf die GPA kann in der EPT 134 verwiesen werden, um sie der HPA der physischen Seite des Speichers zuzuordnen. Das Markieren mit dem s-Bit-Wert kann ein Setzen des s-Bit-Werts auf 0 umfassen, um die physische Seite als privat festzulegen, und ein Setzen des s-Bit-Werts auf 1 umfassen, um die physische Seite als gemeinsam genutzt festzulegen. In einer weiteren Implementierung können die beiden Werte die entgegengesetzten Festlegungen implementieren.
  • Das Verfahren 600 kann mit der Verarbeitungslogik fortfahren, die unter Verwendung der Menge von Gastseitentabellen die GVA in die GPA übersetzt, wobei die nach der Übersetzung erhaltene GPA auch das s-Bit mit dem gleichen Wert wie in der GVA enthält (630). Das Verfahren 600 kann mit der Verarbeitungslogik fortfahren, die unter Verwendung der EPT 134, die GPA in die physische Speicheradresse HPA übersetzt (640). Das Verfahren 600 kann mit der Verarbeitungslogik fortfahren, die bestimmt, ob der s-Bit-Wert „privat“ (z. B. 0, das Bit ist „gelöscht“) oder „gemeinsam genutzt“ (z. B. 1, das Bit ist „gesetzt“) ist (650). Wenn der s-Bit-Wert zu 0 bestimmt wird (was eine private physische Speicherseite angibt), kann das Verfahren 600 mit der Verarbeitungslogik fortfahren, die die erste (beschränkte) Schlüssel-ID abruft, die der TD zugewiesen ist (660). Beispielsweise kann die Verarbeitungslogik die erste Schlüssel-ID aus der in dem Prozessor 112 gespeicherten MOT 126 abrufen. Alternativ kann die Verarbeitungslogik den ersten Schlüssel aus dem Hypervisor 140 oder dem TDRM 142 abrufen.
  • Das Verfahren 600 kann mit der Verarbeitungslogik fortfahren, die eine Speichertransaktion erzeugt, die in einer Implementierung die erste (beschränkte TDX) Schlüssel-ID und die physische Speicheradresse HPA umfasst (670). Wenn jedoch die Verarbeitungslogik bestimmt, dass der s-Bit-Wert gesetzt ist (was eine gemeinsam genutzte Speicherseite angibt), kann das Verfahren 600 mit der Verarbeitungslogik fortfahren, die eine Speichertransaktion erzeugt, die in einer Implementierung die zweite (nicht beschränkte MK-TME-) Schlüssel-ID und die physische Hostspeicheradresse HPA umfasst (680).
  • 7A ist ein Blockdiagramm, das eine reihenfolgetreue Pipeline und eine nicht reihenfolgetreue Ausgabe-/Ausführungs-Pipeline mit Registerumbenennungsstufe eines Prozessors, der die Leistung einer Verarbeitungsvorrichtung überwacht, um die Koexistenz einer Vertrauensdomänenarchitektur mit Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie bereitzustellen, gemäß mindestens einer Implementierung der Offenbarung darstellt. 7B ist ein Blockdiagramm, das einen reihenfolgetreuen Architekturkern und eine nicht reihenfolgetreue Ausgabe-/Ausführungslogik mit Registerumbenennungslogik darstellt, die in einem Prozessor gemäß mindestens einer Implementierung der Offenbarung enthalten sein sollen. Die mit durchgehenden Linien dargestellten Kästen in 7A zeigen die reihenfolgetreue Pipeline, während die gestrichelten Kästen die nicht reihenfolgetreue Ausgabe-/Ausführungs-Pipeline mit Registerumbenennung darstellen. In ähnlicher Weise sind zeigen die mit durchgehenden Linien dargestellten Kästen in 7B die reihenfolgetreue Architekturlogik, während die gestrichelten Kästen die Registerumbenennungslogik und die nicht reihenfolgetreue Ausgabe-/Ausführungslogik darstellen.
  • In 7A umfasst eine Prozessorpipeline 700 eine Abrufstufe 702, eine Längendecodierstufe 704, eine Decodierstufe 706, eine Zuweisungsstufe 708, eine Umbenennungsstufe 710, eine Planungsstufe (auch als Abfertigungs- oder Ausgabestufe bekannt) 712, eine Registerlese-/Speicherlesestufe 714, eine Ausführungsstufe 716, eine Rückschreib-/Speicherschreibstufe 718, eine Ausnahmebehandlungsstufe 722 und eine Festschreibstufe 724. In einigen Implementierungen sind die Stufen in einer anderen Reihenfolge bereitgestellt und verschiedene Stufen können als reihenfolgetreu und nicht reihenfolgetreu betrachtet werden.
  • In 7B zeigen Pfeile eine Kopplung zwischen zwei oder mehr Einheiten und die Pfeilrichtung gibt eine Richtung des Datenflusses zwischen diesen Einheiten an. 7B zeigt den Prozessorkern (Kern) 790, der eine Frontend-Einheit 730 umfasst, die mit einer Ausführungsmaschineneinheit 750 gekoppelt ist, und beide sind mit einer Speichereinheit 770 gekoppelt.
  • Der Kern 790 kann ein Kern für Berechnungen mit reduziertem Befehlssatz (RISC-Kern), ein Kern für Berechnungen mit komplexem Befehlssatz (CISC-Kern), ein Kern mit sehr langem Befehlswort (VLIW-Kern) oder ein hybrider oder alternativer Kerntyp sein. Als noch eine weitere Option kann der Kern 790 ein Spezialkern wie etwa ein Netz- oder Kommunikationskern, eine Kompressionsmaschine, ein Grafikkern oder dergleichen sein.
  • Die Frontend-Einheit 730 umfasst eine Verzweigungsvorhersageeinheit 732, die mit einer Befehls-Cacheeinheit 734 gekoppelt ist, die mit einem Befehlsübersetzungsnachschlagepuffer (TLB) 736 gekoppelt ist, der mit einer Befehlsabrufeinheit 738 gekoppelt ist, die mit einer Decodiereinheit 740 gekoppelt ist. Die Decodiereinheit bzw. der Decodierer kann Befehle decodieren und als eine Ausgabe eine oder mehrere Mikrooperationen, Mikrocode-Eintrittspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale, die aus den ursprünglichen Befehlen decodiert werden oder diese reflektieren oder von diesen abgeleitet sind, erzeugen. Die Decodiereinheit kann unter Verwendung verschiedener unterschiedlicher Mechanismen implementiert werden. Beispiele für geeignete Mechanismen umfassen, sind aber nicht beschränkt auf, Nachschlagetabellen, Hardware-Implementierungen, programmierbare Logikanordnungen (PLAs), Mikrocode-Nur-Lese-Speicher (ROMs) usw. Die Befehls-Cache-Einheit 734 ist ferner mit einer Ebene-2-Cache-Einheit (L2-Cache-Einheit) 776 in der Speichereinheit 770 gekoppelt. Die Decodiereinheit 740 ist mit einer Umbenennungs-/Zuweisungseinheit 752 in der Ausführungsmaschineneinheit 750 gekoppelt.
  • Die Ausführungsmaschineneinheit 750 umfasst die Umbenennungs-/Zuweisungseinheit 752, die mit einer Stilllegungseinheit 754 und einem Satz von einer oder mehreren Scheduler-Einheiten 756 gekoppelt ist. Die eine oder die mehreren Scheduler-Einheiten 756 repräsentieren eine beliebige Anzahl verschiedener Scheduler, einschließlich Reservierungsstationen, eines zentralen Befehlsfensters usw. Die eine oder die mehreren Scheduler-Einheiten 756 sind mit der einen oder den mehreren physischen Registersatzeinheiten 758 gekoppelt. Jede der einen oder der mehreren physischen Registersatzeinheiten 758 stellt einen oder mehrere physische Registersätze dar, von denen verschiedene einen oder mehrere unterschiedliche Datentypen speichern, wie z. B. skalare Ganzzahl, skalare Gleitkommazahl, gepackte Ganzzahl, gepackte Gleitkommazahl, Vektor-Ganzzahl, Vektor-Gleitkomma, usw., Status (z. B. einen Befehlszeiger, der die Adresse des nächsten auszuführenden Befehls ist) usw. Die eine oder die mehreren physischen Registersatzeinheiten 758 werden von der Stilllegungseinheit 754 überlappt, um verschiedene Arten zu veranschaulichen, in denen Registerumbenennung und nicht reihenfolgetreue Ausführung implementiert sein können (z. B. unter Verwendung eines oder mehrerer Umordnungspuffer und eines oder mehrerer Stilllegungsregistersätze, unter Verwendung einer oder mehrerer Zukunftsdateien, unter Verwendung eines oder mehrerer Verlaufspuffer und eines oder mehrerer Stilllegungsregistersätze; unter Verwendung einer Registerkarte und eines Pools von Registern; etc.).
  • Im Allgemeinen sind die Architekturregister von außerhalb des Prozessors oder aus Sicht eines Programmierers sichtbar. Die Register sind nicht auf einen bestimmten bekannten Schaltungstyp beschränkt. Zahlreiche verschiedene Registertypen sind geeignet, solange sie wie hier beschrieben Daten speichern und bereitstellen können. Beispiele für geeignete Register umfassen, ohne darauf beschränkt zu sein, dedizierte physische Register, dynamisch zugewiesene physische Register unter Verwendung von Registerumbenennung, Kombinationen von dedizierten und dynamisch zugewiesenen physischen Registern usw. Die Stilllegungseinheit 754 und die eine oder die mehreren physischen Registersatzeinheiten 758 sind mit dem einen oder den mehreren Ausführungsclustern 760 gekoppelt. Der eine oder die mehreren Ausführungscluster 760 umfassen einen Satz von einer oder mehreren Ausführungseinheiten 762 und einen Satz von einer oder mehreren Speicherzugriffseinheiten 764. Die Ausführungseinheiten 762 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) durchführen und arbeiten mit verschiedenen Arten von Daten (z. B. skalare Gleitkommazahl, gepackte Ganzzahl, gepackte Gleitkommazahl, Vektor-Ganzzahl, Vektor-Gleitkommazahl) .
  • Obwohl einige Ausführungsformen eine Anzahl von Ausführungseinheiten enthalten können, die bestimmten Funktionen oder Mengen von Funktionen zugeordnet sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten enthalten, die alle jeweils alle Funktionen ausführen. Die eine oder die mehreren Scheduler-Einheiten 756, die eine oder die mehreren physischen Registersatzeinheiten 758 und die Ausführungscluster 760 sind optional mehrfach dargestellt, da bestimmte Ausführungsformen separate Pipelines für bestimmte Arten von Daten/Operationen erzeugen (z. B. eine Pipeline für skalare Ganzzahlen, ein Pipeline für skalare Gleitkommazahl/gepackte Ganzzahl/gepackte Gleitkommazahl/Vektor-Ganzzahl/Vektor Gleitkommazahl und/oder eine SpeicherzugriffsPipeline, die jeweils ihre eigene Scheduler-Einheit, physische Registersatzeinheit und/oder ihren eigenen Ausführungscluster haben - und im Falle einer separaten Speicherzugriffspipeline sind bestimmte Ausführungsformen implementiert, bei denen nur der Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 764 aufweist). Es sollte auch verstanden werden, dass dann, wenn separate Pipelines verwendet werden, eine oder mehrere dieser Pipelines nicht reihenfolgetreuer Ausgabe/Ausführung dienen können und der Rest reihenfolgetreu sein kann.
  • Der Satz von Speicherzugriffseinheiten 764 ist mit der Speichereinheit 770 gekoppelt, die eine Daten-TLB-Einheit 772 umfasst, die mit einer Daten-Cacheeinheit 774 gekoppelt ist, die mit einer Ebene-2-Cache-Einheit (L2-Cache-Einheit) 776 gekoppelt ist. In einer beispielhaften Implementierung können die Speicherzugriffseinheiten 764, eine Ladeeinheit, eine Speicheradresseinheit und eine Speicherdateneinheit umfassen, die jeweils mit der Daten-TLB-Einheit 772 in der Speichereinheit 770 gekoppelt sind. Die L2-Cacheeinheit 776 ist mit einer oder mehreren anderen Cache-Ebenen und schließlich mit einem Hauptspeicher gekoppelt.
  • Beispielsweise kann die beispielhafte Kernarchitektur mit Registerumbenennung und nicht reihenfolgetreuer Ausgabe/Ausführung die Pipeline 700 von 7A wie folgt implementieren: 1) die Befehlsabrufeinheit 38 führt die Abruf- und Längendecodierstufen 702 und 704 durch; 2) die Decodiereinheit 740 führt die Decodierstufe 706 durch; 3) die Umbenennungs-/Zuweisungseinheit 752 führt die Zuweisungsstufe 708 und die Umbenennungsstufe 710 durch; 4) die eine oder die mehreren Scheduler-Einheiten 756 führen die Planungsstufe 712 durch; 5) die eine oder die mehreren physische Registersatzeinheiten 758 und die Speichereinheit 770 führen die Registerlese-/Speicherlesestufe 714 durch; der Ausführungscluster 760 führt die Ausführungsstufe 716 aus; 6) die Speichereinheit 770 und die eine oder die mehreren physische Registersatzeinheiten 758 führen die Rückschreib-/Speicherschreibstufe 718 durch; 7) verschiedene Einheiten können an der Ausnahmebehandlungsstufe 722 beteiligt sein; die Stilllegungseinheit 754 und die eine oder die mehreren physische Registersatzeinheiten 758 führen die Festschreibstufe 724 durch.
  • Der Kern 790 kann einen oder mehrere Befehlssätze unterstützen (z. B. den x86-Befehlssatz (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden), den MIPS-Befehlssatz von MIPS Technologies aus Sunnyvale, Kalifornien, den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie NEON) von ARM Holdings aus Sunnyvale, Kalifornien).
  • Es sollte verstanden werden, dass der Kern Mehrsträngigkeit (ein Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Strängen) unterstützen kann und dies auf eine Vielzahl von Arten tun kann, einschließlich zeitlich aufgeteilter Mehrsträngigkeit, simultaner Mehrsträngigkeit (bei der ein einzelner physischer Kern einen logischen Kern für jeden der Stränge liefert, für die der physische Kern simultane Mehrsträngigkeit bietet) oder einer Kombination davon (z. B. zeitlich aufgeteiltes Abrufen und Decodieren und simultane Mehrsträngigkeit danach, wie bei der Intel®-Hyperthreading-Technologie).
  • Obwohl die Registerumbenennung im Zusammenhang mit der nicht reihenfolgetreuen Ausführung beschrieben ist, sollte verstanden werden, dass die Registerumbenennung in einer reihenfolgetreuen Architektur verwendet werden kann. Obwohl die veranschaulichte Ausführungsform des Prozessors auch eine separate Befehls- und Daten-Cacheeinheit 734/774 und eine gemeinsame L2-Cache-Einheit 776 enthält, können alternative Ausführungsformen einen einzelnen internen Cache sowohl für Befehle als auch Daten aufweisen, wie etwa einen internen Cache erster Ebene (L1-Cache) oder mehrere Ebenen internen Caches. In einigen Ausführungsformen kann das System eine Kombination aus einem internen Cache und einem externen Cache, der sich außerhalb des Kerns und/oder des Prozessors befindet, umfassen. Alternativ kann sich der gesamte Cache außerhalb des Kerns und/oder des Prozessors befinden.
  • 8 zeigt ein Blockdiagramm der Mikroarchitektur für eine Verarbeitungsvorrichtung 800, die Logikschaltungen aufweist, um die Koexistenz einer Vertrauensdomänenarchitektur mit einer Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie gemäß mindestens einer Implementierung der Offenbarung bereitzustellen. In einigen Implementierungen kann ein Befehl implementiert werden, um Datenelemente mit Byte-, Wort-, Doppelwort-, Vierwort-Größen usw. sowie Datentypen wie Ganzzahl- und Gleitkomma-Datentypen mit einfacher und doppelter Genauigkeit zu bearbeiten. In einer Implementierung ist das reihenfolgetreue Frontend 801 der Teil der Verarbeitungsvorrichtung 800, der die auszuführenden Befehle abruft und sie für die spätere Verwendung in der Verarbeitungsvorrichtungspipeline vorbereitet. Die Implementierungen des Bereitstellens der Koexistenz einer Vertrauensdomänenarchitektur mit einer Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie können in der Verarbeitungsvorrichtung 800 implementiert werden.
  • Das Frontend 801 kann mehrere Einheiten aufweisen. In einer Implementierung ruft der Befehlsvorabrufer 826 Befehle aus dem Speicher ab und führt sie einem Befehlsdecodierer 828 zu, der sie wiederum decodiert oder interpretiert. Zum Beispiel decodiert der Decodierer in einer Implementierung einen empfangenen Befehl in eine oder mehrere Operationen, die als „Mikrobefehle“ oder „Mikrooperationen“ (auch Mikro-Op oder uops genannt) bezeichnet werden, die die Maschine ausführen kann. In anderen Implementierungen parst der Decodierer den Befehl in einen Opcode und entsprechende Daten und Steuerfelder, die von der Mikroarchitektur verwendet werden, um Operationen gemäß einer Implementierung durchzuführen. In einer Ausführungsform nimmt der Spur-Cache 830 decodierte uops und setzt sie zur Ausführung in programmgesteuerte Sequenzen oder Spuren in der uop-Warteschlange 834 zusammen. Wenn der Spur-Cache 830 auf einen komplexen Befehl trifft, stellt der Mikrocode-ROM 832 die zum Abschließen der Operation erforderlichen uops bereit.
  • Einige Befehle werden in eine einzelne Mikrooperation umgewandelt, während andere mehrere Mikrooperationen benötigen, um die vollständige Operation abzuschließen. Wenn in einer Implementierung mehr als vier Mikrobefehle benötigt werden, um einen Befehl abzuschließen, greift der Decodierer 818 auf den Mikrocode-ROM 832 zu, um den Befehl auszuführen. Bei einer Implementierung kann ein Befehl in eine kleine Anzahl von Mikroops zur Verarbeitung in dem Befehlsdecodierer 828 decodiert werden. In einer weiteren Implementierung kann ein Befehl innerhalb des Mikrocode-ROM 832 gespeichert werden, wenn eine Anzahl von Mikrobefehlen benötigt wird, um die Operation zu erreichen. Der Spur-Cache 830 bezieht sich auf ein programmierbares Eintrittspunkt-Logikarray (PLA), um einen korrekten Mikrobefehlszeiger zum Lesen der Mikrocodesequenzen zum Abschließen eines oder mehrerer Befehle gemäß einer Implementierung aus dem Mikrocode-ROM 832 zu bestimmen. Nachdem der Mikrocode-ROM 832 das Sequenzieren von Mikrobefehlen für einen Befehl abgeschlossen hat, nimmt das Frontend 801 der Maschine das Abrufen von Mikrobefehlen aus dem Spur-Cache 830 wieder auf.
  • Die nicht reihenfolgetreue Ausführungsmaschine 803 ist der Ort, an dem die Befehle zur Ausführung vorbereitet werden. Die nicht reihenfolgetreue Ausführungslogik weist eine Reihe von Puffern auf, um den Befehlsablauf zu glätten und umzuordnen, um die Leistung zu optimieren, wenn diese die Pipeline durchlaufen und für die Ausführung eingeplant werden. Die Zuweisungslogik weist die Maschinenpuffer und Betriebsmittel zu, die jede uop zur Ausführung benötigt. Die Registerumbenennungslogik 840 benennt logische Register in Einträge in einem Registersatz um. Der Zuweiser 840 weist auch einen Eintrag für jede uop in einer der zwei uop-Warteschlangen, einen für Speicheroperationen 842 und einen für Nicht-Speicheroperationen 844, vor den Befehls-Schedulern zu: Speicher-Scheduler 846, schneller Scheduler 802, langsamer/allgemeiner Gleitkomma-Scheduler 804 und einen einfachen Gleitkomma-Scheduler 806. Die uop-Scheduler 802, 804, 806 bestimmen, wann eine uop zur Ausführung bereit ist, und zwar basierend auf der Bereitschaft ihrer abhängigen Eingaberegisteroperandenquellen und der Verfügbarkeit der Ausführungsbetriebsmittel, die die uops benötigen, um ihre Operation abzuschließen. Der schnelle Scheduler 802 einer Implementierung kann bei jeder Hälfte des Haupttaktzyklus planen, während die anderen Scheduler vielleicht nur einmal pro Hauptprozessortaktzyklus planen. Die Scheduler vermitteln für die Abfertigungs-Ports, um uops für die Ausführung zu planen.
  • Registersätze 808, 810 befinden sich zwischen den Schedulern 802, 804, 806 und den Ausführungseinheiten 812, 814, 816, 818, 820, 822, 824 in dem Ausführungsblock 811. Es gibt einen separaten Registersatz 808, 810, für Ganzzahl- bzw. Gleitkommaoperationen. Jeder Registersatz 808, 810 einer Implementierung enthält auch ein Umgehungsnetz, das gerade fertige Ergebnisse, die noch nicht in den Registersatz geschrieben wurden, an neue abhängige uops umleiten oder weiterleiten kann. Der Ganzzahl-Registersatz 808 und der Gleitkomma-Registersatz 810 können auch Daten miteinander austauschen. Bei einer Implementierung ist der Ganzzahl-Registersatz 808 in zwei getrennte Registersätze aufgeteilt, einen Registersatz für die 32 Bits niedriger Ordnung und einen zweiten Registersatz für die 32 Bits hoher Ordnung von Daten. Der Gleitkomma-Registersatz 810 einer Implementierung weist 128 Bit breite Einträge auf, da Gleitkommabefehle typischerweise Operanden mit einer Breite von 64 bis 128 Bits aufweisen.
  • Der Ausführungsblock 811 enthält die Ausführungseinheiten 812, 814, 816, 818, 820, 822, 824, in denen die Befehle tatsächlich ausgeführt werden. Dieser Abschnitt enthält die Registersätze 808, 810, die die Ganzzahl- und Gleitkomma-Datenoperandenwerte speichern, die die Mikrobefehle zur Ausführung benötigen. Die Verarbeitungsvorrichtung 800 einer Implementierung besteht aus einer Reihe von Ausführungseinheiten:
    • einer Adressengenerierungseinheit (AGU) 812, einer AGU 814, einer schnellen ALU 816, einer schnellen ALU 818, einer langsamen ALU 820, einer Gleitkomma-ALU 822, einer Gleitkomme-Verschiebungseinheit 824.
    • Bei einer Implementierung führen die Gleitkomma-Ausführungsblöcke 812, 814 Gleitkomma-, MMX-, SIMD- und SSE- oder andere Operationen aus. Die Gleitkomma-ALU 812 einer Implementierung enthält einen Gleitkomma-Dividierer mit 64 Bit mal 64 Bit,
    • um Divisions-, Quadratwurzel- und Rest-Mikrooperationen auszuführen. Bei Implementierungen der vorliegenden Offenbarung können Befehle, die einen Gleitkommawert beinhalten, mit der Gleitkomma-Hardware gehandhabt werden.
  • In einer Implementierung gehen die ALU-Operationen zu den Hochgeschwindigkeits-ALU-Ausführungseinheiten 816, 818. Die schnellen ALUs 816, 818 einer Implementierung können schnelle Operationen mit einer effektiven Latenz von einem halben Taktzyklus ausführen. Bei einer Implementierung gehen die meisten komplexen Ganzzahl-Operationen zu der langsamen ALU 820, da die langsame ALU 820 Ganzzahl-Ausführungshardware für Operationen mit langer Latenz enthält, wie z. B. einen Multiplizierer, Verschiebungen, Merkerlogik und Verzweigungsverarbeitung. Speicher-Lade- /Speicheroperationen werden durch die AGUs 812, 814 ausgeführt. Bei einer Implementierung sind die Ganzzahl-ALUs 816, 818, 820 im Zusammenhang mit der Durchführung von Ganzzahloperationen an 64-Bit-Datenoperanden beschrieben. In alternativen Implementierungen können die ALUs 816, 818, 820 implementiert sein, um eine Vielzahl von Datenbits einschließlich 16, 32, 128, 256 usw. zu unterstützen. In ähnlicher Weise können die Gleitkommaeinheiten 822, 824 implementiert sein, um einen Bereich von Operanden mit Bits verschiedener Breite zu unterstützen. Bei einer Implementierung können die Gleitkommaeinheiten 822, 824 mit 128 Bit breiten gepackten Datenoperanden in Verbindung mit SIMD- und Multimedia-Befehlen arbeiten.
  • In einer Implementierung senden die uops-Scheduler 802, 804, 806 abhängige Operationen ab, bevor der übergeordnete Ladevorgang die Ausführung beendet hat. Wenn uops in der Verarbeitungsvorrichtung 800 spekulativ geplant und ausgeführt werden, enthält die Verarbeitungsvorrichtung 800 auch eine Logik zur Behandlung von Speicherverfehlungen. Wenn ein Datenladevorgang in dem Daten-Cache verfehlt, kann es in der Pipeline abhängige Operationen auf dem Weg geben, die den Scheduler mit vorübergehend inkorrekten Daten verlassen haben. Ein Wiederholungsmechanismus verfolgt Befehle, die inkorrekte Daten verwenden, und führt sie erneut aus. Nur die abhängigen Operationen müssen wiederholt werden und die unabhängigen Operationen dürfen abgeschlossen werden. Die Scheduler und der Wiedergabemechanismus einer Implementierung eines Prozessors sind auch dazu ausgelegt, Befehlssequenzen für Textfolgevergleichsoperationen abzufangen.
  • Die Verarbeitungsvorrichtung 800 umfasst auch eine Logik zum Implementieren einer Speicheradressenvorhersage für eine Speicherdisambiguierung gemäß Implementierungen der Offenbarung. In einer Implementierung kann der Ausführungsblock 811 der Verarbeitungsvorrichtung 800 den TDRM 142, die MOT 126 und die TDCS umfassen, um die Koexistenz einer Vertrauensdomänenarchitektur mit einer Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie gemäß der Beschreibung hierin bereitzustellen.
  • Der Ausdruck „Register“ kann sich auf die an Bord befindlichen Prozessorspeicherstellen beziehen, die als Teil von Befehlen zum Identifizieren von Operanden verwendet werden. Mit anderen Worten können Register die sein, die von außerhalb der Verarbeitungsvorrichtung (aus der Perspektive eines Programmierers) verwendbar sind. Die Register einer Implementierung sollen jedoch nicht auf eine bestimmte Art von Schaltung beschränkt sein. Vielmehr kann ein Register einer Implementierung Daten speichern und bereitstellen und die hierin beschriebenen Funktionen ausführen. Die hierin beschriebenen Register können durch Schaltungen innerhalb einer Verarbeitungsvorrichtung unter Verwendung einer beliebigen Anzahl verschiedener Techniken implementiert sein, wie etwa dedizierte physische Register, dynamisch zugewiesene physische Register unter Verwendung von Registerumbenennung, Kombinationen dedizierter und dynamisch zugeordneter physischer Register usw. In einer Implementierung speichern Ganzzahlregister 32-Bit-Ganzzahl-Daten. Ein Registersatz einer Implementierung enthält zudem acht Multimedia-SIMD-Register für gepackte Daten.
  • Für die folgenden Ausführungen werden die Register als Datenregister verstanden, die gepackte Daten enthalten, wie etwa 64-Bit breite MMX™-Register (in einigen Fällen auch als „mm“-Register bezeichnet) in Mikroprozessoren, die mit MMX-Technologie von Intel Corporation aus Santa Clara, Kalifornien, ausgestattet sind. Diese MMX-Register, die sowohl in Ganzzahl- als auch Gleitkomma-Formaten verfügbar sind, können mit gepackten Datenelementen arbeiten, die SIMD- und SSE-Befehle begleiten. In ähnlicher Weise können 128 Bits breite XMM-Register, die sich auf die SSE2-, SSE3-, SSE4-Technologie oder Technologie darüber hinaus (im Allgemeinen als „SSEx“ bezeichnet) beziehen, auch verwendet werden, um solche gepackte Datenoperanden zu halten. In einer Implementierung müssen die Register beim Speichern gepackter Daten und ganzzahliger Daten nicht zwischen den zwei Datentypen unterscheiden. In einer Implementierung sind Ganzzahl- und Fließkomma-Daten entweder in dem gleichen Registersatz oder in verschiedenen Registersätzen enthalten. Weiterhin können in einer Implementierung Gleitkomma- und Ganzzahl-Daten in verschiedenen Registern oder den gleichen Registern gespeichert werden.
  • Implementierungen zum Bereitstellen der Koexistenz der Vertrauensdomänenarchitektur mit der Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie können in vielen verschiedenen Systemtypen implementiert werden. Unter Bezugnahme auf 9 ist ein Blockdiagramm eines Mehrfachverarbeitungsvorrichtungssystems 900 gemäß einer Implementierung gezeigt. Wie es in 9 gezeigt ist, ist das Mehrfachverarbeitungsvorrichtungssystem 900 ein Punkt-zu-Punkt-Zwischenverbindungssystem und umfasst eine erste Verarbeitungsvorrichtung 970 und eine zweite Verarbeitungsvorrichtung 980, die über eine Punkt-zu-Punkt-Zwischenverbindung 950 gekoppelt sind. Wie es in 9 gezeigt ist, können die Verarbeitungsvorrichtungen 970 und 980 jeweils Mehrkern-Verarbeitungsvorrichtungen sein, die einen ersten und zweiten Verarbeitungsvorrichtungskern (nicht gezeigt) umfassen, obwohl möglicherweise viel mehr Kerne in den Verarbeitungsvorrichtungen vorhanden sein können. Die Verarbeitungsvorrichtungen können jeweils Hybrid-Schreibmoduslogiken gemäß einer Implementierung der vorliegenden Offenbarung umfassen. Die Implementierungen zum Bereitstellen der Koexistenz einer Vertrauensdomänenarchitektur mit einer Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie können in der Verarbeitungsvorrichtung 970, der Verarbeitungsvorrichtung 980 oder beiden implementiert werden.
  • Während hier zwei Verarbeitungsvorrichtungen 970, 980 gezeigt sind, versteht es sich, dass der Umfang der Offenbarung nicht darauf beschränkt ist. In anderen Implementierungen können eine oder mehrere zusätzliche Verarbeitungsvorrichtungen in einer gegebenen Verarbeitungsvorrichtung vorhanden sein.
  • Die Prozessoren 970 und 980 sind mit integrierten Speicher-Controller-Einheiten (IMCs) 972 bzw. 982 gezeigt. Die Verarbeitungsvorrichtung 970 umfasst als Teil ihrer Bus-Controller-Einheiten auch Punkt-zu-Punkt-Schnittstellen (P-P-Schnittstellen) 976 und 978; ebenso umfasst die zweite Verarbeitungsvorrichtung 980 P-P-Schnittstellen 986 und 988. Die Verarbeitungsvorrichtungen 970, 980 können Informationen über eine Punkt-zu-Punkt-Schnittstelle (P-P-Schnittstelle) 950 unter Verwendung von P-P-Schnittstellenschaltungen 978, 988 austauschen. Wie es in 9 gezeigt ist, koppeln die IMCs 972 und 982 die Verarbeitungsvorrichtungen mit jeweiligen Speichern, nämlich einem Speicher 932 und einem Speicher 934, die Teile des Hauptspeichers sein können, die lokal an die jeweiligen Verarbeitungsvorrichtungen angeschlossen sind.
  • Die Prozessoren 970, 980 können jeweils Informationen mit einem Chipsatz 990 über einzelne P-P-Schnittstellen 952, 954 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 976, 994, 986, 998 austauschen. Der Chipsatz 990 kann optional über eine Hochleistungs-Grafikschnittstelle 992 Informationen mit einer Hochleistungs-Grafikschaltung 938 austauschen.
  • Ein gemeinsam genutzter Cache (nicht gezeigt) kann in jeder Verarbeitungsvorrichtung enthalten sein oder außerhalb von beiden Verarbeitungsvorrichtungen sein, jedoch über P-P-Zwischenverbindung mit den Prozessoren verbunden sein, so dass lokale Cache-Informationen eines oder beider der Prozessoren in dem gemeinsamen Cache gespeichert werden können, wenn ein Prozessor in einen Niederleistungsmodus versetzt wird.
  • Der Chipsatz 990 kann mit einem ersten Bus 916 über eine Schnittstelle 996 gekoppelt sein. In einer Ausführungsform kann der erste Bus 916 ein Peripheriekomponenten-Zwischenverbindungs-Bus (PCI-Bus) oder ein Bus wie etwa ein PCI-Express-Bus oder ein anderer E/A-Zwischenverbindungsbus dritter Generation sein, auch wenn der Umfang der vorliegenden Erfindung nicht darauf beschränkt ist.
  • Wie es in 9 gezeigt ist, können verschiedene E/A-Vorrichtungen 914 mit dem ersten Bus 916 gemeinsam mit einer Busbrücke 918 gekoppelt sein, die den ersten Bus 916 mit einem zweiten Bus 920 koppelt. In einer Implementierung kann der zweite Bus 920 ein Bus mit geringer Stiftanzahl (LPC-Bus) sein. Verschiedene Vorrichtungen können mit dem zweiten Bus 920 gekoppelt sein, einschließlich beispielsweise einer Tastatur und/oder Maus 922, Kommunikationsvorrichtungen 927 und einer Speichereinheit 928 wie etwa eines Plattenlaufwerks oder einer anderen Massenspeichereinheit, die in einer Implementierung Befehle/Code und Daten 930 enthalten kann. Ferner kann eine Audio-E/A-Vorrichtung 924 mit dem zweiten Bus 920 gekoppelt sein. Es versteht sich, dass andere Architekturen möglich sind. Beispielsweise kann ein System anstelle der Punkt-zu-Punkt-Architektur von 9 einen Multi-Drop-Bus oder eine andere solche Architektur implementieren.
  • Unter Bezugnahme auf 10 ist ein Blockdiagramm eines dritten Systems 1000 gemäß einer Implementierung der Offenbarung gezeigt. Gleiche Elemente in 9 und 10 tragen gleiche Bezugszeichen und bestimmte Aspekte von 9 wurden in 10 weggelassen, um zu vermeiden, dass andere Aspekte von 10 verunklart werden.
  • 10 zeigt die Prozessoren 970, 980. In einer Ausführungsform können die Prozessoren 970, 980 Hybridkerne implementieren. Die Prozessoren 970, 980 können einen integrierten Speicher und eine E/A-Steuerlogik („CL“) 1072 bzw. 1082 umfassen und über eine Punkt-zu-Punkt-Zwischenverbindung 950 zwischen Punkt-zu-Punkt-Schnittstellen (P-P-Schnittstellen) 978 bzw. 988 miteinander kommunizieren. Die Prozessoren 970, 980 kommunizieren jeweils mit dem Chipsatz 990 über Punkt-zu-Punkt-Zwischenverbindungen 952 und 954 über die jeweiligen P-P-Schnittstellen 976 bis 994 und 986 bis 998, wie es gezeigt ist. Bei mindestens einer Implementierung kann die CL 1072, 1082 IMCs 972, 982 umfassen, wie sie hierin beschrieben sind. Zusätzlich kann die CL 1072, 1082 auch eine E/A-Steuerlogik aufweisen. 10 zeigt, dass die Speicher 932, 934 mit der CL 1072, 1082 gekoppelt sind und dass die E/A-Vorrichtungen 1014 auch mit der CL 1072, 1082 gekoppelt sind. Alt-E/A-Vorrichtungen 1015 sind über die Schnittstelle 996 mit dem Chipsatz 990 gekoppelt. Die Implementierungen zum Bereitstellen der Koexistenz einer Vertrauensdomänenarchitektur mit einer Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie können in der Verarbeitungsvorrichtung 970, der Verarbeitungsvorrichtung 980 oder beiden implementiert werden.
  • 11 ist ein beispielhaftes Ein-Chip-System (SoC) 1100, das einen oder mehrere der Kerne 1112A...1112N des Anwendungsprozessors 1110 umfassen kann. Andere auf dem Fachgebiet bekannte Systemgestaltungen und Konfigurationen für Laptops, Desktops, handtragbare PCs, persönliche digitale Assistenten, technische Arbeitsstationen, Server, Netzvorrichtungen, Netz-Hubs, Switches, eingebettete Verarbeitungsvorrichtungen, digitale Signalverarbeitungsvorrichtungen (DSPs), Grafikvorrichtungen, Videospielvorrichtungen, Set-Top-Boxen, Mikrocontroller, Mobiltelefone, tragbare Medienabspieler, handtragbare Vorrichtungen und verschiedene andere elektronische Vorrichtungen sind auch geeignet. Im Allgemeinen ist eine große Vielzahl von Systemen oder elektronischen Vorrichtungen geeignet, die eine Verarbeitungsvorrichtung und/oder eine andere hierin offenbarte Ausführungslogik aufnehmen können.
  • Unter Bezugnahme auf 11 ist ein Blockdiagramm eines SoC 1100 gemäß einer Implementierung der Offenbarung gezeigt. Gestrichelte Kästen sind zudem Merkmale für fortgeschrittenere SoCs. In 11 sind eine oder mehrere Zwischenverbindungseinheiten 1102 gekoppelt mit: dem Anwendungsprozessor 1110, der einen Satz von einem oder mehreren Kernen 1112A-N, die eine oder mehrere Cache-Einheiten 1104A...1104N aufweisen, bzw. eine oder mehrere gemeinsam genutzte Cache-Einheiten 1106 umfasst; einer Systemagenteneinheit 1113; einer oder mehreren Bus-Controller-Einheiten 1116; einer oder mehreren integrierten Speicher-Controller-Einheiten 1114; einem Satz oder einer oder mehreren Medienverarbeitungsvorrichtungen 1120, die eine integrierte Grafiklogik 1108, eine Bildverarbeitungsvorrichtung 1124 zum Bereitstellen von Standbild- und/oder Videokamerafunktionalität, eine Audioverarbeitungsvorrichtung 1126 zum Bereitstellen von Hardware-Audiobeschleunigung und eine Videoverarbeitungsvorrichtung 1128 zum Bereitstellen einer Video-Codierungs- /Decodierungsbeschleunigung umfassen können; einer statischen Direktzugriffsspeichereinheit (SRAM-Einheit) 1130; einer Direktspeicherzugriffseinheit (DMA-Einheit) 1132; und einer Anzeigeeinheit 1140 zum Koppeln mit einer oder mehreren externen Anzeigen. Die Implementierungen zum Bereitstellen der Koexistenz der Vertrauensdomänenarchitektur mit der Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie können in dem SoC 1100 implementiert werden.
  • Unter Bezugnahme auf 12 ist eine Implementierung eines SoC-Entwurfs gemäß Implementierungen der Offenbarung dargestellt. Als veranschaulichendes Beispiel ist das SoC 1200 in dem Anwendergerät (UE) enthalten. In einer Implementierung bezieht sich UE auf eine beliebige Vorrichtung, die von einem Endbenutzer zur Kommunikation verwendet werden soll, wie z. B. ein handtragbares Telefon, ein Smartphone, ein Tablet, ein ultradünnes Notebook, ein Notebook mit Breitbandadapter oder eine andere ähnliches Kommunikationsvorrichtung. Ein UE kann eine Verbindung zu einer Basisstation oder einem Knoten herstellen, die bzw. der einer Mobilstation (MS) in einem GSM-Netz entsprechen kann. Die Implementierungen zum Bereitstellen der Koexistenz der Vertrauensdomänenarchitektur mit der Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie können in dem SoC 1200 implementiert werden.
  • Hier umfasst das SOC 1220 zwei Kerne, 1206 und 1207. Ähnlich wie in der obigen Diskussion können die Kerne 1206 und 1207 einer Befehlssatzarchitektur entsprechen, beispielsweise einem auf Intel® Architecture Core™ basierten Prozessor, einem Prozessor von Advanced Micro Devices, Inc. (AMD), einem MIPS-basierten Prozessor, einem ARM-basierten Prozessor oder einem von deren Kunden sowie deren Lizenznehmern oder Anwendern. Die Kerne 1206 und 1207 sind mit der Cache-Steuerung 1208 gekoppelt, die der Busschnittstelleneinheit 1209 und dem L2-Cache 1210 zugeordnet ist, um mit anderen Teilen des Systems 1200 zu kommunizieren. Die Zwischenverbindung 1211 umfasst eine On-Chip-Zwischenverbindung wie etwa IOSF, AMBA oder eine andere oben diskutierte Zwischenverbindung, die potentiell einen oder mehrere Aspekte der beschriebenen Offenbarung implementiert.
  • Die Zwischenverbindung 1211 bietet Kommunikationskanäle zu den anderen Komponenten wie z. B. einem Teilnehmeridentitätsmodul (SIM) 1230 zur Verbindung mit einer SIM-Karte, einem Boot-ROM 1235 zum Halten des Boot-Codes zur Ausführung durch die Kerne 1206 und 1207 zum Initialisieren und Booten des SoC 1200, einem SDRAM-Controller 1240 zur Verbindung mit externem Speicher (z. B. DRAM 1260), einem Flash-Controller 1245 zur Verbindung mit nichtflüchtigem Speicher (z. B. Flash 1265), einer Peripheriesteuerung 1250 (z. B. einer seriellen Peripherieschnittstelle) zur Verbindung mit Peripherievorrichtungen, Video-Codecs 1220 und einer Videoschnittstelle 1225 zum Anzeigen und Empfangen von Eingaben (z. B. berührungsaktivierten Eingaben), einer GPU 1215 zum Ausführen grafischer Berechnungen usw. Jede dieser Schnittstellen kann Aspekte der hier beschriebenen Implementierung enthalten.
  • Zudem zeigt das System Peripherievorrichtungen für die Kommunikation wie z. B. ein Bluetooth-Modul 1270, ein 3G-Modem 1275, GPS 1280 und Wi-Fi 1285. Es ist zu beachten, dass ein UE, wie oben angegeben, ein Funkgerät zur Kommunikation aufweist. Infolgedessen sind möglicherweise nicht alle peripheren Kommunikationsmodule enthalten. In einem UE sollte jedoch eine Form eines Funkgeräts für die externe Kommunikation enthalten sein.
  • 13 zeigt eine schematische Darstellung einer Maschine in der beispielhaften Form eines Rechensystems 1300, in dem ein Satz von Befehlen ausgeführt werden kann, um zu veranlassen, dass die Maschine irgendeine oder mehrere der hierin erörterten Methodologien ausführt. In alternativen Ausführungsformen kann die Maschine mit anderen Maschinen in einem LAN, einem Intranet, einem Extranet oder dem Internet verbunden (beispielsweise vernetzt) sein. Die Maschine kann in der Eigenschaft eines Servers oder einer Client-Vorrichtung in einer Client-Server-Netzumgebung oder als eine Peer-Maschine in einer Peer-zu-Peer-Netzumgebung (bzw. verteilten Netzumgebung) arbeiten. Die Maschine kann ein Personalcomputer (PC), ein Tablet-PC, ein Beistellgerät (STB), ein persönlicher digitaler Assistent (PDA), ein Mobiltelefon, ein Web-Gerät, ein Server, ein Netz-Router, ein Switch oder eine Bridge oder irgendeine Maschine, die in der Lage ist, eine Reihe von Befehle (sequentiell oder anderweitig) auszuführen, die Aktionen spezifizieren, die von dieser Maschine vorgenommen werden sollen. Obwohl nur eine einzige Maschine dargestellt ist, soll der Begriff „Maschine“ ferner auch jede Sammlung von Maschinen umfassen, die einzeln oder gemeinsam einen Satz (oder mehrere Sätze) von Befehlen ausführen, um ein oder mehrere der hierin erörterten Methodologien durchzuführen. Die Implementierungen des Umwandelns von Seiten und Abschnitten kann in dem Rechensystem 1300 implementiert werden.
  • Das Rechensystem 1300 umfasst eine Verarbeitungsvorrichtung 1302, einen Hauptspeicher 1304 (z. B. Nur-Lese-Speicher (ROM), einen Flash-Speicher, einen dynamischen Direktzugriffsspeicher (DRAM, wie etwa Synchron-DRAM (SDRAM) oder DRAM (RDRAM) usw.), einen statischen Speicher 1306 (z. B. Flash-Speicher, statischen Speicher mit wahlfreiem Zugriff (SRAM) usw.) und eine Datenspeichervorrichtung 1318, die über einen Bus 1330 miteinander kommunizieren.
  • Die Verarbeitungsvorrichtung 1302 stellt eine oder mehrere Allzweck-Verarbeitungsvorrichtungen wie etwa einen Mikroprozessor, eine zentrale Verarbeitungseinheit oder dergleichen dar. Insbesondere kann die Verarbeitungsvorrichtung eine Mikroverarbeitungsvorrichtung für Berechnung mit komplexem Befehlssatz (CISC-Mikroverarbeitungsvorrichtung), eine Mikroverarbeitungsvorrichtung für Berechnung mit reduziertem Befehlssatz (RISC-Mikroverarbeitungsvorrichtung), eine Mikroverarbeitungsvorrichtung mit sehr langem Befehlswort (VLIW-Mikroverarbeitungsvorrichtung) oder eine Verarbeitungsvorrichtung, die andere Befehlssätze implementiert, oder Verarbeitungsvorrichtungen, die eine Kombination von Befehlssätzen implementieren, sein. Die Verarbeitungsvorrichtung 1302 kann auch eine oder mehrere Spezialverarbeitungsvorrichtungen wie etwa eine anwendungsspezifische integrierte Schaltung (ASIC), eine feldprogrammierbare Gatteranordnung (FPGA), ein Digitalsignalprozessor (DSP), eine Netzverarbeitungsvorrichtung oder dergleichen sein. In einer Implementierung kann die Verarbeitungsvorrichtung 1302 einen oder mehrere Verarbeitungskerne umfassen. Die Verarbeitungsvorrichtung 1302 ist dazu ausgelegt, Befehle 1326 zum Ausführen der hierin erörterten Operationen und Schritte auszuführen. In einer Implementierung kann die Verarbeitungsvorrichtung 1302 Teil des Rechensystems 100 von 1 sein. Alternativ kann das Rechensystem 1300 andere Komponenten aufweisen, wie es hierin beschrieben ist. Es versteht sich, dass der Kern Mehrsträngigkeit (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Strängen) unterstützen kann und dies auf verschiedene Arten, einschließlich zeitlich aufgeteilter Mehrsträngigkeit und gleichzeitiger Mehrsträngigkeit (wenn ein einzelner physischer Kern einen logischen Kern für jeden der Stränge bereitstellt, betreibt dieser physische Kern gleichzeitige Mehrsträngigkeit) oder eine Kombination davon (z. B. zeitlich aufgeteiltes Abrufen und Decodieren und gleichzeitige Mehrsträngigkeit danach, wie bei der Intel® Hyperthreading-Technologie) .
  • Das Rechensystem 1300 kann ferner eine Netzschnittstellenvorrichtung 1308 umfassen, die kommunikationstechnisch mit einem Netz 1320 gekoppelt ist. Das Rechensystem 1300 kann auch eine Videoanzeigeeinheit 1310 (z. B. eine Flüssigkristallanzeige (LCD) oder eine Kathodenstrahlröhre (CRT)), eine alphanumerische Eingabevorrichtung 1312 (z. B. eine Tastatur), eine Cursorsteuervorrichtung 1314 (z. B. eine Maus), eine Signalerzeugungsvorrichtung 1316 (z. B. einen Lautsprecher) oder andere Peripherievorrichtungen umfassen. Ferner kann das Rechensystem 1300 eine Grafikverarbeitungseinheit 1322, eine Videoverarbeitungseinheit 1328 und eine Audioverarbeitungseinheit 1332 umfassen. In einer weiteren Implementierung kann das Rechensystem 1300 einen Chipsatz (nicht dargestellt) umfassen, der sich auf eine Gruppe integrierter Schaltungen oder Chips bezieht, die für die Arbeit mit der Verarbeitungsvorrichtung 1302 ausgelegt sind und die Kommunikation zwischen der Verarbeitungsvorrichtung 1302 und externen Vorrichtungen steuern. Beispielsweise kann der Chipsatz ein Satz von Chips auf einer Hauptplatine sein, die die Verarbeitungsvorrichtung 1302 mit Vorrichtung mit sehr hoher Geschwindigkeit wie dem Hauptspeicher 1304 und Grafik-Controllern verbindet sowie die Verarbeitungsvorrichtung 1302 mit Peripheriebussen mit niedrigerer Geschwindigkeit von Peripherievorrichtungen wie USB-, PCI- oder ISA-Bussen verbindet.
  • Die Datenspeichervorrichtung 1318 kann ein computerlesbares Speichermedium 1324 umfassen, auf dem Software 1326 gespeichert ist, die irgendeine oder mehrere der hierin beschriebenen Methodologien von Funktionen implementiert. Die Befehle 1326 können sich während ihrer Ausführung durch das Rechensystem 1300 auch vollständig oder zumindest teilweise innerhalb des Hauptspeichers 1304 als Befehle 1326 und/oder innerhalb der Verarbeitungsvorrichtung 1302 als Verarbeitungslogik befinden; der Hauptspeicher 1304 und die Verarbeitungsvorrichtung 1302 bilden ebenfalls computerlesbare Speichermedien.
  • Das computerlesbare Speichermedium 1324 kann zudem verwendet werden, um Befehle 1326, die die Verarbeitungsvorrichtung 1302 verwenden, wie etwa in Bezug auf 1 beschrieben, und/oder eine Software-Bibliothek, die Verfahren zum Aufrufen der obigen Anwendungen enthält, zu speichern. Obwohl das computerlesbare Speichermedium 1324 in einer beispielhaften Ausführungsform als ein einzelnes Medium gezeigt ist, sollte der Begriff „computerlesbares Speichermedium“ so verstanden werden, dass er ein einzelnes Medium oder mehrere Medien (z. B. eine zentralisierte oder verteilte Datenbank und/oder zugeordnete Caches und Server), die den einen oder die mehreren Sätze von Befehlen speichern, umfasst. Der Begriff „computerlesbares Speichermedium“ soll auch jedes Medium umfassen, das in der Lage ist, einen Befehlssatz zur Ausführung durch die Maschine zu speichern, zu codieren oder zu tragen, der veranlasst, dass die Maschine eine oder mehrere der Methodologien der Implementierung ausführt. Unter dem Begriff „computerlesbares Speichermedium“ sollen demnach auch Festkörperspeicher und optische und magnetische Medien verstanden werden, ohne darauf beschränkt zu sein.
  • Die folgenden Beispiel beziehen sich auf weitere Implementierungen:
  • Beispiel 1 ist ein Prozessor, der umfasst: 1) einen Prozessorkern zum Ausführen eines Hypervisors, wobei der Prozessorkern ein Hardware-Register umfasst, um Folgendes zu speichern: a) einen Bitbereich zum Identifizieren einer ersten Anzahl von Adressbits von physischen Speicheradressen, die Schlüsselkennungen (Schlüssel-IDs) definieren; und b) eine Aufteilungsschlüssel-ID der Schlüssel-IDs, um eine Grenze zwischen nicht beschränkten Schlüssel-IDs und beschränkten Schlüssel-IDs der Schlüssel-IDs zu identifizieren; und wobei der Prozessorkern Folgendes ausführen soll: a) Zuweisen mindestens einer der nicht beschränkten Schlüssel-IDs zur Verwendung durch den Hypervisor; und b) Zuweisen einer ersten Schlüssel-ID der Schlüssel-IDs zu einer ersten Vertrauensdomäne einer Vertrauensdomäneninfrastruktur, wobei die erste Schlüssel-ID eine der beschränkten Schlüssel-IDs ist; und 2) einen Speicher-Controller, der mit dem Prozessorkern gekoppelt ist, um der ersten Vertrauensdomäne eine erste physische Seite eines Speichers zuzuweisen, wobei Daten der ersten physischen Seite des Speichers mit einem der ersten Schlüssel-ID zugeordneten Kryptographieschlüssel verschlüsselt werden sollen.
  • In Beispiel 2 der Prozessor von Beispiel 1, wobei der Bitbereich einen ersten Bitunterbereich von nicht beschränkten Bits und einen zweiten Bitunterbereich von beschränkten Bits umfasst, wobei für die nicht beschränkten Schlüssel-IDs jedes der beschränkten Bits einen ersten Binärwert haben soll und wobei für die beschränkten Schlüssel-IDs mindestens eines der beschränkten Bits einen zweiten Binärwert haben soll, der sich von dem ersten Binärwert unterscheidet.
  • In Beispiel 3, der Prozessor von Beispiel 2, wobei der Speicher-Controller ferner Folgendes ausführen soll: 1) Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, die der ersten Vertrauensdomäne zugeordnet ist, wobei die Speichertransaktion eine physische Speicheradresse der physischen Seite des Speichers und eine Anforderungsschlüssel-ID umfasst; und 2) Erzeugen eines Fehlers als Antwort auf eine Bestimmung, dass mindestens eines der beschränkten Bits der Anforderungsschlüssel-ID den zweiten Binärwert hat.
  • In Beispiel 4, der Prozessor von Beispiel 3, wobei die Speichertransaktion ein Codeabruf oder eine Speichertransaktion ist, die einen Seitenlauf verwendet, und wobei der Fehler ein Seitenfehler nicht beschränkter Schlüssel ist.
  • In Beispiel 5, der Prozessor von Beispiel 1, wobei der Speicher-Controller ferner einen Fehler als Antwort auf das Detektieren einer Speichertransaktion erzeugen soll, die von einem Software-Programm außerhalb einer vertrauenswürdigen Rechenbasis (TCB) der ersten Vertrauensdomäne initiiert wird und auf die erste physische Seite des Speichers gerichtet ist.
  • In Beispiel 6, der Prozessor von Beispiel 1, wobei der Prozessorkern ferner eine zweite Schlüssel-ID einer zweiten Vertrauensdomäne zuweisen soll, wobei die zweite Schlüssel-ID eine der beschränkten Schlüssel-IDs ist und wobei der Speicher-Controller ferner Folgendes ausführen soll: 1) Zuweisen einer zweiten physischen Seite des Speichers zu der zweiten Vertrauensdomäne, wobei Daten auf der zweiten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der zweiten Schlüssel-ID zugeordnet ist; 2) Speichern der Zuweisung der ersten Schlüssel-ID zu der ersten Vertrauensdomäne und der Zuweisung der zweiten Schlüssel-ID zu der zweiten Vertrauensdomäne in einer Schlüsselbesitztabelle (KOT); und 3) Speichern einer ersten Vertrauensdomänenkennung, die die Zuweisung der ersten physischen Seite des Speichers zu der ersten Vertrauensdomäne identifiziert, und einer zweiten Vertrauensdomänenkennung, die die Zuweisung der zweiten physischen Seite des Speichers zu der zweiten Vertrauensdomäne identifiziert, in einer Speicherbesitztabelle (MOT).
  • In Beispiel 7, der Prozessor von Beispiel 6, wobei der Speicher-Controller ferner Folgendes ausführen soll: 1) Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, wobei die Speichertransaktion eine physische Speicheradresse der ersten physischen Seite des Speichers und die zweite Schlüssel-ID umfasst; 2) Zurückgreifen auf die MOT, um zu bestimmen, dass die zweite Schlüssel-ID kein korrektes Attribut der ersten physischen Seite des Speichers ist; und 3) Erzeugen eines Fehlers.
  • In Beispiel 8, der Prozessor von Beispiel 6, wobei der Speicher-Controller ferner Folgendes ausführen soll: 1) Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, wobei die Speichertransaktion aus der zweiten Vertrauensdomäne stammt und eine Speicheradresse der ersten physischen Seite des Speichers und die erste Schlüssel-ID umfasst; 2) Zurückgreifen auf die KOT, um zu bestimmen, dass die erste Schlüssel-ID nicht der zweiten Vertrauensdomäne zugewiesen ist; und 3) Erzeugen eines Fehlers.
  • In Beispiel 9, der Prozessor von Beispiel 1, wobei der Hypervisor ferner Folgendes ausführen soll: 1) Markieren der ersten physischen Seite, die einer ersten physischen Speicheradresse des Speichers zugeordnet ist, als privat, wobei das Markieren ein Löschen eines Werts eines gemeinsam genutzten Bits (s-Bits) in einem Eintrag für eine physische Gastadresse, die der ersten physischen Seite zugeordnet ist, innerhalb eines Satzes von EPT für die erste Vertrauensdomäne umfasst, 2) Übersetzen einer virtuellen Gastadresse in die physische Gastadresse unter Verwendung eines Satzes von Gastseitentabellen, 3) Übersetzen der physischen Gastadresse in die erste physische Speicheradresse unter Verwendung der erweiterten Seitentabellen; 4) Abrufen der ersten Schlüssel-ID aus einem sicheren Speicher des Prozessors basierend auf dem Wert des s-Bits in der physischen Gastadresse; und 5) Erzeugen einer Speichertransaktion, die die erste Schlüssel-ID und die erste physische Speicheradresse umfasst.
  • In Beispiel 10, der Prozessor von Beispiel 9, wobei der Prozessorkern ferner einen Multiplexer umfasst, um basierend auf dem Wert des s-Bits zwischen der ersten Schlüssel-ID und einer zweiten Schlüssel-ID auszuwählen, wobei die zweite Schlüssel-ID eine nicht beschränkte Schlüssel-ID umfasst, die an eine zweite physische Speicheradresse innerhalb eines Eintrags der EPT angehängt ist.
  • In Beispiel 11, der Prozessor von Beispiel 1, wobei der Hypervisor ferner Folgendes ausführen soll: 1) Zuweisen einer zweiten Schlüssel-ID zu der ersten Vertrauensdomäne, wobei die zweite Schlüssel-ID eine der nicht beschränkten Schlüssel-IDs ist, 2) Markieren einer zweiten physischen Seite, die einer zweiten gemeinsam genutzten physischen Speicheradresse des Speichers zugeordnet ist, wobei das Markieren ein Setzen eines Werts eines gemeinsam genutzten Bits (s-Bits) in einem Eintrag innerhalb eines Satzes von EPT für die erste Vertrauensdomäne für eine physische Gastadresse, die der zweiten physischen Seite zugeordnet ist, umfasst, 3) Übersetzen einer virtuellen Gastadresse in die physische Gastadresse unter Verwendung eines Satzes von Gastseitentabellen, 4) Übersetzen der physischen Gastadresse unter Verwendung der EPT und basierend auf dem Wert des s-Bit, um eine Kombination aus der zweiten physischen Speicheradresse und der zweiten Schlüssel-ID aus einem Eintrag in der EPT zu erhalten; und 5) Erzeugen einer Speichertransaktion, die die zweite Schlüssel-ID und die zweite physische Speicheradresse umfasst.
  • Verschiedene Implementierungen können andere Kombinationen der oben beschriebenen Strukturmerkmale aufweisen. Beispielsweise können alle optionalen Merkmale der oben beschriebenen Prozessoren und Verfahren auch in Bezug auf ein hierin beschriebenes System implementiert werden und Besonderheiten in den Beispielen können irgendwo in einer oder mehreren Implementierungen verwendet werden.
  • Beispiel 12 ist ein System, das umfasst: 1) eine Speichervorrichtung; 2) ein Hardware-Register um Folgendes zu speichern: a) einen Bitbereich zum Identifizieren einer ersten Anzahl von Adressbits von physischen Speicheradressen, die Schlüsselkennungen (Schlüssel-IDs) definieren; und b) eine Aufteilungsschlüssel-ID der Schlüssel-IDs, um eine Grenze zwischen nicht beschränkten Schlüssel-IDs und beschränkten Schlüssel-IDs der Schlüssel-IDs zu identifizieren; und 3) einen Prozessor, der mit der Speichervorrichtung gekoppelt ist, wobei der Prozessor das Hardwareregister und einen Speicher-Controller umfasst, wobei der Prozessor ein erstes Software-Programm ausführen soll, um einer ersten Vertrauensdomäne einer Vertrauensdomäneninfrastruktur eine erste Schlüssel-ID der Schlüssel-IDs zuzuweisen, wobei die erste Schlüssel-ID eine der beschränkten Schlüssel-IDs ist; und wobei der Speicher-Controller der ersten Vertrauensdomäne eine erste physische Seite der Speichervorrichtung zuweisen soll, wobei Daten der ersten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der ersten Schlüssel-ID zugeordnet ist.
  • In Beispiel 13, das System von Beispiel 12, wobei das erste Software-Programm ferner eine zweite Schlüssel-ID der Schlüssel-IDs einer zweiten Vertrauensdomäne zuweisen soll, wobei die zweite Schlüssel-ID eine der beschränkten Schlüssel-IDs ist, und wobei der Speicher-Controller ferner eine zweite physische Seite des Speichers der zweiten Vertrauensdomäne zuweisen soll, wobei Daten auf der zweiten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der zweiten Schlüssel-ID zugeordnet ist.
  • In Beispiel 14, das System von Beispiel 13, das ferner eine gemeinsam genutzte Hardware-Vorrichtung umfasst, auf die ein zweites Software-Programm zugreifen kann, das in der ersten Vertrauensdomäne arbeitet, wobei auf die gemeinsam genutzte Hardware-Vorrichtungen ein drittes Software-Programm zugreifen kann, das in der zweiten Vertrauensdomäne arbeitet, wobei das erste Software-Programm ferner eine gemeinsam genutzte Schlüssel-ID sowohl der ersten Vertrauensdomäne als auch der zweiten Vertrauensdomäne zuweisen soll, wobei die gemeinsam genutzte Schlüssel-ID eine der nicht beschränkten Schlüssel-IDs ist und wobei ein Kryptographieschlüssel, der der gemeinsam genutzten Schlüssel-ID zugeordnet ist, für Speichertransaktionen verwenden werden soll, an denen die gemeinsam genutzte Hardware-Vorrichtung beteiligt ist.
  • In Beispiel 15, das System von Beispiel 14, wobei die gemeinsam genutzte Hardware-Vorrichtung eine E/A-Vorrichtung, ein Netzadapter, ein Drucker, eine Kommunikationsvorrichtung oder eine Verarbeitungsvorrichtung ist.
  • In Beispiel 16, das System von Beispiel 12, wobei der Speicher-Controller ferner Folgendes ausführen soll: 1) Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, die der ersten Vertrauensdomäne zugewiesen ist, wobei die Speichertransaktion eine physische Speicheradresse der ersten physischen Seite des Speichers und eine gemeinsam genutzte Schlüssel-ID umfasst; und 2) Erzeugen eines Fehlers als Antwort auf eine Bestimmung, dass die gemeinsam genutzte Schlüssel-ID eine nicht beschränkte Schlüssel-ID ist.
  • In Beispiel 17, das System von Beispiel 16, wobei die Speichertransaktion einem Codeabruf zugeordnet ist oder einen Seitenlauf zum Zugreifen auf die physische Speicheradresse verwenden soll und wobei der Fehler ein Seitenfehler nicht beschränkter Schlüssel ist.
  • Verschiedene Implementierungen können unterschiedliche Kombinationen der oben beschriebenen Strukturmerkmale aufweisen. Beispielsweise können alle optionalen Merkmale der oben beschriebenen Prozessoren und Verfahren auch in Bezug auf ein hierin beschriebenes System implementiert werden und Besonderheiten in den Beispielen können irgendwo in einer oder mehreren Implementierungen verwendet werden.
  • Beispiel 18 ist ein Verfahren, das umfasst: 1) Abrufen eines Bitbereichs aus einem Hardware-Register eines Prozessors, um eine erste Anzahl von Adressbits von physischen Speicheradressen zu identifizieren, die Schlüsselkennungen (Schlüssel-IDs) definieren; und 2) Abrufen einer Aufteilungsschlüssel-ID der Schlüssel-IDs aus dem Hardware-Register, um die Schlüssel-IDs in nicht beschränkte Schlüssel-IDs und beschränkte Schlüssel-IDs der Schlüssel-IDs aufzuteilen; 3) Ausführen eines Hypervisors durch den Prozessor; 4) Zuweisen mindestens einer der nicht beschränkten Schlüssel-IDs durch den Prozessor zur Verwendung durch den Hypervisor; 5) Zuweisen einer ersten Schlüssel-ID der Schlüssel-IDs durch den Hypervisor zu einer ersten Vertrauensdomäne einer Vertrauensdomäneninfrastruktur, wobei die erste Schlüssel-ID eine der beschränkten Schlüssel-IDs ist; und 6) Zuweisen einer ersten physischen Seite eines Speichers durch einen Speicher-Controller zu der ersten Vertrauensdomäne, wobei Daten auf der ersten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der ersten Schlüssel-ID zugeordnet ist.
  • In Beispiel 19 umfasst das Verfahren von Beispiel 18 ferner: 1) Zuweisen einer zweiten Schlüssel-ID durch den Hypervisor zu einer zweiten Vertrauensdomäne, wobei die zweite Schlüssel-ID eine der beschränkten Schlüssel-IDs ist; 2) Zuweisen einer zweiten physischen Seite des Speichers durch den Speicher-Controller zu der zweiten Vertrauensdomäne, wobei Daten auf der zweiten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der zweiten Schlüssel-ID zugeordnet ist; 3) Speichern der Zuweisung der ersten Schlüssel-ID zu der ersten Vertrauensdomäne und der Zuweisung der zweiten Schlüssel-ID zu der zweiten Vertrauensdomäne durch den Speicher-Controller in einer Schlüsselbesitztabelle (KOT); und 4) Speichern einer ersten Vertrauensdomänenkennung, die die Zuweisung der ersten physischen Seite des Speichers zu der ersten Vertrauensdomäne identifiziert, und einer zweiten Vertrauensdomänenkennung, die die Zuweisung der zweiten physischen Seite des Speichers zu der zweiten Vertrauensdomäne identifiziert, durch den Speicher-Controller in einer Speicherbesitztabelle (MOT) .
  • In Beispiel 20 umfasst das Verfahren von Beispiel 19 ferner: 1) Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, durch den Speicher-Controller, wobei die Speichertransaktion eine physische Speicheradresse der ersten physischen Seite des Speichers und die zweite Schlüssel-ID umfasst; 2) Zurückgreifen auf die MOT durch den Speicher-Controller, um zu bestimmen, dass die zweite Schlüssel-ID kein korrektes Attribut der ersten physischen Seite des Speichers ist; und 3) Erzeugen eines Fehlers durch den Speicher-Controller.
  • In Beispiel 21 umfasst das Verfahren von Beispiel 20 ferner: 1) Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, durch den Speicher-Controller, wobei die Speichertransaktion aus der zweiten Vertrauensdomäne stammt und eine Speicheradresse der ersten physischen Seite des Speichers und die erste Schlüssel-ID umfasst; 2) Zurückgreifen auf die KOT durch den Speicher-Controller, um zu bestimmen, dass die erste Schlüssel-ID nicht der zweiten Vertrauensdomäne zugewiesen ist; und 3) Erzeugen eines Fehlers durch den Speicher-Controller.
  • In Beispiel 22 umfasst das Verfahren von Beispiel 18 ferner: 1) Markieren der ersten physischen Seite, die einer ersten physischen Speicheradresse des Speichers zugeordnet ist, als privat, wobei das Markieren ein Löschen eines Werts eines E(s-Bits) in einem Eintrag für eine physische Gastadresse, die der ersten physischen Seite zugeordnet ist, innerhalb eines Satzes von EPT für die erste Vertrauensdomäne umfasst; 2) Übersetzen der virtuellen Gastadresse in die physische Gastadresse unter Verwendung eines Satzes von Gastseitentabellen; 3) Übersetzen der physischen Gastadresse in die physische Speicheradresse unter Verwendung von EPT; 4) Abrufen der ersten Schlüssel-ID basierend auf dem Wert des s-Bits in der physischen Gastadresse; und 5) Erzeugen einer Speichertransaktion, die die erste Schlüssel-ID und die erste physische Speicheradresse umfasst.
  • In Beispiel 23 umfasst das Verfahren von Beispiel 18 ferner: 1) Zuweisen einer zweiten Schlüssel-ID zu der ersten Vertrauensdomäne, wobei die zweite Schlüssel-ID eine der nicht beschränkten Schlüssel-IDs ist; 2) Markieren einer zweiten physischen Seite, die einer zweiten physischen Speicheradresse des Speichers zugeordnet ist, als gemeinsam genutzt, wobei das Markieren ein Setzen eines Werts eines gemeinsam genutzten Bits (s-Bits) in einem Eintrag für eine physische Gastadresse, die der zweiten physischen Seite zugeordnet ist, innerhalb eines EPT-Satzes für die erste Vertrauensdomäne umfasst; 3) Übersetzen einer virtuellen Gastadresse in die physische Gastadresse unter Verwendung eines Satzes von Gastseitentabellen, 4) Übersetzen der physische Gastadresse unter Verwendung der EPT und basierend auf dem Wert des s-Bits, um eine Kombination aus der zweiten physischen Speicheradresse und der zweiten Schlüssel-ID aus einem Eintrag in der EPT zu erhalten; und 5) Erzeugen einer Speichertransaktion, die die zweite Schlüssel-ID und die zweite physische Speicheradresse umfasst.
  • Verschiedene Implementierungen können unterschiedliche Kombinationen der oben beschriebenen Strukturmerkmale aufweisen. Beispielsweise können alle optionalen Merkmale der oben beschriebenen Prozessoren und Verfahren auch in Bezug auf ein hierin beschriebenes System implementiert werden und Besonderheiten in den Beispielen können irgendwo in einer oder mehreren Implementierungen verwendet werden.
  • Beispiel 24 ist ein nichttransitorisches computerlesbares Medium zum Speichern von Befehlen, die, wenn sie von einem Prozessor ausgeführt werden, dessen Kern mit einem Systemspeicher gekoppelt ist, den Prozessor dazu veranlassen, mehrere Logikoperationen auszuführen, die Folgendes umfassen: 1) Abrufen eines Bitbereichs zum Identifizieren einer ersten Anzahl von Adressbits von physischen Speicheradressen, die Schlüsselkennungen (IDs) definieren, aus einem Hardware-Register eines Prozessors; und 2) Abrufen einer Aufteilungsschlüssel-ID der Schlüssel-IDs aus dem Hardware-Register, um die Schlüssel-IDs in nicht beschränkte Schlüssel-IDs und beschränkte Schlüssel-IDs der Schlüssel-IDs aufzuteilen; 3) Ausführen eines Hypervisors durch den Prozessor; 4) Zuweisen mindestens einer der nicht beschränkten Schlüssel-IDs zur Verwendung durch den Hypervisor durch den Prozessor; 5) Zuweisen einer ersten Schlüssel-ID der Schlüssel-IDs zu einer ersten Vertrauensdomäne einer Vertrauensdomäneninfrastruktur durch den Hypervisor, wobei die erste Schlüssel-ID eine der beschränkten Schlüssel-IDs ist; und 6) Zuweisen einer ersten physischen Seite eines Speichers durch einen Speicher-Controller zu der ersten Vertrauensdomäne, wobei Daten auf der ersten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der ersten Schlüssel-ID zugeordnet ist.
  • In Beispiel 25, das nichttransitorische computerlesbare Medium von Beispiel 24, wobei die Operationen ferner umfassen: 1) Zuweisen einer zweiten Schlüssel-ID zu einer zweiten Vertrauensdomäne durch den Hypervisor, wobei die zweite Schlüssel-ID eine der beschränkten Schlüssel-IDs ist; 2) Zuweisen einer zweiten physischen Seite des Speichers zu der zweiten Vertrauensdomäne durch den Speicher-Controller, wobei Daten auf der zweiten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der zweiten Schlüssel-ID zugeordnet ist; 3) Speichern der Zuweisung der ersten Schlüssel-ID zu der ersten Vertrauensdomäne und der Zuweisung der zweiten Schlüssel-ID zu der zweiten Vertrauensdomäne durch den Speicher-Controller in einer Schlüsselbesitztabelle (KOT); und 4) Speichern einer ersten Vertrauensdomänenkennung, die die Zuweisung der ersten physischen Seite des Speichers zu der ersten Vertrauensdomäne identifiziert, und einer zweiten Vertrauensdomänenkennung, die die Zuweisung der zweiten physischen Seite des Speichers zu der zweiten Vertrauensdomäne identifiziert, durch den Speicher-Controller in einer Speicherbesitztabelle (MOT).
  • In Beispiel 26, das nichttransitorische computerlesbare Medium von Beispiel 25, wobei die Operationen ferner umfassen: 1) Detektieren einer Speichertransaktion durch den Speicher-Controller, die auf die erste physische Seite des Speichers gerichtet ist, wobei die Speichertransaktion eine physische Speicheradresse der ersten physischen Seite des Speichers und die zweite Schlüssel-ID umfassen; 2) Zurückgreifen auf die MOT durch den Speicher-Controller, um zu bestimmen, dass die zweite Schlüssel-ID kein korrektes Attribut der ersten physischen Seite des Speichers ist; und 3) Erzeugen eines Fehlers durch den Speicher-Controller.
  • In Beispiel 27, das nichttransitorische computerlesbare Medium von Beispiel 26, wobei die Operationen ferner umfassen: 1) Detektierten einer Speichertransaktion durch den Speicher-Controller, die auf die erste physische Seite des Speichers gerichtet ist, wobei die Speichertransaktion aus der zweiten Vertrauensdomäne stammt und eine Speicheradresse der ersten physischen Seite des Speichers und die erste Schlüssel-ID umfasst; 2) Zurückgreifen auf die KOT durch den Speicher-Controller, um zu bestimmen, dass die erste Schlüssel-ID nicht der zweiten Vertrauensdomäne zugewiesen ist; und 3) Erzeugen eines Fehlers durch den Speicher-Controller.
  • In Beispiel 28, das nichttransitorische computerlesbare Medium von Beispiel 24, wobei die Operationen ferner umfassen: 1) Markieren der ersten physischen Seite, die einer ersten physischen Speicheradresse des Speichers zugeordnet ist, als privat, wobei das Markieren ein Löschen innerhalb eines Werts eines gemeinsam genutzten Bits (s-Bits) in einem Eintrag für eine physische Gastadresse, die der ersten physischen Seite zugeordnet ist, innerhalb eines Satzes von EPT für die erste Vertrauensdomäne umfasst; 2) Übersetzen einer virtuellen Gastadresse in die physische Gastadresse unter Verwendung eines Satzes von Gastseitentabellen; 3) Übersetzen der physischen Gastadresse in die erste physische Speicheradresse unter Verwendung der EPT; 4) Abrufen der ersten Schlüssel-ID basierend auf dem Wert des s-Bits in der physischen Gastadresse; und 5) Erzeugen einer Speichertransaktion, die die erste Schlüssel-ID und die erste physische Speicheradresse umfasst.
  • In Beispiel 29 das nichttransitorische computerlesbare Medium von Beispiel 24, wobei die Operationen ferner umfassen: 1) Zuweisen einer zweiten Schlüssel-ID zu der ersten Vertrauensdomäne, wobei die zweite Schlüssel-ID eine der nicht beschränkten Schlüssel-IDs ist; 2) Markieren einer zweiten physischen Seite, die einer zweiten physischen Speicheradresse des Speichers zugeordnet ist, als gemeinsam genutzt, wobei das Markieren ein Setzen eines Werts eines gemeinsam genutzten Bits (s-Bits) in einem Eintrag für eine physische Gastadresse, die der zweiten physischen Seite zugeordnet ist, innerhalb eines EPT-Satzes für die erste Vertrauensdomäne umfasst; 3) Übersetzen einer virtuellen Gastadresse in die physische Gastadresse unter Verwendung eines Satzes von Gastseitentabellen; 4) Übersetzen der physischen Gastadresse unter Verwendung der EPT und basierend auf dem Wert des s-Bits, um eine Kombination aus der zweiten physischen Speicheradresse und der zweiten Schlüssel-ID aus einem Eintrag in der EPT zu erhalten; und 5) Erzeugen einer Speichertransaktion, die die zweite Schlüssel-ID und die zweite physische Speicheradresse umfasst.
  • Verschiedene Implementierungen können unterschiedliche Kombinationen der oben beschriebenen Strukturmerkmale aufweisen. Beispielsweise können alle optionalen Merkmale der oben beschriebenen Prozessoren und Verfahren auch in Bezug auf ein hierin beschriebenes System implementiert werden und Besonderheiten in den Beispielen können irgendwo in einer oder mehreren Implementierungen verwendet werden.
  • Beispiel 30 ist ein System, das umfasst: 1) Mittel zum Abrufen eines Bitbereichs aus einem Hardware-Register eines Prozessors, um eine erste Anzahl von Adressbits von physischen Speicheradressen zu identifizieren, die Schlüsselkennungen (Schlüssel-IDs) definieren; und 2) Mittel zum Abrufen einer Aufteilungsschlüssel-ID der Schlüssel-IDs aus dem Hardware-Register, um die Schlüssel-IDs in nicht beschränkte Schlüssel-IDs und beschränkte Schlüssel-IDs der Schlüssel-IDs aufzuteilen; 3) Mittel zum Ausführen eines Hypervisors durch den Prozessor; 4) Mittel zum Zuweisen mindestens einer der nicht beschränkten Schlüssel-IDs durch den Prozessor zur Verwendung durch den Hypervisor; 5) Mittel zum Zuweisen einer ersten Schlüssel-ID der Schlüssel-IDs zu einer ersten Vertrauensdomäne einer Vertrauensdomäneninfrastruktur durch den Hypervisor, wobei die erste Schlüssel-ID eine der beschränkten Schlüssel-IDs ist; und 6) Mittel zum Zuweisen einer ersten physischen Seite eines Speichers zu der ersten Vertrauensdomäne durch einen Speicher-Controller, wobei Daten auf der ersten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der ersten Schlüssel-ID zugeordnet ist.
  • In Beispiel 31 umfasst das System von Beispiel 30 ferner: 1) Mittel zum Zuweisen einer zweiten Schlüssel-ID zu einer zweiten Vertrauensdomäne durch den Hypervisor, wobei die zweite Schlüssel-ID eine der beschränkten Schlüssel-IDs ist; 2) Mittel zum Zuweisen einer zweiten physischen Seite des Speichers zu der zweiten Vertrauensdomäne durch den Speicher-Controller, wobei Daten auf der zweiten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der zweiten Schlüssel-ID zugeordnet ist; 3) Mittel zum Speichern der Zuweisung der ersten Schlüssel-ID zu der ersten Vertrauensdomäne und der Zuweisung der zweiten Schlüssel-ID zu der zweiten Vertrauensdomäne durch den Speicher-Controller in einer Schlüsselbesitztabelle (KOT); und 4) Mittel zum Speichern einer ersten Vertrauensdomänenkennung, die die Zuweisung der ersten physischen Seite des Speichers zu der ersten Vertrauensdomäne identifiziert, und einer zweiten Vertrauensdomänenkennung, die die Zuweisung der zweiten physische Seite des Speichers zu der zweiten Vertrauensdomäne identifiziert, durch den Speicher-Controller in einer Speicherbesitztabelle (MOT).
  • In Beispiel 32 umfasst das System von Beispiel 31 ferner: 1) Mittel zum Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, durch den Speicher-Controller, wobei die Speichertransaktion eine physische Speicheradresse der ersten physischen Seite des Speichers und die zweite Schlüssel-ID umfasst; 2) Mittel zum Zurückgreifen auf die MOT durch den Speicher-Controller, um zu bestimmen, dass die zweite Schlüssel-ID kein korrektes Attribut der ersten physischen Seite des Speichers ist; und 3) Mittel zum Erzeugen eines Fehlers durch den Speicher-Controller.
  • In Beispiel 33 umfasst das System von Beispiel 32 ferner: 1) Mittel zum Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, durch den Speicher-Controller, wobei die Speichertransaktion aus der zweiten Vertrauensdomäne stammt und eine Speicheradresse der ersten physischen Seite des Speichers und die erste Schlüssel-ID umfasst; 2) Mittel zum Zurückgreifen auf die KOT durch den Speicher-Controller, um zu bestimmen, dass die erste Schlüssel-ID nicht der zweiten Vertrauensdomäne zugewiesen ist; und 3) Mittel zum Erzeugen eines Fehlers durch den Speicher-Controller.
  • In Beispiel 34 umfasst das System von Beispiel 30 ferner: 1) Mittel zum Markieren der ersten physischen Seite, die einer ersten physischen Speicheradresse des Speichers zugeordnet ist, als privat, wobei das Markieren ein Löschen eines Werts eines gemeinsam genutzten Bits (s-Bits) in einem Eintrag für eine physische Gastadresse, die der ersten physischen Seite zugeordnet ist, innerhalb eines Satzes von EPT für die erste Vertrauensdomäne umfasst; 2) Mittel zum Übersetzen einer virtuellen Gastadresse in die physische Gastadresse unter Verwendung eines Satzes von Gastseitentabellen; 3) Mittel zum Übersetzen der physischen Gastadresse in die erste physische Speicheradresse unter Verwendung der EPT; 4) Mittel zum Abrufen der ersten Schlüssel-ID basierend auf dem Wert des s-Bits in der physischen Gastadresse; und 5) Mittel zum Erzeugen einer Speichertransaktion, die die erste Schlüssel-ID und die erste physische Speicheradresse umfasst.
  • In Beispiel 35 umfasst das System von Beispiel 30 ferner: 1) Mittel zum Zuweisen einer zweiten Schlüssel-ID zu der ersten Vertrauensdomäne, wobei die zweite Schlüssel-ID eine der nicht beschränkten Schlüssel-IDs ist; 2) Mittel zum Markieren einer zweiten physischen Seite, die einer zweiten physischen Speicheradresse des Speichers zugeordnet ist, als gemeinsam genutzt, wobei das Markieren ein Setzen eines Werts eines gemeinsam genutzten Bits (s-Bits) in einem Eintrag für eine physische Gastadresse, die der zweiten physischen Seite zugeordnet ist, innerhalb eines Satzes von EPT für die erste Vertrauensdomäne umfasst; 3) Mittel zum Übersetzen einer virtuellen Gastadresse in die physische Gastadresse unter Verwendung eines Satzes von Gastseitentabellen; 4) Mittel zum Übersetzen der physischen Gastadresse unter Verwendung der EPT und basierend auf dem Wert des s-Bits, um eine Kombination der zweiten physischen Speicheradresse und der zweiten Schlüssel-ID aus einem Eintrag in der EPT zu erhalten; und 5) Mittel zum Erzeugen einer Speichertransaktion, die die zweite Schlüssel-ID und die zweite physische Speicheradresse umfasst.
  • Obwohl die Offenbarung in Bezug auf eine begrenzte Anzahl von Implementierungen beschrieben wurde, werden Fachleute zahlreiche Abwandlungen und Variationen davon erkennen. Es ist beabsichtigt, dass die beigefügten Ansprüche alle derartigen Abwandlungen und Variationen abdecken, die unter den wahren Gedanken und Umfang dieser Offenbarung fallen.
  • In der Beschreibung hierin werden zahlreiche spezifische Einzelheiten dargelegt, wie beispielsweise Beispiele für spezifische Arten von Verarbeitungsvorrichtungen und Systemkonfigurationen, spezifische Hardware-Strukturen, spezifische Architektur- und Mikroarchitekturdetails, spezifische Registerkonfigurationen, spezifische Befehlstypen, spezifische Systemkomponenten, spezifische Abmessungen/Höhen, spezifische Verarbeitungsvorrichtungs-Pipeline-Stufen und Operationen usw., um ein gründliches Verständnis der Offenbarung zu ermöglichen. Es ist jedoch für Fachleute offensichtlich, dass diese spezifischen Einzelheiten nicht verwendet werden müssen, um die Offenbarung zu praktizieren. In anderen Fällen wurden bekannte Komponenten oder Verfahren wie spezifische und alternative Verarbeitungsvorrichtungsarchitekturen, spezifische Logikschaltungen/Code für beschriebene Algorithmen, spezifischer Firmware-Code, spezifischer Zwischenverbindungsbetrieb, spezifische Logikkonfigurationen, spezifische Herstellungstechniken und -materialien, spezifische Kompiliererimplementierungen, ein spezifischer Ausdruck von Algorithmen in Code, spezifische Ausschalt- und Ansteuerungstechniken/-logik und andere spezifische Betriebsdetails des Computersystems nicht im Einzelnen beschrieben, um zu vermeiden, dass die Offenbarung unnötig verunklart wird.
  • Die Implementierungen sind unter Bezugnahme auf das Bereitstellen der Koexistenz der Vertrauensdomänenarchitektur mit der Mehrschlüssel-Gesamtspeicherverschlüsselungstechnologie in virtualisierten Systemen unter Verwendung von Vertrauensdomänen in bestimmten integrierten Schaltungen wie beispielsweise in Rechenplattformen oder Mikroverarbeitungsvorrichtungen beschrieben. Die Implementierungen können auch auf andere Arten von integrierten Schaltungen und programmierbaren Logikvorrichtungen anwendbar sein. Beispielsweise sind die offenbarten Implementierungen nicht auf Desktop-Computersysteme oder tragbare Computer wie die Intel®-Ultrabooks™-Computer beschränkt und können auch in anderen Vorrichtungen verwendet werden, z. B. handtragbaren Vorrichtungen, Tablets, anderen schmalen Notebooks, Ein-Chip-System-Vorrichtungen (SoC-Vorrichtungen) und eingebetteten Anwendungen. Einige Beispiele für handgetragene Vorrichtungen sind Mobiltelefone, Internetprotokollvorrichtungen, Digitalkameras, persönliche digitale Assistenten (PDAs) und handgetragene PCs. Eingebettete Anwendungen umfassen typischerweise einen Mikrocontroller, eine Digitalsignalverarbeitungsvorrichtung (DSP), ein Ein-Chip-System, Netzcomputer (NetPC), Beistellkästen, Netz-Hubs, Weitbereichsnetz-Switches (WAN-Switches) oder ein anderes System, das die unten beschriebenen Funktionen und Operationen ausführen kann. Es wird beschrieben, dass das System jede Art von Computer oder eingebettetes System sein kann. Die offenbarten Implementierungen können insbesondere für Low-End-Vorrichtungen wie tragbare Vorrichtungen (z. B. Uhren), elektronische Implantate, Sensor- und Steuerungsinfrastrukturvorrichtungen, Controller, Überwachungs- und Datenerfassungssysteme (SCADA-Systeme) oder dergleichen verwendet werden. Darüber hinaus sind die hier beschriebenen Vorrichtungen, Verfahren und Systeme nicht auf physische Rechenvorrichtungen beschränkt, sondern können sich auch auf Softwareoptimierungen zur Energieeinsparung und Effizienz beziehen. Wie in der folgenden Beschreibung leicht ersichtlich wird, sind die hier beschriebenen Implementierungen von Verfahren, Vorrichtungen und Systemen (ob in Bezug auf Hardware, Firmware, Software oder eine Kombination davon) für eine Zukunft mit „grüner Technologie“, die mit Leistungsgedanken kompatibel ist, von entscheidender Bedeutung.
  • Obwohl die Implementierungen hierin unter Bezugnahme auf eine Verarbeitungsvorrichtung beschrieben sind, sind andere Implementierungen auf andere Arten von integrierten Schaltungen und Logikvorrichtungen anwendbar. Ähnliche Techniken und Lehren von Implementierungen der Offenbarung können auf andere Arten von Schaltungen oder Halbleitervorrichtungen angewendet werden, die von einem höheren Pipeline-Durchsatz und einer verbesserten Leistung profitieren können. Die Lehren der Implementierungen der Offenbarung sind auf jede Verarbeitungsvorrichtung oder -maschine anwendbar, die Datenmanipulationen durchführt. Die Offenbarung ist jedoch nicht auf Verarbeitungsvorrichtungen oder -maschinen beschränkt, die 512-Bit-, 256-Bit-, 128-Bit-, 64-Bit-, 32-Bit- oder 16-Bit-Datenoperationen ausführen, und kann auf jede Verarbeitungsvorrichtung und -maschine angewendet werden, bei der eine Manipulation oder Verwaltung von Daten erfolgt. Zudem liefert die Beschreibung hierin Beispiele und die beigefügten Zeichnungen zeigen verschiedene Beispiele zum Zwecke der Veranschaulichung. Diese Beispiele sollten jedoch nicht in einem einschränkenden Sinne ausgelegt werden, da sie lediglich Beispiele für Implementierungen der Offenbarung liefern sollen, und keine erschöpfende Liste aller möglichen Implementierungen der Implementierungen der Offenbarung.
  • Obwohl die folgenden Beispiele die Befehlshandhabung und -verteilung im Kontext von Ausführungseinheiten und Logikschaltungen beschreiben, können andere Implementierungen der Offenbarung über Daten oder Befehle erreicht werden, die auf einem maschinenlesbaren, konkreten Medium gespeichert sind und bei Ausführung durch eine Maschine veranlassen, dass die Maschine Funktionen ausführt, die mit mindestens einer Implementierung der Offenbarung konsistent sind. In einer Implementierung sind Funktionen, die Implementierungen der Offenbarung zugeordnet sind, in maschinenausführbaren Befehlen enthalten. Die Befehle können verwendet werden, um eine Allzweck- oder Spezialverarbeitungsvorrichtung, die mit den Befehlen programmiert ist, dazu zu veranlassen, die Schritte der Offenbarung auszuführen. Implementierungen der Offenbarung können als Computerprogrammprodukt oder Software bereitgestellt werden, was eine Maschine oder ein computerlesbares Medium umfassen kann, auf dem Befehle gespeichert sind, die zum Programmieren eines Computers (oder anderer elektronischer Vorrichtungen) verwendet werden können, um eine oder mehrere Operationen gemäß Implementierungen der Offenbarung auszuführen. Alternativ können Operationen von Implementierungen der Offenbarung von spezifischen Hardwarekomponenten, die eine Logik mit fester Funktion zum Ausführen der Operationen umfassen, oder von einer beliebigen Kombination von programmierten Computerkomponenten und Hardware-Komponenten mit fester Funktion ausgeführt werden.
  • Befehle, die zum Programmieren der Logik zum Ausführen von Implementierungen der Offenbarung verwendet werden, können in einem Speicher in dem System wie beispielsweise einem DRAM, einem Cache, einem Flash-Speicher oder einem anderen Speicher gespeichert werden. Darüber hinaus können die Befehle über ein Netz oder über andere computerlesbare Medien verbreitet werden. Somit kann ein maschinenlesbares Medium einen beliebigen Mechanismus zum Speichern oder Übertragen von Informationen in einer Form, die von einer Maschine (z. B. einem Computer) gelesen werden kann, umfassen ist jedoch nicht auf Disketten, optische Datenträger, Kompaktscheiben-Nur-Lese-Speicher (CD-ROMs) und magnetooptische Festplatten, Nur-Lese-Speicher (ROMs), Direktzugriffsspeicher (RAM), löschbare programmierbare Nur-Lese-Speicher (EPROM), elektrisch löschbare programmierbare Nur-Lese-Speicher (EEPROM), magnetische oder optische Karten, Flash-Speicher oder einen konkreten maschinenlesbaren Speicher, der bei der Übertragung von Informationen über das Internet über elektrische, optische, akustische oder andere Formen von Ausbreitungssignalen (z. B. Trägerwellen, Infrarotsignale, digitale Signale usw.) verwendet wird, beschränkt. Dementsprechend umfasst das computerlesbare Medium jede Art von konkretem maschinenlesbarem Medium, das zum Speichern oder Übertragen elektronischer Befehle oder Informationen in einer von einer Maschine (z. B. einem Computer) lesbaren Form geeignet ist.
  • Ein Entwurf kann verschiedene Phasen durchlaufen, von der Erstellung über die Simulation bis zur Herstellung. Daten, die einen Entwurf darstellen, können den Entwurf auf verschiedene Arten darstellen. Erstens kann die Hardware, wie es in Simulationen nützlich ist, unter Verwendung einer Hardware-Beschreibungssprache oder einer anderen funktionalen Beschreibungssprache dargestellt werden. Zudem kann in einigen Phasen des Entwurfsprozesses ein Modell auf Schaltungsebene mit Logik- und/oder Transistorgattern erstellt werden. Darüber hinaus erreichen die meisten Entwürfe zu einem bestimmten Zeitpunkt eine Ebene von Daten, die die physische Platzierung verschiedener Vorrichtungen im Hardware-Modell darstellen. In dem Fall, in dem herkömmliche Halbleiterherstellungstechniken verwendet werden, können die Daten, die das Hardware-Modell darstellen, die Daten sein, die das Vorhandensein oder Fehlen verschiedener Merkmale auf verschiedenen Maskenschichten für Masken, die zur Herstellung der integrierten Schaltung verwendet werden, spezifizieren. In jeder Darstellung des Entwurfs können die Daten in irgendeiner Form eines maschinenlesbaren Mediums gespeichert werden. Ein Speicher oder ein magnetischer oder optischer Ablagespeicher wie eine Platte kann das maschinenlesbare Medium sein, um Informationen zu speichern, die über optische oder elektrische Wellen übertragen werden, die moduliert oder auf andere Weise erzeugt wurden, um solche Informationen zu übertragen. Wenn eine elektrische Trägerwelle, die den Code oder den Entwurf angibt oder trägt, übertragen wird, wird eine neue Kopie erstellt, sofern das elektrische Signal kopiert, gepuffert oder erneut übertragen wird. Somit kann ein Kommunikationsanbieter oder ein Netzanbieter zumindest vorübergehend auf einem konkreten maschinenlesbaren Medium einen Artikel wie beispielsweise Informationen speichern, die in einer Trägerwelle codiert sind und Techniken zur Implementierung der Offenbarung verkörpern.
  • Ein hier verwendetes Modul bezieht sich auf eine beliebige Kombination von Hardware, Software und/oder Firmware. Beispielsweise umfasst ein Modul Hardware wie beispielsweise einen Mikrocontroller, der einem nichttransitorischen Medium zugeordnet ist, um Code zu speichern, der zur Ausführung durch den Mikrocontroller ausgelegt ist. Daher bezieht sich der Verweis auf ein Modul in einer Implementierung auf die Hardware, die speziell konfiguriert ist, um den Code zu erkennen und/oder auszuführen, der auf einem nichttransitorischen Medium gehalten werden soll. Darüber hinaus bezieht sich in einer weiteren Implementierung die Verwendung eines Moduls auf das nichttransitorische Medium, das den Code enthält, der speziell dazu ausgelegt ist, von dem Mikrocontroller ausgeführt zu werden, um vorbestimmte Operationen auszuführen. Und wie gefolgert werden kann, kann sich der Begriff Modul (in diesem Beispiel) in einer weiteren Implementierung auf die Kombination des Mikrocontrollers und des nichttransitorischen Mediums beziehen. Oft variieren Modulgrenzen, die als getrennt dargestellt werden, und überlappen sich möglicherweise. Beispielsweise können ein erstes und ein zweites Modul Hardware, Software, Firmware oder eine Kombination davon gemeinsam nutzen, während gleichzeitig möglicherweise einiges an unabhängiger Hardware, Software oder Firmware erhalten bleibt. In einer Implementierung umfasst die Verwendung des Begriffs Logik Hardware wie Transistoren, Register oder andere Hardware wie programmierbare Logikvorrichtungen.
  • Die Verwendung des Ausdrucks „ausgelegt für“ in einer Implementierung bezieht sich auf das Anordnen, Zusammenstellen, Herstellen, Anbieten, Verkaufen, Importieren und/oder Entwerfen einer Vorrichtung, Hardware, Logik oder eines Elements, um eine festgelegte oder bestimmte Aufgabe auszuführen. In diesem Beispiel ist eine Einrichtung oder ein Element davon, das nicht in Betrieb ist, immer noch „dazu ausgelegt“, eine bestimmte Aufgabe auszuführen, wenn sie für die Ausführung dieser bestimmten Aufgabe entworfen, gekoppelt und/oder verbunden ist. Als rein veranschaulichendes Beispiel kann ein Logikgatter während des Betriebs eine 0 oder eine 1 liefern. Ein Logikgatter, das „dazu ausgelegt“ ist, ein Freigabesignal an einen zu Takt liefern, umfasst jedoch nicht jedes potentielle Logikgatter, das eine 1 oder 0 liefern kann. Stattdessen ist das Logikgatter in irgendeiner Weise so gekoppelt, dass während des Betriebs die Ausgabe 1 oder 0 den Takt aktivieren soll. Es ist erneut zu beachten, dass die Verwendung des Begriffs „dazu ausgelegt“ keine Operation erfordert, sondern sich auf den latenten Zustand einer Einrichtung, Hardware und/oder eines Elements konzentriert, wobei die Einrichtung, die Hardware und/oder das Element im latenten Zustand dazu ausgelegt ist, eine bestimmte Aufgabe auszuführen, wenn die Einrichtung, die Hardware und/oder das Element in Betrieb ist.
  • Darüber hinaus bezieht sich die Verwendung der Ausdrücke „zu“, „fähig zu“ und/oder „betreibbar für“ in einer Implementierung auf irgendeine Einrichtung, Logik, Hardware und/oder Elemente, die so ausgelegt sind, dass sie die Verwendung der Einrichtung, Logik, Hardware und/oder Elemente in einer bestimmten Weise ermöglichen. Es ist wie oben zu beachten, dass sich die Verwendung von „zu“, „fähig zu“ oder „betreibbar für“ in einer Implementierung auf den latenten Zustand einer Einrichtung, Logik, Hardware und/oder eines Elements bezieht, in dem die Einrichtung, Logik, Hardware und/oder das Element nicht in Betrieb ist, jedoch so ausgelegt ist, dass die Verwendung einer Einrichtung in einer bestimmten Weise möglich ist.
  • Ein Wert, wie er hier verwendet wird, umfasst jede bekannte Darstellung einer Zahl, eines Zustands, eines logischen Zustands oder eines binären logischen Zustands. Oft wird die Verwendung von Logikpegeln, Logikwerten oder logischen Werten auch als Einsen und Nullen bezeichnet, die einfach binäre Logikzustände darstellen. Beispielsweise bezieht sich eine 1 auf einen hohen Logikpegel und eine 0 auf einen niedrigen Logikpegel. In einer Implementierung kann eine Speicherzelle wie beispielsweise ein Transistor oder eine Flash-Zelle einen einzelnen logischen Wert oder mehrere logische Werte enthalten. Es wurden jedoch andere Darstellungen von Werten in Computersystemen verwendet. Zum Beispiel kann die Dezimalzahl zehn auch als ein Binärwert 1010 und ein Hexadezimalbuchstabe A dargestellt werden. Daher umfasst ein Wert jede Darstellung von Informationen, die in einem Computersystem gehalten werden kann.
  • Darüber hinaus können Zustände durch Werte oder Teile von Werten dargestellt werden. Beispielsweise kann ein erster Wert, beispielsweise eine logische Eins, einen standardmäßigen Zustand oder Anfangszustand darstellen, während ein zweiter Wert, beispielsweise eine logische Null, einen nicht standardmäßigen Zustand darstellen kann. Darüber hinaus beziehen sich die Begriffe „zurückgesetzt“ und „gesetzt“ in einer Implementierung auf einen Standardwert bzw. einen aktualisierten Wert bzw. Status. Beispielsweise umfasst ein Standardwert möglicherweise einen hohen logischen Wert, d. h. zurückgesetzt, während ein aktualisierter Wert möglicherweise einen niedrigen logischen Wert umfasst, d. h. gesetzt. Es ist zu beachten, dass eine beliebige Kombination von Werten verwendet werden kann, um eine beliebige Anzahl von Zuständen darzustellen.
  • Die oben beschriebenen Implementierungen von Verfahren, Hardware, Software, Firmware oder Code können über Befehle oder Code implementiert werden, die auf einem maschinenzugänglichen, maschinenlesbaren, computerzugänglichen oder computerlesbaren Medium gespeichert sind und von einem Verarbeitungselement ausgeführt werden können. Ein nichttransitorisches maschinenzugängliches/lesbares Medium umfasst jeden Mechanismus, der Informationen in einer von einer Maschine wie einem Computer oder einem elektronischen System lesbaren Form bereitstellt (d. h. speichert und/oder überträgt). Beispielsweise umfasst ein nichttransitorisches Medium, auf das über eine Maschine zugegriffen werden kann, einen Direktzugriffsspeicher (RAM) wie beispielsweise einen statischen RAM (SRAM) oder einen dynamischen RAM (DRAM); ROM; ein magnetisches oder optisches Speichermedium; Flash-Speichervorrichtungen; elektrische Speichervorrichtungen; optische Speichervorrichtungen; akustische Speichervorrichtungen; andere Formen von Speichervorrichtungen zum Halten von Informationen, die von transitorischen (sich ausbreitenden) Signalen (z. B. Trägerwellen, Infrarotsignale, digitale Signale); usw., die von den nichttransitorischen Medien zu unterscheiden sind, die daraus Informationen erhalten können. Befehle, die zum Programmieren der Logik zum Ausführen von Implementierungen der Offenbarung verwendet werden, können in einem Speicher in dem System wie beispielsweise einem DRAM, einem Cache, einem Flash-Speicher oder einem anderen Speicher gespeichert sein. Darüber hinaus können die Befehle über ein Netz oder über andere computerlesbare Medien verbreitet werden. Somit kann ein maschinenlesbares Medium einen beliebigen Mechanismus zum Speichern oder Übertragen von Informationen in einer Form, die von einer Maschine (z. B. einem Computer) gelesen werden kann, umfassen ist jedoch nicht auf Disketten, optische Datenträger, Kompaktplatten-Nur-Lese-Speicher (CD-ROMs) und magnetooptische Festplatten, Nur-Lese-Speicher (ROMs), Direktzugriffsspeicher (RAM), löschbare programmierbare Nur-Lese-Speicher (EPROM), elektrisch löschbare programmierbare Nur-Lese-Speicher (EEPROM), magnetische oder optische Karten, Flash-Speicher oder einen konkreten maschinenlesbaren Speicher, der bei der Übertragung von Informationen über das Internet über elektrische, optische, akustische oder andere Formen von Ausbreitungssignalen (z. B. Trägerwellen, Infrarotsignale, digitale Signale usw.) verwendet wird, beschränkt. Dementsprechend umfasst das computerlesbare Medium jede Art von materiellem maschinenlesbarem Medium, das zum Speichern oder Übertragen elektronischer Befehle oder Informationen in einer von einer Maschine (z. B. einem Computer) lesbaren Form geeignet ist.
  • Die Bezugnahme in dieser Spezifikation auf „eine Implementierung“ bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, die/das im Zusammenhang mit der Implementierung beschrieben wurde, in mindestens einer Implementierung der Offenbarung enthalten ist. Daher bezieht sich das Auftauchen des Ausdrucks „in einer Implementierung“ an verschiedenen Stellen in dieser Schrift nicht notwendigerweise immer auf dieselbe Implementierung. Darüber hinaus können die besonderen Merkmale, Strukturen oder Eigenschaften in einer oder mehreren Implementierungen auf jede geeignete Weise kombiniert werden.
  • In der vorstehenden Schrift wurde eine genaue Beschreibung unter Bezugnahme auf spezifische beispielhafte Implementierungen gegeben. Es ist jedoch ersichtlich, dass verschiedene Abwandlungen und Änderungen daran vorgenommen werden können, ohne von dem in den beigefügten Ansprüchen dargelegten allgemeineren Gedanken und Umfang der Offenbarung abzuweichen. Die Schrift und die Zeichnungen sind dementsprechend eher als veranschaulichend denn als einschränkend zu betrachten. Darüber hinaus bezieht sich die vorstehende Verwendung von Implementierung, Implementierung und/oder anderer beispielhafter Sprache nicht notwendigerweise auf dieselbe Implementierung oder dasselbe Beispiel, sondern kann sich auf verschiedene und unterschiedliche Implementierungen sowie möglicherweise auf dieselbe Implementierung beziehen.
  • Einige Teile der genauen Beschreibung sind in Form von Algorithmen und symbolischen Darstellungen von Operationen an Datenbits in einem Computerspeicher dargestellt. Diese algorithmischen Beschreibungen und Darstellungen sind die Mittel, die von Fachleuten der Datenverarbeitung verwendet werden, um die Substanz ihrer Arbeit anderen Fachleuten am effektivsten zu vermitteln. Ein Algorithmus wird hier und allgemein als eine selbstkonsistente Folge von Operationen verstanden, die zu einem gewünschten Ergebnis führen. Die Operationen erfordern physikalische Manipulationen physikalischer Größen. Normalerweise, aber nicht unbedingt, liegen diese Größen in Form von elektrischen oder magnetischen Signalen vor, die gespeichert, übertragen, kombiniert, verglichen und auf andere Weise manipuliert werden können. Es hat sich manchmal als zweckmäßig erwiesen, diese Signale hauptsächlich aus Gründen des allgemeinen Gebrauchs als Bits, Werte, Elemente, Symbole, Zeichen, Begriffe, Zahlen oder dergleichen zu bezeichnen. Die hier beschriebenen Blöcke können Hardware, Software, Firmware oder eine Kombination davon sein.
  • Es ist jedoch zu beachten, dass alle diese und ähnliche Begriffe den entsprechenden physikalischen Größen zugeordnet werden müssen und lediglich zweckmäßige Bezeichnungen für diese Größen sind. Sofern aus der obigen Diskussion nicht ausdrücklich etwas anderes hervorgeht, wird davon ausgegangen, dass in der gesamten Beschreibung Diskussionen, bei denen Begriffe wie „Definieren“, „Empfangen“, „Bestimmen“, „Ausgeben“, „Verknüpfen“, „Zuordnen“, „Erhalten“, „Authentifizieren“, „Verbieten“, „Ausführen“, „Anfordern“, „Kommunizieren“ oder dergleichen verwendet werden, sich auf die Aktionen und Prozesse eines Rechensystems oder einer ähnlichen elektronischen Rechenvorrichtung beziehen, die die als physikalische (z. B. elektronische) Größen dargestellten Daten in den Registern und Speichern des Rechensystems in andere Daten manipuliert und transformiert, die in ähnlicher Weise als physikalische Größen in den Speichern oder Registern des Rechensystems oder anderen derartigen Informationsspeicher-, Übertragungs- oder Anzeigevorrichtungen dargestellt sind.
  • Die Wörter „Beispiel“ oder „beispielhaft“ werden hier für als Beispiel, Instanz oder Veranschaulichung dienend verwendet. Jeder Aspekt oder Entwurf, der hier als „Beispiel“ oder „beispielhaft“ beschrieben ist, ist nicht notwendigerweise als bevorzugt oder vorteilhaft gegenüber anderen Aspekten oder Entwürfen auszulegen. Die Verwendung der Wörter „Beispiel“ oder „beispielhaft“ soll vielmehr Konzepte konkret darstellen. Wie er in dieser Anmeldung verwendet wird, soll der Begriff „oder“ eher ein inklusives „oder“ als ein exklusives „oder“ bedeuten. Das heißt, sofern nicht etwa anderes angegeben oder aus dem Kontext ersichtlich ist, soll „X umfasst A oder B“ beliebige der natürlichen einschließlichen Permutationen umfassen. Das heißt, wenn X A umfasst; umfasst X B; oder X umfasst sowohl A als auch B, dann ist „X umfasst A oder B“ unter beliebiger der vorstehenden Instanzen erfüllt. Darüber hinaus sollten die Artikel „eine/r/s“, wie sie in dieser Anmeldung verwendet werden, und die beigefügten Ansprüche im Allgemeinen so ausgelegt werden, dass sie „ein oder mehrere“ bedeuten, sofern nichts anderes angegeben ist oder aus dem Kontext ersichtlich ist, dass auf eine Einzahlform abgezielt wird. Darüber hinaus soll die Verwendung des Begriffs „eine Implementierung“ oder „eine Implementierung“ oder „eine Implementierung“ oder „eine Implementierung“ nicht dieselbe Implementierung oder Implementierung bedeuten, es sei denn, sie wird solchermaßen beschrieben. Auch die hier verwendeten Begriffe „erste/r/s“, „zweite/r/s“, „dritte/r/s“, „vierte/r/s“ usw. sind als Bezeichnungen zur Unterscheidung zwischen verschiedenen Elementen gedacht und müssen nicht unbedingt eine ordnende Bedeutung gemäß ihrer numerischen Bezeichnung haben.

Claims (9)

  1. Verarbeitungsvorrichtung, die Folgendes umfasst: einen Prozessorkern zum Ausführen eines Hypervisors, wobei der Prozessorkern ein Hardware-Register umfasst, um Folgendes zu speichern: einen Bitbereich zum Identifizieren einer ersten Anzahl von Adressbits von physischen Speicheradressen, die Schlüsselkennungen (Schlüssel-IDs) definieren; und eine Aufteilungsschlüssel-ID der Schlüssel-IDs, um eine Grenze zwischen nicht beschränkten Schlüssel-IDs und beschränkten Schlüssel-IDs der Schlüssel-IDs zu identifizieren; und wobei der Prozessorkern Folgendes ausführen soll: Zuweisen mindestens einer der nicht beschränkten Schlüssel-IDs zur Verwendung durch den Hypervisor; und Zuweisen einer ersten Schlüssel-ID der Schlüssel-IDs zu einer ersten Vertrauensdomäne einer Vertrauensdomäneninfrastruktur, wobei die erste Schlüssel-ID eine der beschränkten Schlüssel-IDs ist; und einen Speicher-Controller, der mit dem Prozessorkern gekoppelt ist, um der ersten Vertrauensdomäne eine erste physische Seite eines Speichers zuzuweisen, wobei Daten der ersten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der ersten Schlüssel-ID zugeordnet ist.
  2. Verarbeitungsvorrichtung nach Anspruch 1, wobei der Bitbereich einen ersten Bitunterbereich von nicht beschränkten Bits und einen zweiten Bitunterbereich von beschränkten Bits umfasst, wobei für die nicht beschränkten Schlüssel-IDs jedes der beschränkten Bits einen ersten Binärwert haben soll und wobei für die beschränkten Schlüssel-IDs mindestens eines der beschränkten Bits einen zweiten Binärwert haben soll, der sich von dem ersten Binärwert unterscheidet.
  3. Verarbeitungsvorrichtung nach Anspruch 2, wobei der Speicher-Controller ferner Folgendes ausführen soll: Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, die der ersten Vertrauensdomäne zugeordnet ist, wobei die Speichertransaktion eine physische Speicheradresse der physischen Seite des Speichers und eine Anforderungsschlüssel-ID umfasst; und Erzeugen eines Fehlers als Antwort auf eine Bestimmung, dass mindestens eines der beschränkten Bits der Anforderungsschlüssel-ID den zweiten Binärwert hat.
  4. Verarbeitungsvorrichtung nach einem der Ansprüche 1 bis 3, wobei der Speicher-Controller ferner einen Fehler als Antwort auf das Detektieren einer Speichertransaktion erzeugen soll, die von einem Software-Programm außerhalb einer vertrauenswürdigen Rechenbasis (TCB) der ersten Vertrauensdomäne initiiert wird und auf die erste physische Seite des Speichers gerichtet ist.
  5. Verarbeitungsvorrichtung nach einem der Ansprüche 1 bis 4, wobei der Prozessorkern ferner eine zweite Schlüssel-ID einer zweiten Vertrauensdomäne zuweisen soll, wobei die zweite Schlüssel-ID eine der beschränkten Schlüssel-IDs ist und wobei der Speicher-Controller ferner Folgendes ausführen soll: Zuweisen einer zweiten physischen Seite des Speichers zu der zweiten Vertrauensdomäne, wobei Daten auf der zweiten physischen Seite des Speichers mit einem Kryptographieschlüssel verschlüsselt werden sollen, der der zweiten Schlüssel-ID zugeordnet ist; Speichern der Zuweisung der ersten Schlüssel-ID zu der ersten Vertrauensdomäne und der Zuweisung der zweiten Schlüssel-ID zu der zweiten Vertrauensdomäne in einer Schlüsselbesitztabelle (KOT); und Speichern einer ersten Vertrauensdomänenkennung, die die Zuweisung der ersten physischen Seite des Speichers zu der ersten Vertrauensdomäne identifiziert, und einer zweiten Vertrauensdomänenkennung, die die Zuweisung der zweiten physischen Seite des Speichers zu der zweiten Vertrauensdomäne identifiziert, in einer Speicherbesitztabelle (MOT).
  6. Verarbeitungsvorrichtung nach Anspruch 5, wobei der Speicher-Controller ferner Folgendes ausführen soll: Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, wobei die Speichertransaktion eine physische Speicheradresse der ersten physischen Seite des Speichers und die zweite Schlüssel-ID umfasst; Zurückgreifen auf die MOT, um zu bestimmen, dass die zweite Schlüssel-ID kein korrektes Attribut der ersten physischen Seite des Speichers ist; und Erzeugen eines Fehlers.
  7. Verarbeitungsvorrichtung nach Anspruch 5, wobei der Speicher-Controller ferner Folgendes ausführen soll: Detektieren einer Speichertransaktion, die auf die erste physische Seite des Speichers gerichtet ist, wobei die Speichertransaktion aus der zweiten Vertrauensdomäne stammt und eine Speicheradresse der ersten physischen Seite des Speichers und die erste Schlüssel-ID umfasst; Zurückgreifen auf die KOT, um zu bestimmen, dass die erste Schlüssel-ID nicht der zweiten Vertrauensdomäne zugewiesen ist; und Erzeugen eines Fehlers.
  8. Verarbeitungsvorrichtung nach einem der Ansprüche 1 bis 7, wobei der Hypervisor ferner Folgendes ausführen soll: Markieren der ersten physischen Seite, die einer ersten physischen Speicheradresse des Speichers zugeordnet ist, als privat, wobei das Markieren ein Löschen eines Werts eines gemeinsam genutzten Bits (s-Bits) in einem Eintrag für eine physische Gastadresse, die der ersten physischen Seite zugeordnet ist, innerhalb eines Satzes von erweiterten Seitentabellen (EPT) für die erste Vertrauensdomäne umfasst; Übersetzen einer virtuellen Gastadresse in die physische Gastadresse unter Verwendung eines Satzes von Gastseitentabellen, Übersetzen der physischen Gastadresse in die erste physische Speicheradresse unter Verwendung der EPT; Abrufen der ersten Schlüssel-ID aus einem sicheren Speicher des Prozessors basierend auf dem Wert des s-Bits in der physischen Gastadresse; und Erzeugen einer Speichertransaktion, die die erste Schlüssel-ID und die erste physische Speicheradresse umfasst.
  9. Verarbeitungsvorrichtung nach einem der Ansprüche 1 bis 8, wobei der Hypervisor ferner Folgendes ausführen soll: Zuweisen einer zweiten Schlüssel-ID zu der ersten Vertrauensdomäne, wobei die zweite Schlüssel-ID eine der nicht beschränkten Schlüssel-IDs ist; Markieren einer zweiten physischen Seite, die einer zweiten gemeinsam genutzten physischen Speicheradresse des Speichers zugeordnet ist, wobei das Markieren ein Setzen eines Werts eines gemeinsam genutzten Bits (s-Bits) in einem Eintrag innerhalb eines Satzes von erweiterten Seitentabellen (EPT) für die erste Vertrauensdomäne für eine physische Gastadresse, die der zweiten physischen Seite zugeordnet ist, umfasst; Übersetzen einer virtuellen Gastadresse in die physische Gastadresse unter Verwendung eines Satzes von Gastseitentabellen; Übersetzen der physischen Gastadresse unter Verwendung der EPT und basierend auf dem Wert des s-Bit, um eine Kombination aus der zweiten physischen Speicheradresse und der zweiten Schlüssel-ID aus einem Eintrag in der EPT zu erhalten; und Erzeugen einer Speichertransaktion, die die zweite Schlüssel-ID und die zweite physische Speicheradresse umfasst.
DE202019005671.8U 2018-12-20 2019-10-16 Koexistenz von Vertrauensdomänenarchitektur mitMehrschlüssel-Gesamtspeicherverschlüsselungstechnologieauf Servern Active DE202019005671U1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/227,386 2018-12-20
US16/227,386 US11461244B2 (en) 2018-12-20 2018-12-20 Co-existence of trust domain architecture with multi-key total memory encryption technology in servers

Publications (1)

Publication Number Publication Date
DE202019005671U1 true DE202019005671U1 (de) 2021-07-29

Family

ID=68290184

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202019005671.8U Active DE202019005671U1 (de) 2018-12-20 2019-10-16 Koexistenz von Vertrauensdomänenarchitektur mitMehrschlüssel-Gesamtspeicherverschlüsselungstechnologieauf Servern

Country Status (4)

Country Link
US (1) US11461244B2 (de)
EP (1) EP3671521A1 (de)
CN (1) CN111353158A (de)
DE (1) DE202019005671U1 (de)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11429412B2 (en) * 2016-02-25 2022-08-30 Red Hat Israel, Ltd. Guest protection from application code execution in kernel mode
EP3561778A1 (de) 2018-04-26 2019-10-30 Promaton Holding B.V. Automatisierte korrektur von metallbehafteten voxeldarstellungen von röntgendaten mit hilfe von tiefenlerntechniken
US11954026B1 (en) * 2018-09-18 2024-04-09 Advanced Micro Devices, Inc. Paging hierarchies for extended page tables and extended page attributes
US11176054B2 (en) 2019-03-08 2021-11-16 International Business Machines Corporation Host virtual address space for secure interface control storage
US11455398B2 (en) * 2019-03-08 2022-09-27 International Business Machines Corporation Testing storage protection hardware in a secure virtual machine environment
US11487906B2 (en) 2019-03-08 2022-11-01 International Business Machines Corporation Storage sharing between a secure domain and a non-secure entity
US11068310B2 (en) 2019-03-08 2021-07-20 International Business Machines Corporation Secure storage query and donation
US11283800B2 (en) * 2019-03-08 2022-03-22 International Business Machines Corporation Secure interface control secure storage hardware tagging
US11640361B2 (en) 2019-03-08 2023-05-02 International Business Machines Corporation Sharing secure memory across multiple security domains
US11182192B2 (en) 2019-03-08 2021-11-23 International Business Machines Corporation Controlling access to secure storage of a virtual machine
US11531627B2 (en) * 2019-03-08 2022-12-20 International Business Machines Corporation Secure storage isolation
US11782713B1 (en) * 2019-08-27 2023-10-10 Amazon Technologies, Inc. Security vulnerability mitigation using address space co-execution
EP3819774B1 (de) 2019-11-06 2022-05-25 Microsoft Technology Licensing, LLC Vertraulicher rechenmechanismus
EP3819775A1 (de) * 2019-11-06 2021-05-12 Microsoft Technology Licensing, LLC Vertraulicher rechenmechanismus
US11436342B2 (en) * 2019-12-26 2022-09-06 Intel Corporation TDX islands with self-contained scope enabling TDX KeyID scaling
US11556395B2 (en) * 2020-01-24 2023-01-17 Microsoft Technology Licensing, Llc Data race detection with per-thread memory protection
US11500747B2 (en) * 2020-01-30 2022-11-15 Dell Products L.P. Computer initialization debug message display system
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
US20210109870A1 (en) * 2020-12-23 2021-04-15 Ravi L. Sahita Isolating memory within trusted execution environments
EP4315075A1 (de) * 2021-03-26 2024-02-07 INTEL Corporation Vorrichtung und verfahren zur implementierung eines gemeinsamen virtuellen speichers in einer vertrauenswürdigen zone
US11709786B2 (en) * 2021-04-29 2023-07-25 Renesas Electronic Corporation Device and method of secure decryption by virtualization and translation of physical encryption keys
GB2618128B (en) * 2022-04-28 2024-04-24 Advanced Risc Mach Ltd Protecting execution environments within domains
US11977496B1 (en) 2022-09-29 2024-05-07 Amazon Technologies, Inc. Security vulnerability mitigation using hardware-supported context-dependent address space hiding
CN117272350B (zh) * 2023-11-16 2024-02-13 苏州元脑智能科技有限公司 数据加密密钥管理方法、装置、存储控制卡及存储介质

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2385951A (en) * 2001-09-21 2003-09-03 Sun Microsystems Inc Data encryption and decryption
US7925938B2 (en) * 2001-10-12 2011-04-12 Geneticware Co. Ltd. Structure and method of repairing SDRAM by generating slicing table of fault distribution
TWI224735B (en) * 2002-10-25 2004-12-01 Via Tech Inc Method for storing and accessing data in random bit range between different platforms
US7305526B2 (en) * 2004-11-05 2007-12-04 International Business Machines Corporation Method, system, and program for transferring data directed to virtual memory addresses to a device memory
FR2910145A1 (fr) * 2006-12-18 2008-06-20 St Microelectronics Sa Procede et dispositif pour securiser la lecture d'une memoire.
JP5268595B2 (ja) * 2008-11-28 2013-08-21 ソニー株式会社 画像処理装置、画像表示方法及び画像表示プログラム
US9602276B2 (en) * 2010-06-11 2017-03-21 Qualcomm Incorporated Method and apparatus for virtual pairing with a group of semi-connected devices
US8972746B2 (en) * 2010-12-17 2015-03-03 Intel Corporation Technique for supporting multiple secure enclaves
CN103052946A (zh) * 2011-07-01 2013-04-17 松下电器产业株式会社 存储器访问控制装置及制造方法
US8958817B1 (en) * 2012-01-19 2015-02-17 Google Inc. Weighted-distance spatial indexing
US20140047236A1 (en) * 2012-08-07 2014-02-13 International Business Machines Corporation Authenticated file handles for network file systems
EP2965254B1 (de) * 2013-03-08 2020-05-13 Robert Bosch GmbH Vorrichtungen und verfahren zum aufrechterhalten der integrität und geheimhaltung und in unsicheren datenverarbeitungsplattformen
US9607071B2 (en) * 2014-03-07 2017-03-28 Adobe Systems Incorporated Managing a distributed database across a plurality of clusters
FR3024003B1 (fr) * 2014-07-21 2018-10-19 Morpho Dispositif et procede d'authentification de document
GB2529214B (en) * 2014-08-14 2016-10-19 Soloprotect Ltd An identity card holder and system
GB2539429B (en) * 2015-06-16 2017-09-06 Advanced Risc Mach Ltd Address translation
GB2539433B8 (en) * 2015-06-16 2018-02-21 Advanced Risc Mach Ltd Protected exception handling
GB2539428B (en) * 2015-06-16 2020-09-09 Advanced Risc Mach Ltd Data processing apparatus and method with ownership table
GB2539436B (en) * 2015-06-16 2019-02-06 Advanced Risc Mach Ltd Secure initialisation
GB2539435B8 (en) * 2015-06-16 2018-02-21 Advanced Risc Mach Ltd Data processing memory access control, in which an owning process for a region of memory is specified independently of privilege level
US10142303B2 (en) * 2015-07-07 2018-11-27 Qualcomm Incorporated Separation of software modules by controlled encryption key management
US10223289B2 (en) * 2015-07-07 2019-03-05 Qualcomm Incorporated Secure handling of memory caches and cached software module identities for a method to isolate software modules by means of controlled encryption key management
US10102370B2 (en) * 2015-12-21 2018-10-16 Intel Corporation Techniques to enable scalable cryptographically protected memory using on-chip memory
US10310774B2 (en) * 2015-12-24 2019-06-04 Intel Corporation Techniques for data storage protection and integrity checking
US10261919B2 (en) * 2016-07-08 2019-04-16 Hewlett Packard Enterprise Development Lp Selective memory encryption
US10810321B2 (en) * 2016-08-11 2020-10-20 Intel Corporation Secure public cloud
US10255202B2 (en) * 2016-09-30 2019-04-09 Intel Corporation Multi-tenant encryption for storage class memory
US10402574B2 (en) * 2016-12-30 2019-09-03 Intel Corporation Techniques for multi-domain memory encryption
US10776369B2 (en) * 2017-06-21 2020-09-15 Citrix Systems, Inc. Systems and methods of sharing a database across multiple deployments and services
US11030117B2 (en) * 2017-07-14 2021-06-08 Advanced Micro Devices, Inc. Protecting host memory from access by untrusted accelerators
US11349659B2 (en) * 2017-08-29 2022-05-31 Amazon Technologies, Inc. Transmitting an encrypted communication to a user in a second secure communication network
US10691813B2 (en) * 2018-03-30 2020-06-23 Intel Corporation Techniques for enclave confidentiality management
US11397692B2 (en) * 2018-06-29 2022-07-26 Intel Corporation Low overhead integrity protection with high availability for trust domains
US11099878B2 (en) * 2019-06-28 2021-08-24 Intel Corporation Scalable virtual machine operation inside trust domains within the trust domain architecture
US20220121447A1 (en) * 2021-12-23 2022-04-21 Intel Corporation Hardening cpu predictors with cryptographic computing context information

Also Published As

Publication number Publication date
EP3671521A1 (de) 2020-06-24
US11461244B2 (en) 2022-10-04
CN111353158A (zh) 2020-06-30
US20200201786A1 (en) 2020-06-25

Similar Documents

Publication Publication Date Title
DE202019005671U1 (de) Koexistenz von Vertrauensdomänenarchitektur mitMehrschlüssel-Gesamtspeicherverschlüsselungstechnologieauf Servern
EP3671515B1 (de) Verfahren und vorrichtung zur erstellung und zerstörung von vertrauenswürdigen domänen
EP3657378B1 (de) Bereitstellung von isolierung in virtualisierten systemen unter verwendung von vertrauensdomänen
DE102019109088A1 (de) Schutz von schlüsseln und sensitiven daten gegen angriffe in einer mikroprozessorarchitektur
DE102018126731A1 (de) Freigabeanweisung, um Seitenblock während des Auslagerns umzukehren
DE112017004017T5 (de) Sichere öffentliche cloud
DE10195999B3 (de) Computersystem mit einer in einem Chipsatz enthaltenen Speichersteuereinrichtung zum Kontrollieren von Zugriffen auf einen isolierten Speicher für eine isolierte Ausführung
EP3757839B1 (de) Skalierbarer betrieb einer virtuellen maschine innerhalb einer vertrauensdomäne innerhalb einer vertrauensdomänenarchitektur
DE112017003483T5 (de) Eingeschränkte adressumsetzung zum schutz vor vorrichtungs-tlb-anfälligkeiten
DE202019005672U1 (de) System zum Verhindern eines unautorisierten Zugriffs auf verschlüsselten Speicher
DE102018125747A1 (de) Unterstützung für eine höhere anzahl von gleichzeitigenschlüsseln in einer kryptografie-engine mit mehrerenschlüsseln
DE102018000886A1 (de) Virtuelle Maschinenkommunikation auf Hardware-Basis
DE102018005180A1 (de) Flexible Bescheinigung von Containern
CN114902225A (zh) 多租户环境中的密码计算
DE102015006863A1 (de) Befehle und Logik zum Unterbrechen und Wiederaufnehmen von Paging in Secure Enclaves
DE102014004563A1 (de) Befehle und Logik zur Bereitstellung verbesserter Paging-Fähigkeiten für Secure Enclave-Seitencaches
DE102019126125A1 (de) System, vorrichtung und verfahren zum integritätsschutz von kunden-arbeitslasten in einer mehrkunden-datenverarbeitungsumgebung
DE202017007430U1 (de) Erkennen von Bussperrbedingungen und Vermeiden von Bussperren
DE112017005005T5 (de) Systeme, vorrichtungen, und verfahren zur plattformsicherheit
DE112019006898T5 (de) Dynamisches umschalten zwischen ept- und schattenseitentabellen zur laufzeitprozessorverifikation
DE102020126293A1 (de) Vorrichtungen, verfahren und systeme für anweisungen für kryptografisch an daten gebundene nutzungsbeschränkungen
DE202019005686U1 (de) Skalierbare Gesamtspeicherverschlüsselungs-Engine mit mehrfachen Schlüsseln
DE112010003942T5 (de) Einrichtung zum Setzen von Schlüsseln ohne Stilllegung
CN112149125A (zh) 使用与高速缓存行有关的存储器所有权位防止信任域访问
DE102020128050A1 (de) Tdx-inseln mit in sich abgeschlossenem geltungsbereich, wodurch eine tdx-schlüsselkennungsskalierung ermöglicht wird

Legal Events

Date Code Title Description
R207 Utility model specification
R150 Utility model maintained after payment of first maintenance fee after three years