DE102020126293A1 - Vorrichtungen, verfahren und systeme für anweisungen für kryptografisch an daten gebundene nutzungsbeschränkungen - Google Patents

Vorrichtungen, verfahren und systeme für anweisungen für kryptografisch an daten gebundene nutzungsbeschränkungen Download PDF

Info

Publication number
DE102020126293A1
DE102020126293A1 DE102020126293.0A DE102020126293A DE102020126293A1 DE 102020126293 A1 DE102020126293 A1 DE 102020126293A1 DE 102020126293 A DE102020126293 A DE 102020126293A DE 102020126293 A1 DE102020126293 A1 DE 102020126293A1
Authority
DE
Germany
Prior art keywords
instruction
handle
data
ciphertext
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020126293.0A
Other languages
English (en)
Inventor
Jason W. Brandt
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 DE102020126293A1 publication Critical patent/DE102020126293A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30025—Format conversion instructions, e.g. Floating-Point to Integer, decimal conversion
    • 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/3017—Runtime instruction translation, e.g. macros
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/75—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information by inhibiting the analysis of circuitry or operation
    • G06F21/755—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information by inhibiting the analysis of circuitry or operation with measures against power attack
    • 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/3017—Runtime instruction translation, e.g. macros
    • G06F9/30178—Runtime instruction translation, e.g. macros of compressed or encrypted instructions
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2149—Restricted operating environment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/04—Masking or blinding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/125—Parallelization or pipelining, e.g. for accelerating processing of cryptographic operations

Landscapes

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

Abstract

Es werden Systeme, Verfahren und Vorrichtungen in Bezug auf eine Schaltungsanordnung zum Implementieren einer Anweisung zum Erzeugen und/oder Verwenden von Daten beschrieben, die in Bezug darauf beschränkt sind, wie sie verwendet werden können. In einer Ausführungsform umfasst ein Hardwareprozessor einen Decoder eines Kerns zum Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung, wobei die Einzelanweisung einen ersten Eingabeoperanden eines Handles, das einen Chiffretext eines Verschlüsselungsschlüssels (z. B. eines kryptografischen Schlüssels), ein Authentisierungstag und zusätzliche Authentisierungsdaten umfasst, und einen zweiten Eingabeoperanden von Daten aufweist, die mit dem Verschlüsselungsschlüssel verschlüsselt sind; und eine Ausführungseinheit des Kerns zum Ausführen der decodierten Einzelanweisung zum: Durchführen eines ersten Vergleichs des Authentisierungstags mit dem Chiffretext und den zusätzlichen Authentisierungsdaten hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten, Durchführen eines zweiten Vergleichs einer aktuellen Anforderung des Kerns mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten des Handles spezifizierten Beschränkungen, Entschlüsseln des Chiffretexts zum Erzeugen des Verschlüsselungsschlüssels nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde, Entschlüsseln der mit dem Verschlüsselungsschlüssel verschlüsselten Daten, um unverschlüsselte Daten zu erzeugen, und Bereitstellen der unverschlüsselten Daten als eine Resultierende der Einzelanweisung.

Description

  • TECHNISCHES GEBIET
  • Die Offenbarung betrifft im Allgemeinen die Elektronik, und insbesondere betrifft eine Ausführungsform der Offenbarung eine Schaltungsanordnung zum Implementieren einer Anweisung zum Erzeugen und/oder Verwenden von Daten, die in Bezug darauf beschränkt sind, wie sie verwendet werden können.
  • HINTERGRUND
  • Ein Prozessor oder ein Satz von Prozessoren führt Anweisungen aus einem Anweisungssatz, z. B. der Anweisungssatzarchitektur (ISA - Instruction Set Architecture), aus. Der Anweisungssatz ist der Teil der Computerarchitektur, der mit Programmierung in Beziehung steht, und umfasst im Allgemeinen die nativen Datentypen, Anweisungen, Registerarchitektur, Adressiermodi, Speicherarchitektur, Interrupt- und Ausnahmenhandhabung sowie externe Eingabe und Ausgabe (E/A). Es ist zu erwähnen, dass der Begriff „Anweisung“ hierin sich auf eine Makroanweisung, z. B. eine Anweisung, die für den Prozessor zur Ausführung bereitgestellt wird, oder auf eine Mikroanweisung, z. B. eine Anweisung, die aus Decodierungs-Makroanweisungen eines Decoders des Prozessors resultiert, beziehen kann.
  • Figurenliste
  • Die vorliegende Offenbarung wird in den Figuren der beiliegenden Zeichnungen, in welchen gleiche Bezugszeichen ähnliche Elemente anzeigen, lediglich als Beispiel und nicht als Einschränkung veranschaulicht, wobei:
    • 1 ein Blockdiagramm eines Mehrkern-Hardwareprozessors veranschaulicht, der ein Handle gemäß Ausführungsformen der Offenbarung verwendet.
    • 2 veranschaulicht einen Hardwareprozessor, der mit einem Speicher gekoppelt ist, der eine oder mehrere Verschlüsselungs- und Entschlüsselungsanweisungen umfasst, die ein Handle gemäß Ausführungsformen der Offenbarung verwenden.
    • 3 veranschaulicht einen Hardwareprozessor, der mit einem Speicher gekoppelt ist, der eine oder mehrere Internen-Schlüssel-laden-Anweisungen umfasst, die ein Handle gemäß Ausführungsformen der Offenbarung verwenden.
    • 4 veranschaulicht einen Hardwareprozessor, der mit einem Speicher gekoppelt ist, der eine oder mehrere Handle-Erzeugungsanweisungen gemäß Ausführungsformen der Offenbarung umfasst.
    • Figure 5 veranschaulicht Ausführung einer ersten „Internen-Schlüssel-laden“-Anweisung zum Laden eines ersten Gastschlüssels und Ausführung einer zweiten „Internen Schlüssel laden“-Anweisung zum Laden eines zweiten Gastschlüssels gemäß Ausführungsformen der Offenbarung.
    • Figure 6 veranschaulicht ein Verfahren zur Verarbeitung einer Entschlüsselungsanweisung unter Verwendung eines Handles gemäß Ausführungsformen der Offenbarung.
    • 7A ist ein Blockdiagramm, das ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen der Klasse A davon gemäß Ausführungsformen der Offenbarung veranschaulicht.
    • 7B ist ein Blockdiagramm, welches das generische vektorfreundliche Anweisungsformat und Anweisungsvorlagen der Klasse B davon gemäß Ausführungsformen der Offenbarung veranschaulicht.
    • 8A ist ein Blockdiagramm, das Felder für die generischen vektorfreundlichen Anweisungsformate in 7A und 7B gemäß Ausführungsformen der Offenbarung veranschaulicht.
    • 8B ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats in 8A veranschaulicht, die ein vollständiges Opcode-Feld gemäß einer Ausführungsform der Offenbarung bilden.
    • 8C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats in 8A veranschaulicht, die ein Registerindexfeld gemäß einer Ausführungsform der Offenbarung bilden.
    • 8D ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats in 8A veranschaulicht, die das Erweiterungsoperationsfeld 750 gemäß einer Ausführungsform der Offenbarung bilden.
    • 9 ist ein Blockdiagramm einer Registerarchitektur gemäß einer Ausführungsform der vorliegenden Erfindung.
    • 10A ist ein Blockdiagramm, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs- und Out-of-Order-Ausgabe-/Ausführungs-Pipeline gemäß Ausführungsformen der Offenbarung veranschaulicht.
    • 10B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines Kerns mit In-Order-Architektur als auch eines beispielhaften Kerns mit Registerumbenennungs- und Out-of-Order-Ausgabe-/Ausführungsarchitektur veranschaulicht, die in einen Prozessor gemäß Ausführungsformen der Offenbarung integriert werden sollen.
    • 11A ist ein Blockdiagramm eines einzigen Prozessorkerns zusammen mit seiner Verbindung zum chipinternen Zwischenverbindungsnetzwerk und mit seinem lokalen Teilsatz des Caches der Ebene 2 (L2) gemäß Ausführungsformen der Offenbarung.
    • 11B ist eine erweiterte Ansicht des Prozessorkerns in 11A gemäß Ausführungsformen der Offenbarung.
    • 12 ist ein Blockdiagramm eines Prozessors gemäß Ausführungsformen der Offenbarung, der mehr als einen Kern aufweisen kann, eine integrierte Speichersteuerung aufweisen kann, und integrierte Grafik aufweisen kann.
    • 13 ist ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Offenbarung.
    • 14 ist ein Blockdiagramm eines spezifischeren beispielhaften Systems gemäß einer Ausführungsform der vorliegenden Offenbarung.
    • 15 ist ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems gemäß einer Ausführungsform der vorliegenden Offenbarung.
    • 16 stellt ein Blockdiagramm eines Systemchips (SoC) gemäß einer Ausführungsform der vorliegenden Erfindung, dar.
    • 17 ist ein Blockdiagramm, das die Verwendung eines Softwareanweisungsumsetzers zum Umsetzen von Binäranweisungen in einem Quellenanweisungssatz in Binäranweisungen in einem Zielanweisungssatz gemäß Ausführungsformen der Offenbarung vergleicht.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt. Es versteht sich jedoch, dass Ausführungsformen der Offenbarung ohne diese spezifischen Einzelheiten in die Praxis umgesetzt werden können. In anderen Fällen wurden allgemein bekannte Schaltungen, Strukturen und Techniken nicht im Detail dargestellt, um das Verständnis dieser Beschreibung nicht zu erschweren.
  • Bezugnahmen in der Spezifikation auf „eine (konkrete) Ausführungsform“, „(irgend)eine Ausführungsform“, „eine beispielhafte Ausführungsform“ usw. weisen darauf hin, dass die beschriebene Ausführungsform eine bestimmte Funktion, Struktur oder Charakteristik umfassen kann, aber nicht unbedingt jede Ausführungsform die bestimmte Funktion, Struktur oder Charakteristik umfassen muss. Außerdem beziehen sich solche Ausdrücke nicht unbedingt auf die gleiche Ausführungsform. Es wird ferner der Anspruch erhoben, dass, wenn eine bestimmte Funktion, Struktur oder Charakteristik in Verbindung mit einer Ausführungsform beschrieben wird, ein Fachmann über die Kenntnisse verfügt, um solch eine Funktion, Struktur oder Charakteristik in Verbindung mit anderen Ausführungsformen nachzuvollziehen, einerlei ob ausdrücklich beschrieben oder nicht.
  • Ein Hardwareprozessor kann einen Verschlüsselungsschlüssel (z. B. einen kryptografischen Schlüssel) zum Verschlüsseln und/oder Entschlüsseln von Daten, zum Beispiel Daten, die vor einem Angreifer geschützt werden sollen, verwenden. Die Ausführungsformen entschärfen Szenarien von Hardware- und Softwareangriffen, die den zugrunde liegenden Schlüssel, z. B. einen Schlüssel gemäß einem Advanced Encryption Standard (AES), stehlen. Bestimmte Ausführungsformen beschränken Operationen auf die Art und Weise, in der sie verwendet werden sollen, damit ein Angreifer, der die verschlüsselten Daten stiehlt, nicht darauf zugreifen kann. In einer Ausführungsform ist ein Verschlüsselungsschlüssel zur Verschlüsselung von Daten (z. B. eines Datenträgers) darauf beschränkt, dass er nur im OS, aber nicht in einer Anwendung verwendet werden kann. In bestimmten Ausführungsformen setzt ein Prozessor
    (z. B. auf Wunsch von Software) Schlüssel in jeweilige „Handles“ um, die den Schlüsselwert nicht erkennen lassen (wobei z. B. der Originalschlüssel dann aus dem Speicher gelöscht wird), und dann führt der Prozessor Verschlüsselung und/oder Entschlüsselung mit dem Handle unter Verwendung einer oder mehrerer der hierin offenbarten Anweisungen durch. In bestimmten Ausführungsformen kann ein spezifisches Handle auf anderen Systemen oder nach Annullierung (z. B. nach einem Neustart) nicht verwendet werden. Handles können mit Beschränkungen in Bezug darauf, was erlaubt ist, spezifiziert sein, zum Beispiel wird das Handle nur durch ein Betriebssystem (OS - Operating System) verwendet, wird das Handle nur für Verschlüsselung verwendet, oder wird das Handle nur für Entschlüsselung verwendet. Nicht einschränkende Nutzungen der Anweisungen und Verfahren hierin sind für kryptografische Bibliotheken, Datenträgerverschlüsselung, Networking, jegliche Software, die einen Verschlüsselungsstandard (beispielsweise AES) verwendet. In einer Ausführungsform besteht eine Verwendung für eine kryptografische Bibliothek darin, Anwendungen die Verwendung des Handles zu entziehen (z. B. zu verheimlichen).
  • In bestimmten Ausführungsformen umfasst eine Anweisungssatzarchitektur eines Hardwareprozessors eine oder mehrere der hierin erörterten Anweisungen zum Erzeugen und/oder Verwenden von Daten (z. B. Originaldaten), die in Bezug darauf beschränkt sind, wie sie verwendet werden können. Obwohl im Folgenden ein kryptografischer Schlüssel als ein Beispiel der Originaldaten verwendet wird, die geschützt werden, ist dies lediglich ein Beispiel, so dass auch andere Anwendungen möglich sind. In einer Ausführungsform ist ein (z. B. kryptografischer) Schlüssel zur Verschlüsselung darauf beschränkt, nur in einem spezifischen Modus verwendet zu werden, zum Beispiel wird der Schlüssel nur durch das OS, nur durch eine spezifische Anwendung, nur durch eine spezifische vertrauenswürdige Ausführungsumgebung (z. B. Enklave), nur durch eine spezifische virtuelle Maschine, nur an einem spezifischen Anweisungszeiger usw. verwendet.
  • Auf diese Weise kann ein Angreifer, der die verschlüsselten Daten (die z. B. den Schlüssel umfassen) stiehlt (z. B. durch einen Seitenkanal oder ein Datenleck), diese außerhalb des beschränkten Bereichs nicht verwenden. Für einige Angriffsszenarien verhindert dies überhaupt, dass der Angreifer die Daten (z. B. den Schlüssel) verwendet.
  • Ausführungsformen hierin sind eine Verbesserung der Computerfunktionalität, da sie Schlüssel vor Exfiltration schützen (wobei z. B. ein gestohlenes „Handle“ auf einem anderen System/Prozessor nicht genutzt werden kann). Ausführungsformen hierin sind eine Verbesserung der Computerfunktionalität, da sie leicht annulliert werden (z. B. nach Erkennen eines Sicherheitsproblems), wobei zum Beispiel die Verwendung eines Handles sicherstellt, dass der Angreifer, der das Handle stiehlt, den wahren Schlüssel nicht bekommt (wobei z. B. das Handle nach Annullierung (z. B. nach einem Neustart) nicht genutzt werden kann, so dass ein Angreifer weiter auf seinem Zugriff bestehen muss). Wie nachstehend genauer erörtert, kann die Verwendung eines Handles auf eine spezifische Anforderung (z. B. basierend auf dem Modus/der Nutzung) beschränkt werden. Zum Beispiel wird die Verwendung eines Handles nur auf ein OS (z. B. Ring 0), nur auf Verschlüsselung, nur auf Entschlüsselung, darauf, spezifisch für eine virtuelle Maschine (VM) zu sein (z. B. in der Annahme, dass ein Virtual-Machine-Monitor (VMM) keine Gäste zum Teilen von Handle-Raum einrichtet), darauf, prozessspezifisch zu sein, darauf, spezifisch für eine (z. B. sichere) vertrauenswürdige Ausführungsumgebung zu sein, oder beliebige Kombinationen davon beschränkt. In einer Ausführungsform ist eine vertrauenswürdige Ausführungsumgebung eine (z. B. sichere) Enklave. In einer Ausführungsform ist eine vertrauenswürdige Ausführungsumgebung eine vertrauenswürdige Domäne (TD - Trusted Domain), z. B. eine TD, in der gearbeitet wird, wenn eine ganze VM
    (z. B. ein Gast) derart ausgeführt wird, dass sie gegen Angriff von einem böswilligen VMM geschützt ist, der sie verwaltet.
  • Bestimmte Ausführungsformen hierin sind eine Verbesserung der Computerfunktionalität, da sie Schutz von Daten mit den hierin erörterten Anweisungen ermöglichen, statt zu einer anderen Umgebung (z. B. einer sicheren virtuellen Maschine oder einer vertrauenswürdigen Umgebung) zu wechseln, um Daten (z. B. einen Schlüssel) zu verwenden, die hoher Overhead und für Software schwieriger zu verwalten sein können, als die Daten nur direkt mit nativen Prozessoranweisungen zu verwenden.
  • 1 veranschaulicht ein Blockdiagramm eines Mehrkern-Hardwareprozessors 100, der ein Handle 126 gemäß Ausführungsformen der Offenbarung verwendet. Der Hardwareprozessor 100 umfasst eine Mehrzahl von Kernen 104(1) bis 104(N), wobei N z. B. eine beliebige ganze Zahl von eins (z. B. ein Einkernprozessor) oder größer (z. B. Mehrkernprozessor) ist. Der Hardwareprozessor 100 ist so dargestellt, dass er mit einem Systemspeicher 102 gekoppelt ist, um z. B. ein Datenverarbeitungssystem 101 zu bilden. In der dargestellten Ausführungsform umfasst ein Kern (z. B. jeder Kern) des Hardwareprozessors 100 eine Mehrzahl von logischen Kernen (z. B. logischen Verarbeitungselementen oder logischen Prozessoren), wobei M zum Beispiel eine ganze Zahl von 1 oder größer ist. In bestimmten Ausführungsformen unterstützt jeder der physischen Kerne 104(1) bis 104(N) Multithreading
    (z. B. Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads auf einem ersten und einem zweiten logischen Kern) und kann dies auf zahlreiche Arten und Weisen tun, die Zeitscheiben-Multithreading, simultanes Multithreading (wobei z. B. ein einziger physischer Kern einen jeweiligen logischen Kern für jeden der Threads (z. B. Hardware-Threads) bereitstellt), für die der physische Kern simultanes Multithreading ausführt) oder eine Kombination davon (z. B. Abrufen und Decodieren in Zeitscheiben und anschließendes simultanes Multithreading) umfassen. In bestimmten Ausführungsformen erscheint jeder logische Kern für Software (z. B. das Betriebssystem (OS)) als eine verschiedene Verarbeitungseinheit, so dass die Software (z. B. das OS) zum Beispiel zwei Prozesse (z. B. zwei Threads) zur gleichzeitigen Ausführung disponieren kann.
  • Der dargestellte Hardwareprozessor 100 umfasst Register 106 von Kern 104(1). In bestimmten Ausführungsformen umfasst jeder Kern seinen eigenen Satz von Registern 106. Die Register 106 können ein oder mehrere Universal- (z. B. Daten-)Register 108 zum Durchführen von (z. B. logischen oder arithmetischen) Operationen zum Beispiel zusätzlich oder alternativ zum Zugreifen (z. B. Laden oder Speichern) von Daten im Speicher 102 umfassen. Die Register 106 können ein Segmentregister 110 umfassen, um z. B. Daten zu speichern, die eine aktuelle Berechtigungsstufe von Software anzeigen, die auf einem logischen Kern z. B. getrennt für jeden logischen Kern ausgeführt wird. In einer Ausführungsform wird die Berechtigungsstufe in einem Feld „aktuelle Berechtigungsstufe“ (CPL - Current Privilege Level) eines Codesegmentselektorregisters des Segmentregisters 110 gespeichert. In bestimmten Ausführungsformen verlangt der Prozessor 100 eine bestimmte Berechtigungsstufe zum Durchführen bestimmter Aktionen, zum Beispiel Aktionen, die von einem spezifischen logischen Kern angefordert werden (z. B. Aktionen, die von Software angefordert werden, die auf diesem spezifischen logischen Kern ausgeführt wird).
  • Die Register 106 können eine oder mehrere modellspezifische Register 112 umfassen. In einer Ausführungsform sind die modellspezifischen Register 112 Konfigurations- und/oder Steuerregister. In bestimmten Ausführungsformen weist jeder physische Kern seinen eigenen jeweiligen Satz von Registern 106 auf. In bestimmen Ausführungsform weist jeder logische Kern (z. B. von mehreren logischen Kernen eines einzelnen physischen Kerns) seinen eigenen jeweiligen Satz von Registern 106 auf. In bestimmten Ausführungsformen umfasst jeder logische Kern seine eigenen jeweiligen Konfigurations- und/oder Steuerregister. In einer Ausführungsform wird auf Wunsch des OS, das auf dem Prozessor ausgeführt wird, in ein oder mehrere (z. B. modellspezifische) Register (z. B. nur) geschrieben, wobei das OS z. B. in einem Berechtigungs- (z. B. System-)Modus funktioniert, aber nicht in einem Nicht-Berechtigungs- (z. B. Benutzer-)Modus funktioniert. In einer Ausführungsform kann nur durch Software, die in einem Supervisormodus ausgeführt wird, aber nicht durch Software, die im Benutzermodus ausgeführt wird, in ein modellspezifisches Register geschrieben werden. Die Register 106 können ein oder mehrere Fähigkeitsregister 116 umfassen, um z. B. anzuzeigen, ob der Prozessor (z. B. Kern) zum Ausführen der Anweisung(en) oder anderer hierin beschriebener Funktionalität imstande ist.
  • Die Register 106 (z. B. die modellspezifischen Register 110) können eines oder mehrere von Steuerregistern 114, Fähigkeitsregistern 116 oder Registern interner Schlüssel 118 z. B. zusätzlich zu anderen Steuerregistern umfassen. In einer Ausführungsform weist jeder logische Kern sein eigenes oder seine eigenen jeweiligen Steuerregister 114, Fähigkeitsregister 116, Register interner Schlüssel 118 und beliebige Kombinationen davon auf. In einer Ausführungsform teilt sich eine Mehrzahl von logischen Kernen ein einziges Register, z. B. teilt sie sich ein oder mehrere Universal- (z. B. Daten-)Register 108.
  • In bestimmten Ausführungsformen umfasst jeder logische Kern sein eigenes oder seine eigenen (z. B. nicht mit anderen logischen Kernen geteilten) Steuerregister 114, Fähigkeitsregister 116 und/oder Register interner Schlüssel 118 z. B. getrennt von den Datenregistern 108. In einer Ausführungsform handelt es sich bei dem einen oder den mehreren Registern interner Schlüsseln 118 um ein lesegeschütztes Register (die z. B. von Software nur beschrieben, aber von Software nicht gelesen werden können). In bestimmten Ausführungsformen sind das eine oder die mehreren Steuerregister 114 und/oder Fähigkeitsregister 116 jeweils Lese- und Schreibregister, wobei z. B. ein Schreibvorgang erlaubt ist, wenn der Schreib-Anforderer (z. B. Software) eine entsprechende (z. B. zugelassene) Berechtigungsstufe (und/oder Prädiktormodus) aufweist, und/oder ein Lesevorgang für jede Berechtigungsstufe erlaubt ist. Jedes Register kann nur lesbar (z. B. durch einen logischen Kern, der auf einer Berechtigungsstufe unter einer Schwelle funktioniert) oder les- und beschreibbar (z. B. durch einen logischen Kern, der auf einer Berechtigungsstufe über der Schwelle funktioniert, beschreibbar) sein. In bestimmten Ausführungsformen sind die Lese- und Schreibregister nur auf Supervisor-Berechtigungsstufe lesbar und beschreibbar. In bestimmten Ausführungsformen sind lesegeschützte Register nur auf Supervisor-Berechtigungsstufe beschreibbar und für keine Berechtigungsstufe lesbar. In bestimmten Ausführungsformen sind schreibgeschützte Register nur auf Supervisor-Berechtigungsstufe lesbar und für keine Berechtigungsstufe beschreibbar.
  • Der Speicher kann einen Verschlüsselungsschlüssel 124, ein Handle 126 und/oder verschlüsselte Daten 128 (z. B. mehrere Blöcke 128(1) bis 128(X) von verschlüsselten Daten, wobei X eine ganze Zahl größer als 1 ist) umfassen. In einer Ausführungsform ist jeder Block von verschlüsselten Daten durch seinen eigenen Verschlüsselungsschlüssel 124 verschlüsselt. In einer Ausführungsform sind mehrere Blöcke von verschlüsselten Daten durch einen einzigen Verschlüsselungsschlüssel 124 verschlüsselt.
  • Der Speicher 102 kann eine oder mehrere (z. B. eine beliebige Kombination) der folgenden Software umfassen (z. B. speichern): einen Betriebssystem-(OS-)Code 130, einen ersten Anwendungscode 132, einen zweiten (oder mehr) Anwendungscode(s) 134, einen Virtual-Machine-Monitor-Code 136 oder eine beliebige Kombination davon. Der erste Anwendungscode 132 oder der zweite Anwendungscode 134 können ein jeweiliges Benutzerprogramm sein.
  • Es ist zu erwähnen, dass die Figuren hierin nicht alle Datenkommunikationsverbindungen darstellen. Für einen Fachmann ist zu erkennen, dass dies ist, um bestimmte Details in den Figuren nicht zu verunklaren. Es ist zu erwähnen, dass ein zweispitzige Pfeile in den Figuren keine Zweiwege-Kommunikation erfordert, sondern zum Beispiel eine Einweg-Kommunikation (z. B. zu oder von dieser Komponente oder diesem Gerät) anzeigen kann. In bestimmten Ausführungsformen können jede oder alle Kombinationen von Kommunikationswegen verwendet werden. In einer Ausführungsform weist der Prozessor 100 einen einzigen Kern auf. In bestimmten Ausführungsformen umfassen das Datenverarbeitungssystem 101 und/oder der Prozessor eine/s oder mehrere der Merkmale und/oder Komponenten, die im Folgenden z. B. unter Bezugnahme auf eine der Figuren hierin erörtert werden.
  • Bestimmte Ausführungsformen hierin führen Verschlüsselung/Entschlüsselung unter Verwendung eines Handles 126 anstelle eines Schlüssels für verschlüsselte Daten 128 durch. In einer Ausführungsform verwendet ein Verfahren (z. B. eine Anweisung) Daten, die in das Handle 126 umgesetzt wurden. In bestimmten Ausführungsformen umfasst ein Handle die Originaldaten, die mit einem Schlüssel (z. B. dem Verschlüsselungsschlüssel 124) verschlüsselt sind, ein Integritätsmaß (z. B. ein Authentisierungstag) und zusätzliche Authentisierungsdaten (z. B. Metadaten), die Beschränkungen in Bezug darauf anzeigen, wie die Daten verwendet werden können (z. B. können auch die zusätzlichen Authentisierungsdaten durch das Integritätsmaß geschützt sein). Beispielhafte Beschränkungen sind, dass das Handle (z. B. ein innerhalb des Handles verschlüsselter Schlüssel) nicht zum Verschlüsseln/Entschlüsseln auf einer CPL (z. B. einem Ring) über null verwendet werden kann, nicht zum Verschlüsseln verwendet werden kann und/oder nicht zum Entschlüsseln verwendet werden kann. Ein beispielhaftes Format für ein Handle 126 ist ein (z. B. 384-Bit-)Handle für eine erste Größe von Schlüsseln (z. B. 128-Bit-Schlüssel), wobei es sich bei einem ersten Feld (z. B. Bits [127:0] des Handles 126) um die zusätzlichen Authentisierungsdaten handelt, es sich bei einem zweiten Feld (z. B. Bits [255:128] des Handles 126) um ein Authentisierungstag handelt, und ein drittes Feld (z. B. Bits [383:256] des Handles 126) die verschlüsselte Version (z. B. Chiffretext) der Originaldaten (z. B. Verschlüsselungsschlüssel) ist. Ein weiteres beispielhaftes Format für ein Handle 126 ist ein (z. B. 512-Bit-)Handle für eine zweite Größe von Schlüsseln (z. B. 256-Bit-Schlüssel), wobei es sich bei einem ersten Feld (z. B. Bits [127:0] des Handles 126) um die zusätzlichen Authentisierungsdaten handelt, es sich bei einem zweiten Feld (z. B. Bits [255:128] des Handles 126) um ein Authentisierungstag handelt, ein drittes Feld ein Teil (z. B. die erste Hälfte von Bits von Chiffretextbits in [127:0]) der verschlüsselten Version des Verschlüsselungsschlüssels (z. B. Bits [383:256] des Handles 126) ist, und ein viertes Feld der andere Teil (z. B. die zweite Hälfte von Bits von Chiffretextbits in [255:128]) der verschlüsselten Version des Verschlüsselungsschlüssels (z. B. Bits [511:383] des Handles 126) ist. Ein beispielhaftes Format für die zusätzlichen Authentisierungsdaten umfasst eine oder mehrere von Folgenden: eine erste Bitposition (z. B. Index [0]), wenn (z. B. auf eins) gesetzt, zeigt an, dass das Handle auf CPL > 0 nicht verwendbar ist, eine zweite Bitposition (z. B. Index [1]), wenn (z. B. auf eins) gesetzt, zeigt an, dass das Handle für Verschlüsselung nicht verwendbar ist, eine dritte Bitposition (z. B. Index [2]), wenn (z. B. auf eins) gesetzt, zeigt an, dass das Handle nicht für Entschlüsselung verwendbar ist, wobei eine andere Bitposition (z. B. Bits [27:24]) einen Schlüsseltyp (z. B. 0 für einen 128-Bit-Schlüssel und 1 für einen 256-Bit-Schlüssel) anzeigt.
  • In einer Ausführungsform sind die zusätzlichen (z. B. Authentisierungs-)Daten integritätsgeschützt, aber nicht verschlüsselt. In einer Ausführungsform sind die zusätzlichen (z. B. Authentisierungs-)Daten sowohl integritätsgeschützt als auch vertraulichkeitsgeschützt, indem sie verschlüsselt sind. Zum Beispiel können die Metadaten „im Klartext“ sein (was bedeutet, dass sie innerhalb des Handles beobachtet werden können), aber das Konzept von Beschränkungen auch mit verschlüsselten Metadaten durchgeführt werden (so dass z. B. ein Angreifer, der das Handle erlangt, nicht weiß, welche Beschränkungen auf das Handle angewendet sind).
  • In bestimmten Ausführungsform wird ein Handle durch Verschlüsseln von Originaldaten eines Verschlüsselungsschlüssels 124 (z. B. Verschlüsselungsschlüssel 124, der zum Verschlüsseln eines Blocks von Daten in den verschlüsselten Daten 128 verwendet wird) und Festlegen der gewünschten Bit(s) in den zusätzlichen Authentisierungsdaten erstellt. In bestimmen Ausführungsformen sind der Chiffretext des verschlüsselten „Verschlüsselungsschlüssels“ 124 und die (z. B. verschlüsselten oder unverschlüsselten) zusätzlichen Authentisierungsdaten aneinander gebunden, um ein Authentisierungstag zu bilden, indem zum Beispiel die assoziierten Daten (z. B. zusätzlichen Authentisierungsdaten) an den Chiffretext und an den Kontext gebunden werden, in welchem sie auftreten/verwendet werden sollen, so dass „Cut-and-paste“-Versuche, um einen gültigen Chiffretext „auszuschneiden“ und in einen anderen Kontext „einzufügen“, erkannt und zurückgewiesen werden, indem zum Beispiel eine authentisierte Verschlüsselung mit den assoziierten Daten durchgeführt wird (um z. B. einem Empfänger zu ermöglichen, sowohl die Integrität der verschlüsselten als auch der unverschlüsselten Informationen in einer Nachricht zu überprüfen). In bestimmten Ausführungsformen wird eine Nonce zum Erstellen eines Handles verwendet. In bestimmten Ausführungsformen wird keine Nonce zum Erstellen eines Handles verwendet. In einer Ausführungsform verursachen Versuche zum Modifizieren des Chiffretexts oder der zusätzlichen Authentisierungsdaten, die ein spezifisches Authentisierungstag aufweisen, einen Fehlschlag beim Entschlüsseln des Chiffretexts unter Verwendung dieses Authentisierungstags (z. B. und des Verschlüsselungsschlüssels 120 und/oder des Integritätsschlüssels 122). In bestimmten Ausführungsformen wird ein Verschlüsselungsschlüssel 124 nach der Erzeugung eines entsprechenden Handles gelöscht. Die Erzeugung eines Handles wird im Folgenden unter Bezugnahme auf 4 ausführlicher erörtert.
  • In bestimmten Ausführungsformen wird ein Handle 126 für eine zukünftige Anforderung (z. B. Modus/Nutzung) des Prozessors (z. B. Kern 104(1)) (z. B. eine Anforderung, die den Beschränkungen entspricht, die in den zusätzlichen Authentisierungsdaten spezifiziert sind) erzeugt, wobei das Handle verwendet werden soll. Zum Beispiel kann eine zukünftige Anforderung (z. B. Modus und/oder Verwendung) nur zum Ausführen eines OS (z. B. Ring 0), einer Verschlüsselung, einer Entschlüsselung, Ausführen einer spezifischen virtuellen Maschine (VM), Ausführen eines spezifischen Prozesses, Ausführen in einer (z. B. sicheren) Enklave oder eine beliebige Kombination davon sein. In einer Ausführungsform wird eine Anforderung (z. B. eine Anweisung wie unter Bezugnahme auf 2 erörtert) zum Entschlüsseln oder Verschlüsseln durch den Kern 104(1)) empfangen, und in Reaktion liest der Kern das Handle 126 und das Register interner Schlüssel 118 (das z. B. einen Schlüssel aufweist, der zum Erstellen des verschlüsselten Handles 126 verwendet wird) aus. In bestimmten Ausführungsformen sind der oder die zum Erstellen eines Handles verwendeten Schlüssel privat im Kern 104(1), wie z. B. im Register interner Schlüssel 118 gespeichert (z. B. und worauf weder eine MSR-Lese- noch eine MSR-Schreibanweisung, sondern nur eine Anweisung wie unter Bezugnahme auf 3 erörtert, zugreifen kann).
  • In bestimmten Ausführungsformen führt der Kern 104(1) nach dem Auslesen des Handles 126 und des zum Erstellen des Handles 126 verwendeten Schlüssels einen Vergleich des Authentisierungstags des Handles 126 mit dem Chiffretext des Handles 126 (der in einem Beispiel der Verschlüsselungsschlüssel für die verschlüsselten Daten 128 ist) und den zusätzlichen Authentisierungsdaten des Handles 126 hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten durch und führt dann, wenn dieser erfolgreich ist, einen Vergleich einer aktuellen Anforderung (z. B. Modus/Verwendung) des Kerns 104(1) mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten spezifizierten Beschränkungen des Handles 126 durch und entschlüsselt den Chiffretext zum Erzeugen der Originaldaten (z. B. Klartext) (z. B. Verschlüsselungsschlüssel in einem Beispiel) des Chiffretexts nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde. Der Kern 104(1) kann dann Daten mit dem unverschlüsselten Verschlüsselungsschlüssel entschlüsseln oder verschlüsseln, z. B. die verschlüsselten Daten 128 mit dem Verschlüsselungsschlüssel entschlüsseln, der jetzt im Klartext ist.
  • In bestimmten Ausführungsformen speichert ein Prozessor (z. B. eine CPU) die Abbildung vom Handle auf das Klartextformat der Originaldaten zwischen, um die zum Entschlüsseln des Chiffretextformats der Originaldaten im Normalfall erforderliche Latenz oder Leistung zu vermeiden. In einer Ausführungsform wird noch Entschlüsselung benötigt, wenn die „Handle“-auf-„Originaldaten“-Abbildung nicht im Cache vorhanden ist. Bestimmte Ausführungsformen verwenden einen Spezialcache für diesen Zweck, z. B. keinen Daten-/ Anweisungscache.
  • 2 veranschaulicht einen Hardwareprozessor 200, der mit einem Speicher 200 gekoppelt ist, der eine oder mehrere Verschlüsselungs- oder Entschlüsselungsanweisungen 204 umfasst, die ein Handle 216 gemäß Ausführungsformen der Offenbarung verwenden. In bestimmten Ausführungsformen ist eine Verschlüsselung oder Entschlüsselung gemäß einer beliebigen der Offenbarung hierin. In einer Ausführungsform wird die Anweisung (z. B. Makroanweisung) z. B. in Reaktion auf eine Anforderung zum Durchführen einer Operation vom Speicher 202 abgerufen und an einen Decoder 206 gesendet. In der dargestellten Ausführungsform decodiert der Decoder 206 (z. B. eine Decoderschaltung) die Anweisung in eine decodierte Anweisung (z. B. eine oder mehrere Mikroanweisungen oder Mikrooperationen). Die decodierte Anweisung wird dann zur Ausführung z. B. durch eine Scheduler-Schaltung 208 zum Disponieren der decodierten Anweisung zur Ausführung gesendet.
  • In bestimmten Ausführungsformen (in welchen z. B. der Prozessor/Kern Out-of-Order-(OoO-)Ausführung unterstützt) umfasst der Prozessor eine mit einer Registerdatei-/- speicherschaltung 210 (z. B. -einheit) gekoppelte Registerumbenennungs-/-zuordnungsschaltung zum Zuordnen von Ressourcen und Durchführen von Registerumbenennung an Registern (z. B. Registern, die mit der Anweisung assoziiert sind). In bestimmten Ausführungsformen (z. B. für Out-of-Order-Ausführung) umfasst der Prozessor eine oder mehrere Scheduler-Schaltungen 208, die mit dem Decoder gekoppelt sind. Die Scheduler-Schaltung(en) können eine oder mehrere mit den decodierten Anweisungen assoziierte Operationen, die eine oder mehrere Operation umfassen, die aus einer Verschlüsselungs- oder Entschlüsselungsanweisung decodiert wurden, zur Ausführung auf der Ausführungsschaltung 212 disponieren.
  • In bestimmten Ausführungsformen ist eine Rückschreibschaltung 214 enthalten, um zum Beispiel Ergebnisse einer Anweisung in ein Ziel zurückzuschreiben (z. B. dieselben in ein oder mehrere Register und/oder einen Speicher zu schreiben), so dass diese Ergebnisse innerhalb eines Prozessor sichtbar sind (z. B. außerhalb der Ausführungsschaltung, die diese Ergebnisse erzeugte, sichtbar sind).
  • Eine oder mehrere dieser Komponenten (z. B. Decoder 206, Registerumbenennung / Registerzuordnung / Scheduler 208, Ausführungsschaltung 212, Registerdatei/-speicher 210 oder Rückschreibschaltung 214) können in einem einzigen Kern eines Hardwareprozessors (z. B. und mehreren Kernen jeweils mit einer Instanz dieser Komponenten) sein.
  • In einer Ausführungsform einer Verschlüsselungsanweisung bestimmt die Ausführungsschaltung 212 (z. B. -einheit) einen Verschlüsselungsschlüssel aus dem Handle 216 (z. B. wie hierin erörtert) und verwendet den Verschlüsselungsschlüssel dann, wenn keine Ausnahme (z. B. Fehler), zum Verschlüsseln der unverschlüsselten Daten 218 in verschlüsselte Daten 220.
  • In einer Ausführungsform einer Entschlüsselungsanweisung bestimmt die Ausführungsschaltung 212 (z. B. -einheit) einen Verschlüsselungsschlüssel aus dem Handle 216 (z. B. wie hierin erörtert) und verwendet dann, wenn keine Ausnahme (z. B. Fehler aus einer Nichtübereinstimmung des Authentisierungstags), den Entschlüsselungsschlüssel zum Entschlüsseln der verschlüsselten Daten 220 in unverschlüsselte (z. B. entschlüsselte) Daten 218.
  • In bestimmten Ausführungsformen weist eine Verschlüsselungs- oder Entschlüsselungsanweisung das folgende Format auf: OPCODE{ENC,DEC} {128,256} KL zum Verschlüsseln (ENC) oder Entschlüsseln (DEC) eines einzigen (z. B. 128-Bit-)Blocks von Daten. Zum Beispiel mit den Quellen- und Zieldaten in Registern 108 (z. B. in einem von XMM0-7-Registern). Zum Beispiel mit dem Handle im Speicher spezifiziert durch ein Speicherargument.
  • In bestimmten Ausführungsformen weist eine Verschlüsselungs- oder Entschlüsselungsanweisung das folgende Format auf:
    • OPCODE{ENC,DEC} WIDE{ 128,256}KL Verschlüsselungen/Entschlüsselungen zum Verschlüsseln (ENC) oder Entschlüsseln (DEC) mehrerer (z. B. einer beliebigen Mehrzahl, zum Beispiel acht) Blöcken von (z. B. von 128 Bit von) Daten mit demselben einzigen Schlüssel. Zum Beispiel mit den Quellen- und Zieldaten in Registern 108 (z. B. in XMM0-7-Registern). Zum Beispiel mit dem Handle im Speicher spezifiziert durch ein Speicherargument.
    • In bestimmten Ausführungsformen ist eine Verschlüsselungs- oder Entschlüsselungsanweisung nicht erfolgreich (löst z. B. eine Ausnahme aus), wenn Handle-Authentizitätsfehler. In einer Ausführungsform verursacht ein Fehler ein Setzen eines Ausnahmeflags (z. B. EFLAGS.ZF) und modifiziert Zieldaten nicht. In einer Ausführungsform, bei welcher das Ziel Original-Klartext/Chiffretext halten kann, prüft Software auf ein Ausnahmeflag (z. B. EFLAGS.ZF), um Probleme zu vermeiden (z. B. Setzen von Klartext in Ergebnis). Beispielhafte Authentizitätsfehler sind: wenn ein Handle nicht mit einem aktuellen (z. B. Verpackungs-)Schlüssel (z. B. einem internen Schlüssel aus dem Register interner Schlüssel 118) erstellt (z. B. verpackt) wird, wenn ein Handle einen Schlüssel einer anderen Größe anzeigt, als eine Anweisung spezifiziert, und/oder wenn zusätzliche Authentisierungsdaten Regeln spezifizieren, gegen die verstoßen wird (z. B. Verwenden eines Handles außerhalb der angegebenen Beschränkungen).
  • In bestimmten Ausführungsformen wird ein Handle aus Originaldaten erstellt, und ein Schlüssel ist in dieser Erörterung ein Beispiel für „Originaldaten“, z. B. derart dass es einen internen Schlüssel (IKey) gibt, der zum Erstellen eines Handles aus „Originaldaten“ verwendet wird, und im nachstehenden Beispiel sind diese Originaldaten zufällig auch ein anderer Schlüssel.
  • In bestimmten Ausführungsformen wird ein interner Schlüssel (IKey) (z. B. ein interner Verpackungsschlüssel (IWKey)) zum Erstellen eines Handles aus einem anderen Schlüssel verwendet, der zur Datenverschlüsselung (z. B. zum Erzeugen von verschlüsselten Daten 220) oder Datenentschlüsselung (z. B. zum Erzeugen von entschlüsselten Daten 218) verwendet werden soll. In einer Ausführungsform darf Software (z. B. ein OS oder eine Anwendung) den internen Schlüssel in einen Prozessor schreiben, aber Software darf den internen Schlüssel nicht aus dem Prozessor auslesen, z. B. kann Software in das Register interner Schlüssel 118 in 1 schreiben, aber sie kann nicht aus dem Register interner Schlüssel 118 auslesen. In einer Ausführungsform wird der interne Schlüssel durch Ausführung einer Internen-Schlüssel-laden-Anweisung (z. B. einer LOADIKEY-Anweisung oder einer Register-Schreibanweisung (z. B. WRMSR)) in den Prozessor (z. B. in das Register interner Schlüssel 118) geschrieben. Der interne Schlüssel kann durch Software spezifiziert oder durch Hardware zufallsbedingt sein. Bestimmte Ausführungsformen lassen Auslesen eines internen Schlüssels nur durch Software in einem sicheren Spezialmodus (z. B. Systemverwaltungsmodus (SMM) oder einer besonders privilegierten Enklave) zu.
  • In einer Ausführungsform kann Software den internen Schlüssel in einem Plattformbereichszustand (z. B. IKeyBackup) speichern und ihn aus seinem Speicher unter Verwendung eines neuen architektonischen MSRs wiederherstellen. In einer Ausführungsform kann ein Betriebssystem dies zum Speichern/Wiederherstellen des internen Schlüssels über Schlafzustände (z. B. S3/S4-Schlafzustände) verwenden. Ein Virtual-Machine-Monitor (VMM) kann dies zum Speichern/Wiederherstellen eine internen Hypervisor-Schlüssels über eine Ausführung einer virtuellen Maschine verwenden. Ein Prozessor kann dies zum sicheren Verteilen eines internen Schlüssels an andere logische Prozessoren (z. B. innerhalb desselben Kerns) verwenden.
  • In bestimmten Ausführungsformen wird der interne Schlüssel durch Software oder Hardware programmiert, wobei z. B. Software einen zufallsbedingten oder spezifischen Wert unter Verwendung einer Internen-Schlüssel-laden-Anweisung (z. B. früh beim Start) spezifiziert. In einer Ausführungsform konfiguriert Software denselben internen (z. B. innerhalb eines Kerns) Schlüssel für alle logischen Prozessoren (z. B. logischen Kerne), zum Beispiel alle logischen Prozessoren in einem einzelnen Kern. In einer Ausführungsform ist der Wert des internen Schlüssels nicht verriegelt und kann überschrieben werden. Die Ausführung einer Handle-Erzeugungsanweisung (wie z. B. unter Bezugnahme auf 4 erörtert) kann Informationen darüber zurücksenden, welche Entität z. B. den aktuellen internen Schlüssel schrieb, und einen durch Software spezifizierten Wert für einen internen Schlüssel oder einen zufällig erzeugten internen Schlüssel anzeigen. Die zurückgesendeten Informationen ermöglichen es Code, zu entscheiden, ob er dem internen Schlüssel vertraut (z. B. kann Code in einer vertrauenswürdigen Ausführungsumgebung nur internen Zufallsschlüsseln vertrauen).
  • 3 veranschaulicht einen Hardwareprozessor 300, der mit einem Speicher 302 gekoppelt ist, der eine oder mehrere Internen-Schlüssel-laden-Anweisungen 304 gemäß Ausführungsformen der Offenbarung umfasst. In bestimmten Ausführungsformen ist die Internen-Schlüssel-laden-Anweisung gemäß einer beliebigen der Offenbarung hierin. In einer Ausführungsform wird die Anweisung (z. B. Makroanweisung) z. B. in Reaktion auf eine Anforderung zum Durchführen einer Operation vom Speicher 302 abgerufen und an einen Decoder 306 gesendet. In der dargestellten Ausführungsform decodiert der Decoder 306 (z. B. eine Decoderschaltung) die Anweisung in eine decodierte Anweisung (z. B. eine oder mehrere Mikroanweisungen oder Mikrooperationen). Die decodierte Anweisung wird dann zur Ausführung z. B. durch eine Scheduler-Schaltung 308 zum Disponieren der decodierten Anweisung zur Ausführung gesendet.
  • In bestimmten Ausführungsformen (in welchen z. B. der Prozessor/Kern Out-of-Order-(OoO-)Ausführung unterstützt) umfasst der Prozessor eine mit einer Registerdatei-/- speicherschaltung 310 (z. B. -einheit) gekoppelte Registerumbenennungs-/-zuordnungsschaltung zum Zuordnen von Ressourcen und Durchführen von Registerumbenennung an Registern (z. B. Registern, die mit der Anweisung assoziiert sind). In bestimmten Ausführungsformen (z. B. für Out-of-Order-Ausführung) umfasst der Prozessor eine oder mehrere Scheduler-Schaltungen 308, die mit dem Decoder gekoppelt sind. Die Scheduler-Schaltung(en) können eine oder mehrere mit den decodierten Anweisungen assoziierten Operationen, die eine oder mehrere Operation umfassen, die aus einer Internen-Schlüssel-laden-Anweisung decodiert wurden, zur Ausführung auf der Ausführungsschaltung 312 disponieren.
  • In bestimmten Ausführungsformen ist eine Rückschreibschaltung 314 enthalten, um zum Beispiel Ergebnisse einer Anweisung in ein Ziel zurückzuschreiben (z. B. dieselben in ein oder mehrere Register und/oder einen Speicher zu schreiben), so dass diese Ergebnisse innerhalb eines Prozessor sichtbar sind (z. B. außerhalb der Ausführungsschaltung, die diese Ergebnisse erzeugte, sichtbar sind).
  • Eine oder mehrere dieser Komponenten (z. B. Decoder 306, Registerumbenennung / Registerzuordnung / Scheduler 308, Ausführungsschaltung 312, Registerdatei/-speicher 310 oder Rückschreibschaltung 314) können in einem einzigen Kern eines Hardwareprozessors (z. B. und mehreren Kernen jeweils mit einer Instanz dieser Komponenten) sein.
  • In einer Ausführungsform einer Internen-Schlüssel-laden-Anweisung gibt die Ausführungsschaltung 312 (z. B. -einheit) einen internen Schlüssel aus (z. B. in den Speicher interner Schlüssel 316). In bestimmten Ausführungsformen weist ein interner Schlüssel (IKey) das folgende Format auf: einen (z. B. 256-Bit-)Verschlüsselungsschlüssel (z. B. Verschlüsselungsschlüssel 120 in 1) (z. B. zum Verschlüsseln von Originaldaten zur Verwendung eines Chiffretexts in einem Handle), einen (z. B. 128-Bit-)Integritätsschlüssel (z. B. Integritätsschlüssel 122 in 1) (z. B. einen Schlüssel, um einem Empfänger zu ermöglichen, sowohl die Integrität der verschlüsselten Informationen (z. B. Chiffretext in einem Handle) als auch unverschlüsselten Informationen (z. B. zusätzlichen Authentisierungsdaten in einem Handle) zu überprüfen, eine Identität eines „Besitzers eines internen (z. B. 384-Bit-)Schlüssels“ (z. B. Besitzer-ID), ein Ein-Bit-Flag „Kein Backup“, das, wenn gesetzt, anzeigt, dass Backup des internen Schlüssels in einem Backup-Speicher interner Schlüssel (z. B. in einem Cache des Kerns) nicht erlaubt ist, und oder ein Quellenfeld, wobei ein erster Wert (z. B. Null) bedeutet, dass Software einen spezifischen internen Schlüssel (z B. durch Ausführung einer jeweiligen Internen-Schlüssel-laden-Anweisung) anforderte, und ein zweiter Wert (z. B. Eins) bedeutet, dass Software einen internen Zufallsschlüssel (z. B. durch Ausführung einer jeweiligen Internen-Schlüssel-laden-Anweisung) anforderte. In bestimmten Ausführungsformen darf Software den internen Schlüssel nicht aus dem Prozessor auslesen.
  • In bestimmten Ausführungsformen weist eine Anweisung zum Laden eines „internen Schlüssels“ das folgende Format auf:_OPCODE (z. B. für LOADIKEY- oder LOADIWKEY-Mnemonik) Quelle 2 (z. B. xmm_reg_src2), Quelle 1 (z. B. xmm_reg_src1). In bestimmten Ausführungsformen kann nur ein OS (z. B. Ring 0) zum Beispiel Ausführung einer Anweisung zum Laden eines „internen Schlüssels“ anfordern, aber eine Anwendung nicht. In einer Ausführungsform werden implizite Register (z. B. XMMO und EAX) verwendet. In einer Ausführungsform IKey.Encryption Key = Verkettung von Quelle 1 und Quelle 2 (z. B. xmm_src_reg_2, xmm_src_reg1) und IKey.Integrity_Key = XMMO. In einer Ausführungsform werden dann, wenn ein implizites Register (z. B. EAX[1]) festgelegt ist, IKey.Encryption_Key und IKey.Integrity_Key mit Zufallszahlen (z. B. von einem Zufallszahlengenerator des Kerns) exklusiv ODERiert. In bestimmten Ausführungsformen, wenn unzulängliche Zufälligkeit, schlägt dies fehl (z. B. modifiziert IKey nicht) und setzt ein Ausnahmeflag (z. B. ZF). In bestimmten Ausführungsformen spezifiziert ein implizites Register (z. B. EAX[0]) einen IKey.NoBackup-Wert. In bestimmten Ausführungsformen wird IKey.KeySource gesetzt, um softwarespezifiziert [z. B. EAX[1] = 0) oder zufallsbedingt (z. B. EAX[1] = 1) anzuzeigen. In einer Ausführungsform ist ein Virtual-Machine-Monitor so konfiguriert ist, dass er eine LOADIKEY-VM-Beendigung durch Setzen einer „LoadIKey-beenden“-VM-Ausführungssteuerung bewirkt. In bestimmten Ausführungsformen wird der Verschlüsselungsschlüssel (z. B. Encryption_Key) zum Verschlüsseln der Originaldaten in den Handle-Chiffretext verwendet, während der interne Schlüssel (z. B. Integrity_Key) zum Erzeugen und Verifizieren des Authentisierungstags verwendet wird (das z. B. die Originaldaten und die zusätzlichen Authentisierungsdaten umfasst).
  • In bestimmten Ausführungsformen wird der interne Schlüssel für Integrität und/oder Verschlüsselung/Entschlüsselung eines Handles verwendet. Zum Beispiel wenn das Handle eine verschlüsselte Form eines zum Verschlüsseln von Daten (z. B. der Daten 128 in 1) zu verwendenden Schlüssels umfasst. In bestimmten Ausführungsformen erzeugt Software ein Handle aus einem Schlüssel und anderen Eingabewerten durch Handle-Erzeugungsanweisungen (z. B. ENCODEKEY128 zum Erzeugen eines Handles aus einem 128-Bit-Schlüssel und ENCODEKEY256 zum Erzeugen eines Handles aus einem 256-Bit-Schlüssel).
  • 4 veranschaulicht einen Hardwareprozessor 400, der mit einem Speicher 402 gekoppelt ist, der eine oder mehrere Handle-Erzeugungsanweisungen 404 gemäß Ausführungsformen der Offenbarung umfasst. In bestimmten Ausführungsformen ist eine Handle-Erzeugungsanweisung gemäß einer beliebigen der Offenbarung hierin. In einer Ausführungsform wird die Anweisung (z. B. Makroanweisung) z. B. in Reaktion auf eine Anforderung zum Durchführen einer Operation vom Speicher 402 abgerufen und an einen Decoder 406 gesendet. In der dargestellten Ausführungsform decodiert der Decoder 406 (z. B. eine Decoderschaltung) die Anweisung in eine decodierte Anweisung (z. B. eine oder mehrere Mikroanweisungen oder Mikrooperationen). Die decodierte Anweisung wird dann zur Ausführung z. B. durch eine Scheduler-Schaltung 408 zum Disponieren der decodierten Anweisung zur Ausführung gesendet.
  • In bestimmten Ausführungsformen (in welchen z. B. der Prozessor/Kern Out-of-Order-(OoO-)Ausführung unterstützt) umfasst der Prozessor eine mit einer Registerdatei-/- speicherschaltung 410 (z. B. -einheit) gekoppelte Registerumbenennungs-/-zuordnungsschaltung zum Zuordnen von Ressourcen und Durchführen von Registerumbenennung an Registern (z. B. Registern, die mit der Anweisung assoziiert sind). In bestimmten Ausführungsformen (z. B. für Out-of-Order-Ausführung) umfasst der Prozessor eine oder mehrere Scheduler-Schaltungen 408, die mit dem Decoder gekoppelt sind. Die Scheduler-Schaltung(en) können eine oder mehrere mit den decodierten Anweisungen assoziierten Operationen, die eine oder mehrere Operation umfassen, die aus einer Handle-Erzeugungsanweisung decodiert wurden, zur Ausführung auf der Ausführungsschaltung 412 disponieren.
  • In bestimmten Ausführungsformen ist eine Rückschreibschaltung 414 enthalten, um zum Beispiel Ergebnisse einer Anweisung in ein Ziel zurückzuschreiben (z. B. dieselben in ein oder mehrere Register und/oder einen Speicher zu schreiben), so dass diese Ergebnisse innerhalb eines Prozessor sichtbar sind (z. B. außerhalb der Ausführungsschaltung, die diese Ergebnisse erzeugte, sichtbar sind).
  • Eine oder mehrere dieser Komponenten (z. B. Decoder 406, Registerumbenennung / Registerzuordnung / Scheduler 408, Ausführungsschaltung 412, Registerdatei/-speicher 410 oder Rückschreibschaltung 414) können in einem einzigen Kern eines Hardwareprozessors (z. B. und mehreren Kernen jeweils mit einer Instanz dieser Komponenten) sein.
  • In einer Ausführungsform einer Handle-Erzeugungsanweisung erzeugt eine Ausführungsschaltung 412 (z. B. -einheit) ein Handle 416 aus einem (z. B. AES-)Verschlüsselungsschlüssel und einem internen Schlüssel (z. B. einem internen Verschlüsselungsschlüssel und einem internen Integritätsschlüssel) (wie z. B. hierin erörtert). In einer Ausführungsform verwendet die Ausführungseinheit einen Verschlüsselungs- und Integritätsalgorithmus (z. B. AES-Algorithmus) (z. B. den AES-GCM-SIV) zum Erzeugen des Handles 416. In bestimmten Ausführungsformen wird das Handle 416 in ein Register (z. B. ein oder mehrere Register 108 in 1) geschrieben. In einer Ausführungsform wird das Handle in den Speicher 102 geschrieben (z. B. das Handle 126 in 1).
  • In bestimmten Ausführungsformen bewirkt eine Ausführung einer Handle-Erzeugungsanweisung außerdem, dass ein Zielregister mit einem Wert zum Anzeigen des Ladeprogramms des internen Schlüssels (z. B. und Software oder interner Zufallsschlüssel) und, wenn Backup des internen Schlüssels erlaubt ist, aktualisiert wird. In einer Ausführungsform kann Software, die nur internen Zufallsschlüssel wünscht, ein Handle löschen, wenn nicht zufallsbedingt. In bestimmten Ausführungsformen ist die Ausführung einer Handle-Erzeugungsanweisung auf allen Berechtigungsstufen (z. B. OS, Anwendung, Enklave usw.) erlaubt. In bestimmten Ausführungsformen verwendet der Verschlüsselungs-/Entschlüsselungsalgorithmus keine Schlüsselableitfunktion, wenn eine Anweisung zum Laden eines internen Schlüssels (z. B. Verschlüsselungs- und Integritätsschlüssel) verwendet wird. Zum Beispiel bei der Handle-Erzeugungsanweisung, die keine Nonce bei ihrer Ausführung verwendet (z. B. keine Nonce im Verschlüsselungs-/Integritätsalgorithmus verwendet).
  • In bestimmten Ausführungsformen nimmt eine Handle-Erzeugungsanweisung nicht nur den Schlüssel, sondern auch Beschränkungen in Bezug darauf, wie das Handle verwendet werden kann, als Eingabe. In bestimmten Ausführungsformen nimmt eine Handle-Erzeugungsanweisung ein Beschränkungstypfeld in einer Quelle (z. B. Quellenregister). Eine beispielhafte Beschränkung ist, nicht zu erlauben, dass ein Handle zum Verschlüsseln/Entschlüsseln an einem Ring über null verwendet wird. In bestimmten Ausführungsformen ist der Beschränkungstyp in zusätzlichen Authentisierungsdaten eines resultierenden Handles (z. B. in Bits 127:0) zu sehen. In bestimmten Ausführungsformen sind Beschränkungstyp und Qualifikation in zusätzlichen Authentisierungsdaten eines resultierenden Handles (z. B. in Bits 127:0) zu sehen. In einer Ausführungsform sind zusätzliche Authentisierungsdaten (AAD - Additional Authentication Data) eines resultierenden Handles integritätsgeschützt (z. B. durch ein Authentisierungstag), aber nicht verschlüsselt. In bestimmten Ausführungsformen kann ein einziger Handle mehrere Beschränkungen anzeigen, zum Beispiel ein Handle, der nur in Ring null funktioniert und nur verschlüsselt (nicht entschlüsselt). In bestimmten Ausführungsformen ist der Beschränkungstyp im Handle ersichtlich, aber die Beschränkung kann nicht ohne Bruch der Verschlüsselung geändert werden (z. B. werden die Originaldaten zerstört, die im vorstehenden Beispiel ein (z. B. AES-)Verschlüsselungsschlüssel sind).
  • In bestimmten Ausführungsformen weist eine Handle-Erzeugungsanweisung (z. B. für einen 128-Bit-Schlüssel, der in Chiffretext umgesetzt wird) das folgende Format in Tabelle 1 auf. Tabelle 1: Beispielhaftes Format für eine Handle-Erzeugungsanweisung (z. B. ENCODEKEY 128-Anweisung).
    Eingaben Beschreibung
    XMMO Eingabeschlüssel (z. B. [127:0])
    Src(GPR) Bit 23-0: Handle-Beschränkungstyp. Ausnahme (z. B. #GP), wenn reservierte Codierung spezifiziert
    Bits 31-24 sind reserviert und werden #GP, wenn ungleich 0. Obere 32 Bit ignoriert (ignoriert z. B. REX.W, CS.D)
    Ausgaben Beschreibung
    XMM0-XMM2 Ausgabe von Handle:
    XMMO speichert Handle 127:0 (AAD)
    XMM1 speichert Handle 255:128 (Tag)
    XMMO speichert Handle 383:256 (Chiffretext) .
    Dest(GPR) Bit 0 wird nur dann gesetzt, wenn Kein-Backup-Flag gesetzt
    Bit 4:1 wird auf KeySource gesetzt (0, wenn LoadIKey SW-spezifiziert, 1, wenn LoadIKey zufallsbedingt, andere Werte reserviert)
    Bits 63-5 auf 0 gesetzt
    XMM4-6 Auf null gesetzt oder kann optional Identität des „Besitzers des internen Schlüssels“ halten
  • In bestimmten Ausführungsformen weist eine Handle-Erzeugungsanweisung (z. B. für einen 256-Bit-Schlüssel, der in Chiffretext umgesetzt wird) das folgende Format in Tabelle 2 auf. Tabelle 2: Beispielhaftes Format für eine Handle-Erzeugungsanweisung (z. B. ENCODEKEY256-Anweisung).
    Eingaben Beschreibung
    XMMO Eingabeschlüssel (z. B. [127:0])
    XMM1 Eingabeschlüssel (z. B. [255:128])
    Src(GPR) Bit 23-0: Handle-Beschränkungstyp. Ausnahme (z. B. #GP), wenn reservierte Codierung spezifiziert
    Bits 31-24 sind reserviert und werden #GP, wenn ungleich 0. Obere 32 Bit ignoriert (ignoriert z. B. REX.W, CS.D)
    Ausgaben Beschreibung
    XMM0-XMM2 Ausgabe von Handle:
    XMMO speichert Handle 127:0 (AAD)
    XMM1 speichert Handle 255:128 (Tag)
    XMM2 speichert Handle 383:256 (Chiffretext [127: 0])
    XMM2 speichert Handle 511:384 (Chiffretext [255: 128])
    Dest(GPR) Bit 0 wird nur dann gesetzt, wenn Kein-Backup-Flag gesetzt
    Bit 4:1 wird auf KeySource gesetzt (0, wenn LoadlKey SW-spezifiziert, 1, wenn LoadIKey zufallsbedingt, andere Werte reserviert)
    Bits 63-5 auf 0 gesetzt
    XMM4-6 Auf null gesetzt oder kann optional Identität des „Besitzers des internen Schlüssels“ halten
  • Unter neuerlicher Bezugnahme auf 1 können Steuerung und Fähigkeiten der hierin erörterten Funktionalität z. B. durch das Steuerregister 114 bzw. die Fähigkeitsregister 116 gesteuert und beschrieben werden. Nachstehende Tabelle 3 erörtert beispielhafte Bits für Steuerung und Fähigkeiten. Die Verwendung eines Handles kann Teil eines Satzes von KeyLocker-(KL-)Funktionalität sein. Tabelle 3: Beispielhafte Aufzählung von Steuerung und Fähigkeiten
    CPUID-Bit Wenn gesetzt Zeigt Unterstützung an für
    KL SUPPORTED Hardware unterstützt CR4.KL, Basis-LoadIKey-Anweisungen,
    KL KL CPUID-Blatt
    ENC.DEC_KL_ENABLED KL voll aktiviert Anweisungen Internen-Schlüssel-laden
    (CR4.KLset, {128,256} und Verschlüsselung oder
    Merkmalsaktivierung erfolgt, falls nötig) Entschlüsselung {ENC,DEC} {128,256}KL-Anweisungen
    KL Wide HW unterstützt Verschlüsselungs- oder
    WIDE*KL- Entschlüsselungsanweisungen
    Anweisungen {ENC,DEC}WIDE{128,256}KL-
    Anweisungen
    IKeyBackup System unterstützt KeyLocker-MSRs
    IKeyBackup (IA32_COPY_LOCAL_TO_PLATFORM,
    IA32_COPY_PLATFORM TO_LOCAL,
    IA32_COPY_STATUS,
    IA32_IKEYBACKUP_STATUS)
    NoBackup System unterstützt LoadIKey, wobei EAX[0] gesetzt
    NoBackup
    Random LoadIKey System unterstützt LoadIKey von HW mit Zufallsschlüssel LoadIKey, wobei EAX[1] gesetzt
    Bitmap unterstützter Beschränkungen Zeigt an, welche Beschränkungen unterstützt werden Welche Bits im Quellenregister für Internen-Schlüssel-laden {128,256} gesetzt werden können
  • Die Ausführungsformen hierin können als Infrastruktur für Erlaubnisüberprüfungen verwendet werden. In bestimmten Ausführungsformen kann ein (z. B. KeyLocker-)Handle nur auf zweierlei Arten und Weisen verwendet werden: (i) wie durch Handle-Beschränkungen erlaubt und auf demselben System oder (ii) durch einen Agenten, der den internen Schlüssel (IKey) kennt, wobei der Agent zum Beispiel ein Handle entschlüsseln kann, um einen Originalschlüssel wiederherzustellen. In bestimmten Ausführungsformen kann (ii) durch eine korrekte Verwaltung eines internen Schlüssels verhindert werden. Handle-Beschränkungen können verwendet werden, um zu verhindern, dass böswillige Software Handles anderswo verwendet, z. B. selbst wenn es ihr gelingt, sie zu stehlen.
  • Die Ausführungsformen hierin können als Beschränkung zum Begrenzen der Verwendung von Handles auf eine Enklave verwendet werden. Wenn zum Beispiel ein Bit „Enklavenbeschränkt“-Bit in einem Handle gesetzt ist, dann kann dieses Handle nur innerhalb einer Enklave verwendet werden, deren (z. B. 64-Bit-)Enklaven-ID (EID) den Bits (z. B. 127:64) des Zusätzliche-Authentisierungsdaten-Feldes des Handles entspricht (z. B. Bits, die integritätsgeschützt, aber nicht verschlüsselt sind). Dies kann verhindern, dass ein Angreifer, der das Handle stiehlt, dieses außerhalb der Enklave verwendet, vorausgesetzt, dass der Angreifer nicht über den internen Schlüssel verfügt. Eine Enklave kann einen internen Hardware-Zufallsschlüssel erfordern (der z. B. für jegliche Software unbekannt ist).
  • Die Ausführungsformen hierin können als Beschränkung zum Begrenzen der Verwendung von Handles auf einen Prozess verwendet werden. Wenn zum Beispiel ein „Prozessbeschränkt“-Bit in einem Handle gesetzt ist, dann kann dieses Handle nur innerhalb eines Prozesses verwendet werden, dessen (z. B. 64-Bit-)Prozess-ID den Handle-Bits (z. B Bits [95:32]) entspricht. In einer Ausführungsform hält ein neues IA32_PROCESS_ID-MSR die Prozess-ID in Bits 63:0. Wenn weniger Bits für die Prozess-ID benötigt werden (z. B. nur 48 Bit), kann das OS zusätzliche MSR-Bits für andere Nutzungen (z. B. Handle-Annullierung) verwenden. Eine spezifische Anwendungen kann das „Prozessbeschränkt“-Bit verwenden, um sicherzustellen, dass Handles, die durch eine andere Anwendung auf dem System gestohlen werden, das Handle nicht verwenden können.
  • Bei Virtualisierung stoppen oder migrieren Virtual-Machine-Monitore (z. B. Hypervisoren) Gäste (z. B. virtuelle Maschinen) häufig. Es kann wünschenswert sein, einen Gast zu stoppen und ihn (z. B. Monate) später (z. B. nach mehreren Neustarts) fortzusetzen. Es kann wünschenswert sein, den Gast auf ein anderes System zu verlegen (Migration). In bestimmten Ausführungsformen macht ein Handle Schlüssel ephemer, so dass sie nach einem Neustart oder auf einem anderen System nicht verwendet werden können. Als eine Lösung, um die oben erwähnten Wünsche zu erfüllen, kann ein interner Schlüssel durch Software spezifiziert werden (wobei zum Beispiel der Virtual-Machine-Monitor einen internen Schlüssel aufzeichnet, z. B. wenn ein Gast eine Internen-Schlüssel-laden-Anweisung verwendet), und/oder der Virtual-Machine-Monitor verheimlicht/verhindert Nutzung einer Internen-Schlüssel-laden-Anweisung (z. B. mit EAX[1], oder er kann VM-Beendigung nehmen und durch einen SW-spezifizierten Schlüssel oder sogar durch einen internen Schlüssel des Hosts ersetzen). In einer Ausführungsform sichert ein Virtual-Machine-Monitor einen internen Hypervisor-Schlüssel unter Verwendung von Plattformbereichs-IKeyBackup vor dem Laden des Gastschlüssels.
  • Figure 5 veranschaulicht Ausführung einer ersten „Internen-Schlüssel-laden“-Anweisung zum Laden eines ersten Gastschlüssels und Ausführung einer zweiten „Internen-Schlüssel-laden“-Anweisung zum Laden eines zweiten Gastschlüssels gemäß Ausführungsformen der Offenbarung. Ein Host 502 hat zwei Gäste, d. h. Gast 0 504 und Gast 506. Der dargestellte Gast 504 umfasst eine VM-Steuerstruktur 512, und der dargestellte Gast 506 umfasst eine VM-Steuerstruktur 514. Wie dargestellt, führt der Gast 504 eine Internen-Schlüssel-laden-Anweisung zum Laden des Hosts 502 mit einem Gast-O-Schlüssel 508 aus. In einer Ausführungsform wird bei Beendigung des Gasts 504 ein MSR-Befehl ausgegeben, um den internen Host-Schlüssel anstelle des internen Gast-0-Schlüssels wiederherzustellen. Wie dargestellt, führt der Gast 506 eine Internen-Schlüssel-laden-Anweisung zum Laden des Hosts 502 mit einem Gast-1-Schlüssel 510 aus. In einer Ausführungsform wird bei Beendigung des Gasts 506 ein MSR-Befehl ausgegeben, um den internen Host-Schlüssel anstelle des internen Gast-1-Schlüssels wiederherzustellen.
  • In bestimmten Ausführungsformen wird ein Steuerregister (z. B. CR4.KL (Bit 19)) verwendet, um zu verhindern, dass Gäste von Legacy-Virtual-Machine-Monitoren einen (z. B. Key Locker-)Zustand eines internen Schlüssels schreiben. In einer Ausführungsform verhindert das Steuerregister Lesen/Schreiben von internen Schlüssel(n) z. B. mit einer Ausnahme (z. B. undefiniert (#UD)) auf allen auf Handles/interne Schlüssel bezogenen Anweisungen (z. B. auf allen Anweisungen zum Lesen oder Schreiben von internen Schlüsseln), wenn zum Beispiel CR4.KL 0 ist. In bestimmten Ausführungsformen beeinflusst die Ausnahme den Wert des internen Schlüssels nicht, sie bewirkt lediglich, dass diese Anweisungen eine Ausnahme erzeugen. In einer Ausführungsform verwendet ein Virtual-Machine-Monitor eine MSR-Bitmap zum Schützen von unbekannten MSRs (und demnach IKeyBackup, wenn verwendet). In einer Ausführungsform wird das Vorhandensein von CR4.KL spezifiziert durch CPUID.KL_SUPPORTED (CPUID.(07H,0).ECX[23]).
  • Die Ausführungsformen hierin können als Beschränkung zum Begrenzen eines Handle auf einen Gast verwendet werden. Wenn zum Beispiel ein „Virtuelle-Maschine-Erweiterungen-(VMX-)Gast“-Bit in einem Handle gesetzt ist, dann kann dieses Handle nur innerhalb eines VMX-Gasts verwendet werden, dessen (z. B. 32-Bit-)VM-ID den Handle-Bits (z. B Bits [127:96]) entspricht. Bestimmte Ausführungsformen hierin erlauben die Verknüpfung eines Handles mit einem spezifischen VMX-Gast. In einer Ausführungsform ist VM-ID ein Feld in einer VM-Steuerstruktur, das z. B. verschieden von einem VM-Steuerstrukturzeiger und einem Extended-Page-Table-Zeigerfeld ist, die Gäste identifizieren, sich aber bei Migration ändern und physikalische Adressen sind. Wobei es zum Beispiel wünschenswert ist, physikalische Plattformadressen nicht gegenüber Gästen zu exponieren. Eine Beschränkung zum Begrenzen eines Handles auf einen Gast kann verwendet werden, wenn ein Opfer und Angreifergäste sich manchmal Handles teilen und den- oder dieselben internen Schlüssel verwenden müssen. Wenn in einer Ausführungsform ein Opfer und Angreifergäste verschiedene interne Schlüssel verwenden, dann kann ohnehin keiner die Handles des anderen verwenden.
  • Figure 6 veranschaulicht ein Verfahren 600 zur Verarbeitung einer Entschlüsselungsanweisung unter Verwendung eines Handles gemäß Ausführungsformen der Offenbarung. Das dargestellte Verfahren 600 umfasst ein Abrufen einer Einzelanweisung mit einem Opcode, der anzeigt, dass eine Entschlüsselungsoperation durchgeführt werden soll, und einem Feld zum Identifizieren eines ersten Eingabeoperanden eines Handles, das einen Chiffretext eines Verschlüsselungsschlüssels, ein Authentisierungstag und zusätzliche Authentisierungsdaten umfasst, und eines zweiten Eingabeoperanden von Daten, die mit dem Verschlüsselungsschlüssel verschlüsselt sind 602, Decodieren der Einzelanweisung in eine decodierte Einzelanweisung 604, Abrufen von Daten, die mit den identifizierten Eingabeoperanden assoziiert sind 606, (optionales) Disponieren der decodierten Einzelanweisung zur Ausführung 608, Ausführen der decodierten Einzelanweisung zum Durchführen eines ersten Vergleichs des Authentisierungstags mit dem Chiffretext und den zusätzlichen Authentisierungsdaten hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten, Durchführen eines zweiten Vergleichs einer aktuellen Anforderung des Kerns mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten des Handles spezifizierten Beschränkungen, Entschlüsseln des Chiffretexts zum Erzeugen des Verschlüsselungsschlüssels nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde, Entschlüsseln der mit dem Verschlüsselungsschlüssel verschlüsselten Daten, um unverschlüsselte Daten zu erzeugen, und Bereitstellen der unverschlüsselten Daten als eine Resultierende der Einzelanweisung 610 und Übernehmen der Resultierenden der ausgeführten Anweisung 612.
  • Bestimmte Ausführungsformen hierin betreffen eine Anweisung, die in den Eingabedaten (welche die Originaldaten umfassen) und spezifizierten Beschränkungen weitergegeben wird und ein Handle erstellt. In einer Ausführungsform handelt es sich bei den Originaldaten um einen Verschlüsselungsschlüssel. In einer Ausführungsform handelt es sich bei den Originaldaten um einen AES-128- oder einen AES-256-Verschlüsselungsschlüssel. In einer Ausführungsform sind auch die Metadaten (z. B. zusätzlichen Authentisierungsdaten) verschlüsselt. In einer Ausführungsform sind die Metadaten nicht verschlüsselt, sondern im Klartext (aber immer noch integritätsgeschützt). In einer Ausführungsform handelt es sich bei den Originaldaten um einen Schlüssel, der für signierte Hash-Codierung verwendet wird. In einer Ausführungsform begrenzen die Beschränkung(en) eine Nutzung des Handles (z. B. und der innerhalb des Handles verschlüsselten/integritätsgeschützten Originaldaten) auf: Verschlüsseln (z. B. spezifisch für die Daten, bei denen es sich um einen Schlüssel handelt), Entschlüsseln (z. B. spezifisch für die Daten, bei denen es sich um einen Schlüssel handelt), auf Ring 0 (OS/Kernel) und/oder einen spezifischen Prozess. In einer Ausführungsform begrenzen die Beschränkung(en) Nutzung des Handles, wenn ein spezifisches Element eines OS-gesteuerten Zustands auf eine spezifische Art und Weise festgelegt ist. In einer Ausführungsform wird eine Maske verwendet, so dass Nutzung des Handles nur erlaubt ist, wenn der spezifizierte Teil des OS-gesteuerten Zustands auf eine spezifische Art und Weise festgelegt ist. In einer Ausführungsform begrenzen die Beschränkung(en) Nutzung des Handles (z. B. verhindern sie die Nutzung des Handles) außerhalb einer spezifischen vertrauenswürdigen Ausführungsumgebung, beispielsweise einer spezifischen Software-Guard-Extension-(SGX-)Enklave, einer spezifischen vertrauenswürdigen Domäne (TD) (z. B. TDX-Gast), oder eines Systemverwaltungsmodus (SMM), ohne darauf beschränkt zu sein. In einer Ausführungsform begrenzen die Beschränkung(en) Nutzung des Handles, wenn ein spezifisches Element eines anwendungsgesteuerten Zustands nicht auf die spezifizierte Art und Weise festgelegt ist, um zum Beispiel einen Teilprozess zu begrenzen (z. B. nur wenn in einem spezifischen Schutzschlüssel, oder um ein Handle für Zugriffe auf eine Datenbank einer spezifischen Bank nur dann zu verwenden, wenn Daten für diese spezifische Bank verarbeitet werden). In einer Ausführungsform begrenzen die Beschränkung(en) Nutzung des Handles außerhalb eines Virtual-Machine-Monitors. In einer Ausführungsform begrenzen die Beschränkung(en) Nutzung des Handles auf einen spezifischen Anweisungszeiger. In einer Ausführungsform begrenzen die Beschränkung(en) Nutzung des Handles, wenn ein Annullierungsfeld anzeigt, dass es annulliert wurde. In einer Ausführungsform werden mehrere Beschränkungen kombiniert (z. B. nur verschlüsseln und nur innerhalb eines spezifischen Prozesses).
  • Im Folgenden werden beispielhafte Architekturen, Systeme usw. detailliert, in welchen das Vorhergesagte angewendet werden kann.
  • Wenigstens einige Ausführungsformen der offenbarten Technologien können angesichts der folgenden Beispiele beschrieben werden:
    • Beispiel 1. Hardwareprozessor, aufweisend:
      • einen Decoder eines Kerns zum Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung, wobei die Einzelanweisung einen ersten Eingabeoperanden eines Handles, das einen Chiffretext eines Verschlüsselungsschlüssels (z. B. eines kryptografischen Schlüssels oder anderer Daten), ein Authentisierungstag und zusätzliche Authentisierungsdaten umfasst, und einen zweiten Eingabeoperanden von Daten aufweist, die mit dem Verschlüsselungsschlüssel verschlüsselt sind; und
      • eine Ausführungseinheit des Kerns zum Ausführen der decodierten Einzelanweisung zum:
        • Durchführen eines ersten Vergleichs des Authentisierungstags mit dem Chiffretext und den zusätzlichen Authentisierungsdaten hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten,
        • Durchführen eines zweiten Vergleichs einer aktuellen Anforderung des Kerns mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten des Handles spezifizierten Beschränkungen,
        • Entschlüsseln des Chiffretexts zum Erzeugen des Verschlüsselungsschlüssels nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde {Oder Nachschlagen der Originaldaten (z. B. Klartext) in einem Cache. Außerdem kann eine Implementierung Entschlüsselung (oder Nachschlagen des Klartexts in einem Cache) selbst dann durchführen, wenn ein Vergleich fehlschlägt, und die Originaldaten in diesem Fall des „fehlgeschlagenen Vergleichs“ einfach nicht verwenden. Oder sie kann mit dem Verwenden der Originaldaten beginnen, aber die Ergebnisse nicht an den Benutzer zurücksenden (z. B. auch spekulativ zum Schutz gegen spekulative Ausführungsseitenkanäle)},
        • Entschlüsseln der mit dem Verschlüsselungsschlüssel verschlüsselten Daten, um unverschlüsselte Daten zu erzeugen, und
        • Bereitstellen der unverschlüsselten Daten als eine Resultierende der Einzelanweisung.
  • Beispiel 2. Hardwareprozessor nach Beispiel 1, wobei die Ausführungseinheit die decodierte Einzelanweisung ausführt, um ein Flag zu setzen (z. B. ein entsprechendes Flag auszulösen), wenn:
    • der erste Vergleich eine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt; oder
    • der zweite Vergleich anzeigt, dass gegen die eine oder die mehreren Beschränkungen verstoßen wurde.
  • Beispiel 3. Hardwareprozessor nach Beispiel 1, wobei der Decoder eine zweite Anweisung in eine decodierte zweite Anweisung decodiert, und die zweite Ausführungseinheit die decodierte zweite Anweisung ausführt, um einen internen Schlüssel, der zum Entschlüsseln des Chiffretexts verwendet wird, in ein Register des Kerns zu laden.
  • Beispiel 4. Hardwareprozessor nach Beispiel 3, wobei die Ausführungseinheit die decodierte zweite Anweisung ausführt, um einen ersten Wert im Register zu setzen, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen spezifischen Schlüssel als internen Schlüssel anforderte, und einen zweiten Wert im Register zu setzen, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen Zufallsschlüssel als internen Schlüssel anforderte.
  • Beispiel 5. Hardwareprozessor nach Beispiel 3, wobei der interne Schlüssel einen Integritätsschlüssel und einen separaten Verschlüsselungsschlüssel aufweist.
  • Beispiel 6. Hardwareprozessor nach Beispiel 1, wobei der Decoder eine zweite Anweisung in eine decodierte zweite Anweisung decodiert, und die Ausführungseinheit die decodierte zweite Anweisung ausführt, um das Handle aus einer Eingabe des Verschlüsselungsschlüssels und eines Handle-Beschränkungstyps zu erzeugen.
  • Beispiel 7. Hardwareprozessor nach Beispiel 1, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Verschlüsselung verwendet werden kann.
  • Beispiel 8. Hardwareprozessor nach Beispiel 1, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Entschlüsselung verwendet werden kann.
  • Beispiel 9. Verfahren, aufweisend:
    • Decodieren einer Einzelanweisung mit einem Decoder eines Kerns eines Hardwareprozessors in eine decodierte Einzelanweisung, wobei die Einzelanweisung einen ersten Eingabeoperanden eines Handles, das einen Chiffretext eines Verschlüsselungsschlüssels, ein Authentisierungstag und zusätzliche Authentisierungsdaten umfasst, und einen zweiten Eingabeoperanden von Daten aufweist, die mit dem Verschlüsselungsschlüssel verschlüsselt sind; und
    • Ausführen der decodierten Einzelanweisung mit einer Ausführungseinheit des Kerns zum:
      • Durchführen eines ersten Vergleichs des Authentisierungstags mit dem Chiffretext und den zusätzlichen Authentisierungsdaten hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten,
      • Durchführen eines zweiten Vergleichs einer aktuellen Anforderung des Kerns mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten des Handles spezifizierten Beschränkungen,
      • Entschlüsseln des Chiffretexts zum Erzeugen des Verschlüsselungsschlüssels nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde,
      • Entschlüsseln der mit dem Verschlüsselungsschlüssel verschlüsselten Daten, um unverschlüsselte Daten zu erzeugen, und
      • Bereitstellen der unverschlüsselten Daten als eine Resultierende der Einzelanweisung.
  • Beispiel 10. Verfahren nach Beispiel 9, wobei das Ausführen der decodierten Einzelanweisung ein Flag setzt, wenn:
    • der erste Vergleich eine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt; oder
    • der zweite Vergleich anzeigt, dass gegen die eine oder die mehreren Beschränkungen verstoßen wurde.
  • Beispiel 11. Verfahren nach Beispiel 9, ferner aufweisend:
    • Decodieren einer zweiten Anweisung mit dem Decoder des Kerns in eine decodierte zweite Anweisung; und
    • Ausführen der decodierten zweiten Anweisung mit der Ausführungseinheit des Kerns, um einen internen Schlüssel, der zum Entschlüsseln des Chiffretexts verwendet wird, in ein Register des Kerns zu laden.
  • Beispiel 12. Verfahren nach Beispiel 11, wobei die Ausführungseinheit einen ersten Wert im Register setzt, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen spezifischen Schlüssel als internen Schlüssel anforderte, und einen zweiten Wert im Register setzt, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen Zufallsschlüssel als internen Schlüssel anforderte.
  • Beispiel 13. Verfahren nach Beispiel 11, wobei der interne Schlüssel einen Integritätsschlüssel und einen separaten Verschlüsselungsschlüssel aufweist.
  • Beispiel 14. Verfahren nach Beispiel 9, ferner aufweisend:
    • Decodieren einer zweiten Anweisung mit dem Decoder des Kerns in eine decodierte zweite Anweisung; und
    • Ausführen der decodierten zweiten Anweisung mit der Ausführungseinheit des Kerns, um das Handle aus einer Eingabe des Verschlüsselungsschlüssels und eines Handle-Beschränkungstyps zu erzeugen.
  • Beispiel 15. Verfahren nach Beispiel 9, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Verschlüsselung verwendet werden kann.
  • Beispiel 16. Verfahren nach Beispiel 9, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Entschlüsselung verwendet werden kann.
  • Beispiel 17. Nicht-transitorisches maschinenlesbares Speichermedium, das Programmcode
    speichert, der bei Ausführung durch eine Maschine die Maschine veranlasst, ein Verfahren auszuführen, das aufweist:
    • Decodieren einer Einzelanweisung mit einem Decoder eines Kerns eines Hardwareprozessors in eine decodierte Einzelanweisung, wobei die Einzelanweisung einen ersten Eingabeoperanden eines Handles, das einen Chiffretext eines Verschlüsselungsschlüssels, ein Authentisierungstag und zusätzliche Authentisierungsdaten umfasst, und einen zweiten Eingabeoperanden von Daten aufweist, die mit dem Verschlüsselungsschlüssel verschlüsselt sind; und
    • Ausführen der decodierten Einzelanweisung mit einer Ausführungseinheit des Kerns zum:
      • Durchführen eines ersten Vergleichs des Authentisierungstags mit dem Chiffretext und den zusätzlichen Authentisierungsdaten hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten,
      • Durchführen eines zweiten Vergleichs einer aktuellen Anforderung des Kerns mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten des Handles spezifizierten Beschränkungen,
      • Entschlüsseln des Chiffretexts zum Erzeugen des Verschlüsselungsschlüssels nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde,
      • Entschlüsseln der mit dem Verschlüsselungsschlüssel verschlüsselten Daten, um unverschlüsselte Daten zu erzeugen, und
      • Bereitstellen der unverschlüsselten Daten als eine Resultierende der Einzelanweisung.
  • Beispiel 18. Nicht-transitorisches maschinenlesbares Speichermedium nach Beispiel 17, wobei das Ausführen der decodierten Einzelanweisung ein Flag setzt, wenn:
    • der erste Vergleich eine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt; oder
    • der zweite Vergleich anzeigt, dass gegen die eine oder die mehreren Beschränkungen verstoßen wurde.
  • Beispiel 19. Nicht-transitorisches maschinenlesbares Speichermedium nach Beispiel 17, ferner aufweisend:
    • Decodieren einer zweiten Anweisung mit dem Decoder des Kerns in eine decodierte zweite Anweisung; und
    • Ausführen der decodierten zweiten Anweisung mit der Ausführungseinheit des Kerns, um einen internen Schlüssel, der zum Entschlüsseln des Chiffretexts verwendet wird, in ein Register des Kerns zu laden.
  • Beispiel 20. Nicht-transitorisches maschinenlesbares Speichermedium nach Beispiel 19, wobei die Ausführungseinheit einen ersten Wert im Register setzt, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen spezifischen Schlüssel als internen Schlüssel anforderte, und einen zweiten Wert im Register setzt, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen Zufallsschlüssel als internen Schlüssel anforderte.
  • Beispiel 21. Nicht-transitorisches maschinenlesbares Speichermedium nach Beispiel 19, wobei der interne Schlüssel einen Integritätsschlüssel und einen separaten Verschlüsselungsschlüssel aufweist.
  • Beispiel 22. Nicht-transitorisches maschinenlesbares Speichermedium nach Beispiel 17, ferner umfassend:
    • Decodieren einer zweiten Anweisung mit dem Decoder des Kerns in eine decodierte zweite Anweisung; und
    • Ausführen der decodierten zweiten Anweisung mit der Ausführungseinheit des Kerns, um das Handle aus einer Eingabe des Verschlüsselungsschlüssels und eines Handle-Beschränkungstyps zu erzeugen.
  • Beispiel 23. Nicht-transitorisches maschinenlesbares Speichermedium nach Beispiel 17, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Verschlüsselung verwendet werden kann.
  • Beispiel 24. Nicht-transitorisches maschinenlesbares Speichermedium nach Beispiel 17, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Entschlüsselung verwendet werden kann.
  • Beispiel 25. Hardwareprozessor, aufweisend:
    • einen Decoder eines Kerns zum Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung, wobei die Einzelanweisung einen Eingabeoperanden eines Handles aufweist, das einen Chiffretext von Originaldaten, ein Authentisierungstag und zusätzliche Authentisierungsdaten umfasst; und
    • eine Ausführungseinheit des Kerns zum Ausführen der decodierten Einzelanweisung zum:
      • Durchführen eines ersten Vergleichs des Authentisierungstags mit dem Chiffretext und den zusätzlichen Authentisierungsdaten hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten,
      • Durchführen eines zweiten Vergleichs einer aktuellen Anforderung des Kerns mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten des Handles spezifizierten Beschränkungen,
      • Entschlüsseln des Chiffretexts zum Erzeugen der Originaldaten nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde,
      • Durchführen einer Operation an den Originaldaten, um Ergebnisdaten zu erzeugen, und Bereitstellen der Ergebnisdaten als eine Resultierende der Einzelanweisung.
  • Beispiel 26. Hardwareprozessor nach Beispiel 25, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht außerhalb eines Betriebssystems verwendet werden kann.
  • Beispiel 27. Hardwareprozessor nach Beispiel 25, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht außerhalb einer spezifischen vertrauenswürdigen Ausführungsumgebung verwendet werden kann.
  • Beispiel 28. Hardwareprozessor nach Beispiel 25, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nur verwendet werden kann, wenn ein spezifisches Element eines betriebssystemgesteuerten Zustands auf eine spezifische Art und Weise festgelegt ist.
  • Beispiel 29. Hardwareprozessor nach Beispiel 25, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle durch einen Virtual-Machine-Monitor verwendet werden kann, aber nicht durch eine virtuelle Maschine verwendet werden kann.
  • Beispiel 30. Hardwareprozessor nach Beispiel 25, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Entschlüsselung verwendet werden kann.
  • In noch einer anderen Ausführungsform umfasst eine Vorrichtung ein Datenspeichergerät, das Code speichert, der bei Ausführung durch einen Hardwareprozessor den Hardwareprozessor zum Durchführen eines der hierin offenbarten Verfahren veranlasst. Eine Vorrichtung kann so sein, wie in der ausführlichen Beschreibung dargelegt. Ein Verfahren kann so sein, wie in der ausführlichen Beschreibung dargelegt.
    Ein Anweisungssatz kann ein oder mehrere Anweisungsformate umfassen. Ein bestimmtes Anwendungsformat definiert verschiedene Felder (z. B. Anzahl von Bits, Position von Bits), um u. a. die auszuführende Operation (z. B. Opcode) und den bzw. die Operanden, an welchem/welchen die Operation ausgeführt werden soll, und andere Datenfeld(er) (z. B. Maske) zu spezifizieren. Einige Anweisungsformate sind durch die Definition von Anweisungsvorlagen (oder Subformaten) weiter aufgegliedert. Zum Beispiel können die Anweisungsvorlagen eines gegebenen Anweisungsformats so definiert sein, dass sie verschiedene Teilsätze der Felder des Anweisungsformats aufweisen (die enthaltenen Felder sind typischerweise in der gleichen Reihenfolge, aber wenigstens einige weisen andere Bitpositionen auf, da weniger Felder enthalten sind) und/oder so definiert sein, dass sie ein gegebenes Feld aufweisen, das anders interpretiert wird. Demnach wird jede Anweisung einer ISA unter Verwendung eines gegebenen Anweisungsformats (und, falls definiert, in einem gegebenen der Anweisungsvorlagen dieses Anweisungsformats) ausgedrückt und umfasst Felder zum Spezifizieren der Operation und der Operanden. Zum Beispiel weist eine beispielhafte ADD-Anweisung einen spezifischen Opcode und ein Anweisungsformat auf, das ein Opcode-Feld zum Spezifizieren dieses Opcodes und Operanden-Felder zum Auswählen von Operanden (Ursprung 1/Ziel und Ursprung2) umfasst; und ein Auftreten dieser ADD-Anweisung in einem Anweisungsstrom weist spezifische Inhalte im Operanden-Feld auf, das spezifische Operanden auswählt. Ein Satz von SIMD-Erweiterungen, der als Advanced Vector Extensions (AVX) (AVX1 and AVX2) bezeichnet wird und das Vector Extension-(VEX-)Codierungsschema verwendet, wurde herausgegeben und/oder veröffentlicht (siehe z. B. Intel® 64 und IA-32 Architectures Software Developer's Manual, November 2018; und siehe Intel® Architecture Instruction Set Extensions Programming Reference, Oktober 2018).
  • Beispielhafte Anweisungsformate
  • Ausführungsformen der hierin beschriebenen Anweisung(en) können in verschiedenen Formaten verwirklicht sein. Außerdem werden im Folgenden beispielhafte Systeme, Architekturen und Pipelines ausführlich beschrieben. Ausführungsformen der Anweisung(en) können in solchen Systemen, Architekturen und Pipelines ausgeführt werden, sind aber nicht auf jene beschränkt, die beschrieben werden.
  • Generisches vektorfreundliches Anweisungsformat
  • Ein vektorfreundliches Anweisungsformat ist ein Anweisungsformat, das für Vektoranweisungen geeignet ist (z. B. gibt es bestimmte Felder, die für Vektoroperationen spezifisch sind). Obwohl Ausführungsformen beschrieben werden, in welchen sowohl Vektorals auch Skalar-Operationen durch das vektorfreundliche Anweisungsformat unterstützt werden, verwenden alternative Ausführungsformen nur Vektoroperationen mit dem vektorfreundlichen Anweisungsformat.
  • 7A und 12B sind Blockdiagramme, die ein generisches vektorfreundliches Anweisungsformat und Anweisungsvorlagen davon gemäß Ausführungsformen der Offenbarung veranschaulichen; 7A ist ein Blockdiagramm, das ein generisches vektorfreundliches Anweisungsformat und Klasse-A-Anweisungsvorlagen davon gemäß Ausführungsformen der Offenbarung veranschaulicht; während 7B ein Blockdiagramm ist, das ein generisches vektorfreundliches Anweisungsformat und Klasse-B-Anweisungsvorlagen davon gemäß Ausführungsformen der Offenbarung veranschaulicht. Konkret ein generisches vektorfreundliches Anweisungsformat 700, für welches Anweisungsvorlagen der Klasse A und der Klasse B definiert sind, welche beide Anweisungsvorlagen ohne Speicherzugriff 705 und Anweisungsvorlagen mit Speicherzugriff 720 umfassen. Der Begriff „generisch“ im Kontext des vektorfreundlichen Anweisungsformats bezieht sich darauf, dass das Anweisungsformat an keinen spezifischen Anweisungssatz gebunden ist.
  • Obwohl Ausführungsformen der Offenbarung beschrieben werden, in welchen das vektorfreundliche Anweisungsformat Folgendes unterstützt: eine Vektoroperandenlänge (oder - größe) von 64 Byte mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte) oder 64 Bit (8 Byte) (so dass ein 64-Byte-Vektor entweder aus 16 Elementen von Doppelwortgröße oder alternativ 8 Elementen von Quadwortgröße besteht); eine Vektoroperandenlänge (oder -größe) von 64 Byte mit Datenelementbreiten (oder -größen) von 16 Bit (2 Byte) oder 8 Bit (1 Byte); eine Vektoroperandenlänge (oder -größe) von 32 Byte mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte); und eine Vektoroperandenlänge (oder -größe) von 16 Byte mit Datenelementbreiten (oder -größen) von 32 Bit (4 Byte), 64 Bit (8 Byte), 16 Bit (2 Byte) oder 8 Bit (1 Byte); alternative Ausführungsformen können größere, kleinere und/oder andere Vektoroperandengrößen (z. B. Vektoroperanden von 256 Byte) mit größeren, kleineren und/oder anderen Datenelementbreiten (z. B. Datenelementbreiten von 128 Bit (16 Byte)) unterstützen.
  • Die Anweisungsvorlagen der Klasse A in 7A umfassen: 1) innerhalb der Anweisungsvorlagen ohne Speicherzugriff 705 sind eine Anweisungsvorlage für Vollrundungssteuerungsoperation ohne Speicherzugriff 710 und eine Anweisungsvorlage für Datenumwandlungsoperation ohne Speicherzugriff 715 dargestellt; und 2) innerhalb der Anweisungsvorlagen mit Speicherzugriff 720 sind eine temporale Anweisungsvorlage mit Speicherzugriff 725 und eine nicht-temporale Anweisungsvorlage mit Speicherzugriff 730 dargestellt. Die Anweisungsvorlagen der Klasse B in 7B umfassen: 1) innerhalb der Anweisungsvorlagen ohne Speicherzugriff 705 sind eine Anweisungsvorlage für Schreibmaskensteuerungs- und Teilrundungssteuerungsoperation ohne Speicherzugriff 712 und eine Anweisungsvorlage für Schreibmaskensteuerungs- und vsize-Operation ohne Speicherzugriff 717 dargestellt; und 2) innerhalb der Anweisungsvorlagen mit Speicherzugriff 720 ist eine Anweisungsvorlage für Schreibmaskensteuerung mit Speicherzugriff 727 dargestellt.
  • Das generische vektorfreundliche Anweisungsformat 700 umfasst die folgenden Felder, die nachstehend in der in 7A und 7B veranschaulichten Reihenfolge aufgelistet sind.
  • Formatfeld 740 - ein spezifischer Wert (ein Anweisungsformatkennungswert) in diesem Feld identifiziert das vektorfreundliche Anweisungsformat und demnach die Auftrittshäufigkeiten von Anweisungen im vektorfreundlichen Anweisungsformat in Anweisungsströmen eindeutig. Entsprechend ist dieses Feld insofern optional, als es für einen Anweisungssatz, der nur das generische vektorfreundliche Anweisungsformat aufweist, nicht benötigt wird.
  • Basisoperationsfeld 742 - sein Inhalt unterscheidet verschiedene Basisoperationen.
  • Registerindexfeld 744 - sein Inhalt spezifiziert direkt oder durch Adressgenerierung die Orte der Quellen- und Zieloperanden, einerlei ob in Registern und in Speicher. Diese umfassen eine ausreichende Anzahl von Bits, um N Register aus einer P x Q (z. B. 32 x 512, 16 x 128, 32 x 1024, 64 x 1024)-Registerdatei auszuwählen. Obwohl sich N in einer Ausführungsform auf bis zu drei Quellen- und ein Zielregister belaufen kann, können alternative Ausführungsformen mehr oder weniger Quellen- und Zielregister unterstützen (z. B. können sie bis zu zwei Quellen unterstützen, wobei eine dieser Quellen auch als Ziel fungiert, sie können bis zu drei Quellen unterstützen, wobei eine dieser Quellen auch Ziel fungiert, sie können bis zu zwei Quellen und ein Ziel unterstützen).
  • Modifiziererfeld 746 - sein Inhalt unterscheidet Auftrittshäufigkeiten von Anweisungen im generischen vektorfreundlichen Anweisungsformat, welche Speicherzugriff spezifizieren, von jenen, die dies nicht tun; das heißt, zwischen Anweisungsvorlagen ohne Speicherzugriff 705 und Anweisungsvorlagen mit Speicherzugriff 720. Speicherzugriffsoperationen lesen und/oder schreiben in die Speicherhierarchie (in einigen Fällen unter Angabe der Quellen- und/oder Zieladressen, wobei Werte in Registern verwendet werden), während Operationen ohne Speicherzugriff dies nicht tun (z. B. die Quellen und die Ziele Register sind). Obwohl dieses Feld in einer Ausführungsform auch zwischen drei verschiedenen Möglichkeiten zum Durchführen von Speicheradressberechnungen auswählt, können alternative Ausführungsformen mehr, weniger oder andere Möglichkeiten zum Durchführen von Speicheradressberechnungen unterstützen.
  • Erweiterungsoperationsfeld 750 - sein Inhalt unterscheidet, welche von einer Vielzahl von verschiedenen Operationen zusätzlich zur Basisoperation ausgeführt werden soll. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Offenbarung ist dieses Feld in ein Klassenfeld 768, ein Alpha-Feld 752 und ein Beta-Feld 754 unterteilt. Das Erweiterungsoperationsfeld 750 ermöglicht die Ausführung von gemeinsamen Gruppen von Operationen in einer einzigen Anweisung statt in 2, 3 oder 4 Anweisungen.
  • Skalierfeld 760 - sein Inhalt ermöglicht die Skalierung des Indexfeldinhalts zur Speicheradressgenerierung (z. B. für eine Adressgenerierung, die 2scale * Index + Basis verwendet).
  • Verschiebungsfeld 762A - sein Inhalt wird als Teil einer Speicheradressgenerierung verwendet (z. B. für eine Adressgenerierung, die 2scale * Index + Basis + Verschiebung verwendet).
  • Verschiebungsfaktorfeld 762B (es ist zu erwähnen, dass die Nebeneinanderstellung des Verschiebungsfeldes 762A direkt über dem Verschiebungsfaktorfeld 762B anzeigt, dass eines oder das andere verwendet wird) - sein Inhalt wird als Teil der Adressgenerierung verwendet; er spezifiziert einen Verschiebungsfaktor, der um die Größe eines Speicherzugriffs (N) skaliert werden soll - wobei N die Anzahl von Bytes im Speicherzugriff ist (z. B. für Adressgenerierung, die 2scale * Index + Basis + skalierte Verschiebung verwendet). Redundante niederwertige Bits werden ignoriert, und daher wird der Inhalt des Verschiebungsfaktorfeldes mit der Gesamtgröße (N) der Speicheroperanden multipliziert, um die endgültige Verschiebung zu generieren, die beim Berechnen einer effektiven Adresse verwendet werden soll. Der Wert von N wird durch die Prozessorhardware zur Laufzeit basierend auf dem vollständigen Opcode-Feld 774 (später hierin beschrieben) und dem Datenbearbeitungsfeld 754C bestimmt. Das Verschiebungsfeld 762A und das Verschiebungsfaktorfeld 762B sind insofern optional, als sie für die Anweisungsvorlagen ohne Speicherzugriff 705 nicht verwendet werden, und/oder verschiedene Ausführungsformen nur eines oder keines der beiden implementieren können.
  • Datenelementbreitenfeld 764 - sein Inhalt unterscheidet, welche von einer Anzahl von Datenelementbreiten verwendet werden soll (in einigen Ausführungsformen für alle Anweisungen; in anderen Ausführungsformen nur für einige der Anweisungen). Dieses Feld ist insofern optional, als es nicht benötigt wird, wenn nur eine Datenelementbreite unterstützt wird und/oder Datenelementbreiten unter Verwendung eines gewissen Aspekts der Opcodes unterstützt werden.
  • Schreibmaskenfeld 770 - sein Inhalt kontrolliert auf einer Pro-Datenelementposition-Basis, ob die Datenelementposition im Zielvektoroperanden das Ergebnis der Basisoperation und der Erweiterungsoperation widerspiegelt. Anweisungsvorlagen der Klasse A unterstützen Zusammenführungs-Schreibmaskieren, während Anweisungsvorlagen der Klasse B sowohl Zusammenführungs- als auch Nullsetzungs-Schreibmaskieren unterstützen. Beim Zusammenführen ermöglichen Vektormasken es, jeden Satz von Elementen im Ziel vor Aktualisierungen während der Ausführung jeglicher Operation (spezifiziert durch die Basisoperation und die Erweiterungsoperation) zu schützen; wobei in einer anderen Ausführungsform der alte Wert jedes Elements des Ziels bewahrt wird, wenn das entsprechende Maskenbit eine 0 aufweist. Beim Nullsetzen dagegen ermöglichen Vektormasken es, jeden Satz von Elementen im Ziel vor Aktualisierungen während der Ausführung jeglicher Operation (spezifiziert durch die Basisoperation und die Erweiterungsoperation) auf null zu setzen; in einer Ausführungsform wird ein Elements des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Ein Teilsatz dieser Funktionalität ist die Fähigkeit zum Steuern der Vektorlänge der Operation, die ausgeführt wird (das heißt, die Spanne von Elementen wird vom ersten bis zum letzten modifiziert); es ist jedoch nicht notwendig, dass die Elemente, die modifiziert werden, hintereinander sind. Demnach ermöglicht das Schreibmaskenfeld 770 partielle Vektoroperationen, die Lade, Speicher-, arithmetische, logische usw. Operationen umfassen. Obwohl Ausführungsformen der Offenbarung beschrieben werden, in welchen der Inhalt des Schreibmaskenfeldes 770 eines von einer Anzahl von Schreibmaskenregistern auswählt, das die Schreibmaske enthält, die verwendet werden soll (und der Inhalt des Schreibmaskenfeldes 770 daher indirekt identifiziert, dass diese Maskierung durchgeführt werden soll), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Schreibmaskenfeldes 770 die Maskierung, die ausgeführt werden soll, direkt spezifiziert.
  • Unmittelbares Feld 772 - sein Inhalt ermöglicht die Spezifizierung einer unmittelbaren Adressierung. Dieses Feld ist insofern optional, als es in einer Implementierung des generischen vektorfreundlichen Formats, das unmittelbare Adressierung nicht unterstützt, nicht vorhanden ist und in Anweisungen, die unmittelbare Adressierung nicht verwenden, nicht vorhanden ist.
  • Klassenfeld 768 - sein Inhalt unterscheidet zwischen verschiedenen Klassen von Anweisungen. Unter Bezugnahme auf 7A und 7B wählen die Inhalte dieses Feldes zwischen Anweisungen der Klasse A und der Klasse B. In 7A und 7B werden Vierecke mit abgerundeten Ecken verwendet, um anzuzeigen, dass ein spezifischer Wert in einem Feld vorhanden ist (z. B. Klasse A 768A und Klasse B 768B für das Klassenfeld 768 in 7A bzw. 7B).
  • Anweisungsvorlagen der Klasse A
  • Im Falle der Anweisungsvorlagen ohne Speicherzugriff 705 der Klasse A, wird das Alpha-Feld 752 als ein RS-Feld 752A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Erweiterungsoperationstypen durchgeführt werden soll (z. B. werden Rundung 752A.1 und Datenumwandlung 752A.2 für die Anweisungsvorlagen für Rundungsoperation ohne Speicherzugriff 710 bzw. Datenumwandlungsoperation ohne Speicherzugriff 715 spezifiziert), während das Beta-Feld 754 unterscheidet, welche der Operationen des spezifizierten Typs ausgeführt werden soll. In den Anweisungsvorlagen ohne Speicherzugriff 705 sind das Skalierfeld 760, das Verschiebungsfeld 762A und das Verschiebungsfaktorfeld 762B nicht vorhanden.
  • Anweisungsvorlagen ohne Speicherzugriff - Vollrundungssteuerungsoperation
  • In der Anweisungsvorlage für Vollrundungssteuerungsoperation ohne Speicherzugriff 710 wird das Beta-Feld 754 als ein Rundungssteuerungsfeld 754A interpretiert, dessen Inhalt(e) statische Rundung bereitstellen. Obwohl in den beschriebenen Ausführungsformen der Offenbarung das Rundungssteuerungsfeld 754A ein Feld Alle-Gleitkomma-Ausnahmenunterdrücken (SAE - Suppress All floating point Exceptions) 756 und ein Rundungsoperationssteuerungsfeld 758 umfasst, könne alternative Ausführungsformen beide dieser Konzepte im gleichen Feld unterstützen oder nur eines oder das andere diese Konzepte/Felder aufweisen (z. B. nur das Rundungsoperationssteuerfeld 758 aufweisen).
  • SAE-Feld 756 - sein Inhalt unterscheidet, ob die Ausnahmeereignismeldung deaktiviert werden soll oder nicht; wenn der Inhalt des SAE-Feldes 756 anzeigt, dass Unterdrückung aktiviert ist, dann meldet eine bestimmte Anweisung weder irgendeine Art von Gleitkomma-Ausnahme-Flag, noch löst sie einen Gleitkomma-Ausnahmehandler aus.
  • Rundungsoperationssteuerungsfeld 758 - sein Inhalt unterscheidet, welche von einer Gruppe von Rundungsoperationen ausgeführt werden soll (z. B. Aufrunden, Abrunden, Runden gegen Null und Runden auf nächste Zahl). Daher ermöglicht das Rundungsoperationssteuerungsfeld 758 die Änderung des Rundungsmodus auf einer Pro-Anweisung-Basis. In einer Ausführungsform der Offenbarung, in welcher ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi umfasst, überschreibt der Inhalt des Rundungsoperationssteuerungsfeldes 750 diesen Registerwert.
  • Anweisungsvorlagen ohne Speicherzugriff - Datenumwandlungsoperation
  • In der Anweisungsvorlage für Datenumwandlungsoperation ohne Speicherzugriff 715 wird das Beta-Feld 754 als ein Datenumwandlungsfeld 754B interpretiert, dessen Inhalt unterscheidet, welche von einer Anzahl von Datenumwandlungen durchgeführt werden soll (z. B. keine Datenumwandlung, Umordnung, Broadcast).
  • Im Falle einer Anweisungsvorlage mit Speicherzugriff 720 der Klasse A wird das Alpha-Feld 752 als ein Entfernungshinweisfeld 752B interpretiert, dessen Inhalt unterscheidet, welcher der Entfernungshinweise verwendet werden soll (in 7A sind temporal 752B.1 und nicht-temporal 752B.2 für die temporale Anweisungsvorlage mit Speicherzugriff 725 bzw. die für nicht-temporale Anweisungsvorlage mit Speicherzugriff 730 spezifiziert), während das Beta-Feld 754 als ein Datenbearbeitungsfeld 754C interpretiert wird, dessen Inhalt unterscheidet, welche von einer Anzahl von Datenbearbeitungsoperationen (auch als Primitive bekannt) ausgeführt werden soll (z. B. keine Bearbeitung; Broadcast; Aufwärtsumsetzung einer Quelle; und Abwärtsumsetzung eines Ziels). Die Anweisungsvorlagen mit Speicherzugriff 720 umfassen das Skalierfeld 760 und optional das Verschiebungsfeld 762A oder das Verschiebungsfaktorfeld 762B.
  • Vektorspeicheranweisungen führen Operationen des Vektorladens aus und Vektorspeicherns in Speicher mit Umsetzungsunterstützung durch. Wie bei regulären Vektoranweisungen übertragen Vektorspeicheranweisungen Daten datenelementweise aus/in Speicher, wobei die Elemente, die tatsächlich übertragen werden, durch die Inhalte der Vektormaske vorgeschrieben werden, die als die Schreibmaske ausgewählt ist.
  • Anweisungsvorlagen mit Speicherzugriff - Temporal
  • Temporale Daten sind Daten, die wahrscheinlich früh genug wiederverwendet werden, um aus Caching Nutzen zu ziehen. Dies ist jedoch ein Hinweis, und verschiedene Prozessoren können ihn auf verschiedene Art und Weise, einschließlich eines völligen Ignorierens des Hinweises, implementieren.
  • Anweisungsvorlagen mit Speicherzugriff - Nicht-temporal
  • Nicht-temporale Daten sind Daten, die wahrscheinlich nicht früh genug wiederverwendet werden, um aus Caching im Cache der 1. Ebene Nutzen zu ziehen, und denen Entfernungspriorität erteilt werden sollte. Dies ist jedoch ein Hinweis, und verschiedene Prozessoren können ihn auf verschiedene Art und Weise, einschließlich eines völligen Ignorierens des Hinweises, implementieren.
  • Anweisungsvorlagen der Klasse B
  • Im Falle der Anweisungsvorlagen der Klasse B wird das Alpha-Feld 752 als ein Feld Schreibmaskensteuerung (Z) 752C interpretiert, dessen Inhalt unterscheidet, ob das Schreibmaskieren, das durch das Schreibmaskenfeld 770 gesteuert wird, ein Zusammenführen oder ein Nullsetzen sein sollte.
  • Im Falle der Anweisungsvorlagen ohne Speicherzugriff 705 der Klasse B, wird das Beta-Feld 754 als ein RL-Feld 757A interpretiert, dessen Inhalt unterscheidet, welche der verschiedenen Erweiterungsoperationstypen durchgeführt werden soll (z. B. werden Rundung 757A.1 und Vektorlänge (VSIZE) 757A.2 für die Anweisungsvorlage für Schreibmaskensteuerungs- und Teilrundungssteuerungsoperation ohne Speicherzugriff 712 bzw. die Anweisungsvorlage für Schreibmaskensteuerungs- und VSIZE-Operation ohne Speicherzugriff 717 spezifiziert), während der Rest des Beta-Feldes 754 unterscheidet, welche der Operationen des spezifizierten Typs ausgeführt werden soll. In den Anweisungsvorlagen ohne Speicherzugriff 705 sind das Skalierfeld 760, das Verschiebungsfeld 762A und das Verschiebungsfaktorfeld 762B nicht vorhanden.
  • In der Anweisungsvorlage für Schreibmaskensteuerungs- und Teilrundungssteuerungsoperation ohne Speicherzugriff 710 wird des Rest des beta-Feldes 754 als ein Rundungsoperationsfeld 759A interpretiert, und Ausnahmeereignismeldung ist deaktiviert (ein bestimmte Anweisung meldet weder irgendeine Art von Gleitkomma-Ausnahme-Flag, noch löst sie einen Gleitkoma-Ausnahmehandler aus).
  • Rundungsoperationssteuerungsfeld 759A - wie beim Rundungsoperationssteuerungsfeld 758 unterscheidet sein Inhalt, welche von einer Gruppe von Rundungsoperationen ausgeführt werden soll (z. B. Aufrunden, Abrunden, Runden gegen null und Runden auf nächste Zahl). Daher ermöglicht das Rundungsoperationssteuerungsfeld 759A die Änderung des Rundungsmodus auf einer Pro-Anweisung-Basis. In einer Ausführungsform der Offenbarung, in welcher ein Prozessor ein Steuerregister zum Spezifizieren von Rundungsmodi umfasst, überschreibt der Inhalt des Rundungsoperationssteuerungsfeldes 750 diesen Registerwert.
  • In der Anweisungsvorlage für Schreibmaskensteuerungs- und VSIZE-Operation ohne Speicherzugriff 717 wird der Rest des Beta-Feldes 754 als ein Vektorlängenfeld 759B interpretiert, dessen Inhalt unterscheidet, welche von einer Anzahl von Datenvektorlängen daran durchgeführt werden soll (z. B. 128, 256 oder 512 Byte).
  • Im Falle einer Anweisungsvorlage mit Speicherzugriff 720 der Klasse B wird ein Teil des Beta-Feldes 754 als ein Broadcast-Feld 757B interpretiert, dessen Inhalt unterscheidet, ob die Broadcastdatenbearbeitungsoperation ausgeführt werden soll oder nicht, während der Rest des Beta-Feldes 754 als das Vektorlängenfeld 759B interpretiert wird. Die Anweisungsvorlagen mit Speicherzugriff 720 umfassen das Skalierfeld 760 und optional das Verschiebungsfeld 762A oder das Verschiebungsfaktorfeld 762B.
  • In Bezug auf das generische vektorfreundliche Anweisungsforma 700 ist ein vollständiges Opcode-Feld 774 so dargestellt, dass es das Formatfeld 740, das Basisoperationsfeld 742 und das Datenelementbreitenfeld 764 umfasst. Obwohl eine Ausführungsform dargestellt ist, in welcher das vollständige Opcode-Feld 774 all diese Felder umfasst, umfasst das vollständige Opcode-Feld 774 in Ausführungsformen, die nicht alle davon unterstützen, weniger als all diese Felder. Das vollständige Opcode-Feld 774 stellt den Operationscode (Opcode) bereit.
  • Das Erweiterungsoperationsfeld 750, das Datenelementbreitenfeld 764 und das Schreibmaskenfeld 770 ermöglichen die Spezifizierung dieser Merkmale auf einer Pro-Anweisung-Basis im generischen vektorfreundlichen Anweisungsformat.
  • Die Kombination von Schreibmaskenfeld und Datenelementbreitenfeld erzeugt typenorientierte Anweisungen, insofern sie ermöglichen, dass die Maske basierend auf verschiedenen Datenelementbreiten angewendet wird.
  • Die verschiedenen Anweisungsvorlagen, die innerhalb der Klasse A und der Klasse B vorzufinden sind, sind in verschiedenen Situationen vorteilhaft. In einigen Ausführungsformen der Offenbarung können verschiedene Prozessoren oder verschiedene Kerne innerhalb eines Prozessors nur Klasse A, nur Klasse B oder beide Klassen unterstützen. Zum Beispiel kann ein für Allzweckberechnung bestimmter Out-of-Order-Hochleistungs-Universalkern nur Klasse B unterstützen, ein in erster Linie für Computergrafik und/oder wissenschaftliches (Durchsatz-) Rechnen bestimmter Kern kann nur Klasse A unterstützen, und ein Kern, der für beides bestimmt ist, kann beide Klassen unterstützen (natürlich fällt ein Kern, der eine bestimmte Mischung von Vorlagen und Anweisungen aus beiden Klassen, aber nicht alle Vorlagen und Anweisungen aus beiden Klassen aufweist, in den Schutzbereich der Offenbarung). Außerdem kann ein einzelner Prozessor mehrere Kerne umfassen, von welchen alle die gleiche Klasse unterstützen, oder in welchen verschiedene Kerne eine unterschiedliche Klasse unterstützen. Zum Beispiel kann in einem Prozessor mit separaten Grafik- und Universalkernen einer der Grafikkerne, der in erster Linie für Computergrafik und/oder wissenschaftliches Rechnen bestimmt ist, nur Klasse A unterstützen, während ein oder mehrere der Universalkerne Hochleistungs-Universalkerne ohne Out-of-Order-Ausführung und Registerumbenennung sein können, die für Allzweckberechnung bestimmt sind und nur Klasse B unterstützen. Ein anderer Prozessor, der keinen separaten Grafikkern aufweist, kann einen oder mehrere In-Order- oder Out-of-Order-Universalkerne umfassen, die sowohl Klasse A als auch Klasse B unterstützen. Natürlich können in verschiedenen Ausführungsformen der Offenbarung Merkmale aus einer Klasse auch in der anderen Klasse implementiert sein. Programme, die in einer höheren Programmiersprache geschrieben sind, würden in eine Vielzahl von verschiedenen ausführbaren Formen versetzt werden, die umfassen: 1) eine Form nur mit Anweisungen der vom Zielprozessor zur Ausführung unterstützen Klasse(n); oder 2) eine Form mit alternativen Routinen, die unter Verwendung von verschiedenen Kombinationen der Anweisungen aller Klassen geschrieben sind und Steuerflusscode aufweisen, der die auszuführenden Routinen basierend auf den Anweisungen auswählt, die vom Prozessor unterstützt werden, der den Code gerade ausführt.
  • Beispielhaftes spezifisches vektorfreundliches Anweisungsformat
  • 8 ist ein Blockdiagramm, das ein beispielhaftes spezifisches vektorfreundliches Anweisungsformat gemäß Ausführungsformen der Offenbarung veranschaulicht. 8 stellt ein spezifisches vektorfreundliches Anweisungsformat 800 dar, das in dem Sinne spezifisch ist, dass es den Position, die Größe, die Interpretation und die Reihenfolge der Felder sowie die Werte für einige dieser Felder spezifiziert. Das spezifische vektorfreundliche Anweisungsformat 800 kann verwendet werden, um den x86-Anweisungssatz zu erweitern, weshalb einige Felder ähnlich oder gleich wie jene sind, die im bestehenden x86-Anweisungssatz und einer Erweiterung davon (z. B. AVX) verwendet werden. Dieses Format bleibt konform mit dem Präfixcodierungsfeld, dem Realer-Opcode-Byte-Feld, dem MOD R/M-Feld, dem SIB-Feld, dem Verschiebungsfeld und den unmittelbaren Feldern des bestehenden x86-Anweisungssatzes mit Erweiterungen. Es sind die Felder von 7 veranschaulicht, in welche die Felder von 8 abgebildet sind.
  • Es versteht sich von selbst, dass, obwohl Ausführungsformen der Offenbarung in Bezug auf das spezifische vektorfreundliche Anweisungsformat 800 im Kontext des generischen vektorfreundlichen Anweisungsformats 700 zu Veranschaulichungszwecken beschrieben werden, die Offenbarung nicht auf das spezifische vektorfreundliche Anweisungsformat 800 beschränkt ist, außer wo dies beansprucht wird. Zum Beispiel sieht das generische vektorfreundliche Anweisungsformat 700 eine Vielzahl von möglichen Größe für die verschiedenen Felder vor, während das spezifische vektorfreundliche Anweisungsformat 800 so dargestellt ist, dass es Felder von spezifischen Größen aufweist. Obwohl als spezifisches Beispiel das Datenelementbreitenfeld 764 im spezifischen vektorfreundlichen Anweisungssatz 800 als ein Ein-Bit-Feld veranschaulicht ist, ist die Offenbarung nicht darauf beschränkt (das heißt, das generische vektorfreundliche Anweisungsformat 700 sieht andere Größen des Datenelementbreitenfeldes 764 vor).
  • Das generische vektorfreundliche Anweisungsformat 700 umfasst die folgenden Felder, die nachstehend in der in 8A veranschaulichten Reihenfolge aufgelistet sind.
  • EVEX-Präfix (Bytes 0-3) 802 - ist für eine Vier-Byte-Form codiert.
  • Formatfeld 740 (EVEX-Byte 0, Bits [7:0]) - das erste Byte (EVEX-Byte 0) ist das Formatfeld 740 und enthält 0x62 (den eindeutigen Wert, der in einer Ausführungsform der Offenbarung zum Unterscheiden des vektorfreundlichen Anweisungsformats verwendet wird).
  • Die zweiten vier Bytes (EVEX-Bytes 1-3) umfassen eine Anzahl von Bitfeldern, die eine spezifische Fähigkeit bereitstellen.
  • REX-Feld 805 (EVEX-Byte 1, Bits [7-5]) - besteht aus einem EVEX.R-Bitfeld (EVEX-Byte 1, Bit [7] - R), EVEX.X-Bitfeld (EVEX-Byte 1, Bit [6] - X) und 757BEX-Byte 1, Bit [5] - B). Die EVEX.R-, EVEX.X- und EVEX.B-Bitfelder stellen die gleiche Funktionalität wie die entsprechenden VEX-Bitfelder bereit und sind unter Verwendung der Einerkomplementform codiert, d. h. ZMM0 ist als 1111B codiert, ZMM15 ist als 0000B codiert. Andere Felder der Anweisungen codieren die unteren drei Bits der Registerindizes so, wie auf dem Fachgebiet bekannt (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch Hinzufügen von EVEX.R, EVEX.X und EVEX.B gebildet werden können.
  • REX'-Feld 710 - dies ist der erste Teil des REX'-Feldes 710 und ist das EVEX.R'-Bitfeld (EVEX-Byte 1, Bit [4] - R'), das verwendet wird, um entweder die oberen 16 oder die unteren 16 des erweiterten 32er-Registersatzes zu codieren. In einer Ausführungsform der Offenbarung wird dieses Bit zusammen mit anderen, wie unten dargelegt, zum Unterscheiden (im allgemein bekannten 32-Bit-Modus von x86) von der BOUND-Anweisung, deren Realer-Opcode-Byte 62 ist, in einem bitinvertierten Format gespeichert, akzeptiert aber im MOD R/M-Feld (nachstehend beschrieben) den Wert von 11 im MOD-Feld nicht; alternative Ausführungsformen der Offenbarung speichern dieses und die anderen unten angegebenen Bits nicht im invertierten Format. Zum Codieren der unteren 16 Register wird ein Wert von 1 verwendet. Mit anderen Worten wird R'Rrrr durch Kombinieren von EVEX.R', EVEX.R gebildet, und das andere RRR aus anderen Feldern.
  • Opcode-Zuordnungsfeld 815 (EVEX-Byte 1, Bits [3:0] - mmmm) - sein Inhalt codiert ein implizites führendes Opcode-Byte (0F, OF 38 oder 0F 3).
  • Datenelementbreitenfeld 764 (EVEX-Byte 2, Bit [7] - W) - wird durch die Schreibweise EVEX.W dargestellt. EVEX.W wird zum Definieren der Granularität (Größe) des Datentyps verwendet (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente).
  • EVEX.vvvv 820 (EVEX-Byte 2, Bits [6:3]-vvvv)- die Funktion von EVEX.vvvv kann Folgendes umfassen: 1) EVEX.vvvv codiert den ersten Quellenregisteroperanden, der in invertierter (Einerkomplement-) Form spezifiziert und für Anweisungen mit 2 oder mehr Quellenoperanden gültig ist; 2) EVEX.vvvv codiert den Zielregisteroperanden, der in Einerkomplementform für bestimmte Vektorverschiebungen spezifiziert ist; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Demnach codiert das EVEX.vvvv-Feld 820 die 4 niederwertigen Bits des ersten Quellenregisterspezifizierers, der in invertierter (Einerkomplement-) Form gespeichert ist. In Abhängigkeit von der Anweisung kann ein zusätzliches verschiedenes EVEX-Bitfeld zum Erweitern der Spezifizierergröße auf 32er-Register verwendet werden.
  • EVEX.U 768 Klassenfeld (EVEX-Byte 2, Bit [2] - U) - Wenn EVEX.U = 0, zeigt dies Klasse A oder EVEX.U0 an; wenn EVEX.U = 1, zeigt dies Klasse B oder EVEX.U1 an.
  • Präfixcodierfeld 825 (EVEX-Byte 2, Bits [1:0] - pp) - stellt zusätzliche Bits für das Basisoperationsfeld bereit. Neben dem Bereitstellen von Unterstützung für die älteren SSE-Anweisungen im EVEX-Präfixformat hat dies außerdem den Vorteil des Kompaktierens des SIMD-Präfixes (statt ein Byte zum Ausdrücken des SIMD-Präfixes zu erfordern, benötigt das EVEX-Präfix nur 2 Bit). Um ältere SSE-Anweisungen, die ein SIMD-Präfix (66H, F2H, F3H) verwenden, sowohl im älteren Format als auch im EVEX-Präfixformat zu unterstützen, sind diese älteren SIMD-Präfixe in einer Ausführungsform in das SIMD-Präfixcodierfeld codiert; und werden zur Laufzeit in das ältere SIMD-Präfix ausgedehnt, bevor sie dem PLA des Decodierers zugeführt werden (so dass das PLA sowohl das ältere als auch das EVEX-Format dieser älteren Anweisungen ohne Modifikation ausführen kann). Obwohl neuere Anweisungen den Inhalt des EVEX-Präfixcodierfeldes direkt als eine Opcode-Erweiterung verwenden könnten, erweitern bestimmte Ausführungsformen der Einheitlichkeit halber auf ähnliche Weise, ermöglichen aber die Spezifizierung anderer Bedeutungen durch diese älteren SIMD-Präfixe. Eine alternative Ausführungsform kann das PLA neu auslegen, um die 2-Bit-SIMD-Präfixcodierungen zu unterstützen, sodass keine Erweiterung erforderlich ist.
  • Alpha-Feld 752 (EVEX-Byte 3, Bit [7] - EH; auch als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.Schreibmaskensteuerung und EVEX.N bekannt; auch als α veranschaulicht) - wie bereits erwähnt, ist dieses Feld kontextspezifisch.
  • Beta-Feld 754 (EVEX-Byte 3, Bits [6:4]-SSS, auch als EVEX.S2-0, EVEX.r2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB bekannt; auch als βββ veranschaulicht) - wie bereits erwähnt, ist dieses Feld kontextspezifisch.
  • REX'-Feld 710 - dies ist der Rest des REX'-Feldes und ist das EVEX.V'-Bitfeld (EVEX-Byte 1, Bit [3] - V'), das verwendet werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32er-Registersatzes zu codieren. Dieses Bit wird im bitinvertierter Format gespeichert. Zum Codieren der unteren 16 Register wird ein Wert von 1 verwendet. Mit anderen Worten wird V'VVVV durch Kombinieren von EVEX.V', EVEX.vvvv gebildet.
  • Schreibmaskenfeld 770 (EVEX-Byte 3, Bits [2:0] - kkk) - sein Inhalt spezifiziert den Index eines Registers in den Schreibmaskenregistern, wie bereits erwähnt. In einer Ausführungsform der Offenbarung weist der spezifische Wert EVEX.kkk = 000 ein spezielles Verhalten auf, das umfasst, dass keine Schreibmaske für die jeweilige Anweisung verwendet wird (dies kann auf eine Vielzahl von Arten und Weisen implementiert werden, welche die Verwendung einer Schreibmaske umfassen, die mit allen Einsen oder Hardware festverdrahtet ist, welche die Maskierungshardware umgeht).
  • Realer-Opcode-Feld 830 (Byte 4) - ist auch als das Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert.
  • MOD R/M-Feld 840 (Byte 5) - umfasst das MOD-Feld 842, das Reg-Feld 844 und das R/M-Feld 846. Wie bereits erwähnt, unterscheidet der Inhalt des MOD-Feldes 842 zwischen Operationen mit Speicherzugriff und ohne Speicherzugriff. Die Funktion des Reg-Feldes 844 lässt sich auf zwei Situationen zusammenfassen: Codieren entweder des Zielregisteroperanden oder eines Quellenregisteroperanden oder Behandeltwerden als eine Opcode-Erweiterung und Nichtverwendetwerden zum Codieren eines Anweisungsoperanden. Die Funktion des R/M-Feldes 846 kann Folgendes umfassen: Codieren des Anweisungsoperanden, der auf eine Speicheradresse verweist, oder Codieren entweder des Zielregisteroperanden oder eines Quellenregisteroperanden.
  • Skala, Index, Basis (SIB) Byte (Byte 6) - Wie bereits erwähnt, wird der Inhalt des Skalierfeldes 750 zur Speicheradressgenerierung verwendet. SIB.xxx 854 und SIB.bbb 856 - die Inhalte dieser Felder wurden zuvor in Bezug auf die Registerindizes Xxxx und Bbbb erwähnt.
  • Verschiebungsfeld 762A (Bytes 7-10) - wenn das MOD-Feld 842 10 enthält, sind die Bytes 7 bis 10 das Verschiebungsfeld 762A, und es funktioniert gleich wie die ältere 32-Bit-Verschiebung (disp32) und arbeitet bei Byte-Granularität.
  • Verschiebungsfaktorfeld 762B (Byte 7) - wenn das MOD-Feld 842 01 enthält, ist Byte 7 das Verschiebungsfaktorfeld 762B. Die Position dieses Feldes ist gleich wie die der 8-Bit-Verschiebung (disp8) des älteren x86-Anweisungssatzes, die bei Byte-Granularität arbeitet. Da disp8 vorzeichenerweitert ist, kann sie nur Offsets zwischen von -128 und 127 Byte adressieren; in Bezug auf 64-Byte-Cachezeilen verwendet disp8 8 Bit, die auf nur vier wirklich brauchbare Werte -128, -64, 0 und 64 gesetzt werden können; da oft ein größerer Bereich benötigt wird, wird disp32 verwendet; disp32 erfordert jedoch 4 Byte. Im Gegensatz zu disp8 und disp32 ist das Verschiebungsfaktorfeld 762B eine Neuinterpretation von disp8; bei Verwenden des Verschiebungsfaktorfeldes 762B wird die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfeldes multipliziert mit der Größe des Speicheroperandenzugriffs (N) bestimmt. Dieser Typ von Verschiebung wird als disp8*N bezeichnet. Dies reduziert die mittlere Anweisungslänge (ein einziges Byte wird zur Verschiebung verwendet, aber mit einem wesentlichen größeren Bereich). Solch eine komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung ein Vielfaches der Granularität des Speicherzugriffs ist, so dass die redundanten niederwertigen Bits des Adressoffsets nicht codiert zu werden brauchen. Mit anderen Worten ersetzt das Verschiebungsfaktorfeld 762B die 8-Bit-Verschiebung des älteren x86-Anweisungssatzes. Demnach wird das Verschiebungsfaktorfeld 762B gleich codiert wie eine 8-Bit-Verschiebung des älteren x86-Anweisungssatzes (daher keine Änderungen der ModRM/SIB-Codierungsregeln) mit der einzigen Ausnahme, dass disp8 zu disp8*N überladen wird. Mit anderen Worten gibt es keine Änderungen an den Codierungsregeln oder Codierungslängen, außer bei der Interpretation des Verschiebungswerts durch Hardware (welche die Verschiebung um die Größe des Speicheroperanden skalieren muss, um einen byteweisen Adressoffset zu erhalten). Unmittelbares Feld 772 - funktioniert so, wie bereits erwähnt.
  • Vollständiges Opcode-Feld
  • 8B ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 800 veranschaulicht, welche das vollständige Opcode-Feld 774 gemäß einer Ausführungsform der Offenbarung bilden. Konkret umfasst das vollständige Opcode-Feld 774 das Formatfeld 740, das Basisoperationsfeld 742 und das Feld Datenelementbreite (W) 764. Das Basisoperationsfeld 742 umfasst das Präfixcodierfeld 825, das Opcode-Zuordnungsfeld 815 und das Realer-Opcode-Feld 830.
  • Registerindexfeld
  • 8C ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 800 veranschaulicht, welche das Registerindexfeld 744 gemäß einer Ausführungsform der Offenbarung bilden. Konkret umfasst das Registerindexfeld 744 das REX-Feld 805, das REX'-Feld 810, das MODR/M.reg-Feld 844, das MODR/M.r/m-Feld 846, das VVVV-Feld 820, xxx-Feld 854 und das bbb-Feld 856.
  • Erweiterungsoperationsfeld
  • 8D ist ein Blockdiagramm, das die Felder des spezifischen vektorfreundlichen Anweisungsformats 800 veranschaulicht, welche das Erweiterungsoperationsfeld 750 gemäß einer Ausführungsform der Offenbarung bilden. Wenn das Feld Klasse (U) 768 0 enthält, bedeutet dies EVEX.U0 (Klasse A 768A); wenn es 1 enthält, bedeutet dies EVEX.U1 (Klasse B 768B). Wenn U = 0 und das MOD-Feld 842 11 enthält (was eine Operation ohne Speicherzugriff bedeutet), wird das Alpha-Feld 752 (EVEX-Byte 3, Bit [7] - EH) als das rs-Feld 752A interpretiert. Wenn das rs-Feld 752A eine 1 enthält (Rundung 752A. 1), wird das Beta-Feld 754 (EVEX-Byte 3, Bits [6:4]- SSS) als das Rundungssteuerungsfeld 754A interpretiert. Das Rundungssteuerungsfeld 754A umfasst ein Ein-Bit-SAE-Feld 756 und ein Zwei-Bit-Rundungsoperationsfeld 758. Wenn das rs-Feld 752A eine 0 enthält (Datenumwandlung 752A.2), wird das Beta-Feld 754 (EVEX-Byte 3, Bits [6:4]- SSS) als ein Drei-Bit-Datenumwandlungsfeld 754B interpretiert. Wenn U = 0 und das MOD-Feld 842 00, 01 oder 10 enthält (was eine Operation mit Speicherzugriff bedeutet), wird das Alpha-Feld 752 (EVEX-Byte 3, Bit [7] - EH) als das Entfernungshinweis (EH)-Feld 752B interpretiert, und das Beta-Feld 754 (EVEX-Byte 3, Bits [6:4] - SSS) wird als ein Drei-Bit-Datenbearbeitungsfeld 754C interpretiert.
  • Wenn U = 1, wird das Alpha-Feld 752 (EVEX-Byte 3, Bit [7] - EH) als das Schreibmaskensteuerungs (Z)-Feld z52C interpretiert. Wenn U = 1 und das MOD-Feld 842 11 enthält (was eine Operation ohne Speicherzugriff bedeutet), wird ein Teil des Beta-Feldes 754 (EVEX-Byte 3, Bit [4]- So) als das RL-Feld 757A interpretiert; wenn es eine 1 enthält (Rundung 757A.1), wird der Rest des Beta-Feldes 754 (EVEX-Byte 3, Bit [6-5]- S2-1) als das Rundungsoperationsfeld 759A interpretiert, während, wenn das RL-Feld 757A eine 0 enthält (VSIZE 757.A2), der Rest des Beta-Feldes 754 (EVEX-Byte 3, Bit [6-5]- S2-1) als das Vektorlängenfeld 759B (EVEX-Byte 3, Bit [6-5]- L1-0) interpretiert wird. Wenn U = 1 und das MOD-Feld 842 00, 01 oder 10 enthält (was eine Operation mit Speicherzugriff bedeutet), wird das Beta-Feld 754 (EVEX-Byte 3, Bits [6:4]- SSS) als das Vektorlängenfeld 759B (EVEX-Byte 3, Bit [6-5]- L1-0) und das Broadcast-Feld 757B (EVEX-Byte 3, Bit [4]- B) interpretiert.
  • Beispielhafte Registerarchitektur
  • 9 ist ein Blockdiagramm einer Registerarchitektur 900 gemäß einer Ausführungsform der vorliegenden Offenbarung. In der veranschaulichten Ausführungsform gibt es 32 Vektorregister 910 mit einer Breite von 512 Bit; diese Register werden zmm0 bis zmm031 bezeichnet. Die niedrigerwertigen 256 Bits der unteren 16 zmm-Register überlagern Registern ymm0 bis ymm16. Die niedrigerwertigen Bits der unteren 16 zmm-Register (die niedrigerwertigen 128 Bits der ymm-Register) überlagern Register xmm0 bis xmm15. Das spezifische vektorfreundliche Anweisungsformat 800 wirkt auf diese übereinander liegenden Registerdateien, wie in den nachstehenden Tabellen veranschaulicht.
    Anpassbare Vektorlänge Klasse Operationen Register
    Anweisungsvorlagen, die das Vektorlängenfeld 759B nicht umfassen. A (7A; U = 0) 710, 715, 725, 730 zmm-Register (die Vektorlänge beträgt 64 Byte)
    B ( 7B; U = 1) 712 zmm-Register (die Vektorlänge beträgt 64 Byte)
    Anweisungsvorlagen, die das Vektorlängenfeld 759B umfassen. B ( 7B; U = 1) 717, 727 zmm-, ymm- oder xmm-Register (die Vektorlänge beträgt 64 Byte, 32 Byte oder 16 Byte) abhängig vom Vektorlängenfeld 759B
  • Mit anderen Worten wählt das Vektorlängenfeld 759B zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen aus, wobei jede solche kürzere Länge die Hälfte der Länge der vorhergehenden Länge ist; und Anweisungsvorlagen ohne das Vektorlängenfeld 759B wirken auf die maximale Vektorlänge. Ferner wirken die Anweisungsvorlagen des spezifischen vektorfreundlichen Anweisungsformats 800 in einer Ausführungsform auf gepackte oder Gleitkomma-Daten mit einfacher/doppelter Genauigkeit und gepackte oder skalare Ganzzahl-Daten. Skalar-Operationen sind Operationen, die an den niedrigstwertigen Datenelementposition in einem zmm-/ymm-/xmm-Register ausgeführt werden; die höherwertigen Datenelementpositionen werden in Abhängigkeit von der Ausführungsform entweder gleich gelassen, wie sie vor der Anweisung waren, oder auf null gesetzt.
  • Schreibmaskenregister 915 - in der veranschaulichten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), jeweils mit einer Größe von 64 Bit. In einer alternativen Ausführungsform weisen die Schreibmaskenregister 915 eine Größe von 16 Bit auf. Wie bereits erwähnt, kann das Vektormaskenregister k0 in einer Ausführungsform der Offenbarung nicht als Schreibmaske verwendet werden; bei der Codierung, die normalerweise anzeigen würde, dass k0 für eine Schreibmaske verwendet wird, wählt es eine festverdrahtete Schreibmaske von OxFFFF aus, wodurch Schreibmaskierung für die Anweisung effektiv deaktiviert wird.
  • Universalregister 925 - in der veranschaulichten Ausführungsform gibt es sechzehn 64-Bit-Universalregister, die zusammen mit den bestehenden x86-Adressiermodi zum Adressieren von Speicheroperanden verwendet werden. Diese Register sind mit den Benennungen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 gekennzeichnet.
  • Skalare Gleitkomma-Stapelregisterdatei (x87-Stapel) 945, in welcher die gepackte ganzzahlige flache MMX-Registerdatei 950 aliasiert ist - in der veranschaulichten Ausführungsform ist der x87-Stapel ein Stapel von acht Elementen, der zum Durchführen von skalaren Gleitkommaoperationen an 32-/64-/80-Bit-Gleitkommadaten unter Verwendung der x87-Anweisungssatzerweiterung verwendet wird; während die MMX-Register zum Ausführen von Operationen an gepackten ganzzahligen 64-Bit-Daten sowie zum Speichern von Operanden für einige Operationen verwendet werden, die zwischen den MMX- und XMM-Registern ausgeführt werden.
  • Alternative Ausführungen der Offenbarung können breitere oder schmalere Register verwenden. Außerdem können alternative Ausführungsformen der Offenbarung mehr, weniger oder andere Registerdateien und Register verwenden.
  • Beispielhafte Kernarchitekturen, Prozessoren und Computerarchitekturen
  • Prozessorkerne können auf verschiedene Arten und Weisen, für verschiedene Zwecke und in verschiedenen Prozessoren implementiert werden. Zum Beispiel können Implementierungen solcher Kerne umfassen: 1) einen In-Order-Universalkern, der für Allzweckberechnung bestimmt ist; 2) einen Out-of-Order-Hochleistungs-Universalkern, der für Allzweckberechnung bestimmt ist; 3) einen Spezialkern, der in erster Linie für Grafik- und/oder wissenschaftliche (Durchsatz-) Berechnung bestimmt ist. Implementierungen von verschiedenen Prozessoren können umfassen: 1) eine CPU, die einen oder mehrere In-Order-Universalkerne, die für Allzweckberechnung bestimmt sind, und/oder einen oder mehrere Out-of-Order-Universalkerne umfasst, die für Allzweckberechnung bestimmt sind; und 2) einen Coprozessor, der einen oder mehrere Spezialkerne umfasst, die in erster Linie für Grafik- und/oder wissenschaftliche (Durchsatz-) Berechnung bestimmt sind. Solche verschiedene Prozessoren führen zu verschiedenen Computersystemarchitekturen, welche umfassen können: 1) den Coprozessor auf einem von der CPU separaten Chip; 2) den Coprozessor auf einem separaten Chip im gleichen Gehäuse wie eine CPU; 3) den Coprozessor auf dem gleichen Chip wie eine CPU (in welchem Fall solch ein Coprozessor manchmal als Speziallogik, wie beispielsweise integrierte Grafik- und/oder wissenschaftliche (Durchsatz-) Logik, oder als Universalkerne bezeichnet wird); und 4) System auf einem Chip, das auf dem gleichen Chip die beschriebene CPU (manchmal als Anwendungskern(e) oder Anwendungsprozessor(en) bezeichnet), den zuvor beschriebenen Coprozessor und zusätzliche Funktionalität umfassen kann. Als Nächstes werden beispielhafte Kernarchitekturen beschrieben, worauf Beschreibungen von beispielhaften Prozessoren und Computerarchitekturen folgen.
  • Beispielhafte Kernarchitekturen
  • In-Order- und Out-of-Order-Kernblockdiagramm
  • 10A ist ein Blockdiagramm, das sowohl eine beispielhafte In-Order-Pipeline als auch eine beispielhafte Registerumbenennungs- und Out-of-Order-Ausgabe-/Ausführungs-Pipeline gemäß Ausführungsformen der Offenbarung veranschaulicht. 10B ist ein Blockdiagramm, das sowohl eine beispielhafte Ausführungsform eines Kerns mit In-Order-Architektur als auch eines beispielhaften Kerns mit Registerumbenennungs- und Out-of-Order-Ausgabe-/Ausführungsarchitektur veranschaulicht, die in einen Prozessor gemäß Ausführungsformen der Offenbarung integriert werden sollen. Die Kästchen mit durchgehenden Linien in 10A und 10B veranschaulichen die In-Order-Pipeline und den In-Order-Kern, während die optionale Hinzufügung der Kästchen mit gestrichelten Linien die Pipeline und den Kern für Registerumbenennung und Out-of-Order-Ausgabe/Ausführung veranschaulicht. Da der In-Order-Aspekt ein Teilsatz des Out-of-Order-Aspekts ist, wird der Out-of-Order-Aspekt beschrieben.
  • In 10A umfasst eine Prozessor-Pipeline 1000 eine Abrufstufe 1002, eine Längendecodierstufe 1004, eine Decodierstufe 1006, eine Zuordnungsstufe 1008, eine Umbenennungsstufe 1010, eine Ablaufsteuerungs (auch bekannt als Abfertigungs- oder Ausgabe)-Stufe 1012, eine Registerlese-/Speicherlesestufe 1014, eine Ausführungsstufe 1016, eine Zurückschreib-/Speicherschreibstufe 1018, eine Ausnahmebehandlungsstufe 1022 und eine Commit-Stufe 1024.
  • 10B stellt einen Prozessorkern 1090 dar, der eine Eingangseinheit 1030 umfasst, die mit einer Ausführungsmaschineneinheit 1050 gekoppelt ist, wobei beide mit einer Speichereinheit 1070 gekoppelt sind. Der Kern 1090 kann ein Kern zum Rechnen mit reduziertem Anweisungssatz (RISC - Reduced Instruction Set Computing), ein Kern zum Rechnen mit komplexem Anweisungssatz (CISC - Complex Instruction Set Computing), ein Kern für sehr lange Anweisungswörter (VLIW - Very Long Instruction Word) oder ein Hybrid- oder alternativer Kerntyp sein. Als noch eine andere Option kann der Kern 1090 ein Spezialkern, wie beispielsweise ein Netzwerk- oder Kommunikationskern, eine Kompressionsmaschine, ein Coprozessorkern, ein Kern für Allzweckberechnung auf Grafikverarbeitungseinheiten (GPGPU - General Purpose Computing Graphics Processing Unit), ein Grafikkern oder dergleichen sein.
  • Die Eingangseinheit 1030 umfasst eine Zweigprädiktionseinheit 1032, die mit einer Anweisungs-Cache-Einheit 1034 gekoppelt ist, die mit einem Anweisungsübersetzungs-Vorgriffspuffer (TLB) 1036 gekoppelt ist, der mit einer Anweisungsabrufeinheit 1038 gekoppelt ist, die mit einer Decodiereinheit 1040 gekoppelt ist. Die Decodiereinheit 1040 (oder der Decoder oder die Decoder-Einheit) kann Anweisungen (z. B. Makroanweisungen) decodieren und als eine Ausgabe eine oder mehrere Mikrooperationen, Mikrocode-Eintrittsstellen, Mikroanweisungen, andere Anweisungen oder andere Steuersignale erzeugen, die aus den Originalanweisungen decodiert oder von diesen abgeleitet werden oder diese anderweitig widerspiegeln. Die Decodiereinheit 1040 kann unter Verwendung von mehreren verschiedenen Mechanismen implementiert sein. Beispiele von geeigneten Mechanismen umfassen, ohne darauf beschränkt zu sein, Nachschlagetabellen, Hardwareimplementierungen, programmierbare Logikfelder (PLAs), Mikrocode-Festwertspeicher (ROM - Read Only Memory) usw. In einer Ausführungsform umfasst der Kern 1090 einen Mikrocode-ROM oder ein anderes Medium, das Mikrocode für bestimmte Makroanweisungen speichert (z. B. in der Decodiereinheit 1040 oder andernfalls in der Eingangseinheit 1030). Die Decodiereinheit 1040 ist mit einer Umbenennungs-/Zuordnungseinheit 1052 in der Ausführungsmaschineneinheit 1050 gekoppelt.
  • Die Ausführungsmaschineneinheit 1050 umfasst die Umbenennungs-/Zuordnungseinheit 1052, die mit einer Ausmusterungseinheit 1054 und einem Satz von einer oder mehreren Scheduler-Einheit(en) 1056 gekoppelt ist. Die Scheduler-Einheit(en) 1056 stellt/stellen eine beliebige Anzahl von verschiedenen Schedulern dar, die Reservierungsstationen, ein zentrales Anweisungsfenster usw. umfassen. Die Scheduler-Einheit(en) 1056 ist/sind mit der/den Einheit(en) physikalischer Registerdatei(en) 1058 gekoppelt. Jede der Einheiten physikalischer Registerdatei(en) 1058 stellt eine oder mehrere physikalische Registerdateien dar, von welchen verschiedene einen oder mehrere Datentypen speichern, wie beispielsweise skalare Ganzzahl, skalares Gleitkomma, gepackte Ganzzahl, gepacktes Gleitkomma, vektorielle Ganzzahl, vektorielles Gleitkomma, Status (z. B. einen Anweisungszeiger, der die Adresse der nächsten Anweisung ist, die ausgeführt werden soll) usw. In einer Ausführungsform umfasst die Einheit physikalischer Registerdatei(en) 1058 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine Skalarregistereinheit. Diese Registereinheiten können architektonische Vektorregister, Vektormaskenregister und Universalregister bereitstellen. Die Einheit(en) physikalischer Registerdatei(en) 1058 sind von der Ausmusterungseinheit 1054 überlappt, um verschiedene Möglichkeiten zu veranschaulichen, in welchen Registerumbenennung und Out-of-Order-Ausführung (z. B. unter Verwendung von Neuordnungspuffer(n) und Ausmusterungsregisterdatei(en); unter Verwendung von Zukunftsdatei(en), Verlaufspuffer(n) und Ausmusterungsregisterdatei(en); unter Verwendung von Registerverzeichnissen und eines Registerpools usw.) implementiert sein können. Die Ausmusterungseinheit 1054 und die Einheit(en) physikalischer Registerdatei(en) 1058 sind mit Ausführungscluster(n) 1060 gekoppelt. Der/die Ausführungscluster 1060 umfasst/umfassen einen Satz von einer oder mehreren Ausführungseinheiten 1062 und einen Satz von einer oder mehreren Speicherzugriffseinheiten 1064. Die Ausführungseinheiten 1062 können verschiedene Operationen (z. B. Verschiebungen, Addition, Subtraktion, Multiplikation) und an verschiedenen Datentypen (z. B. skalarem Gleitkomma, gepackter Ganzzahl, gepacktem Gleitkomma, vektorieller Ganzzahl, vektoriellem Gleitkomma) ausführen. Obwohl einige Ausführungsformen eine Anzahl von Ausführungseinheiten umfassen können, die spezifischen Funktionen oder Sätzen von Funktionen gewidmet sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten umfassen, die allesamt alle Funktionen ausführen. Die Scheduler-Einheit(en) 1056, die Einheit(en) physikalischer Registerdatei(en) 1058 und der/die Ausführungscluster 1060 sind so dargestellt, dass sie möglicherweise mehrere sind, da bestimmte Ausführungsformen separate Pipelines für bestimmte Typen von Daten/Operationen erstellen (z. B. eine skalare Ganzzahl-Pipeline, eine skalare Gleitkomma-/gepackte Ganzzahl-/gepackte Gleitkomma-/vektorielle Ganzzahl-/vektorielle Gleitkomma-Pipeline und/oder eine Speicherzugriffs-Pipeline, die jeweils ihre eigene Scheduler-Einheit, ihre eigene Einheit physikalischer Registerdatei(en) und/oder ihren eigenen Ausführungscluster aufweisen - und im Falle einer separaten Speicherzugriffs-Pipeline sind bestimmte Ausführungsformen implementiert, in welche nur der Ausführungscluster dieser Pipeline die Speicherzugriffseinheit(en) 1064 aufweist). Es versteht sich außerdem, dass bei Verwenden separater Pipelines eine oder mehrere dieser Pipelines mit Out-of-Order- und die restlichen mit In-Order-Ausführung sein können.
  • Der Satz von Speicherzugriffseinheiten 1064 ist mit der Speichereinheit 1070 gekoppelt, welche eine Daten-TLB-Einheit 1072 umfasst, die mit einer Daten-Cache-Einheit 1074 gekoppelt ist, die mit einer Cache-Einheit 1076 der Ebene 2 (L2) gekoppelt ist. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 1064 eine Lasteinheit, eine Speicheradresseinheit und eine Speicherdateneinheit umfassen, die jeweils mit der Daten-TLB-Einheit 1072 in der Speichereinheit 1070 gekoppelt sind. Die Anweisungs-Cache-Einheit 1034 ist ferner mit der Cache-Einheit 1076 der Ebene 2 (L2) in der Speichereinheit 1070 gekoppelt. Die L2-Cache-Einheit 1076 ist mit einer oder mehreren anderen Cache-Ebenen und schließlich mit einem Hauptspeicher gekoppelt.
  • In bestimmten Ausführungsformen ist eine Vorabrufschaltung 1078 zum Vorabrufen von Daten enthalten, um zum Beispiel Zugriffsadressen vorherzusagen und die Daten für diese Adressen in einen oder mehrere Caches zu bringen (z. B. aus dem Speicher 1080). In einer Ausführungsform ist die Vorabrufschaltung 1078 eine Instanz der Vorabrufschaltung in 3B.
  • Als Beispiel kann die beispielhafte Registerumbenennungs- und Out-of-Order-Ausgabe-/Ausführungs-Kernarchitektur die Pipeline 1000 folgendermaßen implementieren: 1) die Anweisungsabrufeinheit 1038 führt die Abruf- und Längendecodierstufen 1002 und 1004 aus; 2) die Decodiereinheit 1040 führt die Decodierstufe 1006 aus; 3) die Umbenennungs-/Zuordnungseinheit 1052 führt die Zuordnungsstufe 1008 und die Umbenennungsstufe 1010 aus; 4) die Scheduler-Einheit(en) 1056 führt/führen die Ablaufsteuerungsstufe 1012 aus; 5) die Einheit(en) physikalischer Registerdatei(en) 1058 und die Speichereinheit 1070 führen die Registerlese-/Speicherlesestufe 1014 aus; der Ausführungscluster 1060 führt die Ausführungsstufe 1016 aus; 6) die Speichereinheit 1070 und die Einheit(en) physikalischer Registerdatei(en) 1058 führen die Zurückschreib-/Speicherschreibstufe 1018 aus; 7) verschiedene Einheiten können an der Ausnahmebehandlungsstufe 1022 beteiligt sein; und 8) die Ausmusterungseinheit 1054 und die Einheit(en) physikalischer Registerdatei(en) 1058 führen die Commit-Stufe 1024 aus.
  • Der Kern 1090 kann einen oder mehrere Anweisungssätze (z. B. den x86-Anweisungssatz (mit einigen Erweiterungen, welche bei neueren Version hinzugefügt wurden); den MIPS-Anweisungssatz von MIPS Technologies, Sunnyvale, Kalifornien; den ARM-Anweisungssatz (mit optionalen zusätzlichen Erweiterungen, wie beispielsweise NEON) von der ARM Holdings, Sunnyvale, Kalifornien), einschließlich der hierin beschriebenen Anweisung(en), unterstützen. In einer Ausführungsform umfasst der Kern 1090 Logik zum Unterstützen einer Anweisungssatzerweiterung für gepackte Daten (z. B. AVX1, AVX2), um dadurch zu ermöglichen, dass die durch viele Multimedia-Anwendungen verwendeten Operationen unter Verwendung von gepackten Daten ausgeführt werden.
  • Es versteht sich, dass der Kern Multithreading (Ausführen von zwei oder mehr parallelen Sätzen von Operationen oder Threads) unterstützten kann und dies auf verschiedene Arten und Weisen tun kann, welche Zeitscheiben-Multithreading, simultanes Multithreading (wobei ein einziger physikalischer Kern einen logischen Kern für jeden der Threads bereitstellt, für die der physikalische Kern simultanes Multithreading ausführt) oder eine Kombination davon (z. B. Zeitscheiben-Abruf und -Decodierung und anschließendes simultanes Multithreading, wie beispielsweise in der Intel® Hyper-Threading-Technologie) umfassen.
  • Es versteht sich, dass, obwohl Registerumbenennung im Kontext von Out-of-Order-Ausführung beschrieben wird, Registerumbenennung auch in einer In-order-Architektur verwendet werden kann. Obwohl die veranschaulichte Ausführungsform des Prozessors getrennte Anweisungs- und Daten-Cache-Einheiten 1034/1074 und eine gemeinsam benutzte L2-Cache-Einheit 1076 umfasst, können alternative Ausführungsformen einen einzigen internen Cache sowohl für Anweisungen als auch Daten aufweisen, wie beispielsweise einen internen Cache der Ebene 1 (L1) oder einen internen Cache mehrerer Ebenen. In einigen Ausführungsformen kann das System eine Kombination eines internen Caches und eines externen Caches aufweisen, der außerhalb des Kerns und/oder des Prozessors ist. Alternativ können alle der Caches außerhalb des Kerns und/oder des Prozessors sein.
  • Spezifische beispielhafte In-Order-Kernarchitektur
  • 11A und 11B veranschaulichen ein Blockdiagramm einer spezifischeren beispielhaften In-Order-Kernarchitektur, wobei der Kern einer von mehreren Logikblöcken (welche andere Kerne des gleichen Typs und/oder verschiedener Typen umfassen) in einem Chip wäre. Die Logikblöcke kommunizieren durch ein Zwischenverbindungsnetzwerk mit hoher Bandbreite (z. B. ein Ringnetzwerk) mit Logik mit irgendeiner bestimmten Funktion, Speicher-I/O-Schnittstellen und anderer erforderlichen I/O-Logik je nach der Anwendung.
  • 11A ist ein Blockdiagramm eines einzigen Prozessorkerns zusammen mit seiner Verbindung zum chipinternen Zwischenverbindungsnetzwerk 1102 und mit seinem lokalen Teilsatz des Caches 1104 der Ebene 2 (L2) gemäß Ausführungsformen der Offenbarung. In einer Ausführungsform unterstützt eine Anweisungsdecodiereinheit 1100 den x86-Befehlssatz mit einer Befehlssatzerweiterung für gepackte Daten. Ein L1-Cache 1106 ermöglicht Zugriffe mit kurzen Latenzzeiten auf Cache-Speicher in die Skalar- und Vektoreinheiten. Obwohl in einer Ausführungsform (zur Vereinfachung des Aufbaus) eine Skalareinheit 1108 und eine Vektoreinheit 1110 getrennte Registersätze (Skalarregister 1112 bzw. Vektorregister 1114) verwenden, und zwischen ihnen übertragene Daten in den Speicher geschrieben und dann aus einem Cache 1106 auf Ebene 1 (L1) zurückeingelesen werden, können alternative Ausführungsformen der Offenbarung einen anderen Ansatz verwenden (z. B. einen einzigen Registersatz verwenden oder einen Kommunikationspfad einbeziehen, der es ermöglicht, einen einzigen Registersatz verwenden oder einen Kommunikationspfad einbeziehen, der es ermöglicht, dass Daten zwischen den beiden Registerdateien übertragen werden, ohne geschrieben und zurückgelesen zu werden).
  • Der lokale Teilsatz des L2-Caches 1104 ist Teil eines globalen L2-Caches, der in separate lokale Teilsätze, einen pro Prozessorkern, geteilt ist. Jeder Prozessorkern weist einen Direktzugriffspfad zu seinem eigenen lokalen Teilsatz des L2-Caches 1104 auf. Daten, die durch einen Prozessorkern ausgelesen werden, werden in seinem L2-Cache-Teilsatz 1104 gespeichert, und parallel zu anderen Prozessoren, die auf ihre eigenen lokalen L2-Cache-Teilsätze zugreifen, kann schnell darauf zugegriffen werden. Daten, die durch einen Prozessorkern geschrieben werden, werden in seinem eigenen L2-Cache-Teilsatz 1104 gespeichert und nötigenfalls aus anderen Teilsätzen entleert. Das Ringnetzwerk gewähreistet Kohärenz für gemeinsam benutzte Daten. Das Ringnetzwerk ist bidirektional, um Agenten, wie beispielsweise Prozessorkernen, L2-Caches und anderen Logikblöcken, zu ermöglichen, innerhalb des Chips miteinander zu kommunizieren. Jeder Ring-Datenpfad ist pro Richtung 1012 Bits breit.
  • 11B ist eine erweiterte Ansicht eines Teils des Prozessorkerns in 11A gemäß Ausführungsformen der Offenbarung. 11B umfasst einen L1-Daten-Cache 1106A, der ein Teil des L 1-Caches 1104 ist, sowie genauere Einzelheiten bezüglich der Vektoreinheit 1110 und der Vektorregister 1114. Konkret ist die Vektoreinheit 1110 eine 16 Bit breite Vektorverarbeitungseinheit (VPU - Vector Processing Unit) (siehe 16 Bit breite ALU 1128), welche einen oder mehrere von Ganzzahl-Anweisungen, Gleitkomma-Anweisungen mit einfacher Genauigkeit und Gleitkomma-Anweisungen mit doppelter Genauigkeit ausführt. Die VPU unterstützt Umordnen der Registereingänge mit einer Umordnungseinheit 1120, numerische Umsetzung mit Einheiten für numerische Umsetzung 1122A-B und Duplizierung mit einer Dupliziereinheit 1124 am Speichereingang. Schreibmaskenregister 1126 ermöglichen ein Vorhersagen resultierender Vektorschreiboperationen.
  • 12 ist ein Blockdiagramm eines Prozessors 1200, der mehr als einen Kern aufweisen kann, eine integrierte Speichersteuerung aufweisen kann, und integrierte Grafik gemäß Ausführungsformen der Offenbarung aufweisen kann. Die Kästchen mit durchgehenden Linien in 12 veranschaulichen einen Prozessor 1200 mit einem einzigen Kern 1202A, einer Systemagenteneinheit 1210, einem Satz von einer oder mehreren Bussteuereinheiten 1216, während die optionale Hinzufügung der Kästchen mit gestrichelten Linien einen alternativen Prozessor 1200 mit mehreren Kernen 1202A-N, einen Satz von einer oder mehreren integrierten Speichersteuereinheit(en) 1214 in der Systemagenteneinheit 1210 und Speziallogik 1208 umfasst.
  • Demnach können verschiedene Implementierungen des Prozessor 1200 Folgendes umfassen: 1) eine CPU mit der Speziallogik 1208, wobei es sich um integrierte Grafik- und/oder wissenschaftliche (Durchsatz-) Logik handelt (welche einen oder mehrere Kerne umfassen kann), und die Kerne 1202A-N, wobei es sich um einen oder mehrere Universalkerne handelt (z. B. In-Order-Universalkerne, Out-of-Order-Universalkerne, eine Kombination der beiden); 2) einen Coprozessor mit den Kernen 1202A-N, wobei es sich um eine große Anzahl von Spezialkernen handelt, die in erster Linie für Grafik und/oder Wissenschaft (Durchsatz) bestimmt sind; und 3) einen Coprozessor mit den Kernen 1202A-N, wobei es sich um eine große Anzahl von In-Order-Universalkernen handelt. Demnach kann der Prozessor 1200 ein Universalprozessor, ein Coprozessor oder Spezialprozessor, wie beispielsweise ein Netzwerk- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU (Universal-Grafikverarbeitungseinheit), ein Coprozessor mit hohem Durchsatz und vielen integrierten Kernen (MIC - Many Integrated Core) (der 30 oder mehr Kerne umfasst), ein eingebetteter Prozessor oder dergleichen sein. Der Prozessor kann auf einem oder mehreren Chips implementiert sein. Der Prozessor 1200 kann Teil eines oder mehrerer Substrate sein und/oder er kann auf einem oder mehreren Substraten unter Verwendung einer beliebigen von einer Anzahl von Prozesstechnologien, wie beispielsweise BiCMOS, CMOS oder NMOS, implementiert sein.
  • Die Speicherhierarchie umfasst eine oder mehrere Cache-Ebenen innerhalb der Kerne, einen Satz von oder eine oder mehrere(n) gemeinsam benutzte(n) Cache-Einheiten 1206 und einen externen Speicher (nicht dargestellt), der mit dem Satz von integrierten Speichercontrollereinheiten 1214 gekoppelt ist. Der Satz der gemeinsam benutzten Cache-Einheiten 1206 kann einen oder mehrere Caches mittlerer Ebene, wie beispielsweise Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder anderer Cache-Ebenen, einen Cache der letzten Ebene (LLC - Last Level Cache) und/oder Kombinationen davon umfassen. Obwohl in einer Ausführungsform eine ringbasierte Zwischenverbindungseinheit 1212 die integrierte Grafiklogik 1208, den Satz von gemeinsam benutzten Cache-Einheiten 1206 und die Systemagenteneinheit 1210 bzw. die integrierten Speichersteuereinheit(en) 1214 miteinander verbindet, können alternative Ausführungsformen eine beliebige Anzahl von allgemein bekannten Techniken für die Verbindung solcher Einheiten miteinander verwenden. In einer Ausführungsform wird Kohärenz zwischen einer oder mehreren Cache-Einheiten 1206 und den Kernen 1202A-N aufrechterhalten.
  • In einigen Ausführungsformen sind ein oder mehrere der Kerne 1202A-N zu Multithreading imstande. Der Systemagent 1210 umfasst jene Komponenten, welche die Kerne 1202A-N koordinieren und steuern. Die Systemagenteneinheit 1210 kann zum Beispiel eines Leistungssteuerungseinheit (PCU - Power Control Unit) und eine Anzeigeeinheit umfassen. Die PCU kann Logik sein oder Logik und Komponenten umfassen, die zum Regeln des Leistungszustands der Kerne 1202A-N und der integrierten Grafiklogik 1208 benötigt werden. Die Anzeigeeinheit ist zum Ansteuern einer oder mehrerer extern angeschlossener Anzeigen.
  • Die Kerne 1202A-N können homogen oder heterogen in Bezug auf den Architekturanweisungssatz sein; das heißt, zwei oder mehr der Kerne 1202A-N können zur Ausführung des gleichen Anweisungssatzes imstande sein, während andere nur zur Ausführung eines Teilsatzes dieses Anweisungssatzes oder eines anderen Anweisungssatzes imstande sein können.
  • Beispielhafte Computerarchitekturen
  • 13 bis 16 sind Blockdiagramme von beispielhaften Computerarchitekturen. Andere auf dem Fachgebiet bekannte Systemkonstruktionen und -konfigurationen für Laptops, Tischcomputer, Hand-PCs, persönliche digitale Assistenten, Engineering-Workstations, Server, Netzwerkgeräte, Netzkontrollstationen, Switches, eingebettete Prozessoren, Digitalsignalprozessoren (DSPs), Grafikgeräte, Videospielgeräte, Set-Top-Boxen, MikroController, Zellulartelefone, tragbare Media Player, Hand-Geräte und verschiedene andere elektronische Einrichtungen sind ebenfalls geeignet. Im Allgemeinen eignet sich grundsätzlich eine große Vielzahl von Systemen oder elektronischen Einrichtungen, die zum Integrieren eines Prozessors und/oder anderer Ausführungslogik, wie hierin offenbart, imstande sind.
  • Nunmehr unter Bezugnahme auf 13 ist ein Blockdiagramm eines Systems 1300 gemäß einer Ausführungsform der vorliegenden Offenbarung dargestellt. Das System 1300 kann einen oder mehrere Prozessoren 1310, 1315 umfassen, welche mit einem Controllerhub 1320 gekoppelt sind. In einer Ausführungsform umfasst der Steuerhub 1320 einen Grafikspeicher-Steuerhub (GMCH - Graphics Memory Controller Hub) 1390 und einen Eingangs-/AusgangsHub (EAH) 1350 (die auf separaten Chips sein können); der GMCH 1390 umfasst Speicher- und Grafiksteuerungen, mit welchen ein Speicher 1340 und ein Coprozessor 1345 gekoppelt sind; der EAH 1350 koppelt Eingabe-/Ausgabe (E-/A)-Einrichtungen 1360 mit dem GMCH 1390. Alternativ sind eine oder beide der Speicher- und Grafiksteuerungen in den Prozessor integriert (wie hierin beschrieben), der Speicher 1340 und der Coprozessor 1345 sind direkt mit dem Prozessor 1310 gekoppelt, und der Steuerhub 1320 in einem einzigen Chip mit dem EAH 1350. Der Speicher 1340 kann Verschlüsselungs-/Entschlüsselungscode 1340A umfassen, um zum Beispiel Code zu speichern, der bei Ausführung einen Prozessor zum Durchführen eines der Verfahren dieser Offenbarung veranlasst.
  • Die optionale Beschaffenheit von zusätzlichen Prozessoren 1315 ist in 13 durch gestrichelte Linien dargestellt. Jeder Prozessor 1310, 1315 kann einen oder mehrere der hierin beschriebenen Prozessorkerne umfassen und kann eine Version des Prozessors 1200 sein.
  • Der Speicher 1340 kann zum Beispiel ein dynamischer Direktzugriffsspeicher (DRAM - Dynamic Random Access Memory), ein Phasenwechselspeicher (PCM - Phase Change Memory) oder eine Kombination der beiden sein. Für mindestens eine Ausführungsform kommuniziert der Controllerhub 1320 mit dem/den Prozessor(en) 1310, 1315 über einen Mehrpunktverbindungsbus, wie beispielsweise einem Frontside-Bus (FSB), eine Punkt-zu-Punkt-Schnittstelle, wie beispielsweise eine QuickPath Interconnect (QPI), oder eine ähnliche Verbindung 1395.
  • In einer Ausführungsform ist der Coprozessor 1345 ein Spezialprozessor, wie beispielsweise ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann der Controllerhub 1320 einen integrierten Grafikbeschleuniger umfassen.
  • Es kann eine Vielzahl von Unterschieden zwischen den physikalischen Ressourcen 1310, 1315 in Bezug auf ein Spektrum von Bewertungsmetriken geben, die architektonische, mikroarchitektonische, thermische und Leistungsverbrauchscharakteristiken und dergleichen umfassen.
  • In einer Ausführungsform führt der Prozessor 1310 Anweisungen aus, welche Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In die Anweisungen können Coprozessoranweisungen eingebettet sein. Der Prozessor 1310 erkennt diese Coprozessoranweisungen als einen Typ, der vom angeschlossenen Coprozessor 1345 ausgeführt werden sollte. Demgemäß gibt der Prozessor 1310 diese Coprozessoranweisungen (oder Steuersignale, welche die Coprozessoranweisungen darstellen) auf einem Coprozessorbus oder einen anderen Interconnect an den Coprozessor 1345 aus. Der oder die Coprozessor(en) 1345 nehmen die empfangenen Coprozessoranweisungen an und führen sie aus.
  • Nunmehr unter Bezugnahme auf 14 ist ein Blockdiagramm eines ersten spezifischeren beispielhaften Systems 1400 gemäß einer Ausführungsform der vorliegenden Offenbarung dargestellt. Wie in 14 dargestellt, ist das Multiprozessorsystem 1400 ist ein Punkt-zu-Punkt-Zwischenverbindungssystem 1470 und umfasst einen ersten Prozessor 1170 und einen zweiten Prozessor 1480, die über eine Punkt-zu-Punkt-Zwischenverbindung 1450 gekoppelt sind. Jeder der Prozessoren 1470 und 1480 kann eine Version des Prozessors 1200 sein. In einer Ausführungsform der Offenbarung sind die Prozessoren 1470 und 1480 Prozessoren 1310 bzw. 1315, während ein Coprozessor 1438 ein Coprozessor 1345 ist. In einer Ausführungsform sind die Prozessoren 1470 und 1480 ein Prozessor 1310 bzw. ein Coprozessor 1345.
  • Die Prozessoren 1470 und 1480 sind so dargestellt, dass sie integrierte Speichersteuer (IMC - Integrated Memory Controller)-Einheiten 1472 bzw. 1482 aufweisen. Der Prozessor 1470 umfasst außerdem als Teil seiner Buscontrollereinheiten Punkt-zu-Punkt (P-P)-Schnittstellen 1476 und 1478; ähnlich umfasst der zweite Prozessor 1480 P-P-Schnittstellen 1486 und 1488. Die Prozessoren 1470, 1480 können über eine Punkt-zu-Punkt (P-P)-Schnittstelle 1450 unter Verwendung von P-P-Schnittstellenschaltungen 1478, 1488 Informationen austauschen. Wie in 14 dargestellt, koppeln die IMCs 1472 und 1482 die Prozessoren mit jeweiligen Speichern, nämlich mit einem Speicher 1432 und einem Speicher 1434, welche Abschnitte eines Hauptspeichers sein können, der lokal an die jeweiligen Prozessoren angeschlossen ist.
  • Die Prozessoren 1470, 1480 können jeweils über individuelle P-P-Schnittstellen P-P 1452, 1454 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1476, 1494, 1486, 1498 Informationen mit einem Chipsatz 1490 austauschen. Der Chipsatz 1490 kann optional über eine Hochleistungsschnittstelle 1439 Informationen mit dem Coprozessor 1438 austauschen. In einer Ausführungsform ist der Coprozessor 1438 ein Spezialprozessor, wie beispielsweise ein MIC-Prozessor mit hohem Durchsatz, ein Netzwerk- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Grafikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.
  • Ein gemeinsam benutzter Cache (nicht dargestellt) kann in jedem Prozessor enthalten oder außerhalb von beiden Prozessoren, aber dennoch über eine P-P-Zwischenverbindung mit den Prozessoren verbunden sein, derart dass Informationen des lokalen Caches eines oder beider Prozessoren im gemeinsam benutzten Cache gespeichert werden können, wenn ein Prozessor in einen Stromsparmodus versetzt wird.
  • Der Chipsatz 1490 kann über eine Schnittstelle 1496 mit einem ersten Bus 1416 gekoppelt sein. In einer Ausführungsform kann der erste Bus 1416 ein Bus zur Verbindung von Peripheriekomponenten (PCI - Peripheral Component Interconnect) oder solch ein Bus wie beispielsweise ein PCI Express-Bus oder ein anderer E-/A-Interconnect-Bus der dritten Generation sein, obwohl der Schutzbereich der vorliegenden Offenbarung nicht darauf beschränkt ist.
  • Wie in 14 dargestellt, können verschiedene E-/A-Einrichtungen 1414 mit dem ersten Bus 1416 zusammen mit einer Busbrücke 1418 gekoppelt sein, welche den ersten Bus 1416 mit einem zweiten Bus 1420 koppelt. In einer Ausführungsform sind ein oder mehrere zusätzliche Prozessor(en) 1415, wie beispielsweise Coprozessoren, MIC-Prozessoren mit hohem Durchsatz, GPGPUs, Beschleuniger (wie etwa z. B. Grafikbeschleuniger oder Digitalsignalverarbeitungs (DSP)-Einheiten), feldprogrammierbare Gate-Arrays oder jeglicher andere Prozessor mit dem ersten Bus 1416 gekoppelt. In einer Ausführungsform kann der zweite Bus 1420 ein Bus mit geringer Anschlusszahl (LPC - Low Pin Count) sein. Verschiedene Geräte können an einen zweiten Bus 1420 angeschlossen sein, die in einer Ausführungsform zum Beispiel eine Tastatur und/oder eine Maus 1422, Kommunikationseinrichtungen 1427 und eine Speichereinheit 1428, wie beispielsweise ein Plattenlaufwerk oder ein Massenspeichergerät, umfassen, das Anweisungen/Code und Daten 1430 enthalten kann. Ferner kann Audio-E/-A 1424 mit dem zweiten Bus 1420 gekoppelt sein. Es ist zu erwähnen, dass auch eine andere Architektur möglich ist. Zum Beispiel kann ein System anstelle der Punkt-zu-Punkt-Architektur von 14 eine Mehrpunktbus- oder andere derartige Architektur implementieren.
  • Nunmehr unter Bezugnahme auf 15 ist ein Blockdiagramm eines zweiten spezifischeren beispielhaften Systems 1500 gemäß einer Ausführungsform der vorliegenden Offenbarung dargestellt. Gleiche Elemente in 14 und 15 tragen gleiche Bezugszeichen, und bestimmte Aspekte von 14 wurden in 15 weggelassen, um ein Verkomplizieren anderer Aspekte von 15 zu vermeiden.
  • 15 veranschaulicht, dass die Prozessoren 1470, 1480 integrierte Speicher und E-/A-Steuerlogik („CL“ - Control Logic) 1472 bzw. 1482 umfassen können. Demnach umfassen die CL 1472, 1482 integrierte Speichercontrollereinheiten und E-/A-Steuerlogik. 15 veranschaulicht, dass nicht nur die Speicher 1432, 1434 mit der CL 1472, 1482 gekoppelt sind, sondern dass auch E-/A-Einrichtungen 1514 mit der Steuerlogik 1472, 1482 gekoppelt sind. Ältere E-/A-Geräte 1515 sind mit dem Chipsatz 1490 gekoppelt.
  • Nunmehr unter Bezugnahme auf 16 ist ein Blockdiagramm eines Systemchips (SoC - System on a Chip) 1600 gemäß einer Ausführungsform der vorliegenden Offenbarung dargestellt. Ähnliche Elemente in 12 tragen gleiche Bezugszeichen. Außerdem sind Kästchen mit gestrichelten Linien optionale Funktionen auf weiterentwickelten SoCs. In 16 sind eine oder mehrere Zwischenverbindungseinheiten 1602 mit Folgendem gekoppelt: einem Anwendungsprozessor 1610, der einen Satz von einem oder mehreren Kernen 202A-N und einer oder mehreren gemeinsam benutzte Cache-Einheit(en) 1206 umfasst, einer Systemagenteneinheit 1210; Bussteuereinheit(en) 1216; integrierten Speichersteuereinheit(en) 1214; einem Satz von oder einem oder mehreren Coprozessoren 1620, welche integrierte Grafiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor umfassen können; einer statischen Direktzugriffsspeicher (SRAM - Static Random Access Memory)-Einheit 1630; einer Speicherdirektzugriffs (DMA - Direct Memory Access)-Einheit 1632; und einer Anzeigeeinheit 1640 zur Kopplung mit einer oder mehreren externen Anzeigen. In einer Ausführungsform umfasst/umfassen der/die Coprozessor(en) 1620 einen Spezialprozessor, wie beispielsweise einen Netzwerk- oder Kommunikationsprozessor, eine Kompressionsmaschine, eine GPGPU, einen MIC-Prozessor mit hohem Durchsatz, einen eingebetteten Prozessor oder dergleichen.
  • Hierin offenbarte Ausführungsformen (z. B. der Mechanismen) können in Hardware, Software, Firmware oder einer Kombination solcher Implementierungslösungen implementiert sein. Ausführungsformen der Offenbarung können als Computerprogramme oder Programmcode implementiert sein, die auf programmierbaren Systemen ausgeführt werden, die mindestens einen Prozessor, ein Speichersystem (das flüchtige und nichtflüchtige Speicher und/oder Speicherelemente umfasst), mindestens ein Eingabegerät und mindestens ein Ausgabegerät umfassen.
  • Programmcode, wie beispielsweise der in 14 veranschaulichte Code 1430, kann auf Eingabeanweisungen angewendet werden, um die hierin beschriebenen Funktionen auszuführen und Ausgabeinformationen zu generieren. Die Ausgabeinformationen können in bekannter Weise auf eine oder mehrere Ausgabeeinrichtungen angewendet werden. Zum Zwecke dieser Anmeldung umfasst ein Verarbeitungssystem jedes System, das einen Prozessor, wie beispielsweise einen Digitalsignalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC - Application Specific Integrated Circuit) oder einen Mikroprozessor, aufweist.
  • Der Programmcode kann in einer verfahrens- oder objektorientierten Programmiersprache implementiert sein, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmiercode kann außerdem in Assembler- oder Maschinensprache implementiert sein, falls gewünscht. Tatsächlich sind die hierin beschriebenen Mechanismen nicht auf eine bestimmte Programmiersprache beschränkt. Auf jeden Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
  • Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentative Anweisungen implementiert sein, die auf einem maschinenlesbaren Medium gespeichert sind, welches diverse Logik innerhalb des Prozessors darstellt, und die, wenn durch eine Maschine ausgelesen, die Maschine veranlassen, Logik zu erstellen, um die hierin beschriebenen Techniken auszuführen. Solche Darstellungen, die als „IP-Kerne“ bekannt sind, können auf einem gegenständlichen, maschinenlesbaren Medium gespeichert sein und an verschiedene Kunden oder Produktionsstätten geliefert werden, um sie in die Fertigungsmaschinen zu laden, welche die Logik oder den Prozessor tatsächlich erzeugen.
  • Solche maschinenlesbaren Speichermedien können, ohne darauf beschränkt zu sein, Folgende umfassen: nicht-transitorische, gegenständliche Anordnungen von Gegenständen, die durch eine Maschine oder ein Gerät hergestellt oder gebildet sind, einschließlich Speichermedien, wie beispielsweise Festplatten, jeglichen anderen Typs von Platten, einschließlich Disketten, optischer Platten, Compact-Disk-Festwertspeicher (CD-ROM - Compact Disk Read-Only Memory), wiederbeschreibbarer Compact-Disks (CD-RW - Compact Disk Rewritable) und magnetooptischer Platten, Halbleiterbauelemente wie beispielsweise Festwertspeicher (ROM - Read-Only Memory), Direktzugriffsspeicher (RAM - Random Access Memory), wie beispielsweise dynamischer Direktzugriffsspeicher (DRAM - Dynamic Random Access Memory), statischer Direktzugriffsspeicher (SRAM - Static Random Access Memory), löschbarer programmierbarer Festwertspeicher (EPROM - Erasable Programmable Read-Only Memory), Flash-Speicher, elektrisch löschbarer programmierbarer Festwertspeicher (EEPROM - Electrically Erasable Programmable Read-Only Memory), Phasenwechselspeicher (PCM - Phase Change Memory), magnetischer oder optischer Karten, oder jeden anderen Typs von Medien, die zum Speichern von elektronischen Anweisungen imstande sind.
  • Demgemäß umfassen Ausführungsformen der Offenbarung auch nicht-transitorische, gegenständliche maschinenlesbare Medien, welche Anweisungen enthalten oder welche Entwurfsdaten enthalten, wie beispielsweise Hardwarebeschreibungssprache (HDL - Hardware Description Language), welche hierin beschriebene Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemfunktionen definiert. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
  • Emulation (einschließlich Binärübersetzung, Code-Morphing usw.)
  • In einigen Fällen kann ein Anweisungsumsetzer zum Umsetzen einer Anweisung von einem Quellenanweisungssatz in einen Zielanweisungssatz verwendet werden. Zum Beispiel kann der Anweisungsumsetzer eine Anweisung in einen oder mehrere durch den Kern zu verarbeitende Anweisungen übersetzen (z. B. unter Verwendung von statischer Binärübersetzung, dynamischer Binärübersetzung, einschließlich dynamischer Kompilierung), morphen, emulieren oder anderweitig umsetzen. Der Anweisungsumsetzer kann in Software, Hardware, Firmware oder einer Kombination davon implementiert sein. Der Anweisungsumsetzer kann prozessorintern, prozessorextern oder teilweise prozessorintern und teilweise prozessorextern sein.
  • 17 ist ein Blockdiagramm, das die Verwendung eines Softwareanweisungsumsetzers zum Umsetzen von Binäranweisungen in einem Quellenanweisungssatz in Binäranweisungen in einem Zielanweisungssatz gemäß Ausführungsformen der Offenbarung vergleicht. In der veranschaulichten Ausführungsform ist der Anweisungsumsetzer ein Softwareanweisungsumsetzer, obwohl der Anweisungsumsetzer alternativ in Software, Firmware, Hardware oder verschiedenen Kombinationen davon implementiert werden kann. 17 stellt ein Programm in einer höheren Programmiersprache 1702 dar, die unter Verwendung eines x86-Compilers 1704 kompiliert werden kann, um x86-Binärcode 1706 zu generieren, der durch einen Prozessor mit mindestens einem x86-Anweisungssatzkern 1716 nativ ausgeführt werden kann. Der Prozessor mit mindestens einen x86-Anweisungssatzkern 1716 stellt jeden Prozessor dar, der im Wesentlichen die gleichen Funktionen wie ein Intel® Prozessor mit mindestens einem x86-Bfehlssatzkern durch kompatibles Ausführen oder anderweitiges Verarbeiten (1) eines wesentlichen Teils des Anweisungssatzes des Intel® x86-Anweisungssatzkerns oder (2) von Objektcodeversionen von Anwendungen oder anderer Software, die auf einem Intel® Prozessor mit mindestens einem x86-Anweisungssatzkern ausgeführt werden soll, ausführen kann, um im Wesentlichen das gleiche Ergebnis wie ein Intel® Prozessor mit mindestens einem x86-Anweisungssatzkern zu erzielen. Der x86-Compiler 1704 stellt einen Compiler dar, der so betrieben werden kann, dass er x86-Binärcode 1706 (z. B. Objektcode) generiert, der mit oder ohne zusätzliche Verknüpfungsverarbeitung, auf dem Prozessor mit mindestens einem x86-Anweisungssatzkern 1716 ausgeführt werden kann. Ähnlich stellt 17 das Programm in der höheren Programmiersprache 1702 dar, die unter Verwendung eines alternativen Anweisungssatz-Compilers 1708 kompiliert werden kann, um alternativen Anweisungssatz-Binärcode 1710 zu generieren, der durch einen Prozessor ohne mindestens einen x86-Anweisungssatzkern 1714 (z. B. einen Prozessor mit Kernen, die den MIPS-Anweisungssatz von MIPS Technologies in Sunnyvale, Kalifornien, ausführen, oder den ARM-Anweisungssatz der ARM Holdings in Sunnyvale, Kalifornien, ausführen) nativ ausgeführt werden kann. Der Anweisungsumsetzer 1712 wird zum Umsetzen des x86-Binärcodes 1706 in Code verwendet, der durch den Prozessor ohne x86-Anweisungssatzkern 1714 nativ ausgeführt werden kann. Dieser umgesetzte Code ist wahrscheinlich nicht der gleiche wie der alternative Anweisungssatz-Binärcode 1710, da ein Anweisungsumsetzer, der dazu imstande ist, schwer herzustellen ist; der umgesetzte Code führt jedoch die allgemeine Operation aus und besteht aus Anweisungen aus dem alternativen Anweisungssatz. Demnach stellt der Anweisungsumsetzer 1712 Software, Firmware, Hardware oder eine Kombination davon dar, die durch Emulation, Simulation oder einen beliebigen anderen Prozess einen Prozessor oder eine andere elektronische Einrichtung ermöglicht, der/die keinen x86-Anweisungssatzprozessor oder -kern zum Ausführen des x86-Binärcodes 1706 aufweist.

Claims (25)

  1. Hardwareprozessor, aufweisend: einen Decoder eines Kerns zum Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung, wobei die Einzelanweisung einen ersten Eingabeoperanden eines Handles, das einen Chiffretext eines Verschlüsselungsschlüssels, ein Authentisierungstag und zusätzliche Authentisierungsdaten umfasst, und einen zweiten Eingabeoperanden von Daten aufweist, die mit dem Verschlüsselungsschlüssel verschlüsselt sind; und eine Ausführungseinheit des Kerns zum Ausführen der decodierten Einzelanweisung zum: Durchführen eines ersten Vergleichs des Authentisierungstags mit dem Chiffretext und den zusätzlichen Authentisierungsdaten hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten, Durchführen eines zweiten Vergleichs einer aktuellen Anforderung des Kerns mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten des Handles spezifizierten Beschränkungen, Entschlüsseln des Chiffretexts zum Erzeugen des Verschlüsselungsschlüssels nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde, Entschlüsseln der mit dem Verschlüsselungsschlüssel verschlüsselten Daten, um unverschlüsselte Daten zu erzeugen, und Bereitstellen der unverschlüsselten Daten als eine Resultierende der Einzelanweisung.
  2. Hardwareprozessor nach Anspruch 1, wobei die Ausführungseinheit die decodierte Einzelanweisung ausführt, um ein Flag zu setzen, wenn: der erste Vergleich eine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt; oder der zweite Vergleich anzeigt, dass gegen die eine oder die mehreren Beschränkungen verstoßen wurde.
  3. Hardwareprozessor nach Anspruch 1, wobei der Decoder eine zweite Anweisung in eine decodierte zweite Anweisung decodiert, und die zweite Ausführungseinheit die decodierte zweite Anweisung ausführt, um einen internen Schlüssel, der zum Entschlüsseln des Chiffretexts verwendet wird, in ein Register des Kerns zu laden.
  4. Hardwareprozessor nach Anspruch 3, wobei die Ausführungseinheit die decodierte zweite Anweisung ausführt, um einen ersten Wert im Register zu setzen, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen spezifischen Schlüssel als internen Schlüssel anforderte, und einen zweiten Wert im Register zu setzen, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen Zufallsschlüssel als internen Schlüssel anforderte.
  5. Hardwareprozessor nach Anspruch 3, wobei der interne Schlüssel einen Integritätsschlüssel und einen separaten Verschlüsselungsschlüssel aufweist.
  6. Hardwareprozessor nach Anspruch 1, wobei der Decoder eine zweite Anweisung in eine decodierte zweite Anweisung decodiert, und die Ausführungseinheit die decodierte zweite Anweisung ausführt, um das Handle aus einer Eingabe des Verschlüsselungsschlüssels und eines Handle-Beschränkungstyps zu erzeugen.
  7. Hardwareprozessor nach einem der Ansprüche 1 bis 6, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Verschlüsselung verwendet werden kann.
  8. Verfahren, aufweisend: Decodieren einer Einzelanweisung mit einem Decoder eines Kerns eines Hardwareprozessors in eine decodierte Einzelanweisung, wobei die Einzelanweisung einen ersten Eingabeoperanden eines Handles, das einen Chiffretext eines Verschlüsselungsschlüssels, ein Authentisierungstag und zusätzliche Authentisierungsdaten umfasst, und einen zweiten Eingabeoperanden von Daten aufweist, die mit dem Verschlüsselungsschlüssel verschlüsselt sind; und Ausführen der decodierten Einzelanweisung mit einer Ausführungseinheit des Kerns zum: Durchführen eines ersten Vergleichs des Authentisierungstags mit dem Chiffretext und den zusätzlichen Authentisierungsdaten hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten, Durchführen eines zweiten Vergleichs einer aktuellen Anforderung des Kerns mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten des Handles spezifizierten Beschränkungen, Entschlüsseln des Chiffretexts zum Erzeugen des Verschlüsselungsschlüssels nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde, Entschlüsseln der mit dem Verschlüsselungsschlüssel verschlüsselten Daten, um unverschlüsselte Daten zu erzeugen, und Bereitstellen der unverschlüsselten Daten als eine Resultierende der Einzelanweisung.
  9. Verfahren nach Anspruch 8, wobei das Ausführen der decodierten Einzelanweisung ein Flag setzt, wenn: der erste Vergleich eine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt; oder der zweite Vergleich anzeigt, dass gegen die eine oder die mehreren Beschränkungen verstoßen wurde.
  10. Verfahren nach Anspruch 8, ferner aufweisend: Decodieren einer zweiten Anweisung mit dem Decoder des Kerns in eine decodierte zweite Anweisung; und Ausführen der decodierten zweiten Anweisung mit der Ausführungseinheit des Kerns, um einen internen Schlüssel, der zum Entschlüsseln des Chiffretexts verwendet wird, in ein Register des Kerns zu laden.
  11. Verfahren nach Anspruch 10, wobei die Ausführungseinheit einen ersten Wert im Register setzt, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen spezifischen Schlüssel als internen Schlüssel anforderte, und einen zweiten Wert im Register setzt, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen Zufallsschlüssel als internen Schlüssel anforderte.
  12. Verfahren nach Anspruch 8, ferner aufweisend: Decodieren einer zweiten Anweisung mit dem Decoder des Kerns in eine decodierte zweite Anweisung; und Ausführen der decodierten zweiten Anweisung mit der Ausführungseinheit des Kerns, um das Handle aus einer Eingabe des Verschlüsselungsschlüssels und eines Handle-Beschränkungstyps zu erzeugen.
  13. Verfahren nach einem der Ansprüche 8 bis 12, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Verschlüsselung verwendet werden kann.
  14. Nicht-transitorisches maschinenlesbares Speichermedium, das Programmcode speichert, der bei Ausführung durch eine Maschine die Maschine veranlasst, ein Verfahren auszuführen, das aufweist: Decodieren einer Einzelanweisung mit einem Decoder eines Kerns eines Hardwareprozessors in eine decodierte Einzelanweisung, wobei die Einzelanweisung einen ersten Eingabeoperanden eines Handles, das einen Chiffretext eines Verschlüsselungsschlüssels, ein Authentisierungstag und zusätzliche Authentisierungsdaten umfasst, und einen zweiten Eingabeoperanden von Daten aufweist, die mit dem Verschlüsselungsschlüssel verschlüsselt sind; und Ausführen der decodierten Einzelanweisung mit einer Ausführungseinheit des Kerns zum: Durchführen eines ersten Vergleichs des Authentisierungstags mit dem Chiffretext und den zusätzlichen Authentisierungsdaten hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten, Durchführen eines zweiten Vergleichs einer aktuellen Anforderung des Kerns mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten des Handles spezifizierten Beschränkungen, Entschlüsseln des Chiffretexts zum Erzeugen des Verschlüsselungsschlüssels nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde, Entschlüsseln der mit dem Verschlüsselungsschlüssel verschlüsselten Daten, um unverschlüsselte Daten zu erzeugen, und Bereitstellen der unverschlüsselten Daten als eine Resultierende der Einzelanweisung.
  15. Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 14, wobei das Ausführen der decodierten Einzelanweisung ein Flag setzt, wenn: der erste Vergleich eine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt; oder der zweite Vergleich anzeigt, dass gegen die eine oder die mehreren Beschränkungen verstoßen wurde.
  16. Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 14, ferner aufweisend: Decodieren einer zweiten Anweisung mit dem Decoder des Kerns in eine decodierte zweite Anweisung; und Ausführen der decodierten zweiten Anweisung mit der Ausführungseinheit des Kerns, um einen internen Schlüssel, der zum Entschlüsseln des Chiffretexts verwendet wird, in ein Register des Kerns zu laden.
  17. Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 16, wobei die Ausführungseinheit einen ersten Wert im Register setzt, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen spezifischen Schlüssel als internen Schlüssel anforderte, und einen zweiten Wert im Register setzt, um anzuzeigen, dass Software durch Ausführung der zweiten Anweisung einen Zufallsschlüssel als internen Schlüssel anforderte.
  18. Nicht-transitorisches maschinenlesbares Speichermedium nach Anspruch 14, ferner aufweisend: Decodieren einer zweiten Anweisung mit dem Decoder des Kerns in eine decodierte zweite Anweisung; und Ausführen der decodierten zweiten Anweisung mit der Ausführungseinheit des Kerns, um das Handle aus einer Eingabe des Verschlüsselungsschlüssels und eines Handle-Beschränkungstyps zu erzeugen.
  19. Nicht-transitorisches maschinenlesbares Speichermedium nach einem der Ansprüche 14 bis 18, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Verschlüsselung verwendet werden kann.
  20. Hardwareprozessor, aufweisend: einen Decoder eines Kerns zum Decodieren einer Einzelanweisung in eine decodierte Einzelanweisung, wobei die Einzelanweisung einen Eingabeoperanden eines Handles aufweist, das einen Chiffretext von Originaldaten, ein Authentisierungstag und zusätzliche Authentisierungsdaten umfasst; und eine Ausführungseinheit des Kerns zum Ausführen der decodierten Einzelanweisung zum: Durchführen eines ersten Vergleichs des Authentisierungstags mit dem Chiffretext und den zusätzlichen Authentisierungsdaten hinsichtlich einer Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten, Durchführen eines zweiten Vergleichs einer aktuellen Anforderung des Kerns mit einer oder mehreren durch die zusätzlichen Authentisierungsdaten des Handles spezifizierten Beschränkungen, Entschlüsseln des Chiffretexts zum Erzeugen der Originaldaten nur dann, wenn der erste Vergleich keine Modifikation des Chiffretexts oder der zusätzlichen Authentisierungsdaten anzeigt, und der zweite Vergleich anzeigt, dass nicht gegen die eine oder die mehreren Beschränkungen verstoßen wurde, Durchführen einer Operation an den Originaldaten, um Ergebnisdaten zu erzeugen, und Bereitstellen der Ergebnisdaten als eine Resultierende der Einzelanweisung.
  21. Hardwareprozessor nach Anspruch 20, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht außerhalb eines Betriebssystems verwendet werden kann.
  22. Hardwareprozessor nach Anspruch 20, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht außerhalb einer spezifischen vertrauenswürdigen Ausführungsumgebung verwendet werden kann.
  23. Hardwareprozessor nach Anspruch 20, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nur verwendet werden kann, wenn ein spezifisches Element eines betriebssystemgesteuerten Zustands auf eine spezifische Art und Weise festgelegt ist.
  24. Hardwareprozessor nach Anspruch 20, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle durch einen Virtual-Machine-Monitor verwendet werden kann, aber nicht durch eine virtuelle Maschine verwendet werden kann.
  25. Hardwareprozessor nach einem der Ansprüche 20 bis 24, wobei die zusätzlichen Authentisierungsdaten ein Feld aufweisen, das anzeigt, ob das Handle nicht zur Entschlüsselung verwendet werden kann.
DE102020126293.0A 2019-12-28 2020-10-07 Vorrichtungen, verfahren und systeme für anweisungen für kryptografisch an daten gebundene nutzungsbeschränkungen Pending DE102020126293A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/729,352 US11917067B2 (en) 2019-12-28 2019-12-28 Apparatuses, methods, and systems for instructions for usage restrictions cryptographically tied with data
US16/729,352 2019-12-28

Publications (1)

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

Family

ID=76310473

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020126293.0A Pending DE102020126293A1 (de) 2019-12-28 2020-10-07 Vorrichtungen, verfahren und systeme für anweisungen für kryptografisch an daten gebundene nutzungsbeschränkungen

Country Status (3)

Country Link
US (2) US11917067B2 (de)
CN (1) CN113050989A (de)
DE (1) DE102020126293A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11593111B2 (en) * 2020-01-27 2023-02-28 Arm Limited Apparatus and method for inhibiting instruction manipulation
US12019736B2 (en) * 2020-02-27 2024-06-25 The Trustees Of The University Of Pennsylvania Methods, systems, and computer readable media for main memory tag compression
GB2597708B (en) * 2020-07-30 2022-11-02 Advanced Risc Mach Ltd Vector processing
US11709675B2 (en) * 2020-10-30 2023-07-25 Apple Inc. Software verification of dynamically generated code
US11308226B1 (en) * 2021-02-22 2022-04-19 CipherMode Labs, Inc. Secure collaborative processing of private inputs
US11954337B2 (en) * 2021-08-26 2024-04-09 International Business Machines Corporation Encryption monitor register and system

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8914648B1 (en) * 2009-08-17 2014-12-16 Sandia Corporation Stateless and stateful implementations of faithful execution
JP6063941B2 (ja) * 2011-08-30 2017-01-18 ヒューレット−パッカード デベロップメント カンパニー エル．ピー．Ｈｅｗｌｅｔｔ‐Ｐａｃｋａｒｄ Ｄｅｖｅｌｏｐｍｅｎｔ Ｃｏｍｐａｎｙ， Ｌ．Ｐ． システム管理要求のための仮想高特権モード
CN104012030B (zh) 2011-12-21 2018-04-13 英特尔公司 用于保护对称加密密钥的系统及方法
KR20150049596A (ko) * 2013-10-30 2015-05-08 삼성전자주식회사 보안 입력 방법 및 그 전자 장치
US10313129B2 (en) * 2015-06-26 2019-06-04 Intel Corporation Keyed-hash message authentication code processors, methods, systems, and instructions
US10374805B2 (en) * 2015-07-20 2019-08-06 Intel Corporation Technologies for trusted I/O for multiple co-existing trusted execution environments under ISA control
US9904805B2 (en) * 2015-09-23 2018-02-27 Intel Corporation Cryptographic cache lines for a trusted execution environment
US10142101B2 (en) * 2015-09-29 2018-11-27 Intel Corporation Hardware enforced one-way cryptography
KR20170059082A (ko) * 2015-11-20 2017-05-30 삼성전자주식회사 파일 조작 처리 방법 및 이를 지원하는 전자 장치
US9680653B1 (en) * 2016-10-13 2017-06-13 International Business Machines Corporation Cipher message with authentication instruction
US10567165B2 (en) * 2017-09-21 2020-02-18 Huawei Technologies Co., Ltd. Secure key transmission protocol without certificates or pre-shared symmetrical keys
US11062299B2 (en) * 2017-10-24 2021-07-13 BBPOS Limited System and method for indicating entry of personal identification number
US10979403B1 (en) * 2018-06-08 2021-04-13 Amazon Technologies, Inc. Cryptographic configuration enforcement
US10785028B2 (en) 2018-06-29 2020-09-22 Intel Corporation Protection of keys and sensitive data from attack within microprocessor architecture
US10963593B1 (en) * 2018-12-11 2021-03-30 Amazon Technologies, Inc. Secure data storage using multiple factors
AU2020217563A1 (en) * 2019-02-05 2021-09-30 Ethopass, Llc Security system and related methods
US20220141004A1 (en) * 2019-08-08 2022-05-05 Zettaset, Inc. Efficient Internet-Of-Things (IoT) Data Encryption/Decryption

Also Published As

Publication number Publication date
US20240250823A1 (en) 2024-07-25
US20210203504A1 (en) 2021-07-01
US11917067B2 (en) 2024-02-27
CN113050989A (zh) 2021-06-29

Similar Documents

Publication Publication Date Title
DE102020126293A1 (de) Vorrichtungen, verfahren und systeme für anweisungen für kryptografisch an daten gebundene nutzungsbeschränkungen
DE102019109088A1 (de) Schutz von schlüsseln und sensitiven daten gegen angriffe in einer mikroprozessorarchitektur
DE102018005180A1 (de) Flexible Bescheinigung von Containern
DE202019005671U1 (de) Koexistenz von Vertrauensdomänenarchitektur mitMehrschlüssel-Gesamtspeicherverschlüsselungstechnologieauf Servern
DE112017004017T5 (de) Sichere öffentliche cloud
DE112012007063B4 (de) Zusammenfügen von benachbarten Sammel-/Streuoperationen
DE112013004798B4 (de) Befehlssatz zur Nachrichtenplanung des SHA256-Algorithmus
DE112017001804T5 (de) Vorrichtung und Verfahren für träge synchrone Seitentabellenaktualisierungen mit geringem Aufwand
DE112017001766T5 (de) Power-side-channel-angriffsresistenter advanced-encryption-standard-beschleunigungsprozessor
DE102018126731A1 (de) Freigabeanweisung, um Seitenblock während des Auslagerns umzukehren
DE102019109845A1 (de) Vereinheitlichte Beschleunigung eines Blockgeheimcodes eines symmetrischen Schlüssels für AES-SMS4-Camellia
DE102014004563A1 (de) Befehle und Logik zur Bereitstellung verbesserter Paging-Fähigkeiten für Secure Enclave-Seitencaches
DE102015006863A1 (de) Befehle und Logik zum Unterbrechen und Wiederaufnehmen von Paging in Secure Enclaves
US20210200880A1 (en) Method and apparatus for multi-key total memory encryption based on dynamic key derivation
DE102019126125A1 (de) System, vorrichtung und verfahren zum integritätsschutz von kunden-arbeitslasten in einer mehrkunden-datenverarbeitungsumgebung
DE102018125747A1 (de) Unterstützung für eine höhere anzahl von gleichzeitigenschlüsseln in einer kryptografie-engine mit mehrerenschlüsseln
DE202019005672U1 (de) System zum Verhindern eines unautorisierten Zugriffs auf verschlüsselten Speicher
DE102015002215A1 (de) Sortierbeschleunigungsprozessor, -Verfahren, -Systeme und -Befehle
DE102015002124A1 (de) Rücksprungzielbeschränkte Prozedurrücksprungbefehle, Prozessoren, Verfahren und Systeme
DE602004005025T2 (de) Instruktionen zur verarbeitung einer verschlusselten nachricht
DE102018004290A1 (de) Kryptographischer Speicherschutz mit Mehrfachschlüssel
DE202019005682U1 (de) Hardwaregestützte Paging-Mechanismen
DE102018005101A1 (de) Feld-Systemtest-Sicherheit
DE112013005239T5 (de) Anweisung zur Beschleunigung des drahtlosen SNOW 3G- Sicherheitsalgorithmus
DE112013003735B4 (de) Systeme, Vorrichtungen und Verfahren zum Ausführen von Rotation und XOR als Reaktion auf eine einzige Anweisung