DE112021007571T5

DE112021007571T5 - Ipu-basierte operatoren

Info

Publication number: DE112021007571T5
Application number: DE112021007571.3T
Authority: DE
Inventors: Francesc Guim Bernat
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2021-09-17
Filing date: 2021-09-17
Publication date: 2024-03-07
Also published as: WO2023043456A1

Abstract

Verfahren und Einrichtungen zur Attestierung und Ausführung von Operatoren. Die Einrichtung ist dazu ausgelegt, in einer Rechenplattform implementiert zu werden, die mindestens eine Verarbeitungseinheit aufweist, und ist dazu ausgelegt, clientseitige Attestierungsoperationen mit einem Operatorattestierungsdienst durchzuführen, um einen Operator zu validieren, der auf der Einrichtung oder einer Verarbeitungseinheit auf der Rechenplattform ausgeführt werden soll. Die Einrichtung ist auch dazu ausgelegt, einen Operator aus einem Operatorkatalog zu beziehen, einen Hash-Wert über den Operator zu berechnen und eine Nachricht, die den Hash-Wert und die Operatorkennung (ID) (oder das Digest, das denselben mit optionaler Signatur enthält) enthält, an den Operatorattestierungsdienst zu senden, der den Operator validiert, indem ein gültiger Hash-Wert für den Operator unter Verwendung der Operator-ID nachgeschlagen und die Hash-Werte verglichen werden. Die Einrichtung ist auch dazu ausgelegt, Mandantenregeln in Bezug auf die Ausführung von Operatoren pflegen und durchzusetzen, und beinhaltet einen Cache zum Zwischenspeichern validierter Operatoren.

Description

HINTERGRUND DER ERFINDUNG
Rechenzentrumsarchitekturen entwickeln sich schnell weiter, um in der Lage zu sein, eine schnelle Bereitstellung von Knoten, eine autonome Lebenszyklusverwaltung von Diensten und nahtlose Aktualisierungen bei Bedarf zu ermöglichen. Ökosystemanbieter (wie etwa Red Hat, VMware usw.) setzen immer stärker auf die Entwicklung von Verfahren, die Konstrukte wie etwa Operatoren verwenden, um die Automatisierung, Robustheit und Lebenszyklusverwaltung des gesamten Rechenzentrums und der zugehörigen Dienste zu realisieren. Zum Beispiel zeigt 1 einen Verwaltungslebenszyklus mit fünf Phasen: Installation, Upgrades, Lebenszyklus, Einblicke („Insights“) und Auto-Pilot. Für die Phasen II-V können verschiedene benutzerdefinierte Operatoren erforderlich sein.
Die Konstrukte können zusätzlich zu mehreren Arten von Technologien und Sprachen entwickelt werden. Zum Beispiel können Softwarelösungen, wie etwa unter anderem Helm (für Kubernetes), Ansible (Infrastruktur als Code) und die Go-Programmiersprache, in verschiedenen Phasen der Systemkonfiguration und des Anwendungseinsatzes sowie der Lebenszyklusverwaltung in Abhängigkeit von der Art der Operatoren genutzt werden.
Diese Vielfalt von Ökosystemanbietern und Verfahren zum Implementieren von Operatoren wird eine schnelle Entwicklung von Mechanismen ermöglichen, um skalierbarere und autonomere Systeme zu erzielen. Allerdings stellt sich die Frage, ob ein Mechanismus im Rechenzentrum zur Verfügung stehen wird, der es ermöglicht, Operatoren zu validieren, zu filtern und zu attestieren, bevor sie in einem bestimmten Knoten ausgeführt werden. Wird ein Infrastrukturelement verfügbar sein, das ihre Attestierung, Validierung und sogar Ausführung übernimmt? Es gibt verschiedenes, das ein Cloud-Diensteanbieter, CSP (Cloud Service Provider), oder ein Datenzentrumsbetreiber verhindern will:

• Operator X ist für einen bestimmten Knoten nicht erwünscht. Zum Beispiel soll ein Knoten verwendet werden, ohne Änderungen an Leistungszuständen zu verwenden, aufgrund des Echtzeitaspekts von Anwendungen, die auf diesem Knoten ausgeführt werden. Ansible-Skripte können Leistungszustände auf gegebenen Kernen ändern.
• Operator X ist für einen gegebenen Knoten nicht vertrauenswürdig oder validiert. Es kann vorkommen, dass jemand Berechtigungsnachweise oder Zugriff auf einen Knoten erwirbt und einen Operator auf bösartige Weise usw. ausführt.
• Operator X wurde für diese Plattform nicht validiert oder kollidiert mit einem Dienst, der auf dem Knoten ausgeführt wird.

KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorstehenden Aspekte und viele der dazugehörigen Vorteile dieser Erfindung werden besser ersichtlich, wenn dieselben unter Bezugnahme auf die folgende ausführliche Beschreibung in Verbindung mit den zugehörigen Zeichnungen besser verstanden werden, wobei sich gleiche Bezugszeichen über alle verschiedenen Ansichten hinweg auf gleiche Teile beziehen, sofern nicht anders angegeben:

1 ist ein Diagramm, das einen Verwaltungslebenszyklus veranschaulicht;
2 ist ein Diagramm, das ein Beispiel für eine Vertrauensumgebung, die eine IPU einsetzt, gemäß einer Ausführungsform veranschaulicht;
3 ist ein schematisches Diagramm, das eine Architektur einer hohen Ebene einer sicheren Operatoreinsatzumgebung gemäß einer Ausführungsform veranschaulicht;
3a ist ein schematisches Diagramm, das eine erste Variante der Rechenplattform aus 3 veranschaulicht, bei der eine XPU anstelle einer CPU verwendet wird;
3b ist ein schematisches Diagramm, das eine zweite Variante der Rechenplattform aus 3 veranschaulicht, bei der die Rechenplattform sowohl eine CPU als auch eine XPU beinhaltet;
4 ist ein schematisches Diagramm einer Architektur, die sich auf weitere Details der IPU konzentriert und darauf, wie sie eine Attestierung von Operatoren und anderen Funktionen durchführt, gemäß einer Ausführungsform;
5 ist ein Flussdiagramm, das Operationen zum Einrichten eines authentifizierten Kanals veranschaulicht, der zur Kommunikation zwischen einer IPU und einem sicheren Server verwendet werden soll;
6 ist ein Flussdiagramm, das einen Prozess zum Attestieren und Validieren eines bestimmten Operators oder einer bestimmten Operation innerhalb eines Operators oder Operatorflusses veranschaulicht, der/die durch eine bestimmte Quelle instanziiert wird, gemäß einer Ausführungsform;
7 ist ein Flussdiagramm, das Operationen und Logik veranschaulicht, die als Reaktion auf das Empfangen einer neuen Operatoranforderung durchgeführt werden;
8 ist ein Diagramm, das weitere Aspekte eines Operatorattestierungsdienstes und eines Operatorkatalogs gemäß einer Ausführungsform veranschaulicht; und
9 ist ein schematisches Diagramm, das eine IPU gemäß einer Ausführungsform veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
Ausführungsformen von Verfahren und Einrichtungen zur Attestierung und Ausführung von Operatoren sind hier beschrieben. In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein gründliches Verständnis von Ausführungsformen der Erfindung zu vermitteln. Ein Fachmann wird jedoch erkennen, dass die Erfindung ohne eine oder mehrere der spezifischen Einzelheiten oder mit anderen Verfahren, Komponenten, Materialien usw. umgesetzt werden kann. In anderen Fällen sind wohlbekannte Strukturen, Materialien oder Operationen nicht ausführlich gezeigt oder beschrieben, um ein Verdecken von Aspekten der Erfindung zu vermeiden.
Durchweg bedeutet in dieser Spezifikation Bezugnahme auf „eine Ausführungsform“, dass ein in Verbindung mit der Ausführungsform beschriebenes bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft in mindestens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Somit beziehen sich die Vorkommen der Phrase „in einer Ausführungsform“ an verschiedenen Stellen über diese Spezifikation hinweg nicht alle notwendigerweise auf dieselbe Ausführungsform. Ferner können die bestimmten Merkmale, Strukturen oder Charakteristiken bei einer oder mehreren Ausführungsformen auf eine beliebige geeignete Weise kombiniert werden.
Der Klarheit halber können einzelne Komponenten in den Figuren hierin anstatt durch eine bestimmte Bezugsziffer auch durch ihre Beschriftungen in den Figuren bezeichnet werden. Zusätzlich dazu können Bezugsziffern, die sich auf einen bestimmten Komponententyp beziehen (im Gegensatz zu einer bestimmten Komponente), mit einer Bezugsziffer gefolgt von „(typ)“ gezeigt sein, was „typisch“ bedeutet. Es versteht sich, dass die Konfiguration dieser Komponenten für ähnliche Komponenten, die existieren können, in den Zeichnungsfiguren der Einfachheit und Klarheit halber aber nicht gezeigt sind, oder anderweitig ähnliche Komponenten, die nicht mit getrennten Bezugsziffern beschriftet sind, typisch ist. Im Gegensatz dazu ist „(typ)“ nicht in der Bedeutung zu verstehen, dass die Komponente, das Element etc. typischerweise für die/den hier offenbarte(n) Funktion, Implementierung, Zweck usw. verwendet wird.
Infrastrukturverarbeitungseinheit
Eine IPU (Infrastructure Processing Unit, Infrastrukturverarbeitungseinheit) ist eine programmierbare Netzwerkvorrichtung, die Infrastrukturressourcen auf Systemebene intelligent verwaltet, indem sie diese Funktionen in einem Rechenzentrum oder einer ähnlichen Umgebung sicher beschleunigt. Sie ermöglicht Cloud-Betreibern, auf eine vollständig virtualisierte Speicher- und Netzwerkarchitektur umzustellen und gleichzeitig eine hohe Leistungsfähigkeit und Vorhersagbarkeit sowie ein hohes Maß an Kontrolle beizubehalten.
Die IPU weist dedizierte Funktionalität zum Beschleunigen moderner Anwendungen auf, die unter Verwendung einer mikrodienstbasierten Architektur im Rechenzentrum erstellt werden. Forschungen von Google und Facebook haben gezeigt, dass 22 % bis 80 % der CPU-Zyklen durch Kommunikations-Overhead von Mikrodiensten verbraucht werden können. Eine IPU kann die CPU-Zyklen, die durch Mikrodienstkommunikation verbraucht werden, drastisch reduzieren.
Mit der IPU kann ein Cloud-Anbieter Infrastrukturfunktionen sicher verwalten, während es seinem Kunden ermöglicht wird, die Funktionen der CPU und des Systemspeichers vollständig zu steuern.
Neben anderen Fähigkeiten bietet eine IPU die Fähigkeit zum:

• Beschleunigen von Infrastrukturfunktionen, einschließlich Speichervirtualisierung, Netzwerkvirtualisierung und Sicherheit, mit dedizierten Protokollbeschleunigern.
• Freigeben von CPU-Kernen durch Verlagern von Speicher- und Netzwerkvirtualisierungsfunktionen, die zuvor in Software auf der CPU durchgeführt wurden, auf die IPU.
• Optimieren der Datenzentrumsauslastung durch Ermöglichen einer flexiblen Arbeitslastplatzierung.
• Ermöglichen, dass Cloud-Diensteanbieter Bereitstellungen von Infrastrukturfunktionen mit der Geschwindigkeit von Software anpassen können.

2 zeigt ein Beispiel für eine Vertrauensumgebung 200, in der eine IPU zum Einsatz kommt, gemäß einer Ausführungsform. Die Vertrauensumgebung 200 beinhaltet eine Plattform 202, die in Kommunikationsverbindung mit einem Vertrauensserver 204 steht. Die Plattform 202 beinhaltet eine CPU 206, die ein vertrauenswürdiges Plattformmodul (TPM, Trusted Platform Module) 208 zur Plattformsicherheitsattestierung und -validierung einsetzt. Wie hier verwendet, ist eine CPU allgemein veranschaulichend für einen Prozessor und/oder ein Ein-Chip-System (SoC, System-on-Chip). Das TPM wird mit einem in die Hardware eingebauten öffentlichen/privaten Schlüsselpaar hergestellt, das als Endorsement-Schlüssel (EK, Endorsement Key) bezeichnet wird. Der EK ist für ein bestimmtes TPM eindeutig und wird von einer vertrauenswürdigen Zertifizierungsstelle (CA, Certification Authority) signiert.
Die Verwendung eines TPM zur Plattformsicherheitsattestierung und -validierung umfasst im Allgemeinen das „Messen“ von Plattformfirmware- und Softwarekomponenten, das Erzeugen eines oder mehrerer Hash-Werte(s) und das Senden der Hash-Werte für den Vertrauensserver 204 zum Vergleich. Unter Messung ist der Prozess zu verstehen, durch den Informationen über die Software, Hardware und Konfiguration eines Systems gesammelt und zusammengefasst werden; solche Messungen können als Digests (Zusammenfassungen) bezeichnet werden oder in einem Digest enthalten sein, das mit anderen Daten oder Metadaten verkettet ist. Zum Ladezeitpunkt verwendet das TPM eine Hash-Funktion, um eine ausführbare Datei, eine ausführbare Datei samt ihrer Eingabedaten oder eine Sequenz solcher Dateien mit einem Fingerabdruck zu versehen. Diese Hash-Werte werden bei der Attestierung verwendet, um Codeidentität für entfernte oder lokale Verifizierer, die in diesem Beispiel Vertrauensserver 204 sind, zuverlässig herzustellen.
Die Attestierung ist ein Mechanismus, mit dem Firmware und/oder Software ihre Identität nachweisen. Das Ziel der Attestierung besteht darin, einer entfernten Partei zu beweisen, dass die Firmware und/oder das Betriebssystem der Plattform und (optional) die Anwendungssoftware intakt und vertrauenswürdig sind. Der Verifizierer vertraut darauf, dass Attestierungsdaten exakt sind, da sie von einem TPM signiert werden, dessen Schlüssel durch die CA zertifiziert ist.
Für eine gegebene Vertrauensumgebung weist der Vertrauensserver 204 Sätze von Hash-Werten für bereitgestellte Plattformen und/oder Knoten auf, wobei die Hash-Werte einer vertrauenswürdigen Konfiguration für den Messgegenstand, etwa die Plattformfirmware, entsprechen. Der Vertrauensserver 204 wird auch einen Satz von Zertifikaten 210 aufweisen. Falls die Plattformfirmware gehackt wurde, stimmen die Hash-Werte nicht überein, und die Firmware und/oder Software der Plattform werden nicht für einen weiteren Betrieb validiert.
Die Plattform 202 beinhaltet ferner eine Netzwerkschnittstelle, die eine SmartNIC 212 umfasst, die eine IPU 214 und ein Vertrauenswürdige-Operatoren-Modul (TOM, Trusted Operators Module) 216 beinhaltet, das zur Operatorattestierung, -überwachung und - bereitstellung verwendet wird. In einer Ausführungsform umfasst das TOM 216 ein zweites TPM, das zur Operatorattestierung (z. B. Attestierung von Operatorsoftware) anstatt zur Attestierung von Plattformfirmware und OS verwendet wird, wie unten ausführlicher beschrieben.
3 zeigt eine Architektur 300 einer hohen Ebene einer sicheren Operatoreinsatzumgebung gemäß einer Ausführungsform. In der Architektur 300 stellt die Logik in der IPU/Smart NIC offenbare Funktionalitäten bereit, um einem Infrastruktureigentümer zu ermöglichen, die Ausführung von Operatoren zu steuern, die Softwarestapel (z. B. Instanzen von Kubernetes, Benutzer usw.) gegen einen Server erzeugen können. Zusätzlich ist die IPU in der Lage, bei Bedarf als Operatoraktor zu fungieren.
Im Allgemeinen ist die IPU für das Validieren und Attestieren von Operatoren verantwortlich, die auf die Plattform/den Knoten selbst angewendet werden. Falls ein Operator von einem Knoten X an dem lokalen Knoten ausgeführt wird, ist die Logik dafür verantwortlich, jede Ausführung oder jeden Schritt, die der Operator an das System sendet, zu validieren und/oder zu attestieren (z. B. Einstellen der Frequenz eines bestimmten Kerns). Dies impliziert, dass die Handlungen von Operatoren gegen ein bestimmtes System mit dem Operatorzertifikat signiert werden müssen. Über die Attestierung hinaus unterstützt die IPU die Registrierung und Durchsetzung von Regeln darüber, welche Art von Operatoren und Aktionen an das lokale System ausgeführt werden können.
Die IPU beinhaltet Logik, die die Ausführung einiger Operatoren direkt auf der IPU ermöglicht. Dies reduziert nicht nur den Verkehr zwischen Plattformen, sondern unterstützt auch eine einheitlichere und autonomere Operatorenverwaltung. Die IPU erhält Zugriff auf einen konsistenten (und attestierten) Katalog von Operatoren. Daher können Benutzer oder Softwareentitäten eine Operatoranforderung an die IPU übermitteln, um spezifische Operatoren aus einem vertrauenswürdigen Katalog auszuführen. Diese Operatoren werden aus dem Katalog bezogen und über die hier beschriebenen Attestierungs- und Validierungsoperationen validiert, bevor sie auf der IPU ausgeführt werden oder einen validierten Operator weiterleiten, der durch eine Verarbeitungseinheit auf der Plattform/dem Knoten ausgeführt werden soll.
Die IPU beinhaltet auch Logik, die den Status der Plattform und der Dienste überwachen kann, um bestimmte Operatoren auf bestimmten Plattformpartitionen (oder der gesamten Plattform) oder Dienste auszuführen, wenn spezifische Bedingungen identifiziert werden (z. B. unter Verwendung von Plattform- oder Anwendungstelemetrie als Auslöser).
Die Architektur sieht auch vor, dass diese Fähigkeiten in einer mandantenfähigen Konfiguration verwaltet werden können. Zum Beispiel das Konfigurieren von Regeln oder das Verwalten der Operatoren pro Mandanten oder Gruppen von Mandanten.
Es wird erneut Bezug genommen auf 3; auf einer obersten Ebene weist die Architektur 300 eine Plattform 302 mit einer CPU 304 und einer IPU 306 auf, die kommunikationsfähig mit einem Operatorattestierungsdienst 308 und einem Operatorkatalog 310 gekoppelt sind. Die CPU 304 weist einen CXL (Compute Express Link)-Hub 312, der mit einem oder mehreren CXL-DIMMs 314 gekoppelt ist, und ein Paar aktiver Brücken mit HBM (High Bandwidth Memory)-Eingabe/Ausgabe(E/A)-Schnittstellen 316 und 317, die mit HBM-Vorrichtungen 318 gekoppelt sind, auf. Ein High-Bandwidth-Speicher ist eine Hochgeschwindigkeits-Computerspeicherschnittstelle für 3D-gestapelten synchronen dynamischen Direktzugriffsspeicher (SDRAM, Synchronous Dynamic Random-Access Memory). Allgemein ist die HBM-Vorrichtung 318 veranschaulichend für eine HBM-Vorrichtung, die einen beliebigen bestehenden und zukünftigen HBM-Standard implementiert, einschließlich HBM, HBM2, HBM2E, HBM3 und HBM-PIM. In einer alternativen Konfiguration weist die CPU 304 eine oder mehrere Speichersteuerungen auf, die mit DRAM oder SDRAM gekoppelt sind. Die CPU 304 weist auch andere Komponenten und Blöcke auf, die in modernen Prozessoren/SoC-Architektur gängig sind, einschließlich mehrerer Kerne und einer Cache-Hierarchie, die der Einfachheit halber nicht gezeigt sind.
Allgemein wird die CPU 304 verwendet, um Plattformsoftware auszuführen, die ein Betriebssystem und zugehörige Komponenten umfasst, die zum Ausführen einer oder mehrerer Anwendungen verwendet werden. Die Plattformsoftware kann auch in einer virtuellen Ausführungsumgebung, die einen Typ-1- oder Typ-2-Hypervisor einsetzt, oder in einer containerbasierten Ausführungsumgebung eingesetzt werden.
Die IPU 306 beinhaltet eine Operatorattestierungs- und -validierungslogik 320, eine Operatorausführungslogik 322 und eine Überwachungs- und bedingte Operatorauslöselogik 324. Die IPU 306 wird in Verbindung mit einem TOM 325 verwendet, das Attestierungs-Hash-Werte (oder Digests, die die Hash-Werte enthalten, die mit anderen Daten, wie etwa Operator-IDs und optionalen Operator-Metadaten, verkettet sind) unter Verwendung eines Zertifikats 327 signiert. Das Zertifikat 327 ist beispielhaft für ein oder mehrere Zertifikate, die Zertifikate, die vom TOM 325 erzeugt und/oder verwendet werden, und Zertifikate, die entweder der IPU 306 oder der Plattform 302 bereitgestellt werden, beinhalten können. Bei alternativen Ausführungsformen ist das TOM 325 eine separate Komponente (wie gezeigt) oder in die IPU 306 integriert.
Der Operatorattestierungsdienst 308 beinhaltet einen oder mehrere sichere IP-Server 326, die über einen sicheren Authentifizierungskanal 328 in Kommunikationsverbindung mit der Plattform 302 stehen. Kommunikationen, die über einen sicheren authentifizierten Kanal 330 ausgetauscht werden, werden verwendet, um eine Operatorattestierung 330 unter Verwendung von Zertifikaten 332 durchzuführen.
Der Operatorkatalog 310 umfasst einen Katalog (z. B. eine Datenbank) von Operatoren, die von einem oder mehreren sicheren IP-Servern 334 gehostet werden, die über einen sicheren authentifizierten Kanal 336 in Kommunikationsverbindung mit der Plattform 302 stehen. Ein Pull-Operator 338, der über einen sicheren authentifizierten Kanal 336 implementiert ist, wird verwendet, um (Pull-)Operatoren) aus dem Operatorkatalog 310 zu beziehen/abzurufen. Der/die sichere(n) IP-Server 334 verwendet/verwenden auch Zertifikate 340.
Während Laufzeitoperationen kann die IPU 306 Eingaben von einem externen Server oder Knoten, Orchestrator, MANO oder dergleichen empfangen, wie etwa durch eine DeployOperator-Eingabe 342 veranschaulicht, die eine Operatorkennung (ID) und Parameter enthält, die die IPU anweisen, einen Operator einzusetzen. Die IPU 306 kann auch Operatorflüsse 344 empfangen, die Befehle zum Ausführen eines bestimmten Operators oder zum Durchführen einer bestimmten Operation mit einem Operator enthalten. In einigen Ausführungsformen ist auch die Version des Operators enthalten.
Zusätzlich zum Einsetzen von Operatoren auf Rechenplattformen mit CPUs können die hierin offenbarten Lehren und Prinzipien auf andere Prozessor-/Verarbeitungseinheiten (zusammenfassend als XPUs bezeichnet) angewendet werden, einschließlich einem oder mehreren von Grafikprozessoreinheiten (GPUs, Graphic Processor Units) oder Allzweck-GPUs (GP-GPUs, General Purpose GPUs), Tensor-Verarbeitungseinheit (TPU, Tensor Processing Unit), Datenprozessoreinheiten (DPUs, Data Processor Units), Künstliche-Intelligenz(KI)-Prozessoren oder KI-Inferenzeinheiten und/oder andere Beschleuniger, FPGAs und/oder andere programmierbare Logik (die zu Rechenzwecken verwendet wird) usw. Obwohl einige der Diagramme hier die Verwendung von CPUs zeigen, ist dies lediglich beispielhaft und nicht einschränkend. Allgemein kann bei den veranschaulichten Ausführungsformen eine beliebige Art von XPU anstelle einer CPU verwendet werden. Dementsprechend wird, wie in den folgenden Ansprüchen verwendet, der Begriff „Prozessoreinheit“ verwendet, um CPUs und verschiedene Formen von XPUs generisch abzudecken.
3a zeigt eine Architektur 300a, die eine Plattform 302a aufweist, die eine XPU 305 anstelle der CPU 304 in der Plattform 302 von 3 aufweist. In einer Ausführungsform weist die XPU 305 einen CXL-Hub 312 auf, der mit einem oder mehreren CXL-DIMMs 314 gekoppelt ist. In einer anderen Ausführungsform weist die XPU 305 keinen CXL-Hub auf, der mit CXL-DIMMs gekoppelt ist.
Eine Rechenplattform kann auch eine CPU in Kombination mit einer XPU oder mehrere CPUs und/oder XPUs aufweisen. 3b zeigt ein Beispiel für eine Plattform 302b, die eine CPU 304 und eine XPU 305 aufweist. Wie oben kann die XPU 305 einen CXL-Hub 312 und CXL-DIMMs 314 aufweisen oder nicht.
Im Allgemeinen kann die IPU 306 gemäß den Ausführungsformen der 3a und 3b zur Attestierung und Validierung von Operatoren verwendet werden, die auf der IPU ausgeführt werden sollen und/oder auf der XPU 305 (und der CPU 304 für die Plattform 302a) ausgeführt werden sollen. Verschiedene Arten von Operatoren können unter Verwendung verschiedener Arten von XPUs eingesetzt werden, einschließlich, jedoch nicht beschränkt auf softwarebasierte Operatoren und Bitströme, die zum Programmieren von FPGAs oder anderen Arten programmierbarer Logikvorrichtungen verwendet werden.
4 zeigt eine Architektur 400, die sich auf weitere Details der IPU 306 konzentriert und darauf, wie sie eine Attestierung von Operatoren und anderen Funktionen durchführt. Die IPU 306 weist nun ferner eine Serverkonfigurationslogik 402, Operator-Mandantenregeln 404, die eine assoziierte Operator-Mandantenregel-Tabelle 406 verwenden, und einen Operator-Cache 408, der eine Operator-Cache-Tabelle 410 verwendet, auf.
Die Serverkonfigurationslogik 402 weist eine Schnittstelle auf, die es der IPU 306 ermöglicht, den oder die sicheren Server zu konfigurieren, die zum Attestieren der Operatoren verwendet werden können, die durch die IPU ausgeführt oder geleitet werden, wie durch die sicheren IP-Server 326 und 334 dargestellt. In einer Ausführungsform beinhaltet dies eine IP-Adresse für den bzw. die sicheren Server und ein Zertifikat zum Validieren der Attestierungsergebnisse. Die Serverkonfigurationslogik 402 wird auch verwendet, um authentifizierte Kanäle 328 und 336 einzurichten, wie in dem Flussdiagramm 500 von 5 gezeigt.
In einigen Ausführungsformen verwendet ein authentifizierter Kanal einen verschlüsselten Kanal unter Verwendung von SSL (Secure Sockets Layer). In einer anderen Ausführungsform umfasst ein authentifizierter Kanal eine VPN-Verbindung (Virtual Private Network, virtuelles Privatnetz), die unter Verwendung bekannter Techniken hergestellt wird. In einer Ausführungsform werden Nachrichten über einen authentifizierten Kanal unter Verwendung des HTTPS-Protokolls ausgetauscht.
In einer Ausführungsform wird ein authentifizierter Kanal, der SSL einsetzt, unter Verwendung eines TSL-Handshakes eingerichtet, wie in der Technik bekannt ist. Während der Plattforminitialisierung und/oder einer IPU-Bereitstellungsoperation werden der IPU IP-Adressen für sichere Server bereitgestellt, die für den Operatorattestierungsdienst und den Operatorkatalog verwendet werden, wie etwa durch die sicheren (IP-) Server 326 und 334 in den Figuren hierin dargestellt. In einem Block 502 initiiert die IPU eine Kommunikation mit einem sicheren Server, um einen authentifizierten Kanal zwischen der IPU und dem sicheren Server einzurichten. In einem Block 504 gibt der sichere Server sein SSL-Zertifikat an die IPU zurück. In einem Block 506 verifiziert die IPU das SSL-Zertifikat mit einer Zertifikatsautorität (betrieben durch einen externen Server und/oder Dienst, der in den Figuren hierin nicht gezeigt ist). Nach der Verifizierung des SSL-Zertifikats erzeugen die IPU und der sichere Server Sitzungsschlüssel, die für eine verschlüsselte Kommunikationssitzung über den authentifizierten Kanal verwendet werden sollen.
In einem optionalen Block 510 tauschen die IPU und der sichere Server öffentliche Schlüssel und/oder Zertifikate aus, die zum Authentifizieren von Nachrichten verwendet werden, die für die andere IPU und den sicheren Server gesendet werden. In einigen Ausführungsformen können die öffentlichen Schlüssel/Zertifikate der IPU und dem bzw. den sicheren Server(n) im Voraus bereitgestellt werden, in welchem Fall die Operation von Block 510 nicht verwendet wird.
Es wird erneut Bezug genommen auf 4; die Operator-Mandantenregeln 404 beinhalten eine zweite Schnittstelle, die das Registrieren einer Operatorvalidierungsregel unterstützt. Die Validierungsregeln und eine assoziierte Mandanten-ID sowie ein(e) Operatortyp/-ID sind in der Operator-Mandantenregel-Tabelle 406 gespeichert. Eine Validierungsregel ist etwas, das der Infrastruktureigentümer registrieren kann, um zu entscheiden, welche Operatoren und welche speziellen Operationen innerhalb eines bestimmten Operators (Typ der Operatorausführung oder Benutzerausführung eines bestimmten Operators) durchgeführt werden können. In einer Ausführungsform beinhaltet dies:

1. Die ID für den Mandanten, für den die Regel gilt. Sie kann auf spezifische Mandanten oder Benutzer zugeschnitten sein. Oder sie kann für jeden Benutzer gelten, der einen bestimmten Operator durchführt. Die Mandanten-ID wird im Feld TENANT ID (Mandanten-ID) der Operator-Mandantenregel-Tabelle 406 gespeichert.
2. Die Operator-ID oder den Operatortyp. Dies stellt eine Möglichkeit bereit zu identifizieren, wann die betreffende Regel ausgeführt werden muss. Dies kann entweder eine bestimmte Operator-ID oder ein bestimmter Operatortyp sein. Ein Operatortyp kann etwas sein, das durch den Operatoreigentümer oder -anbieter festgelegt wird. Eine Operator-ID oder ein Operatortypwert ist im Feld OPERATOR TYPE/ID (Operatortyp/-ID) der Operator-Mandantenregel-Tabelle 406 gespeichert.
3. Die Regel, die ausgeführt werden muss, um Operationen oder die Operatorausführung zu validieren, wenn sie erkannt werden. In einer Ausführungsform kann die Regel eine boolesche Regel sein, die auf die Felder oder Metadaten angewendet wird, die mit dem Operator einhergehen (z. B. Operatortyp, Benutzer usw.), oder sie kann etwas Komplexeres sein, etwa binär, das ausgeführt werden soll. In diesem letzteren Fall wird in die Regel eingefügt, wann die Regel mit einer Operatoranforderung ausgeführt werden muss.

Im Beispiel der Operator-Mandantenregel-Tabelle 406 in 4 ist die Validierungsregel eine boolesche Regel, die angibt, ob der Operator auf der IPU oder der Plattform (z. B. CPU oder XPU auf der Plattform) ausgeführt werden soll. In diesem Beispiel ist die IPU fett gedruckt, was anzeigt, dass die Regel angibt, dass der Operator mit einem ID-Typ 0x32 auf der IPU ausgeführt werden soll.
Die IPU 306 weist auch eine Anwendungsprogrammschnittstelle (API, Application Program Interface) auf, die ermöglicht, die Ausführung eines bestimmten Operators anzufordern. In einer Ausführungsform beinhaltet diese Schnittstelle:

1. Metadaten, die mit der Anforderung verknüpft sind. Z. B. Benutzer, der die Ausführung anfordert, Zertifikat des Benutzers und Signatur der Anforderung.
2. Den auszuführenden Operator. Dies kann entweder die Operator-UUID oder der Operator selbst (z. B. ein Ansible-Skript) sein.

Der Operator-Cache 408 wird verwendet, um die verschiedenen Operatoren zwischenzuspeichern, die im Laufe der Zeit unter Verwendung der dritten Schnittstelle ausgeführt werden. In einer Ausführungsform wird dieser Cache eine Liste von Operatoren enthalten mit:

1. Der Mandanten-ID, die sich auf den Operator bezieht, die im Feld TENANT ID (Mandanten-ID9 gespeichert ist.
2. Die Operator-UUID (Unique Universal Identifier, eindeutige universelle Kennung), die im OPERATOR-ID-Feld gespeichert ist.
3. Den Operator selbst (der binär sein kann usw.), der im Feld OPERATOR gespeichert ist.
4. Optional kann die Operator-Cache-Tabelle 410 andere Felder beinhalten, wie etwa den Ablauf innerhalb des Caches usw.

Die Operatorattestierungs- und -validierungslogik 320 ist für das Validieren von Operatoren und/oder assoziierten Operationen verantwortlich, indem eine clientseitige Attestierungs- und Validierungsoperation in Zusammenwirken mit einem Operatorattestierungsdienst durchgeführt wird, in dem serverseitige Attestierungs- und Validierungsoperationen durchgeführt werden. Diese Logik ist für das Attestieren und Validieren eines bestimmten Operators oder einer Operation innerhalb eines Operators oder eines Operatorflusses verantwortlich, der/die durch eine bestimmte Quelle instanziiert wird.
In einer Ausführungsform ist der Prozess zum Attestieren und Validieren eines bestimmten Operators oder einer bestimmten Operation innerhalb eines Operators oder Operatorflusses, der/die durch eine bestimmte Quelle instanziiert wird, in dem Flussdiagramm 600 von 6 gezeigt. Der Prozess beginnt mit einem Startblock 602, in dem eine neue Operatoranforderung identifiziert wird. In einem Block 604 wird der auszuführende Operator und/oder die auszuführende Operation identifiziert. In einem Block 606 wird ein Hash-Wert berechnet, der mit dem auszuführenden Operator und/oder der auszuführenden Operation verknüpft ist. Zum Beispiel wird in einer Ausführungsform der Hash-Wert über den Operator- und/oder Operationscode berechnet, der eine beliebige Nutzlast beinhaltet (falls eine solche vorhanden ist). In einem Block 608 verbindet sich die Attestierungs- und Validierungslogik mit dem Operatorattestierungsdienst und fordert eine Attestierung des auszuführenden Operators und/oder der auszuführenden Operation an. Bei einer Ausführungsform wird die Verbindung auf die oben im Flussdiagramm 500 von 5 beschriebene Weise hergestellt. Die Operator/Operations-ID zusammen mit dem Hash-Wert wird dann in einer Nachricht (separat oder in einem Digest) an den Operatorattestierungsdienst gesendet. Falls ein Zertifikataustausch in Verbindung mit dem Einrichten des authentifizierten Kanals durchgeführt wurde, kann der Digest mit dem Zertifikat für die IPU oder einem Zertifikat für die Plattform oder den Knoten signiert werden.
In einem Block 610 extrahiert der Operatorattestierungsdienst die ID und den Hash-Wert aus der Nachricht, wobei optional seine Kopie des Zertifikats oder des öffentlichen Schlüssels verwendet wird, um den Digest zu codieren, falls der Digest unter Verwendung des Plattform-/Knotenzertifikats signiert wurde. Die ID wird als ein Nachschlagen in einer Hash-Tabelle verwendet, die bei dem Operatorattestierungsdienst gespeichert ist und Operator-/Operations-ID/Hash-Wert-Paare beinhaltet, wie weiter unten in 8 gezeigt und erörtert. Der Hash-Wert aus der Tabelle wird zurückgegeben und mit dem Hash-Wert in der Nachricht verglichen. Wie in einem Entscheidungsblock 612 dargestellt, wird bestimmt, ob die Hash-Werte übereinstimmen. Falls sie übereinstimmen, ist die Antwort auf den Entscheidungsblock 612 JA, und die Logik geht zu einem Block 614 über, der anzeigt, dass der Operator vertrauenswürdig ist. Falls die Antwort auf den Entscheidungsblock 612 NEIN ist, wird der Operator zurückgewiesen, wie in einem Block 616 gezeigt. Anschließend wird das Attestierungsergebnis von vertrauenswürdig oder zurückgewiesen in einem Endblock 618 als eine Nachricht an den Anforderer zurückgegeben, die (optional) mit dem Zertifikat des sicheren Servers signiert sein kann.
Die Operatorausführungslogik 322 ist für das Durchführen der Ausführung eines Operators und/oder einer Operation eines Operators verantwortlich. Bei einer neuen Operatoranforderung führt sie die Operation und Logik durch, die im Flussdiagramm 700 von 7 gezeigt sind.
Wie gezeigt, wird in einem Startblock 702 eine neue Operatoranforderung empfangen. In diesem Beispiel wird eine DeployOperator (Operator einsetzen)-Nachricht empfangen, die eine Operator-ID und anwendbare Parameter beinhaltet. In einigen Fällen kann der neue Operator selbst durch die Quelle mit der Anforderung bereitgestellt werden. In einem Entscheidungsblock 704 wird bestimmt, ob der Operator durch die Quelle bereitgestellt wird. Wenn ja, wird die Antwort auf den Entscheidungsblock 704 JA sein, und die Logik geht zu Block 710 über, um den Operator zu validieren.
Als Nächstes wird bestimmt, ob sich der Operator im Operator-Cache befindet. Falls die Antwort NEIN ist, geht die Logik zu Block 708 über. Falls sich der Operator im Operator-Cache befindet, geht die Logik zu einem Entscheidungsblock 712 über. In einer anderen Ausführungsform wird die Reihenfolge der Entscheidungsblöcke 704 und 706 umgekehrt.
In Block 706 wird der Operator aus dem Operatorkatalog bezogen, indem eine Nachricht über den authentifizierten Kanal 336 an den IP-Server 334 mit der in Startblock 702 bereitgestellten Operator-ID gesendet wird. Die Nachricht kann optional mit der IPU oder dem Plattform-/Knotenzertifikat signiert werden. Der Operatorkatalog extrahiert die ID aus der Nachricht, wobei optional die Nachricht mit ihrer Kopie des Plattformknotenzertifikats oder des zugehörigen öffentlichen Schlüssels authentifiziert wird. Der Operatorkatalog schlägt die ID in seiner Datenbank von Operatoren nach und gibt den Operator in einer Antwortnachricht über den authentifizierten Kanal 336 zurück, falls ein Operator mit der ID gefunden wird.
In Block 710 wird der Operator durch die Operatorattestierungs- und - validierungslogik 320 validiert, indem die Operationen und die Logik in dem oben besprochenen Flussdiagramm 600 implementiert werden. Die verbleibenden Operationen setzen voraus, dass das Attestierungsergebnis anzeigt, dass der Operator vertrauenswürdig ist.
In Entscheidungsblock 712 wird bestimmt, ob eine Regel mit dem Operator assoziiert ist (entweder Mandant oder Mandant plus Operator). Falls es eine assoziierte Regel gibt, wird die Regel zum Bereitstellen des Operators in einem Block 714 ausgeführt. Falls es keine assoziierte Regel gibt, geht die Logik zu einem Entscheidungsblock 716 mit einem Ergebnis einer erfolgreichen Ausführung über.
In Entscheidungsblock 716 wird bestimmt, ob die Ausführung der Regel, die den Operator bereitstellt, erfolgreich ist. Falls nicht, geht die Logik zu einem Endblock 718 über, in dem der Operator zurückgewiesen wird. Wenn die Ausführung der Regel, die den Operator bereitstellt, erfolgreich ist, fährt die Logik fort, den Operator in einem Endblock 720 auszuführen, wenn der Operator bereitgestellt oder bezogen wurde. Falls der Operator durch eine Plattformquelle bereitgestellt wird, wird eine spezifische Operation des Operators in einem Endblock 722 ausgeführt. Wie oben erörtert, kann in Abhängigkeit von der Validierungsregel in der Operator-Mandantenregel-Tabelle 406 (und falls zutreffend) der Operator oder eine spezifische Operation auf der IPU ausgeführt werden oder kann auf der Plattform-CPU oder XPU ausgeführt werden.
8 zeigt weitere Details der Komponenten, die durch den Operatorattestierungsdienst 308 und den Operatorkatalog 310 verwendet werden, gemäß einer Ausführungsform. Der Operatorattestierungsdienst 308 wird unter Verwendung eines oder mehrerer sicherer IP-Server 326 implementiert, die entweder einen Satz von Zertifikaten 332 aufweisen oder Zugriff auf einen gemeinsam genutzten Satz von Zertifikaten 332 haben.
Die Komponenten auf einem sicheren IP-Server 326 beinhalten eine Schnittstelle 800, eine Operatorattestierungs- und -validierungslogik 802 und eine Operatorattestierungsdatenbank (DB) 804. Die Schnittstelle 800 wird verwendet, um den authentifizierten Kanal 328 einzurichten und Nachrichten über den authentifizierten Kanal 328 zu senden und zu empfangen (einschließlich optionaler Verwendung von Zertifikaten, die zum Signieren von Digests in Nachrichten und zum Entschlüsseln von signierten Digests verwendet werden). In einer Ausführungsform kann die Schnittstelle 800 in einem HTTPS-Server implementiert sein.
Die Operatorattestierungs- und -validierungslogik 802 ist das Gegenstück zu der Operatorattestierungs- und -validierungslogik 320 und führt die dienstseitigen Attestierungs- und Validierungsoperationen durch. Allgemein kann die Operatorattestierungs- und - validierungslogik 802 als eine Softwareanwendung oder ein Dienst in einem sicheren IP-Server 326 implementiert sein. Die Operatorattestierungs-DB 804 umfasst eine Datenbank von Operatorattestierungsdaten, die auf einem sicheren IP-Server 326 gehostet ist (oder anderweitig auf einem separaten Server gehostet ist, auf den ein sicherer IP-Server 326 zugreift). Die Operatorattestierungs-DB 804 beinhaltet eine Tabelle 806 mit einem UUID-Feld 808, das eine ID enthält, einem Feld TYPE (Typ) 810, das eine Typ-ID enthält, einem Feld PROVIDER (Anbieter) 812, das eine Anbieter-ID enthält, die mit einem Zertifikat verkettet ist, und einem Feld HASH 814, das einen Hash-Wert enthält.
Der Operatorkatalog 310 wird unter Verwendung eines oder mehrerer sicherer IP-Server 334 implementiert, die entweder einen Satz von Zertifikaten 340 aufweisen oder Zugriff auf einen gemeinsam genutzten Satz von Zertifikaten 340 haben. Die Komponenten auf einem sicheren IP-Server 334 beinhalten eine Schnittstelle 816 und eine Katalog-DB 818. Die Schnittstelle 816 wird verwendet, um den authentifizierten Kanal 336 einzurichten und Nachrichten über den authentifizierten Kanal 336 zu senden und zu empfangen (einschließlich optionaler Verwendung von Zertifikaten, die zum Signieren von Digests verwendet werden, die in Nachrichten enthalten sind). In einer Ausführungsform kann die Schnittstelle 816 in einem HTTPS-Server implementiert sein.
Die Katalog-DB 818 beinhaltet eine Tabelle 820 mit einem UUID-Feld 822, das eine ID enthält, einem Feld TYPE (Typ) 824, das eine Typ-ID enthält, einem Feld PROVIDER (Anbieter) 826, das eine Verkettung einer Anbieter-ID und eines Anbieterzertifikats enthält, und einem Feld OPERATOR 828, das einen Operator, wie etwa ein Ansible-Skript, einen binären (maschinenausführbaren) Operator oder einen Bitstrom, der zum Programmieren einer FPGA oder eines ähnlichen Beschleunigers verwendet wird, enthält.
In einigen der vorstehenden Ausführungsformen wird ein Digest, der eine Operator-ID + einen Hash-Wert umfasst, erzeugt, unter Verwendung eines Zertifikats signiert und in einer Nachricht verkapselt. Bei einem optionalen Ansatz kann das Digest zusätzliche Metadaten für den Operator beinhalten, wie etwa Operatortyp, Operatorversion, Mandanteninformationen und/oder Anbieterinformationen.
Beispielhafte IPU/SmartNIC
9 zeigt eine beispielhafte IPU 900, die auch SmartNIC genannt werden kann, gemäß einer Ausführungsform. Die IPU 900 beinhaltet mehrere Komponenten, die mit einer Leiterplatte 901 gekoppelt sind. Die Komponenten beinhalten eine FPGA 902, die dazu programmiert sein kann, verschiedene hierin beschriebene Logik zu implementieren. Allgemein kann eine FPGA auf Daten zugreifen, die in einer oder mehreren Speichervorrichtungen gespeichert sind, wie etwa durch die Speichervorrichtungen 904 und 906 dargestellt. Wie nachstehend beschrieben, können verschiedene Arten von Speichervorrichtungen verwendet werden, einschließlich unter anderem DDR4- und DDR5-DIMMs (Dual Inline Memory Modules, zweireihige Speichermodule). Die FPGA kann auch Onboard-Speicher 908 beinhalten, in dem Daten gespeichert werden können.
In der veranschaulichten Ausführungsform beinhaltet die IPU 900 einen NIC-Chip 909 mit vier Netzwerkanschlüssen 910, die als Anschluss 1, Anschluss 2, Anschluss 3 bzw. Anschluss 4 bezeichnet sind. Daten können zwischen dem NIC-Chip 909 und der FPGA 902 unter Verwendung separater Verbindungen pro Netzwerkanschluss 910 oder unter Verwendung einer gemultiplexten Zwischenverbindung übertragen werden. In einer Ausführungsform verwendet der NIC-Chip 909 eine 40-GB/s-MAC, und jeder der vier Netzwerkanschlüsse 910 ist ein 10-GB/s-Anschluss. In anderen Ausführungsformen kann der NIC-Chip 909 eine MAC mit anderen Bandbreiten verwenden. Außerdem ist die veranschaulichte Verwendung von vier Anschlüssen lediglich beispielhaft und nicht einschränkend, da eine IPU verschiedene Anzahlen von Netzwerkanschlüssen aufweisen kann. In manchen Ausführungsformen kann eine IPU mehrere NIC-Chips aufweisen.
Die IPU 900 weist ferner einen CPU 912-Flash-Speicher 914, eine Baseboard-Verwaltungssteuerung (BMC, Baseboard Management Controller) 916, ein USB-Modul 918 und ein TOM 920 auf. Die CPU 912 kann verwendet werden, um eingebettete Software/Firmware oder dergleichen auszuführen. Der Flash-Speicher 914 kann verwendet werden, um Firmware und/oder andere Anweisungen und Daten auf eine nichtflüchtige Weise zu speichern. Andere Software kann über ein Netzwerk geladen werden, das mit einem oder mehreren der NIC-Anschlüsse gekoppelt ist.
In der veranschaulichten Ausführungsform weist die FPGA 902 eine PCIe-Schnittstelle auf, die mit einem PCIe-Edge-Verbinder verbunden ist, der ausgelegt ist, in einem PCIe-Erweiterungssteckplatz installiert zu werden. In einer Ausführungsform umfasst die PCIe-Schnittstelle eine 8-spurige (8x) PCIe-Schnittstelle 922. Andere PCIe-Schnittstellen-Spurbreiten können in anderen Ausführungsformen verwendet werden, einschließlich 16-spuriger (16x) PCIe-Schnittstellen.
In einigen Ausführungsformen ist ein Teil der FPGA-Schaltungsanordnung dazu programmiert, eines oder mehrere von Serverkonfigurationslogik 402, der Operatorattestierungs- und -validierungslogik 320 und der Operatorausführungslogik 322 zu implementieren. Optional kann eine ähnliche Logik über die Ausführung assoziierter Software/Firmware auf der CPU 912 implementiert werden. Andere Logik und Operationen, die in der vorstehenden Ausführungsform beschrieben sind, können unter Verwendung der FPGA 902, der CPU 912 oder einer Kombination der beiden implementiert werden. Eine FPGA-Schaltungsanordnung auf der FPGA 902 und/oder die Ausführung von eingebetteter Software/Firmware auf der CPU 912 können ebenfalls verwendet werden, um Operatoren zu implementieren/auszuführen.
Die Operator-Mandantenregeln 404 und der Operator-Cache 408 können in Abhängigkeit von der speziellen Implementierung im Speicher 904, 906 oder 908 gespeichert sein. Eine Sicherungskopie dieser Daten kann auch periodisch in den Flash 914 geschrieben werden.
Ein flüchtiger Arbeitsspeicher ist ein Arbeitsspeicher, dessen Zustand (und daher auch derjenige der darauf gespeicherten Daten) unbestimmt ist, falls die Stromzufuhr zur Vorrichtung unterbrochen ist. Ein dynamischer flüchtiger Arbeitsspeicher erfordert ein Auffrischen der in der Vorrichtung gespeicherten Daten, um den Zustand beizubehalten. Ein Beispiel eines dynamischen flüchtigen Arbeitsspeichers enthält DRAM (dynamischen Speicher mit wahlfreiem Zugriff) oder eine Variante wie synchronen DRAM (SDRAM). Ein Speichersubsystem, wie hierin beschrieben, kann mit einer Anzahl von Speichertechnologien kompatibel sein, wie etwa DDR3 (Double Data Rate Version 3, ursprüngliche Veröffentlichung durch JEDEC (Joint Electronic Device Engineering Council) am 27. Juni 2007). DDR4 (DDR-Version 4, Erstspezifikation im September 2012 von JEDEC veröffentlicht), DDR4E (DDR-Version 4), LPDDR3 (Niedrigenergie-DDR-Version 3, JESD209-3B, August 2013 von JEDEC), LPDDR4 (LPDDR-Version 4, JESD209-4, ursprünglich von JEDEC im August 2014 veröffentlicht), WIO2 (Wide Input/Output-Version 2, JESD229-2, ursprünglich von JEDEC im August 2014 veröffentlicht, HBM (Speicher mit hoher Bandbreite, JESD235, ursprünglich von JEDEC im Oktober 2013 veröffentlicht), DDR5 (DDR-Version 5), LPDDR5, HBM2E, HBM3 und HBM-PIM und/oder andere oder Kombinationen von Speichertechnologien und Technologien, die auf Derivaten oder Erweiterungen dieser Spezifikationen basieren. Die JEDEC-Standards sind auf www.jedec.org verfügbar.
Eine nichtflüchtige Arbeitsspeichervorrichtung (NVM-Vorrichtung) ist ein Arbeitsspeicher, dessen Zustand bestimmt ist, auch wenn die Stromzufuhr zur Vorrichtung unterbrochen ist. Bei einer Ausführungsform kann die NVM-Vorrichtung eine blockadressierbare Speichervorrichtung umfassen, wie etwa NAND-Technologien oder, genauer gesagt, NAND-Flash-Speicher mit mehreren Schwellenpegeln (zum Beispiel Single-Level Cell („SLC“), Multi-Level Cell („MLC“), Quad-Level Cell („QLC“), Tri-Level-Cell („TLC“) oder ein beliebiges anderes NAND). Eine NVM-Vorrichtung kann auch eine byteadressierbare, dreidimensionale in situ beschreibbare Koppelpunkt-Arbeitsspeichervorrichtung oder andere byteadressierbare in situ beschreibbare NVM-Vorrichtungen (auch als ein persistenter Arbeitsspeicher bezeichnet), wie Phasenwechselspeicher (PCM) mit einem oder mehreren Pegeln oder Phasenwechselspeicher mit einem Schalter (PCMS), NVM-Vorrichtungen, die Chalkogen-Phasenwechselmaterial (zum Beispiel Chalkogenglas) verwenden, einen resistiven Arbeitsspeicher, einschließlich auf Metalloxidbasis, Sauerstofffehlstellenbasis und Leiterbrückenarbeitsspeicher mit wahlfreiem Zugriff (CB-RAM), Nanodrahtarbeitsspeicher, ferroelektrischen Arbeitsspeicher mit wahlfreiem Zugriff (FeRAM, FRAM), magnetoresistiven Arbeitsspeicher mit wahlfreiem Zugriff (MRAM), der Memristortechnologie einbindet, Spin-Transfer-Torque(STT)-MRAM, eine Vorrichtung auf Spintronik-Magnetübergangs-Arbeitsspeicherbasis, eine Vorrichtung auf Magnettunnelübergangsbasis (MTJ-Basis), eine Vorrichtung auf Domänenwand(DW)- und SOT(Spin-Orbit-Transfer)-Basis, eine Arbeitsspeichervorrichtung auf Thyristorbasis oder eine Kombination von beliebigen der obigen oder einen anderen Arbeitsspeicher beinhalten.
Obwohl manche Ausführungsformen unter Bezugnahme auf bestimmte Implementierungen beschrieben wurden, sind andere Implementierungen gemäß manchen Ausführungsformen möglich. Außerdem muss bzw. müssen die Anordnung und/oder die Reihenfolge von Elementen oder anderen Merkmalen, die in den Zeichnungen veranschaulicht sind und/oder hierin beschrieben sind, nicht auf die bestimmte veranschaulichte und beschriebene Weise angeordnet sein. Gemäß einigen Ausführungsformen sind viele andere Anordnungen möglich.
In jedem in einer Figur gezeigten System können die Elemente in einigen Fällen jeweils eine gleiche Bezugsziffer oder eine unterschiedliche Bezugsziffer aufweisen, um darauf hinzuweisen, dass die dargestellten Elemente unterschiedlich und/oder ähnlich sein könnten. Jedoch kann ein Element flexibel genug sein, um unterschiedliche Implementierungen aufzuweisen und mit einigen oder allen der hierin gezeigten oder beschriebenen Systeme zu arbeiten. Die in den Figuren gezeigten verschiedenen Elemente können gleich oder unterschiedlich sein. Welches als ein erstes Element bezeichnet wird und welches ein zweites Element genannt wird, ist willkürlich.
In der Beschreibung und den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ sowie Ableitungen davon verwendet werden. Es sollte klar sein, dass diese Begriffe nicht als Synonyme füreinander gedacht sind. Vielmehr kann in bestimmten Ausführungsformen „verbunden“ verwendet werden, um anzuzeigen, dass zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt miteinander sind. „Gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt stehen. „Gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander stehen, aber dennoch zusammenwirken oder miteinander interagieren. Zusätzlich bedeutet „kommunikationsfähig gekoppelt“, dass zwei oder mehr Elemente, die sich in direktem Kontakt miteinander befinden können oder nicht, in der Lage sind, miteinander zu kommunizieren. Falls beispielsweise die Komponente A mit der Komponente B verbunden ist, die wiederum mit der Komponente C verbunden ist, kann die Komponente A mit der Komponente C unter Verwendung der Komponente B als Zwischenkomponente kommunikationsfähig gekoppelt sein.
Eine Ausführungsform ist eine Implementierung oder ein Beispiel der Erfindungen. Ein Verweis in der Beschreibung auf „eine Ausführungsform“, „manche Ausführungsformen“ oder „andere Ausführungsformen“ bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Charakteristik, das bzw. die in Verbindung mit den Ausführungsformen beschrieben ist, in zumindest manchen Ausführungsformen, aber nicht notwendigerweise allen Ausführungsformen der Erfindungen vorhanden ist. Die verschiedenen Vorkommen von „einer Ausführungsform“ oder „manchen Ausführungsformen“ beziehen sich nicht notwendigerweise alle auf dieselben Ausführungsformen.
Nicht alle hier beschriebenen und veranschaulichten Komponenten, Merkmale, Strukturen, Charakteristiken usw. müssen in einer speziellen Ausführungsform oder speziellen Ausführungsformen vorhanden sein. Wenn in dieser Beschreibung angegeben ist, dass eine Komponente, ein Merkmal, eine Struktur oder eine Eigenschaft vorhanden sein „kann“, „könnte“ oder „möglicherweise“ vorhanden ist, muss diese Komponente, dieses Merkmal, diese Struktur oder diese Eigenschaft nicht unbedingt vorhanden sein. Falls sich die Beschreibung oder der Anspruch auf „ein“ Element bezieht, bedeutet dies nicht, dass nur eines der Elemente vorhanden ist. Falls sich die Beschreibung oder der Anspruch auf „ein zusätzliches“ Element bezieht, schließt dies nicht aus, dass es mehr als eines des zusätzlichen Elements gibt.
Wie oben besprochen, können verschiedene Aspekte der Ausführungsformen hierin durch entsprechende Software- und/oder Firmwarekomponenten und -anwendungen wie etwa durch Software und/oder Firmware, die durch einen eingebetteten Prozessor oder dergleichen ausgeführt wird, ermöglicht werden. Somit können Ausführungsformen dieser Erfindung als oder zur Unterstützung eines Softwareprogramms, von Softwaremodulen, Firmware und/oder verteilter Software verwendet werden, die in irgendeiner Form von Prozessor, Verarbeitungskern oder eingebetteter Logik oder einer virtuellen Maschine, die auf einem Prozessorkern läuft, ausgeführt werden oder anderweitig auf oder innerhalb eines nichtflüchtigen computerlesbaren oder maschinenlesbaren Speichermediums implementiert oder realisiert sind. Ein nichtflüchtiges computerlesbares oder maschinenlesbares Speichermedium beinhaltet einen beliebigen Mechanismus zum Speichern oder Übertragen von Informationen in einer Form, die von einer Maschine (z. B. einem Computer) gelesen werden kann. Zum Beispiel beinhaltet ein nichtflüchtiges computerlesbares oder maschinenlesbares Speichermedium einen beliebigen Mechanismus, der Informationen in einer Form bereitstellt (d. h. speichert und/oder überträgt), auf die ein Computer oder eine Rechenmaschine (z. B. Rechenvorrichtung, elektronisches System usw.) zugreifen kann, wie etwa beschreibbare/nicht beschreibbare Medien (z. B. Nur-Lese-Speicher (ROM, Read Only Memory), Direktzugriffsspeicher (RAM, Random Access Memory), Magnetplattenspeichermedien, optische Speichermedien, Flash-Speichervorrichtungen usw.). Der Inhalt kann direkt ausführbar („Objekt“- oder „ausführbare“ Form), Quellcode oder Differenzcode („Delta“- oder „Patch“-Code) sein. Ein nichtflüchtiges computerlesbares oder maschinenlesbares Speichermedium kann auch einen Speicher oder eine Datenbank einschließen, aus dem/der ein Inhalt heruntergeladen werden kann. Das nichtflüchtige computerlesbare oder maschinenlesbare Speichermedium kann auch eine Vorrichtung oder ein Produkt einschließen, auf der/dem zum Zeitpunkt des Verkaufs oder der Lieferung Inhalte gespeichert sind. Somit kann das Liefern einer Vorrichtung mit gespeicherten Inhalten oder das Anbieten von Inhalten zum Herunterladen über ein Kommunikationsmedium so verstanden werden, dass ein Herstellungsartikel bereitgestellt wird, der ein nichtflüchtiges computerlesbares oder maschinenlesbares Speichermedium mit einem solchen hierin beschriebenen Inhalt umfasst.
Die durch verschiedene hierin beschriebene Komponenten durchgeführten Operationen und Funktionen können durch Software, die auf einem Verarbeitungselement läuft, über eingebettete Hardware oder dergleichen oder eine beliebige Kombination von Hardware und Software implementiert werden. Solche Komponenten können als Softwaremodule, Hardwaremodule, Spezialhardware (z. B. anwendungsspezifische Hardware, ASICs, DSPs usw.), eingebettete Steuerungen, festverdrahtete Schaltungsanordnungen, Hardwarelogik usw. implementiert sein. Softwareinhalt (z. B. Daten, Anweisungen, Konfigurationsinformationen usw.) kann über einen Herstellungsartikel bereitgestellt werden, der ein nichtflüchtiges computerlesbares oder maschinenlesbares Speichermedium beinhaltet, das Inhalt bereitstellt, der Anweisungen repräsentiert, die ausgeführt werden können. Der Inhalt kann dazu führen, dass ein Computer verschiedene hierin beschriebene Funktionen/Operationen durchführt.
Wie hierin verwendet, kann eine Auflistung von durch den Ausdruck „mindestens eines von“ verbundenen Gegenständen jede beliebige Kombination der aufgelisteten Begriffe bedeuten. Der Ausdruck „mindestens eines von A, B oder C“ kann A; B; C; A und B; A und C; B und C oder A, B und C bedeuten.
Die obige Beschreibung veranschaulichter Ausführungsformen der Erfindung, einschließlich dessen, was in der Zusammenfassung beschrieben ist, soll nicht erschöpfend sein oder die Erfindung auf die offenbarten präzisen Formen beschränken. Obgleich hierin spezifische Ausführungsformen und Beispiele für die Erfindung zu Veranschaulichungszwecken beschrieben sind, sind verschiedene äquivalente Modifikationen innerhalb des Schutzumfangs der Erfindung möglich, wie Fachleute auf dem betreffenden Gebiet erkennen werden.
Diese Modifikationen an der Erfindung können vor dem Hintergrund der vorstehenden ausführlichen Beschreibung realisiert werden. Die in den folgenden Ansprüchen verwendeten Begriffe sollten nicht so aufgefasst werden, dass sie die Erfindung auf die spezifischen Ausführungsformen beschränken, die in der Beschreibung und den Zeichnungen offenbart sind. Vielmehr soll der Umfang der Erfindung vollständig durch die folgenden Ansprüche bestimmt werden, die in Übereinstimmung mit etablierten Lehren der Anspruchsauslegung auszulegen sind.

Claims

Einrichtung, die dazu ausgelegt ist, in einer Rechenplattform implementiert zu werden, die mindestens eine Verarbeitungseinheit aufweist, wobei die Einrichtung eine Schaltungsanordnung und Logik umfasst zum: Durchführen von Attestierungsoperationen mit einem Operatorattestierungsdienst, der über einen ersten authentifizierten Kanal mit der Rechenplattform gekoppelt ist, um einen Operator zu validieren, der auf der Einrichtung oder einer Verarbeitungseinheit auf der Rechenplattform ausgeführt werden soll, wobei die Einrichtung mit dem Operatorattestierungsdienst zusammenwirkt, um die Gültigkeit des Operators zu attestieren; und wenn der Operator als gültig attestiert wird, entweder Ausführen des Operators oder Weiterleiten des Operators an die Verarbeitungseinheit, auf der der Operator ausgeführt werden soll.
Einrichtung nach Anspruch 1, wobei die Schaltungsanordnung und die Logik ferner ausgelegt sind zum: Einrichten eines zweiten authentifizierten Kanals, der zwischen die Plattform und einen Operatorkatalog gekoppelt ist, der eine Operatordatenbank aufweist, in der mehrere Operatoren gespeichert sind; Beziehen, aus dem Operatorkatalog, eines Operators durch Senden einer Nachricht, die eine Kennung (ID) für den Operator enthält, wobei der Operatorkatalog als Reaktion auf die Nachricht einen Operator zurückgibt, der der Operator-ID entspricht; und Durchführen von Attestierungsoperationen mit dem Operatorattestierungsdienst, um den Operator zu validieren, der aus dem Operatorkatalog bezogen wird.
Einrichtung nach Anspruch 1, wobei das Durchführen von Attestierungsoperationen umfasst: Berechnen eines Hash-Werts über Inhalt, der den Operator beinhaltet; Senden einer ersten Nachricht über den ersten authentifizierten Kanal an den Operatorattestierungsdienst, einschließlich des Hash-Werts und einer Operatorkennung (ID); und Empfangen einer zweiten Nachricht vom Operatorattestierungsdienst, die anzeigt, ob der Operator gültig ist.
Einrichtung nach Anspruch 3, wobei das Durchführen von Attestierungsoperationen ferner umfasst: Erzeugen eines Digest, das die Operator-ID und den Hash-Wert umfasst; Signieren des Digest mit einem Zertifikat, das entweder der Einrichtung oder der Plattform zugewiesen ist; und Verkapseln des signierten Digest in der ersten Nachricht.
Einrichtung nach Anspruch 1, wobei die Einrichtung dazu ausgelegt ist, in einer Rechenplattform implementiert zu werden, die in einer Mehrmandantenumgebung eingesetzt wird, ferner eine Schaltungsanordnung und Logik zum Aufrechterhalten und Durchsetzen eines Satzes von Operator-Mandantenregeln umfassend, wie sie auf Operatoren angewendet werden, die mit bestimmten Mandanten assoziiert sind, die auf der Einrichtung ausgeführt werden sollen oder auf einer Verarbeitungseinheit in der Plattform ausgeführt werden sollen.
Einrichtung nach Anspruch 1, die ferner eine Schaltungsanordnung und Logik zum Implementieren eines Operator-Caches umfasst, wobei der Operator-Cache verwendet wird, um Operatoren zwischenzuspeichern, die als gültige Operatoren attestiert wurden.
Einrichtung nach Anspruch 1, wobei die mindestens eine Verarbeitungseinheit eine andere Verarbeitungseinheit (XPU), die eine Grafikprozessoreinheit (GPU, Graphic Processor Unit), eine Allzweck-GPU (GP-GPU, General Purpose GPU), eine Tensor-Verarbeitungseinheit (TPU, Tensor Processing Unit), eine Datenprozessoreinheit (DPU, Data Processor Unit), einen Künstliche Intelligenz(KI) -Prozessor oder eine KI-Inferenzeinheit umfasst, und eine feldprogrammierbare Gatteranordnung (FPGA, Field Programmable Gate Array) umfasst.
Einrichtung nach Anspruch 1, wobei die Einrichtung mindestens einen Netzwerkadapter, eine Netzwerkschnittstellensteuerung und eine Infrastrukturverarbeitungseinheit (IPU, Infrastructure Processing Unit) umfasst.
Verfahren, das durch eine Einrichtung auf einer Rechenplattform, die eine oder mehrere von der Einrichtung getrennte Verarbeitungseinheiten aufweist, implementiert wird, umfassend: Durchführen von clientseitigen Attestierungsoperationen mit einem Operatorattestierungsdienst, der über einen ersten authentifizierten Kanal mit der Rechenplattform gekoppelt ist, um einen Operator zu validieren, der auf der Einrichtung oder einer Verarbeitungseinheit auf der Rechenplattform ausgeführt werden soll, wobei die Einrichtung mit dem Operatorattestierungsdienst zusammenwirkt, um die Gültigkeit des Operators zu attestieren; und wenn der Operator als gültig attestiert wird, entweder Ausführen des Operators oder Weiterleiten des Operators an die Verarbeitungseinheit, auf der der Operator ausgeführt werden soll.
Verfahren nach Anspruch 9, ferner umfassend: Einrichten eines zweiten authentifizierten Kanals, der zwischen die Plattform und einen Operatorkatalog gekoppelt ist, der eine Operatordatenbank aufweist, in der mehrere Operatoren gespeichert sind; Beziehen, aus dem Operatorkatalog, eines Operators durch Senden einer Nachricht, die eine Kennung (ID) für den Operator enthält, wobei der Operatorkatalog als Reaktion auf die Nachricht einen Operator zurückgibt, der der Operator-ID entspricht; und Durchführen von clientseitigen Attestierungsoperationen mit dem Operatorattestierungsdienst, um den Operator zu validieren, der aus dem Operatorkatalog bezogen wird.
Verfahren nach Anspruch 9, wobei das Durchführen von clientseitigen Attestierungsoperationen umfasst: Berechnen eines Hash-Werts über Inhalt, der den Operator beinhaltet; Senden einer ersten Nachricht über den ersten authentifizierten Kanal an den Operatorattestierungsdienst, einschließlich des Hash-Werts und einer Operatorkennung (ID); und Empfangen einer zweiten Nachricht vom Operatorattestierungsdienst, die anzeigt, ob der Operator gültig ist.
Verfahren nach Anspruch 11, wobei das Durchführen von clientseitigen Attestierungsoperationen ferner umfasst: Erzeugen eines Digest, das die Operator-ID und den Hash-Wert umfasst; Signieren des Digest mit einem Zertifikat, das entweder der Einrichtung oder der Plattform zugewiesen ist; und Verkapseln des signierten Digest in der ersten Nachricht.
Verfahren nach Anspruch 9, wobei die Einrichtung dazu ausgelegt ist, in einer Rechenplattform implementiert zu werden, die in einer Mehrmandantenumgebung eingesetzt wird, ferner das Aufrechterhalten und Durchsetzen eines Satzes von Operator-Mandantenregeln umfassend, wie sie auf Operatoren angewendet werden, die mit bestimmten Mandanten assoziiert sind, die auf der Einrichtung ausgeführt werden sollen oder auf einer Verarbeitungseinheit in der Plattform ausgeführt werden sollen.
Verfahren nach Anspruch 9, ferner das Implementieren eines Operator-Caches zum Speichern und Bereitstellen von Zugriff auf Operatoren, die als gültige Operatoren attestiert wurden, umfassend.
Verfahren nach Anspruch 9, wobei die mindestens eine Verarbeitungseinheit eine andere Verarbeitungseinheit (XPU), die eine Grafikprozessoreinheit (GPU, Graphic Processor Unit), eine Allzweck-GPU (GP-GPU, General Purpose GPU), eine Tensor-Verarbeitungseinheit (TPU, Tensor Processing Unit), eine Datenprozessoreinheit (DPU, Data Processor Unit), einen Künstliche-Intelligenz(KI) -Prozessor oder eine KI-Inferenzeinheit umfasst, und eine feldprogrammierbare Gatteranordnung (FPGA, Field Programmable Gate Array) umfasst.
Verfahren nach Anspruch 9, wobei die Einrichtung einen Netzwerkadapter oder eine Netzwerkschnittstellensteuerung umfasst.
Rechenplattform, umfassend: eine oder mehrere Verarbeitungseinheiten; eine Netzwerkschnittstellensteuerung (NIC, Network Interface Controller), die mit mindestens einer der ein oder mehreren Verarbeitungseinheiten gekoppelt ist, die eine Schaltungsanordnung und Logik umfasst zum: Durchführen von Attestierungsoperationen mit einem Operatorattestierungsdienst, der über einen ersten authentifizierten Kanal mit der Rechenplattform gekoppelt ist, um einen Operator zu validieren, der auf der Einrichtung oder einer Verarbeitungseinheit auf der Rechenplattform ausgeführt werden soll, wobei die Einrichtung mit dem Operatorattestierungsdienst zusammenwirkt, um die Gültigkeit des Operators zu attestieren; und wenn der Operator als gültig attestiert wird, entweder Ausführen des Operators oder Weiterleiten des Operators an die Verarbeitungseinheit, auf der der Operator ausgeführt werden soll.
Rechenplattform nach Anspruch 17, wobei die Schaltungsanordnung und die Logik auf der NIC ferner ausgelegt sind zum: Einrichten eines zweiten authentifizierten Kanals, der zwischen die Plattform und einen Operatorkatalog gekoppelt ist, der eine Operatordatenbank aufweist, in der mehrere Operatoren gespeichert sind; Beziehen, aus dem Operatorkatalog, eines Operators durch Senden einer Nachricht, die eine Kennung (ID) für den Operator enthält, wobei der Operatorkatalog als Reaktion auf die Nachricht einen Operator zurückgibt, der der Operator-ID entspricht; und Durchführen von Attestierungsoperationen mit dem Operatorattestierungsdienst, um den Operator zu validieren, der aus dem Operatorkatalog bezogen wird.
Rechenplattform nach Anspruch 17, wobei das Durchführen von Attestierungsoperationen umfasst: Berechnen eines Hash-Werts über Inhalt, der den Operator beinhaltet; Senden einer ersten Nachricht über den ersten authentifizierten Kanal an den Operatorattestierungsdienst, einschließlich des Hash-Werts und einer Operatorkennung (ID); und Empfangen einer zweiten Nachricht vom Operatorattestierungsdienst, die anzeigt, ob der Operator gültig ist.
Rechenplattform nach Anspruch 19, wobei das Durchführen von Attestierungsoperationen ferner umfasst: Erzeugen eines Digest, das die Operator-ID und den Hash-Wert umfasst; Signieren des Digest mit einem Zertifikat, das entweder der Einrichtung oder der Plattform zugewiesen ist; und Verkapseln des signierten Digest in der ersten Nachricht.