Method and system for validating kernel objects to be executed by a data processing accelerator of a host system

Abstract

According to one embodiment, the system receives a request from an application to call a predetermined function at a runtime library executed in a trusted execution environment (TEE) of a host system to perform a predetermined operation. In response to the request, the system identifies a kernel object associated with the predetermined function. The system uses a public key corresponding to a private key to confirm an executable image of the kernel object, wherein the private key is used to sign the executable image of the kernel object. In response to successfully confirming the executable image of the kernel object, the system transmits the executable image confirmed by the kernel object to a data processing (DP) accelerator via a bus for execution by the DP accelerator to perform the predetermined operation.

Description

Technical Field

[0001] Embodiments of the present invention generally relate to searching for content. More specifically, embodiments of the present invention relate to methods and systems for verifying / validating kernel objects to be executed by a data processing (DP) accelerator of a host system. Background Art

[0002] Sensitive transactions are increasingly being performed by data processing (DP) accelerators (e.g., artificial intelligence (AI) accelerators or coprocessors). This increases the need to secure the communication channel to the DP accelerator and to secure the host system's environment to protect the host system from unauthorized access.

[0003] For example, AI training data, models, and inference outputs may not be protected and therefore will be leaked to untrusted parties. Therefore, a system for protecting data processed by data processing accelerators is needed. Summary of the invention

[0004] In a first aspect, the present disclosure provides a computer-implemented method for verifying a kernel object to be executed by a data processing accelerator connected to a host system, the method comprising: receiving, at a runtime library executed within a trusted execution environment (TEE) of the host system, a request from an application to call a predetermined function to perform a predetermined operation; in response to the request, identifying a kernel object associated with the predetermined function; verifying the executable image of the kernel object using a public key corresponding to a private key used to sign the executable image of the kernel object; and in response to successfully confirming the executable image of the kernel object, transmitting the executable image confirmed by the kernel object to a data processing (DP) accelerator via a bus for execution by the DP accelerator to perform the predetermined operation.

[0005] In a second aspect, the present disclosure provides a non-transitory machine-readable medium having instructions stored therein, which instructions, when executed by a processor, cause the processor to perform operations, the operations including: receiving a request from an application to call a predetermined function at a runtime library executed within a trusted execution environment (TEE) of a host system to perform a predetermined operation; in response to the request, identifying a kernel object associated with the predetermined function; verifying the executable image of the kernel object using a public key corresponding to a private key used to sign the executable image of the kernel object; and in response to successfully confirming the executable image of the kernel object, transmitting the executable image confirmed by the kernel object to a data processing (DP) accelerator via a bus for execution by the DP accelerator to perform the predetermined operation.

[0006] In a third aspect, the present disclosure provides a host system comprising: a processor; and a memory connected to the processor to store instructions, which instructions, when executed by the processor, cause the processor to perform operations, the operations comprising: receiving a request from an application to call a predetermined function at a runtime library executed within a trusted execution environment (TEE) of the host system to perform a predetermined operation; in response to the request, identifying a kernel object associated with the predetermined function; verifying the executable image of the kernel object using a public key corresponding to a private key used to sign the executable image of the kernel object; and in response to successfully confirming the executable image of the kernel object, transmitting the executable image confirmed by the kernel object to a data processing (DP) accelerator via a bus for execution by the DP accelerator to perform the predetermined operation.

[0007] In a fourth aspect, the present disclosure provides a computer program product, including a computer program, which implements the following method when executed by a processor: receiving a request from an application to call a predetermined function to perform a predetermined operation at a runtime library executed within a trusted execution environment (TEE) of a host system; identifying a kernel object associated with the predetermined function in response to the request; verifying the executable image of the kernel object using a public key corresponding to a private key used to sign the executable image of the kernel object; and in response to successfully confirming the executable image of the kernel object, transmitting the executable image confirmed by the kernel object to a data processing (DP) accelerator via a bus for execution by the DP accelerator to perform the predetermined operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Embodiments of the invention are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.

[0009] Figure 1 is a block diagram illustrating an example of a system configuration for ensuring communications between a host and a data processing (DP) accelerator according to some embodiments.

[0010] Figure 2 is a block diagram illustrating an example of a multi-layered protection solution for securing communications between a host and a data processing (DP) accelerator, according to some implementations.

[0011] Figure 3 is a flow chart illustrating an example of a method according to one embodiment.

[0012] Figure 4 is a block diagram illustrating an example of a host with an I / O manager according to one embodiment.

[0013] Figure 5 is a block diagram illustrating an example of an I / O manager communicating with a DP accelerator according to some implementations.

[0014] Figure 6 is a block diagram illustrating memory regions allocated to multiple DP accelerators according to one embodiment.

[0015] Figure 7 is a block diagram illustrating exemplary communications between a host and a DP accelerator according to one embodiment.

[0016] Fig. 8A and Figure 8B is a flow chart illustrating an exemplary method according to some implementations.

[0017] Fig. 9 is a block diagram illustrating an example of a host having a host channel manager (HCM) according to one embodiment.

[0018] Fig.10 is a block diagram illustrating an example of a host channel manager (HCM) communicatively coupled to one or more accelerator channel managers (ACMs) according to some implementations.

[0019] Fig.11 is a block diagram illustrating mapping of user applications to channels using channel / session keys according to one embodiment.

[0020] Figure 12A-12B is a block diagram illustrating an example of security information exchange between a host and a DP accelerator according to one embodiment.

[0021] Fig.13A and 13B is a flow chart illustrating an exemplary method according to some implementations.

[0022] Fig.14 is a block diagram illustrating an exemplary system for establishing a secure information exchange channel between a host channel manager (HCM) and an accelerator channel manager (ACM), according to one embodiment.

[0023] Fig.15 is a block diagram illustrating an exemplary exchange of information between a host and a DP accelerator to derive a session key according to one embodiment.

[0024] Fig.16A and Fig. 16B is a flow chart illustrating an exemplary method according to some implementations.

[0025] Fig.17 is a block diagram illustrating an example of a host with a secure memory manager (MM) securing a memory buffer of a DP accelerator according to one embodiment.

[0026] Fig.18is a block diagram illustrating an example of a memory manager (MM) according to some implementations.

[0027] Fig.19 is a flow chart illustrating an example of a method according to one embodiment.

[0028] Fig. 20 is a block diagram illustrating an example of a host server communicatively coupled to a DP accelerator according to one embodiment.

[0029] Fig.21 is a block diagram illustrating an example of a time unit according to one embodiment.

[0030] Fig. 22 is a block diagram illustrating an example of a security unit according to one embodiment.

[0031] Fig.23 is a block diagram illustrating an example of a host server communicatively coupled to a DP accelerator to validate kernel objects according to one embodiment.

[0032] Fig.24 is a flow chart illustrating an exemplary kernel object confirmation protocol according to one embodiment.

[0033] Fig.25 is a flow chart illustrating an example of a method according to one embodiment.

[0034] Fig.26 is a block diagram illustrating an example of a host server communicatively coupled to a DP accelerator for kernel attestation according to one embodiment.

[0035] Fig. 27 is a flow chart illustrating an exemplary attestation protocol according to one embodiment.

[0036] Fig.28A and Fig.28B is a flow chart illustrating an exemplary method according to some implementations.

[0037] Fig.29 is a block diagram illustrating an example of a host server communicatively coupled to a trusted server and a DP accelerator according to one embodiment.

[0038] Fig.30 is a flow chart illustrating an exemplary DP accelerator confirmation protocol according to one embodiment.

[0039] Fig.31 is a flow chart illustrating an example of a method according to one embodiment.

[0040] Fig.32 is a block diagram illustrating a data processing system according to one embodiment. DETAILED DESCRIPTION

[0041] Various embodiments and aspects of the present invention will be described with reference to the details discussed below, and the accompanying drawings will illustrate various embodiments. The following description and accompanying drawings may illustrate the present invention, but are not intended to limit the present invention. Many specific details are described to provide a thorough understanding of various embodiments of the present invention. However, in some instances, in order to provide a concise discussion of embodiments of the present invention, known or conventional details are not described.

[0042] Reference to "one embodiment" or "an embodiment" in the specification means that a particular feature, structure, or characteristic described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The phrase "in one embodiment" appearing in various places in the specification does not necessarily refer to the same embodiment.

[0043] According to a first aspect of the present invention, a data processing system uses a security module (e.g., a trusted platform module (TPM)) of a host system to perform a secure boot. The system confirms that an operating system (OS) and one or more drivers including an accelerator driver associated with a data processing (DP) accelerator are provided by a trusted source. The system starts the accelerator driver within the OS. The system establishes a trusted execution environment (TEE) associated with one or more processors of the host system. The system starts an application and a runtime library within the TEE, wherein the application communicates with the DP accelerator via the runtime library and the accelerator driver.

[0044] According to a second aspect, a system establishes a secure connection (having one or more secure channels) between a host system and a data processing (DP) accelerator via a bus, the secure connection comprising: one or more command channels and / or data channels. In one embodiment, one or more command channels may be unsecure. The system transmits a first instruction from the host system to the DP accelerator via the command channel, the first instruction requesting the DP accelerator to perform a data preparation operation. The system receives a first request for reading first data from a first memory location of the host system from the DP accelerator via the data channel in response to the first instruction. In response to the request, the system transmits the first data retrieved from the first memory location of the host system to the DP accelerator via the data channel, wherein the first data is used for a calculation or configuration operation. The system transmits a second instruction from the host system to the DP accelerator via the command channel, the second instruction requesting the DP accelerator to perform a calculation or configuration operation.

[0045] In one embodiment, a system establishes a secure connection between a host system and a data processing (DP) accelerator via a bus, the secure connection comprising: one or more command channels and / or data channels. The command channel may be unsecured. At the DP accelerator, the system receives a first instruction from the host system via the command channel, the first instruction requesting the DP accelerator to perform a data preparation operation. In response to the first instruction, the system transmits a first request from the DP accelerator to the host system via the data channel to read first data from a first memory location of the host system. The system receives first data from the host system via the data channel, wherein the first data is retrieved by the host system from the first memory location of the host system. The system receives a second instruction from the host system via the command channel, the second instruction requesting the DP accelerator to perform a calculation or configuration operation. The system performs a calculation or configuration operation based at least on the first data.

[0046] According to a third aspect, a system receives a request from an application at a host channel manager (HCM) of a host system to establish a secure channel using a data processing (DP) accelerator, wherein the DP accelerator is connected to the host system via a bus. In response to the request, the system generates a first session key for the secure channel based on a first private key of a first key pair associated with the HCM and a second public key of a second key pair associated with the DP accelerator. In response to first data associated with the application to be sent to the DP accelerator, the system encrypts the first data using the first session key. The system then transmits the encrypted first data to the DP accelerator via the secure channel via the bus.

[0047] In one embodiment, a system receives a request from an application of a host channel manager (HCM) of a host system at an accelerator channel manager (ACM) of a data processing (DP) accelerator to establish a secure channel between the host system and the DP accelerator, wherein the DP accelerator is connected to the host system via a bus. In response to the request, the system generates a second session key for the secure channel, encrypts the second session key based on a second private key of a second key pair associated with the DP accelerator and a first public key of a first key pair associated with the HCM, and then sends the encrypted second session key to the HCM. In response to first data to be sent to the host system, the system encrypts the first data using the second session key. Then, the system transmits the encrypted first data to the HCM of the host system via the secure channel.

[0048] According to a fourth aspect, in response to receiving a temporary public key (PK_d) from a data processing (DP) accelerator, a system generates a first random number (nc) at a host system, wherein the DP accelerator is connected to the host system via a bus. The system transmits a request to create a session key from the host system to the DP accelerator, the request including: a host public key (PK_O) and the first random number. The system receives a second random number (ns) from the DP accelerator, wherein the second random number is encrypted using the host public key and a temporary private key (SK_d) corresponding to the temporary public key. The system generates a first session key based on the first random number and the second random number, the first session key being used to encrypt or decrypt subsequent data exchanges between the host system and the DP accelerator.

[0049] In one embodiment, in response to receiving a request from a host system, a system generates a temporary private key and a temporary public key at a data processing (DP) accelerator, wherein the DP accelerator is coupled to the host system via a bus. The system encrypts the temporary public key using an accelerator private root key associated with the DP accelerator. The system transmits the temporary public key and the encrypted temporary public key in unencrypted form to the host system to allow the host system to confirm the temporary public key. The system receives a first random number from the host system, wherein the first random number is generated by the host system after the temporary public key has been confirmed. The system generates a session key based on the first random number and a second random number, wherein the second random number has been generated locally at the DP accelerator.

[0050] According to a fifth aspect, a system performs a secure boot using a security module (e.g., a trusted platform module (TPM)) of a host system. The system establishes a trusted execution environment (TEE) associated with one or more processors of the host system. The system starts a memory manager within the TEE, wherein the memory manager is configured to manage memory resources of a data processing (DP) accelerator connected to the host system via a bus, including maintaining memory usage information of a global memory of the DP accelerator. In response to receiving a request for accessing a memory location of the DP accelerator from an application running within the TEE, the system allows or denies the request based on the memory usage information.

[0051] According to a sixth aspect, the DP accelerator includes: one or more execution units (EUs) configured to perform data processing operations in response to instructions received from a host system connected via a bus. The DP accelerator includes: a security unit (SU) configured to establish and maintain a secure channel with the host system to exchange commands and data associated with the data processing operations. The DP accelerator includes: a time unit (TU) connected to the security unit to provide a timestamp service to the security unit, wherein the time unit includes: a clock generator to locally generate a clock signal without having to derive the clock signal from an external source. The TU includes: a timestamp generator connected to the clock generator to generate a timestamp based on the clock signal, and a power supply to the clock generator and the timestamp generator.

[0052] In one embodiment, the TU further includes: a counter coupled to the clock generator to count a count value based on a clock signal generated from the clock generator; and a permanent memory to store the count value, wherein the count value is used by the timestamp generator to generate a timestamp. In another embodiment, the counter increments the count value in response to each clock signal, and wherein the permanent memory includes a 32-bit variable. However, the permanent memory may include variables of any size, for example, 8 bits, 16 bits, 64 bits, etc.

[0053] In one embodiment, the time unit further comprises: a local oscillator coupled to the clock generator to provide a precise pulse signal. In one embodiment, the power source comprises: a battery to provide power without having to draw power from an external power source. In one embodiment, the clock signal is generated without having to communicate with an external clock source. In one embodiment, the time unit further comprises: a clock calibrator configured to calibrate the clock generator.

[0054] In one embodiment, the timestamp is used by the security unit to timestamp the session key used to encrypt the exchanged data between the DP accelerator and the host system. In another embodiment, the timestamp is used to timestamp the information exchange of the DP accelerator, and the timestamp can be used to determine the freshness of the information exchange. In another embodiment, the timestamp of the session key is used to determine whether the session key has expired.

[0055] According to a seventh aspect, a DP accelerator comprises: one or more execution units (EUs) configured to perform data processing operations in response to receiving instructions from a host system connected via a bus. The DP accelerator comprises: a time unit (TU) connected to a security unit to provide a timestamp service. The DP accelerator comprises: a security unit (SU) configured to establish and maintain a secure channel with the host system to exchange commands and data associated with the data processing operations, wherein the security unit comprises: a secure storage area to store a private root key associated with the DP accelerator, wherein the private root key is used for authentication. The SU comprises: a random number generator for generating random numbers; and an encryption engine for performing encryption operations on data exchanged with the host system via the bus using a session key derived based on the random number.

[0056] In one embodiment, during the manufacture of the DP accelerator, the private root key is pre-configured and stored in a secure storage area. In one embodiment, the security unit will receive a request from the host system to establish a secure connection with the DP accelerator, and in response to the request, generate a session key based on a random number generated by a random number generator, wherein the session key is used to encrypt or decrypt data exchanged with the host system over the secure connection.

[0057] In another embodiment, the random number generator generates the random number based on the seed value. In another embodiment, the timestamp is also used to determine whether the session key has expired, in which a new session key is to be generated.

[0058] In another embodiment, when generating a session key based on a random number, the security unit generates a temporary key pair having a temporary private key and a temporary public key, transmits the temporary public key and the signed temporary public key to the host, wherein the signed temporary public key is signed by a private root key to allow the host system to authenticate the DP accelerator, receives a first random number from the host system, and generates a first session key based on the first random number and the second random number generated locally at the DP accelerator. In another embodiment, the security unit is further configured to transmit the first random number and the second random number signed by the private root key (e.g., the private root key of the DP accelerator) and encrypted by a public key associated with the host system.

[0059] In another embodiment, the host system is configured to use a public root key (e.g., a public root key of the DP accelerator) corresponding to the private root key and the private key of the host system to decrypt the encrypted first random number and the second random number to recover the first random number and the second random number. In another embodiment, the host system is configured to generate a second session key based on the recovered first random number and the second random number, wherein the second session key is used by the host system for encryption and decryption.

[0060] In one embodiment, the time unit includes: a clock generator for locally generating a clock signal without having to derive the clock signal from an external source; a timestamp generator connected to the clock generator to generate a timestamp based on the clock signal; and a power supply for powering the clock generator and the timestamp generator without having to draw power from an external power supply.

[0061] According to an eighth aspect, a system receives a request from an application at a runtime library executed in a trusted execution environment (TEE) of a host system to call a predetermined function to perform a predetermined operation. In response to the request, the system identifies a kernel object associated with the predetermined function. The system confirms the executable image of the kernel object using a public key corresponding to a private key used to sign the executable image of the kernel object. In response to successfully confirming the executable image of the kernel object, the system transmits the confirmed executable image of the kernel object to a data processing (DP) accelerator via a bus to be executed by the DP accelerator to perform the predetermined operation.

[0062] According to the ninth aspect, the system receives a public certification key (PK_ATT) or a signed PK_ATT from a data processing (DP) accelerator via a bus at a host system. The system uses a public root key (PK_RK) associated with the DP accelerator to confirm the PK_ATT. In response to successfully confirming the PK_ATT, the system transmits a kernel identifier (ID) to the DP accelerator to request certification of a kernel object stored in the DP accelerator. In response to receiving a kernel digest or a signed kernel digest corresponding to the kernel object from the DP accelerator, the system uses the PK_ATT to confirm the kernel digest. The system sends the confirmation result to the DP accelerator for the DP accelerator to access the kernel object based on the confirmation result.

[0063] In one embodiment, in response to receiving an attestation request from a host system, a system generates an attestation key pair having a public attestation key (PK_ATT) and a private attestation key (SK_ATT) at a data processing (DP) accelerator. The system transmits the PK_ATT or a signed PK_ATT from the DP accelerator to the host system, wherein the DP accelerator is coupled to the host system via a bus. The system receives a kernel identifier (ID) identifying a kernel object from the host system, wherein the kernel ID is received in response to successfully validating the PK_ATT. The system generates a kernel digest by hashing an executable image of the kernel object in response to the kernel ID. The system transmits the kernel digest or the signed kernel digest to the host system to allow the host system to validate and attest the kernel object before accessing the kernel object to be executed within the DP accelerator.

[0064] According to a tenth aspect, a system receives an accelerator identifier (ID) that uniquely identifies a data processing (DP) accelerator from a host system, wherein the host system is connected to the DP accelerator via a bus. The system transmits the accelerator ID to a predetermined trusted server via a network. The system receives a certificate from a predetermined trusted server via a network, the certificate authenticating the DP accelerator. Optionally, the system confirms that the certificate is associated with the trusted server, for example by confirming a certificate chain of the trusted server. The system extracts a public root key (PK_RK) from the certificate, the PK_RK corresponding to a private root key (SK_RK) associated with the DP accelerator. The system uses the PK_RK to establish a secure channel with the DP accelerator to securely exchange data between the host system and the DP accelerator.

[0065] Figure 1 is a block diagram illustrating an example of a system configuration for ensuring communication between a host and a data processing (DP) accelerator according to some embodiments. Figure 1 , the system configuration 100 includes, but is not limited to: one or more client devices 101-102 communicatively coupled to a DP server 104 via a network 103. The client devices 101-102 may be any type of client device, such as a personal computer (e.g., a desktop computer, a laptop computer, and a tablet computer), a "thin" client, a personal digital assistant (PDA), a web-enabled device, a smart watch or a mobile phone (e.g., a smartphone), etc. Alternatively, the client devices 101-102 may be other servers. The network 103 may be any type of network, such as a local area network (LAN), a wide area network (WAN) (such as the Internet), or a combination thereof (wired or wireless).

[0066] The server (e.g., host) 104 may be any kind of server or server cluster, such as a web or cloud server, an application server, a backend server, or a combination thereof. The server 104 also includes an interface (not shown) to allow clients, such as client devices 101-102, to access resources or services provided by the server 104 (such as resources and services provided by the DP accelerator via the server 104). For example, the server 104 may be a cloud server or a server in a data center that provides various cloud services to clients, such as cloud storage, cloud computing services, machine learning training services, data mining services, etc. The server 104 may be configured as part of a software as a service (SaaS) or platform as a service (PaaS) system on a cloud, which may be a private cloud, a public cloud, or a hybrid cloud. The interface may include a web interface, an application programming interface (API), and / or a command line interface (CLI).

[0067] For example, a client (i.e., in this example, a user application (e.g., a web browser, application) of client device 101) may send or transmit instructions for execution (e.g., artificial intelligence (AI) training, reasoning instructions, etc.) to server 104, and the instructions are received by server 104 via an interface over network 103. In response to the instructions, server 104 communicates with DP accelerators 105-107 to complete the execution of the instructions. In some embodiments, the instructions are machine learning type instructions, where the DP accelerator, as a dedicated machine or processor, can execute the instructions many times faster than the instructions are executed by server 104. Therefore, server 104 can control / manage the execution of one or more DP accelerators in a distributed manner. Server 104 then returns the execution results to client devices 101-102. The DP accelerator or AI accelerator may include: one or more dedicated processors, such as Baidu artificial intelligence (AI) chipsets available from Baidu, or the DP accelerator may be an AI chipset from NVIDIA, Intel, or some other AI chipset provider.

[0068] According to one embodiment, each of the applications accessing any one of the DP accelerators 105-107 and hosted by the DP server 104 (also referred to as the host) may be confirmed to be provided by a trusted source or vendor. Each application may be launched and executed within a trusted execution environment (TEE) that is specifically configured and executed by the central processing unit (CPU) of the host 104. When an application is configured to access any one of the DP accelerators 105-107, a secure connection is established between the host 104 and a corresponding one of the DP accelerators 105-107, thereby protecting data exchanged between the host 104 and each of the DP accelerators 105-107 from malware attacks.

[0069] Figure 2 2 is a block diagram illustrating an example of a multi-layered protection solution for securing communications between a host system and a data processing (DP) accelerator according to some embodiments. In one embodiment, the system 200 provides a protection solution for secure communications between a host and a DP accelerator with or without hardware modifications to the DP accelerator. Figure 2, the host machine or server 104 can be described as a system with one or more layers protected from intrusion, such as user applications 203, runtime libraries 205, drivers 209, operating systems 211, and hardware 213 (e.g., security modules (Trusted Platform Module (TPM)) / central processing units (CPUs)). The host machine 104 is typically a CPU system that can control and manage execution jobs on the host system or DP accelerators 105-107. In order to secure the communication channel between the DP accelerator and the host machine, different components may be required to protect different layers of the host system that are vulnerable to data intrusion or attack. For example, a trusted execution environment (TEE) can protect the user application layer and the runtime library layer from data intrusion.

[0070] Reference Figure 2 According to some embodiments, the system 200 includes: a host system 104 and DP accelerators 105-107. The DP accelerator includes: a Baidu AI chipset or any other AI chipset that can perform AI-intensive computing tasks, such as an NVIDIA graphics processing unit (GPU). In one embodiment, the host system 104 includes hardware having one or more CPUs 213 equipped with a security module (such as a trusted platform module (TPM)) within the host machine 104. TPM is a dedicated chip on an endpoint device that stores encryption keys (e.g., RSA encryption keys) dedicated to the host system for hardware authentication. Each TPM chip may contain one or more RSA key pairs (e.g., public and private key pairs) called endorsement keys (EK) or endorsement credentials (EC), i.e., root keys. The key pairs are maintained inside the TPM chip and cannot be accessed by software. Then, before executing the key parts of the firmware and software, the key parts of the firmware and software can be hashed by the EK or EC to protect the system from unauthorized firmware and software modifications. Therefore, the TPM chip on the host machine can be used as a root of trust for secure boot.

[0071] The TPM chip also ensures that the driver 209 and the operating system (OS) 211 communicate with the DP accelerator in the working kernel space. Here, the driver 209 is provided by the DP accelerator vendor and can be used as a driver for the user application to control the communication channel between the host and the DP accelerator. Because the TPM chip and secure boot protect the OS and drivers in its kernel space, the TPM also effectively protects the driver 209 and the operating system 211.

[0072] Since the communication channels of the DP accelerators 105 - 107 may be exclusively occupied by the OS and the driver, the communication channels are also secured by the TPM chip.

[0073] In one embodiment, the host machine 104 includes: a trusted execution environment (TEE) 201, which is forced to be secure by the TPM / CPU 213. TEE is a secure environment. TEE can ensure that the code and data loaded in the TEE are protected in terms of confidentiality and integrity. An example of TEE can be Intel Software Guard Extensions (SGX), or AMD Secure Encrypted Virtualization (SEV). Intel SGX and / or AMD SEV may include: a set of central processing unit (CPU) instruction codes that allow user-level code to allocate a private area of ​​the CPU's memory, which is protected from processes running at a higher privilege level. Here, TEE 201 can protect user applications 203 and runtime libraries 205, wherein user applications 203 and runtime libraries 205 can be provided by end users and DP accelerator vendors, respectively. Here, runtime library 205 can convert API calls into commands for execution, configuration and / or control of DP accelerators. In one embodiment, runtime library 205 provides a set of predetermined (e.g., predefined) kernels for user application execution.

[0074] In another embodiment, the host machine 104 includes: storing one or more security applications 207, which are implemented using memory-safe languages ​​(such as Rust and GoLang, etc.). These memory-safe applications running on a memory-safe Linux version (e.g., MesaLockLinux) can further protect the system 200 from data confidentiality and integrity attacks. However, the operating system can be any Linux distribution, UNIX, Windows OS, or Mac OS.

[0075] In one embodiment, the system can be set up as follows: Install the memory-safe Linux distribution on a system equipped with TPM secure boot (such as Figure 2 The installation can be performed offline during the manufacturing or preparation phase. The installation can also ensure that the user space applications of the host system are programmed using a memory-safe programming language. Ensuring that other applications running on the host system 104 are memory-safe applications can further mitigate potential confidentiality and integrity attacks on the host system 104.

[0076] After installation, the system can then be started through a TPM-based secure boot. TPM secure boot ensures that only signed / certified operating systems and accelerator drivers are started in the kernel space that provides accelerator services. In one embodiment, the operating system can be loaded through a hypervisor. Note that a hypervisor or virtual machine manager is computer software, firmware, or hardware that creates and runs virtual machines. Note that kernel space is a descriptive area or range that identifies the kernel (i.e., a set of predetermined (e.g., predefined) functions for execution) to provide functions and services to user applications. In the event that the integrity of the system is compromised, the TPM secure boot may fail to boot and instead shut down the system.

[0077] After secure boot, the runtime library 205 runs and creates TEE 201, and TEE 201 places the runtime library 205 in the trusted memory space associated with CPU 213. Next, the user application 203 is started in TEE 201. In one embodiment, the user application 203 and the runtime library 205 are statically linked and started together. In another embodiment, the runtime library 205 is first started in the TEE, and then the user application 203 is dynamically loaded in the TEE 201. In another embodiment, the user application 203 is first started in the TEE, and then the runtime library 205 is dynamically loaded in the TEE 201. Note that the statically linked library is a library that is linked to the application at compile time. Dynamic loading can be performed by a dynamic linker. The dynamic linker loads and links shared libraries for running user applications at runtime. Here, the user application 203 and the runtime library 205 in the TEE 201 are visible to each other at runtime, for example, all process data are visible to each other. However, external access to the TEE is denied.

[0078] In another embodiment, the user application can only call kernels from a set of kernels predetermined by the runtime library 205. In another embodiment, the user application 203 and the runtime library 205 are hardened using a side-channel-free algorithm to defend against side-channel attacks such as cache-based side-channel attacks. A side-channel attack is any attack based on information obtained from the implementation of a computer system, rather than weaknesses in the implemented algorithm itself (e.g., cryptographic analysis and software defects). Examples of side-channel attacks include: cache attacks, which are attacks based on the ability of an attacker to monitor the cache of a shared physical system in a virtualized or cloud environment. Hardening may include: cache masking, outputs generated by the algorithm to be placed on the cache. Next, when the user application finishes execution, the user application terminates its execution and exits from the TEE.

[0079] In summary, system 200 provides multiple layers of protection for the DP accelerator (such as, communication of data such as machine learning models, training data, and inference outputs) to avoid loss of data encryption information and integrity. System 200 may include: a TPM-based secure boot protection layer, a TEE protection layer, and a kernel verification / validation layer. In addition, system 200 may provide a memory-safe user space by ensuring that other applications on the host machine are implemented using a memory-safe programming language, which may further eliminate attacks by eliminating potential memory corruption / vulnerabilities. In addition, system 200 may include: applications that use side-channel-free algorithms to defend against side-channel attacks (e.g., cache-based side-channel attacks).

[0080] Figure 3 is a flow chart illustrating an example of a method according to one embodiment. Process 300 may be performed by processing logic that may include software, hardware, or a combination thereof. For example, process 300 may be performed by a host system (e.g., Figure 1 The host system 104) is executed. Figure 3 At box 301, processing logic uses a security module such as a trusted platform module (TPM) of a host system to perform a secure boot. At box 302, processing logic confirms that an operating system (OS) and an accelerator driver associated with a data processing (DP) accelerator are provided by a trusted source. At box 303, processing logic starts the accelerator driver within the OS. At box 304, processing logic generates a trusted execution environment (TEE) associated with a CPU of the host system. At box 305, processing logic starts an application and a runtime library within the TEE, wherein the application communicates with the DP accelerator via the runtime library and the accelerator driver.

[0081] In one embodiment, the application and the runtime library are statically linked and started together. In another embodiment, the runtime library is started in the TEE, and after the runtime library is started, the application is dynamically loaded for startup. In one embodiment, the processing logic also starts other applications on the host machine, which are memory-safe applications. In another embodiment, the memory-safe application is implemented by one or more memory-safe programming languages. In one embodiment, the runtime library provides a set of predetermined kernels to be started by the application to run tasks by the DP accelerator. In one embodiment, the processing logic also uses a side-channel-free algorithm to strengthen the application and runtime library running in the TEE to defend against cache-based side-channel attacks.

[0082] Figure 4 is a block diagram illustrating an example of a host computer having an I / O manager according to one embodiment. System 400 may represent Figure 2 The system 200 is provided to provide a protection scheme for secure communication between a host and a DP accelerator. Figure 4 In one embodiment, the TEE 201 of the host system 104 includes: an I / O manager 401. In one embodiment, the DP accelerators 405-407 include I / O interfaces 415-417, respectively, which prevent, prohibit or deny the host from directly accessing the memory of the DP accelerator, while the I / O manager 401 allows the DP accelerator to access only certain memory blocks of the host system 104.

[0083] A conventional DP accelerator has an I / O interface that grants the host machine access permission to the entire global memory of the DP accelerator. In practice, malicious applications may abuse this permission to steal or change memory buffers in the global memory of the DP accelerator. In order to solve this technical problem, the embodiments of the present disclosure implement a communication protocol that prohibits access to the memory system of the DP accelerator. For example, the host machine can only communicate with the DP accelerator through a command channel to issue commands, while the DP accelerator can communicate through a data channel to write data to or read data from the host machine through the I / O manager of the host machine. The I / O manager can therefore further characterize the DP accelerator's access to data, and can allow the DP accelerator to access only a limited memory range of the host system.

[0084] For illustration purposes, an exemplary operation performed by the DP may be an addition operation, e.g., 1+2=3. In this case, a host system with access to the memory address of the DP accelerator may remotely issue multiple data preparation instructions to load data into the memory buffer of the DP accelerator before performing the addition operation.

[0085] However, a host system without memory access to the DP accelerator will not be able to reference the accelerator's memory addresses and must issue a different set of processor instructions for data preparation operations. Subsequent instructions are then issued by the DP accelerator to read data from the host machine to obtain data (e.g., operands for an addition instruction). Here, the DP accelerator's memory addresses are not visible to the host system.

[0086] Figure 5 is a block diagram further illustrating an example of an I / O manager communicating with a DP accelerator according to some embodiments. System 500 may be Figure 4 A detailed view of the system 400 is shown. Figure 5In one embodiment, the I / O manager 401 includes: a command generator 501, a mapped memory 503, and an access control list (ACL) module 505. The I / O manager 401 can be communicatively coupled to the driver 209, and the driver 209 can include: an ACL mapping 507 (e.g., an IO MMU). The command generator 501 can generate commands to be issued to the DP accelerator. The mapped memory 503 can include: a plurality of memory regions of the host server 104 mapped to each DP accelerator. The mapped memory 503 can be a memory of the host server 104 (e.g., as Figure 4 The ACL module 505 may control (e.g., allow or deny) access to the corresponding mapped memory region of the host server 104 according to the logic table of the corresponding DP accelerator. The ACL mapping 507 may include a mapping table that maps different memory regions of the memory 503 to the DP accelerator, such as Figure 6 Here, Figure 6 It is shown that according to one embodiment, DP Accelerator 1 is mapped to more than one region (eg, regions 1 ... 11), and DP Accelerator 2 is mapped to region 12. For example, each DP Accelerator may be mapped to many memory regions.

[0087] For example, in one embodiment, the DP accelerator is not allowed to directly access the host server's memory locations (e.g., mapped memory 503). However, the DP accelerator can access the host server's memory region (via ACL module 505) if ACL map 507 contains an entry for the DP accelerator that is mapped to the memory region to be accessed. In one embodiment, when a DP accelerator is added to the host system 104 (e.g., the host system 104 discovers that a new DP accelerator is connected), ACL module 505 assigns an identifier to the DP accelerator, inserts an entry into ACL map 507 corresponding to the DP accelerator, and / or reserves or allocates an available memory block from memory 503, e.g., the host server's 104 memory (as a memory block). Figure 4 Part of the hardware 213 of the host server 104). In one embodiment, the ACL module 505 may send a notification to the DP accelerator to notify the DP accelerator of the available memory blocks. In one embodiment, the DP accelerator identifier may be a generated GUID / UUID (universally unique identifier), a MAC address, an IP address associated with the DP accelerator, or a combination thereof. In some embodiments, the host system is connected to multiple DP accelerators. In one embodiment, when the DP accelerator is removed from the host system 104 (for example, the host system 104 discovers that the existing DP accelerator is no longer connected to the host server 104), the ACL module may remove the entry from the ACL mapping 507 corresponding to the DP accelerator and / or release the memory block from the memory 503 corresponding to the DP accelerator.

[0088] Reference Figure 5 In one embodiment, the I / O interface 415 of the DP accelerator 405 includes modules such as a control register 511 and a command decoder 513. The control register 511 may control the behavior of the execution unit 517 and / or the global memory 515. The command decoder 513 may decode the command received by the DP accelerator 405. In one embodiment, the DP accelerator 405 may issue subsequent commands (e.g., read / write commands) to obtain data from and transmit data to the IO manager 401 to complete the requested command.

[0089] Figure 7 700 is a block diagram illustrating exemplary communications between a host and a DP accelerator according to one embodiment. Operation 700 may be performed by the host server 104 and / or the DP accelerator 405. Figure 7 In operation 701, the host server 104 sends a data preparation command request (e.g., a data preparation instruction to perform a data preparation operation) to the DP accelerator 405 for processing by the DP accelerator via a command channel. In operation 702, the DP accelerator 405 decodes the requested command to determine the type of the command as a data preparation operation command.

[0090] If it is determined that data from the host server 104 is needed to complete the requested command, then in operation 703, the DP accelerator 405 requests read access (e.g., a read operation) of the data from the host memory, where the data may reside in a first memory location of the host system (e.g., Figure 5 In operation 704, in response to receiving the read access request, the host server 104 identifies the requesting DP accelerator and a memory region (e.g., a first memory location) on the host server 104, and queries the ACL mapping to determine whether the DP accelerator has access permission to the requested memory region.

[0091] For example, the host server 104 may query the ACL mapping for the DP accelerator by an identifier associated with the DP accelerator. If there is a query result entry, the host server 104 will determine whether the requested memory location is located within the memory region according to the result entry. If so, the DP accelerator 405 has read / write access permission. If it is determined that the DP accelerator has read access permission to the memory region, then in operation 705, the host server 104 returns the requested data via the data channel. If it is determined that the DP accelerator does not have read access permission, the host server 104 may then send a notification of read failure to the DP accelerator 405.

[0092] In operation 706, the host server 104 sends a DP command or a compute or configuration command or a DP instruction. In operation 707, the DP accelerator 405 processes the DP command or DP operation. In operation 708, when the requested command is completed, the DP accelerator 405 stores the completion result in the global memory of the DP accelerator 405 (e.g., Figure 5 DP accelerator 405 then sends the completion result as a write request to host server 104 via the data channel. In operation 709, host server 104 identifies the DP accelerator and the memory region (e.g., the second memory location) for which write access is requested, and queries the ACL mapping to determine whether DP accelerator 405 has write access permission to the requested memory region.

[0093] If it is determined that the DP accelerator has write access permission, then in operation 710, the host server 104 stores the result in the requested memory location. In operation 711, the host server 104 may then send an acknowledgement upon successful receipt of the result. Note that a DP / compute command refers to a command for a data processing operation to be processed by the DP accelerator. A configuration command refers to a command for configuring the DP accelerator. A data preparation command refers to a command for a data preparation operation, for example, for obtaining data from the host server, such as an operand for a DP command.

[0094] Fig. 8A and 8B is a flow chart illustrating an exemplary method according to some embodiments. Processes 800 and 820 may be performed by processing logic that may include software, hardware, or a combination thereof. For example, process 800 may be performed by Figure 4 The process 820 may be performed by a host system (e.g., I / O manager 401) of Figure 4 DP accelerator (eg, I / O interface 415) is executed. Fig. 8AAt block 801, processing logic establishes a secure connection between a host system and a data processing (DP) accelerator via a bus, the secure connection comprising: one or more data channels. In another embodiment, the secure connection comprises: one or more command channels. At block 802, processing logic transmits a first instruction from the host system to the DP accelerator via a command channel, the first instruction requesting the DP accelerator to perform a data preparation operation. At block 803, processing logic receives a first request for reading first data from a first memory location of the host system via a data channel from the DP accelerator in response to the first instruction. At block 804, in response to the first request, processing logic transmits first data retrieved from the first memory location of the host system to the DP accelerator via the data channel, wherein the first data is used for a calculation or configuration operation. At block 805, processing logic transmits a second instruction from the host system to the DP accelerator via the command channel, the second instruction requesting the DP accelerator to perform a calculation or configuration operation.

[0095] In one embodiment, in response to determining that the DP accelerator has the right to read from the first memory location, the processing logic further checks the first request to determine whether the DP accelerator has the right to read from the first memory location of the host system and allows the DP accelerator to read from the first memory location. In one embodiment, the DP accelerator is not allowed to directly access the first memory location of the host system. In one embodiment, the DP accelerator is one of a plurality of DP accelerators coupled to the host system.

[0096] In one embodiment, the processing logic further receives a second request from the DP accelerator via the data channel to write second data, wherein the second data is to be written to a second memory location of the host system. In response to the second request, the processing logic stores the second data at the second memory location of the host system. In another embodiment, the processing logic further checks the second request to determine that the DP accelerator has permission to write to the second memory location of the host system. In response to determining that the DP accelerator has permission to write to the second memory location, the processing logic allows the DP accelerator to write to the second memory location. In another embodiment, the second data represents at least a portion of a result of a computation or configuration operation in response to the instruction.

[0097] Reference Figure 8BIn one embodiment, at block 821, processing logic establishes a secure connection between a host system and a data processing (DP) accelerator via a bus, the secure connection comprising: one or more command channels and / or one or more data channels. At block 822, processing logic receives a first instruction from the host system via a command channel at the DP accelerator, the first instruction requesting the DP accelerator to perform a data preparation operation. At block 823, in response to the first instruction, processing logic transmits a first request from the DP accelerator to the host system via a data channel to read first data from a first memory location of the host system. At block 824, processing logic receives first data from the host system via the data channel, wherein the first data is retrieved by the host system from the first memory location of the host system. At block 825, processing logic receives a second instruction from the host system via the command channel, the second instruction requesting the DP accelerator to perform a calculation or configuration operation. At block 826, processing logic performs a calculation or configuration operation based on at least the first data.

[0098] In one embodiment, the host system is to check the first request to determine whether the DP accelerator has permission to read from a first memory location of the host system, and wherein the host system is to allow the DP accelerator to read from the first memory location in response to determining that the DP accelerator has permission to read from the first memory location. In another embodiment, the DP accelerator is not allowed to directly access the first memory location of the host system. In another embodiment, the DP accelerator is one of a plurality of DP accelerators coupled to the host system.

[0099] In another embodiment, the processing logic further transmits a second request from the DP accelerator to the host system via the data channel to write second data to a second memory location of the host system, wherein the second data represents at least a portion of a result of the computation or configuration operation. In another embodiment, the host system is to check the second request to determine whether the DP accelerator has permission to write to the second memory location of the host system, and wherein the host system is to allow the DP accelerator to write to the second memory location in response to determining that the DP accelerator has permission to write to the second memory location.

[0100] Fig. 9 is a block diagram illustrating an example of a host having a host channel manager according to one embodiment. System 900 may represent Figure 2 The system 200 is provided to provide a protection scheme to secure an information exchange channel between a host and one or more DP accelerators. Fig. 9In one embodiment, the host system 104 includes a runtime library 205, and the runtime library 205 includes a host channel manager (HCM) 901. Accordingly, the DP accelerators 405-407 include accelerator channel managers (ACMs) 915-917, respectively. The HCM and the ACM support the generation of encryption keys to establish an information exchange channel based on asymmetric (e.g., RSA) and / or symmetric (e.g., AES) encryption between the host system 104 and the DP accelerators 405-407. Here, the DP accelerators 405-407 may be Figure 2 DP accelerator 205-207.

[0101] Fig.10 is a block diagram illustrating an example of a host channel manager (HCM) communicatively coupled to one or more accelerator channel managers (ACMs) according to some embodiments. System 1000 may be Fig. 9 A detailed view of the system 900 is shown. Fig.10 In one embodiment, the HCM 901 includes: an authentication module 1001, a termination module 1003, a key manager 1005, a key storage 1007, and an encryption engine 1009. The authentication module 1001 can authenticate the user application running on the host server 104 to allow access to or use of the resources of the DP accelerator. The termination module 1003 can terminate the connection (e.g., the channel associated with the connection to be terminated). The key manager 1005 can manage (e.g., create or destroy) an asymmetric key pair or a symmetric key for encrypting / decrypting one or a data packet for different secure data exchange channels. Here, each user application (as Fig. 9 A portion of the user application 203) may correspond to or be mapped to different secure data exchange channels in a one-to-many relationship, and each data exchange channel may correspond to a DP accelerator. According to one embodiment, Fig.11 An example of user applications mapped to channels using channel / session keys may be shown. Here, application 1 is mapped to channel session keys 1-11, where each session key is for a secure channel corresponding to a DP accelerator (e.g., 11DP accelerator); application 2 is mapped to channel session key 12, and key 12 corresponds to a specific DP accelerator. Key storage 1007 may store cryptographic asymmetric key pairs or symmetric keys. Cryptographic engine 1009 may encrypt or decrypt packets of data exchanged over any secure channel. Note that some of these modules may be integrated into fewer modules.

[0102] Reference Fig.10In one embodiment, the DP accelerator 405 includes: ACM 915 and security unit (SU) 1020. The security unit 1020 may include: a key manager 1025, a key storage 1027, and an encryption engine 1029. The key manager 1025 may manage (e.g., generate, securely store, and / or destroy) asymmetric key pairs or symmetric keys. The key storage 1027 may store encrypted asymmetric key pairs or symmetric keys. The encryption engine 1029 may encrypt or decrypt key information or data packets for data exchange. In some embodiments, the ACM 915 and the SU 1020 are integrated modules.

[0103] Figure 12A-12B is a block diagram illustrating an example of security information exchange between a host and a DP accelerator according to one embodiment. Example 1200 may be Fig.10 The system 1000 is executed. Fig.10 and Figure 12A-12B In one embodiment, before any data communication will occur between a DP accelerator (such as DP accelerator 405) and an application (hosted on host server 104) requesting DP accelerator resources, a secure information exchange channel needs to be set up or established between host server 104 and the DP accelerator. The information exchange channel setup may be initiated by a user application of host server 104. For example, a user application (such as Fig. 9 The user application of the application 203 of the DP accelerator) can request the HCM 901 to set up a secure data exchange channel. The authentication module 1001 can receive the request and authenticate that the user application is a trusted application. In one embodiment, the authentication module 1001 confirms the permission of the user application or client to access the user application, for example, confirms whether the user application or client has permission to use resources from the requested DP accelerator. If allowed, information can be exchanged between the user application and the DP accelerator through a secure channel with the help of a session key to encrypt and decrypt the information exchange.

[0104] In one embodiment, to create a session key, the HCM 901 generates a first public key / private key pair associated with the application and / or channel, or the first public key / private key pair may be a key pair associated with the HCM 901. The first public key / private key pair may be stored in the key storage 1007, and the first public key is sent to the DP accelerator 405 (or ACM 915) (e.g., operation 1201). The ACM 915 then generates a unique session key (e.g., a second session key) for the session (e.g., operation 1202), wherein the session key may be used to encrypt / decrypt data packets transmitted to and from the host server 104 (e.g., operations 1205-1216). In one embodiment, the session key is a symmetric key derived (or generated) based on a hash function (such as a cyclic redundancy check, a checksum, or a cryptographic hash function, or a random hash / number generator).

[0105] In one embodiment, when the ACM 915 receives the first public key, the ACM 915 generates a second public key / private key pair for the channel, wherein the second private key and the first public key of the second public key / private key pair are used to encrypt the session key or a component of the session key. In another embodiment, the second public key / private key pair is a key pair associated with the DP accelerator 405. In one embodiment, the first public key, the second public key, the second private key, and / or the session key may be stored in the key storage 1027. Then, the session key (or its component) may be encrypted by the first public key, and the encrypted session key may be further encrypted by the second private key (e.g., double encryption), and the double encrypted session key information may be sent to the HCM 901 together with the second public key (e.g., operation 1203).

[0106] The key manager 1005 of the HCM 901 may then decrypt the encrypted session key based on the second public key and the first private key (e.g., operation 1204) to derive the session key (e.g., generate a first session key). Thereafter, data transmitted from the DP accelerator to the host server 104, or vice versa (e.g., operations 1205-1216), may use the symmetric session key to encrypt and decrypt the data for communication. For example, the data is encrypted and then sent by the sender on the information exchange channel. The received data will be decrypted by the receiver. Here, the host server 104 and the DP accelerator 405 can read these data packets because the host server 104 and the DP accelerator 405 have the same symmetric session key to encrypt and decrypt the data packets.

[0107] In one embodiment, the host server 104 (e.g., HCM 901) cannot directly access the memory buffer of the DP accelerator 405 (e.g., ACM 915), but the DP accelerator can access the memory buffer of the host server 104. Therefore, operations 1205-1211 are operations of sending encrypted data packets from the host server 104 to the DP accelerator 405, and operations 1212-1216 are operations of sending encrypted data packets from the DP accelerator 405 to the host server 104. Here, operations 1206-1210 are similar to Figure 7 Operations 701-705 are used for the host server 104 to provide data packets to the DP accelerator 405.

[0108] Finally, when the application sends a signal notifying that the session is complete, the application may request the HCM 901 to terminate the session. The termination module 1003 may then request the key manager 1005 to destroy the session key (e.g., the first session key) associated with the session (as part of operation 1215) and send a termination notification (e.g., operation 1216) to the ACM 915 of the DP accelerator 405 to request the key manager 1025 to destroy the symmetric session key (e.g., the second session key) associated with the session. Although the HCM 901 is shown to communicate only with the ACM 915, the HCM 901 may communicate with multiple ACMs corresponding to multiple DC accelerators to establish multiple data exchange connections simultaneously.

[0109] Fig.13A and Fig. 13B is a flow chart illustrating an exemplary method according to some embodiments. Processes 1300 and 1320 may be performed by processing logic including software, hardware, or a combination thereof. For example, process 1300 may be performed by Fig. 9 The process 1320 may be performed by a host system (e.g., HCM 901) of Fig. 9 DP accelerator (e.g., ACM 915). Fig.13A At block 1301, processing logic receives a request from an application at a host channel manager (HCM) of a host system to establish a secure channel using a data processing (DP) accelerator, wherein the DP accelerator is connected to the host system via a bus. At block 1302, in response to the request, processing logic generates a first session key for the secure channel based on a first private key of a first key pair associated with the HCM and a second public key of a second key pair associated with the DP accelerator. At block 1303, in response to first data associated with the application to be sent to the DP accelerator, processing logic encrypts the first data using the first session key. At block 1304, processing logic transmits the encrypted first data to the DP accelerator via the secure channel via the bus.

[0110] In one embodiment, in response to the request, the processing logic also transmits a first public key of a first key pair associated with the HCM to the DP accelerator. Then, in response to transmitting the first public key, the processing logic receives a second public key of a second key pair associated with the DP accelerator from an accelerator channel manager (ACM) of the DP accelerator. In another embodiment, the ACM is configured to derive a second session key, and encrypt the second session key based on the first public key and the second private key of the second key pair, and then send the encrypted second session key to the HCM, wherein the first session key and the second session key are the same symmetric key. In another embodiment, the ACM is configured to decrypt the encrypted first data using the second session key to recover the first data.

[0111] In one embodiment, the processing logic also receives encrypted second data from the ACM of the DP accelerator, wherein the second data is encrypted using the second session key. The processing logic then decrypts the encrypted second data using the first session key to recover the second data. In one embodiment, in response to the request, the processing logic also checks an application identifier (ID) of the application to determine whether the application has access to the DP accelerator, wherein the first session key is generated only if the application has access to the DP accelerator. In one embodiment, the processing logic also receives a request from the application to terminate the secure channel. In response to the request, the processing logic transmits an instruction to the ACM, instructing the ACM to terminate the secure connection by destroying the second session key. The processing logic then destroys the first session key through the HCM.

[0112] Reference Fig. 13B In one embodiment, at block 1321, processing logic receives a request from an application of a host channel manager (HCM) of a host system at an accelerator channel manager (ACM) of a data processing (DP) accelerator to establish a secure channel between the host system and the DP accelerator, wherein the DP accelerator is coupled to the host system via a bus. At block 1322, in response to the request, processing logic generates a second session key for the secure channel, and encrypts the second session key information based on a second private key of a second key pair associated with the DP accelerator and a first public key of a first key pair associated with the HCM before sending the encrypted second session key information to the HCM. At block 1323, in response to first data being sent to the host system, processing logic encrypts the first data using the second session key. At block 1324, processing logic transmits the encrypted first data to the HCM of the host system via the secure channel.

[0113] In one embodiment, in response to the request, the processing logic also transmits a second public key of a second key pair associated with the DP accelerator to the HCM of the host system and receives a first public key of a first key pair associated with the HCM from the HCM. In another embodiment, the HCM is configured to derive a first session key based on a first private key of the first key pair associated with the HCM and a second public key of the second key pair associated with the DP accelerator. In another embodiment, the HCM is configured to decrypt the encrypted first data using the first session key to recover the first data.

[0114] In another embodiment, the processing logic also receives encrypted second data from the HCM of the host system, wherein the second data is encrypted using the first session key. The processing logic then decrypts the encrypted second data using the second session key to recover the second data, wherein the first session key and the second session key are the same symmetric key. In one embodiment, the processing logic also receives a request from the HCM of the host system to terminate the secure channel, and in response to the request, the processing logic destroys the first session key through the ACM.

[0115] Fig.14 is a block diagram illustrating an exemplary system for establishing a secure information exchange channel between a host channel manager (HCM) and an accelerator channel manager (ACM) according to one embodiment. The system 1400 may be Fig. 9 A detailed view of the system 900 is shown. Fig.14 In one embodiment, the HCM 901 includes: keys PK_O 1401, SK_O 1403, and PK_RK(s) 1411. The keys PK_O 1401 and SK_O 1403 are respectively the public key and the private key of an asymmetric encryption key pair associated with the HCM 901 and / or the application / runtime of the host server 104, and the key PK_RK 1411 is one or more public keys associated with the DP accelerator 405 and / or the ACM 915 of other DP accelerators. The HCM 901 may also include: a key manager 1005. The DP accelerator 405 may include a security unit 1020 connected to the ACM 915, wherein the security unit 1020 may include: keys PK_RK 1413 and SK_RK 1415, which are respectively the public key and the private key of an asymmetric encryption key pair associated with the ACM 915 and / or the DP accelerator 405. ACM 915 also includes a key manager 1025. Key managers 1005 and 1025 may generate encryption / decryption keys using symmetric algorithms (eg, AES) and / or asymmetric algorithms (eg, Diffie-Hellman key exchange protocol, RSA, etc.).

[0116] Fig.15is a block diagram illustrating an exemplary information exchange between a host and a DP accelerator for deriving a session key according to one embodiment. Example 1550 includes: a plurality of operations for deriving a session key, which may be performed by Fig.14 The system 1400 is executed. Fig.14 and Fig.15 In one embodiment, at operation 1551, the HCM 901 sends a command "CMD_get public key" to the ACM 915 to initiate the process of exporting the session key. At operation 1552, upon receiving the request command, the ACM 915 generates a temporary (or exported) public / private key pair (e.g., PK_d and SK_d) for exporting the session key. The ACM 915 encrypts the temporary public key PK_d using a private root key (e.g., SK_RK) associated with the DP accelerator. At operation 1553, a copy of the encrypted temporary public key and a copy of the temporary public key are sent by the ACM 915 to the HCM 901. At operation 1554, the HCM 901 receives the copy and uses the PK_RK (here, the PK_RK may have been previously received and stored by the HCM 901 as Fig.14 The encrypted temporary public key is decrypted by the PK_RK(s) 1411 of the HCM 901 and compared with the copy of the temporary public key PK_d received at operation 1553. If the decrypted key matches the temporary public key, the HCM 901 has confirmed that the message is from the expected party. Note that PK_RK(s) 1411 may contain multiple public keys for multiple DP accelerators 405-407.

[0117] At operation 1555, HCM 901 generates a first random number (nc). At operation 1556, HCM 901 sends a command "CM_generate session key", a public key associated with HCM (e.g., PK_0), and a random number nc to ACM 915. At operation 1557, upon receiving the "CM_generate session key" command, ACM 915 generates a second random number (ns). At operation 1558, ACM 915 derives a session key based on the first random number nc and the second random number ns. In one embodiment, the session key is derived by a hash function of the random number nc cascaded with the random number ns. In another embodiment, the session key is derived by a hash function based on the value of ns plus nc. Then, the session key is used to encrypt and decrypt the data exchanged between ACM 915 and HCM 901.

[0118] At operation 1559, ACM 915 double encrypts random numbers nc and ns with a temporary private key (e.g., SK_d) and a public key associated with HCM (e.g., PK_O). ACM 915 then sends the double encrypted random numbers nc and ns to HCM901. At operation 1560, HCM 901 decrypts the double encrypted random numbers nc and ns based on the HCM associated private key (e.g., SK_O) and the temporary public key (e.g., PK_d). At operation 1561, HCM 901 confirms the freshness of the session key by confirming that the random number nc is actually the same as the copy of the random number nc initially generated by HCM901. If so, then at operation 1562, HCM 901 derives the session key based on the first random number and the second random number (e.g., nc and ns). In one embodiment, the session key is derived by a hash function of the random number nc cascaded with the random number ns. In another embodiment, the session key is derived by a hash function based on the value of ns plus nc. The session key is then used to encrypt and decrypt data exchanged between the HCM 901 and the ACM 915. Note that although the session key is described as an encryption key based on a symmetric encryption algorithm, the session key may also be a public / private key pair.

[0119] Fig.16A and Fig. 16B is a flow chart illustrating an exemplary method according to some embodiments. Processes 1600 and 1620 may be performed by processing logic that may include software, hardware, or a combination thereof. For example, process 1600 may be performed by Fig.14 , and process 1620 may be performed by a host server (e.g., HCM 901) Fig.14 DP accelerator (e.g., ACM 915). Fig.16A At block 1601, in response to receiving a temporary public key (PK_d) from a data processing (DP) accelerator, processing logic generates a first random number (nc) at a host system, wherein the DP accelerator is coupled to the host system via a bus. At block 1602, processing logic transmits a request to create a session key from the host system to the DP accelerator, the request comprising: a host public key (PK_O) and a first random number. At block 1603, processing logic receives a second random number (ns) from the DP accelerator, wherein the second random number is encrypted using the host public key and a temporary private key (SK_d) corresponding to the temporary public key. At block 1604, processing logic generates a first session key based on the first random number and the second random number, the first session key being used to encrypt or decrypt subsequent data exchanges between the host system and the DP accelerator.

[0120] In one embodiment, the processing logic also sends a request from the host system to the DP accelerator to request the DP accelerator to generate a derived or temporary key pair having a temporary public key and a temporary private key, wherein the DP accelerator creates the temporary key pair in response to the request. Depending on the implementation of the DP accelerator, the temporary key may be used once or several times within a predetermined time period (such as days, weeks, or even months). In another embodiment, the temporary public key from the DP accelerator is a first temporary public key, and the processing logic also receives an encrypted second temporary public key, which has been encrypted by the DP accelerator using an accelerator private root key (SK_RK). In another embodiment, the processing logic also decrypts the encrypted second temporary public key using an accelerator public root key (PK_RK) corresponding to the accelerator private root key to recover the second temporary public key. Then, the processing logic confirms whether the first temporary public key and the second temporary public key are the same, wherein a first random number is generated when the first temporary public key and the second temporary public key are the same.

[0121] In one embodiment, receiving the second random number from the DP accelerator includes: receiving a first random number and a second random number that have been encrypted using a temporary private key corresponding to the temporary public key. In another embodiment, the processing logic further decrypts the encrypted first random number and the second random number using the first temporary public key or the second temporary public key at the host system to recover the first random number and the second random number. In another embodiment, the first random number and the second random number encrypted by the temporary private key are also encrypted by the DP accelerator using the host public key. In another embodiment, the processing logic further decrypts the encrypted first random number and the second random number using the host private key corresponding to the host public key to recover the first random number and the second random number.

[0122] Reference Fig. 16B In one embodiment, at block 1621, in response to receiving a request from a host system, processing logic generates a temporary private key and a temporary public key at a data processing (DP) accelerator, wherein the DP accelerator is coupled to the host system via a bus. At block 1622, processing logic encrypts the temporary public key using an accelerator private root key associated with the DP accelerator. At block 1623, processing logic transmits the temporary public key and the encrypted temporary public key in unencrypted form to the host system to allow the host system to confirm the temporary public key. At block 1624, processing logic receives a first random number from the host system, wherein the first random number is generated by the host system after the temporary public key has been confirmed. At block 1625, processing logic generates a session key based on the first random number and a second random number, wherein the second random number has been generated locally at the DP accelerator.

[0123] In one embodiment, the processing logic further encrypts the first random number and the second random number using the temporary private key to generate an encrypted first random number and the second random number. The processing logic then transmits the encrypted first random number and the second random number to the host system so that the host system can create a corresponding host session key. In another embodiment, the processing logic further encrypts the encrypted first random number and the second random number using a host public key associated with the host system before transmitting the encrypted first random number and the second random number. In another embodiment, the host system is configured to decrypt the encrypted first random number and the second random number using a host private key and a temporary public key associated with the host system to recover the first random number and the second random number. In another embodiment, the host system is configured to confirm the freshness of the first random number, wherein the host session key is generated only if the first random number is generated within a predetermined time period.

[0124] The memory buffer of the DP accelerator may contain programs required to run the DP accelerator, input data to the programs, and output results from the programs. The unsecured memory buffer of the DP accelerator may lead to a compromise in the overall host server-DP accelerator system architecture. As described above, the memory buffer of the DP accelerator may be protected by not allowing the host server to access these DP accelerators. However, for situations where the host server cannot access the memory buffer of the DP accelerator, the host server may retain the memory usage information of the DP accelerator. The memory usage information may be maintained in a trusted execution environment (TEE), which may ensure the confidentiality and integrity of the data.

[0125] Fig.17 1700 is a block diagram illustrating an example of a host having a secure memory manager (MM) to protect a memory buffer of a DP accelerator according to one embodiment. Fig. 9 The system 900 is provided to provide a secure memory manager on the host server 104 to manage the memory of the DP accelerator. Fig.17 In one embodiment, the host server 104 includes: a runtime library 205, and the runtime library 205 includes: an MM 1701. Accordingly, the DP accelerator 405 may include: a memory 1703 and a memory unit (MU) 1705, and the DP accelerator 407 may include: a memory 1707 and an MU 1709. The memory manager may manage the memory of the DP accelerator. The memories 1703 and 1707 may be global memories of the DP accelerator. The global memory may be a component in the accelerator for storing information, such as program code to be executed on the DP accelerator, input to the program code, and output results from program execution. The MUs 1705 and 1709 may communicate with the MM 1701 and coordinate memory layout and memory usage regarding the memories 1703 and 1707 of the DP accelerator, respectively.

[0126] Fig.18 is a block diagram illustrating an example of a memory manager (MM) according to some embodiments. Fig.18 , the memory manager 1701 may include: a memory allocator 1801, a memory releaser 1803, and a memory usage registry 1811. The memory allocator 1801 may allocate a memory block from the global memory of the DP accelerator (e.g., the memory 1703 of the DP accelerator 405). The memory releaser 1803 may release a memory block from the global memory of the DP accelerator. The memory usage registry 1811 may record the memory layout and usage information of the memory blocks associated with the DP accelerator of the host server. In one embodiment, each table (as part of the registry 1811) may be associated with the DP accelerator, and the table may have multiple entries for multiple user applications. For example, a user application may have two entries for reserving two memory blocks of the DP accelerator. The registry may then be used as a reference for allocating or releasing memory blocks for the DP accelerator. The memory usage registry 1811 may include: one or more memory management tables. The memory management table is a data structure used by the system in the computer operating system to store mappings between user applications and physical addresses and / or virtual addresses. An exemplary memory usage registry for a DP accelerator may have fields such as application ID, start address, and size, where the application ID indicates which user application has been allocated a memory block, and the start address and size indicate the address and size of the memory block. In some embodiments, the registry may include additional fields, such as flags indicating whether the corresponding memory block has been allocated, whether the physical address is mapped to the virtual address memory, read or write access, etc. Note that there may be many memory usage registry tables, one for each DP accelerator.

[0127] Reference Figure 17-18 For one example, a remote client may issue a command to run a specific application (as part of a user application 203) on a host server 104. The application may request to use resources from the DP accelerators 405-407 by calling an API provided by the runtime library 205. The resources may be memory resources or processor resources. For the memory resource example, upon receiving the request, the runtime library 205 may start an instance of the MM 1701. The runtime library 205 may then command the DP accelerator 405 to allocate a memory block of a specified size from the memory 1703 of the DP accelerator 405 through the memory allocator 1801 of the instance to execute the application.

[0128] In one embodiment, before requesting a resource block, MM 1701 may query memory usage register 1811 to determine whether the resource block has been allocated. MM 1701 then sends an allocation command to DP accelerator 405 in response to determining that the first memory block has not been allocated to allocate the first memory block of global memory to the application. In another embodiment, MM 1701 rejects the first request in response to determining that the requested memory block has been allocated.

[0129] MU 1705 receives the command and performs memory allocation. In one embodiment, MU 1705 may traverse memory 1703 to find a continuous memory block with the requested memory block size to be allocated. Here, MU 1705 may also retain a similar memory usage register (e.g., a memory usage data structure) for DP accelerator 405 for MU 1705 to traverse memory 1703 for DP accelerator 405. In another embodiment, MM 1701 sends the allocation command and a copy of the memory usage register to DP accelerator 405. In this way, MU 1705 knows the memory that has been allocated. Then, MU 1705 may allocate a memory block based on the memory usage information and return the new memory usage information of the newly allocated memory block to MM 1701. MM 1701 then records the application identifier corresponding to the application requesting the memory block, the starting address, and the size of the allocated memory block on the memory usage register 1811. After the memory is allocated, if an application running in the TEE attempts to access the memory location of the DP accelerator 405-407, the MM 1701 can search the registry 1811 and confirm whether the memory location is allocated to the application. If so, the application is allowed to access the memory location. Otherwise, the application is denied access to the memory location. Note that once a memory block is allocated, it cannot be subsequently allocated until it is free.

[0130] In another embodiment, when MU 1705 returns memory usage information when allocating a memory block, in order to avoid transmitting the physical address through the communication channel, MU 1705 may instead return a virtual memory address to MU 1701. Here, MU 1705 may include: a physical memory address to virtual memory address mapping table. The mapping table may map the virtual memory address to the physical memory address of the memory 1703 of the DP accelerator 405. In this way, MU 1705 only discloses the virtual memory address, and thus the physical address of the memory 1703 is not disclosed on the communication channel.

[0131] In one embodiment, when the execution of the user application is completed or when the client issues a completion command, the user application may send a memory release command for the memory block associated with the user application to the DP accelerator 405. In another embodiment, a copy of the registration table is also sent to the DP accelerator 405. In one embodiment, before sending the memory release command, the MM 1701 determines whether the memory block has been allocated to the application based on the memory usage information stored in the memory usage data structure. If so, a release command is sent. Otherwise, no release command is sent (for example, the release request may be rejected).

[0132] MU 1705 receives the release command and executes the memory release. In one embodiment, MU 1705 traverses memory 1703 to locate the memory block to reset the memory buffer of the memory block. Then, MU 1705 returns the status completion and / or new memory usage information to MM 1701. MM1701 then updates (e.g., deletes entries) the memory usage registration table 1811 according to the status completion and / or the new memory usage information.

[0133] Fig.19 is a flow chart illustrating an example of a method according to one embodiment. Process 1900 may be performed by processing logic that may include software, hardware, or a combination thereof. For example, process 1900 may be performed by a host system, such as, Fig.17 Host 104. Fig.19 At box 1901, processing logic uses a security module such as a trusted platform module (TPM) of a host system to perform a secure boot. At box 1902, processing logic establishes a trusted execution environment (TEE) associated with one or more processors of the host system. At box 1903, processing logic starts a memory manager within the TEE, wherein the memory manager is configured to manage memory resources of a data processing (DP) accelerator connected to the host system via a bus, including maintaining memory usage information of a global memory of the DP accelerator. At box 1904, in response to receiving a request from an application running within the TEE to access a memory location of the DP accelerator, the processing logic allows or denies the request based on the memory usage information.

[0134] In one embodiment, the memory manager is implemented as part of a runtime library associated with the DP accelerator, which is executed within the TEE of the host system. In one embodiment, maintaining memory usage information of the global memory of the DP accelerator includes: maintaining a memory usage data structure to record memory allocation of memory blocks of the global memory of the DP accelerator. In another embodiment, the memory usage data structure includes a plurality of entries, each entry recording a memory block of the global memory of the DP accelerator that has been allocated. In another embodiment, each entry stores a starting memory address of a corresponding memory block, a size of the corresponding memory block, and a flag indicating whether the corresponding memory block has been allocated.

[0135] In another embodiment, the processing logic further receives a first request from the application to allocate a first memory block from the global memory of the DP accelerator. In response to the first request, the processing logic determines whether the first memory block has been allocated based on the memory usage information stored in the memory usage data structure without querying the DP accelerator. Then, in response to determining that the first memory block has not been allocated, the processing logic allocates the first memory block of the global memory to the application.

[0136] In another embodiment, in response to determining that the first memory block has been allocated, the processing logic further denies the first request. In another embodiment, the processing logic also receives a second request from the application to release the second memory block from the global memory of the DP accelerator. In response to the second request, the processing logic determines whether the second memory block has been allocated to the application based on the memory usage information stored in the memory usage data structure. In response to determining that the second memory block has been allocated to the application, the processing logic releases the second memory block from the global memory, otherwise denies the second request.

[0137] Fig. 20 2 is a block diagram illustrating an example of a host communicatively coupled to a DP accelerator according to one embodiment. Fig. 9 The system 900, in addition to the system 2000, can provide a root of trust service and a timestamp generation service for the DP accelerators 405-407. Fig. 20 In one embodiment, the DP accelerator 405 includes: a security unit 1020 and a time unit 2003. The security unit 1020 can provide a root of trust service to other modules / units of the DP accelerator using multiple encryption schemes, and the time unit 2003 can generate a timestamp for authenticating encryption keys to support different encryption schemes. Note that the time unit 2003 can be an independent unit or can be integrated with the security unit 1020.

[0138] In one embodiment, the security unit 1020 requires a secure time source to track when encryption keys have been authenticated or when session keys have expired. Using a clock signal from an external source for the security unit 1020 may be unsafe. For example, the clock frequency of the external source's clock may be adjusted, or the power supply of the clock may be tampered with to extend the session key beyond the intended time.

[0139] Fig.21 is a block diagram showing an example of a time unit according to one embodiment. Fig.21 , the time unit 2003 may have an independent clock generation and an independent power supply for a secure clock signal. The time unit 2003 may include: a clock generator 2101, a local oscillator 2103, a counter 2105, a power supply 2107, a clock calibrator 2109, and a time stamp generator 2111. The clock generator 2101 may generate a clock signal locally without having to derive the clock signal from an external source. The local oscillator 2103 may be connected to the clock generator 2101 to provide an accurate pulse signal. For example, the local oscillator 2103 may include: a crystal oscillator, which may provide a pulse signal with an accuracy greater than a certain threshold (e.g., 1 count per microsecond). The counter 2105 may be connected to the clock generator 2101 to count one or more count values ​​based on the clock signal generated from the clock generator 2101. The power supply 2107 may provide power to the clock generator 2101 and the time stamp generator 2111. The clock calibrator 2109 may calibrate the clock generator 2101. The timestamp generator 2111 may be coupled to the clock generator to generate a timestamp based on a clock signal.

[0140] For example, the power supply 2107 can provide stable and lasting power through a battery (e.g., a coin cell). Here, the coin cell will be located on a board outside the security unit 1020. In other embodiments, the circuit of the power supply 2107 is located outside the security unit 1020. The local oscillator 2103 may include: a high-performance crystal oscillator. The counter may include: one or more variable counters in a non-volatile memory (e.g., a variable counter of 8 bits, 16 bits, 32 bits, or 64 bits). Non-volatile memory or memory is a memory that can maintain saved data even when the power is turned off. Unlike volatile memory, non-volatile memory does not need to refresh its memory data periodically. In one embodiment, the non-volatile memory may include: a first counter that can be incremented by 1 for each single signal pulse of the local oscillator 2103. The first counter can count to a certain value, and the value can be changed by an external source or clock calibrator 2109 to adjust the value to represent the microsecond signal of the clock signal. The microseconds can then be accumulated by the second counter to generate the second signal. The third counter, the fourth counter, etc. may be used to accumulate minute, hour, day, month signals, etc. The clock generator 2101 may then generate a clock based on the accumulated signal. Based on the clock signal, the timestamp generator may generate a timestamp. The timestamp may then be formatted for various purposes. Some exemplary timestamp formats may be: yyyy-MM-dd HH:mm:ss.SSS, yyyyMMdd.HHmmssSSS, and yyyy / MM / dd HH:mm:ss. In one embodiment, a converter may convert a timestamp from one format to another. In another embodiment, the clock calibrator 2109 initially calibrates the clock generation signal to match an external source (e.g., an atomic clock) during the manufacturing phase of the DP accelerator.

[0141] Next, a security unit such as the security unit 1020 of the DP accelerator may request the time unit 2003 to generate a timestamp on a per-need basis. The security unit 1020 may then use the timestamp to timestamp key authentication, key generation, and / or key expiration. For example, if the session key is determined to be expired based on the timestamp associated with the time when the session key was generated, the channel session associated with the session key may be terminated. Subsequently, if the session key is configured to be automatically updated or updated through a user application, a new session key may be generated.

[0142] Fig. 22 1 is a block diagram illustrating an example of a security unit according to one embodiment. The security unit 1020 may be used by the DP accelerator to establish and maintain a secure channel with the host server / system to exchange commands and data. Fig. 22, the security unit 1020 may include: a key manager 1025, an encryption engine 1029, a key storage 1027 (which may include a signature key (EK) 2209), a volatile memory 2207, a non-volatile memory 2205, a processor 2203, and a random number generator 2201. The random number generator 2201 may generate a random number, such as a random number. In one embodiment, the random number generator 2201 may generate a random number based on a seed input (e.g., a timestamp). The encryption engine 1029 may perform cryptographic operations, such as encryption and decryption. The non-volatile memory 2205 and the volatile memory 2207 may be storage areas for the security unit 1020. The key storage 1027 may be a key storage area of ​​the security unit 1020, which may securely hold a unique signing credential (EC) or signing key (EK) 2209. Here, EC or EK refers to a public key (e.g., PK_RK) of a public / private encryption root key pair (e.g., PK_RK and SK_RK) randomly generated at the time of manufacture and embedded in the security unit 1020. The private root key (e.g., SK_RK) corresponding to the EK may also be embedded in the non-volatile memory 2205, however, the private root key is never released outside the security unit 1020. An exemplary key pair may be a 2048-bit RSA encryption key pair.

[0143] During the manufacturing / testing phase, the DP accelerator may be tested and configured internally, and an EK 2209 may be generated and embedded in the security unit 1020. In one embodiment, the EK 2209 may be uploaded to a trusted authentication server, where the public key or EK may be signed, and the EK's signed certificate may be used to confirm that the EK is authentic. Here, the authentication server may be a government endorsement server, a third-party trusted authentication server, or a local server.

[0144] During the deployment phase, after the DP accelerator is powered on, the EK 2209 can be read from the security unit 1020, and the EK 2209 can be confirmed as authentic locally or through an authentication server. Once the EK is successfully confirmed, the DP accelerator will be considered authentic. The confirmed EK and the private root key inside the security unit 1020 can then be used to derive other encryption keys, such as the channel session key as described above, or a temporary public / private key pair (e.g., PK_d and SK_d), etc.

[0145] A runtime kernel or kernel (or kernel object) refers to a mathematical function or computational function used to support the operation of a DP accelerator. A kernel may be a mathematical function called by a user application. For some embodiments, a kernel may be uploaded from a host server or other server to a DP accelerator for execution by the DP accelerator. An exemplary kernel may be a matrix multiplication kernel that supports matrix multiplication operations to be performed by the DP accelerator. Note that there may be hundreds of kernels, each dedicated to supporting a different mathematical function or computational function to be performed by the DP accelerator. Tracking the source of kernels, which kernels are uploaded to the DP accelerator, and which kernels are modified may be challenging. Therefore, kernel verification (or validation) and kernel certification protocols or schemes are required to ensure the true source and integrity of the kernels.

[0146] Fig.23 is a block diagram illustrating an example of a host server communicatively coupled to a DP accelerator to validate a kernel object according to one embodiment. The system 2300 may be Fig. 9 System 900. Fig.23 In one embodiment, the host server 104 includes: TEE 201, TEE 201 includes: user application 203 and runtime library 205. The runtime library 205 may include: kernel validator module 2301 and kernel certificate storage 2303. The kernel certificate storage 2303 may store the certificates (or just a list of public keys) of the kernels listed by kernel identifiers, where the certificates may be signed by a trusted certification authority (CA) or a local trusted server. The kernel validator module 2301 may validate the signed kernel object based on the kernel certificate information from the kernel certificate storage 2303.

[0147] The host server 104 is communicatively connected to a permanent storage device (e.g., a storage disk) 2305 and DP accelerators 405-407. Note that the permanent storage device 2305 may be part of the host server 104, or may be a remote storage unit. The permanent storage device 2305 may include: a kernel object 2307. Because the kernel object 2307 may come from a remote source, signing the kernel object ensures that the object comes from a trusted source. The kernel object may refer to an object of a binary file including a kernel. In one embodiment, each kernel object of the kernel object 2307 includes: an executable image of the kernel and a corresponding signature. In addition, the executable image of the kernel may be encrypted. Note that the signature is a hash operation of the kernel signed with a private key of a public / private kernel key pair corresponding to the kernel object. The signature may be confirmed using a public key corresponding to the private key used to sign the kernel. For example, the public key may be obtained from the kernel certificate of the kernel object. In some embodiments, when the kernel developer initially generates the kernel, the kernel object is signed (using the private key of the kernel developer). The signed kernel may then include a corresponding kernel certificate (eg, public key) for validation (or verification) to ensure that the kernel is authentic.

[0148] Fig.24 2400 may be implemented by: Fig.23 2300. In one embodiment, before confirmation, the user application 203 (or runtime library 205) obtains a list of public keys (e.g., PK_i, PK_j, ..., PK_n) from a trusted certification authority or a trusted signer's certificate, where the corresponding private key (e.g., SK_i, SK_j, ..., SK_n) is the private key of the kernel developer used to sign the kernel object 2307. In one embodiment, when the user application 203 (or runtime library 205) calls a kernel (identified by a kernel identifier) ​​to be executed by the DP accelerator 405 (or any other DP accelerator), the user application 203 (or runtime library 205) determines whether the kernel has been updated to the DP accelerator 405. If not, the host server 104 performs operation 2400 according to one embodiment to confirm the kernel before uploading it to the DP accelerator 405. Note that if calling one kernel will call other kernels, the runtime library 205 can call a kernel chain.

[0149] In operation 2401, the user application 203 (or the runtime library 205) (as part of the TEE 201) requests to load the kernel (as part of the kernel object 2307) onto the OS 211 based on the kernel identifier (ID). In one embodiment, the kernel ID can be a globally unique identifier (e.g., a GUID or UUID). In one embodiment, the kernel object includes: a kernel (e.g., an executable image), a kernel ID, and a signature of the kernel. The signature can be an encrypted hash value of the kernel. In another embodiment, the kernel object includes an encrypted kernel (e.g., an encrypted executable image). In operation 2402, the OS 211 retrieves the kernel object from the permanent storage 2305 by the kernel ID. In operation 2403, the OS 211 sends the kernel object back to the TEE 201 of the host server 104. In operation 2404, the kernel validator module 2301 retrieves the kernel certificate from the kernel certificate storage 2303 corresponding to the kernel ID and confirms whether the kernel object is authentic. In one embodiment, confirming the kernel includes: applying the public key to the signature of the kernel object to decrypt the signature to generate the expected hash value. The kernel validator module 2301 then generates the hash value of the kernel, and compares to determine the difference between the expected hash value and the generated hash value. If there is no difference, the signature is valid. If the signature is valid, the integrity of the kernel is confirmed, and the kernel object is considered to be authentic and provided by a trusted developer. In another embodiment, confirming the kernel includes: if the kernel is encrypted, applying the public key to the encrypted executable image of the kernel to decrypt and obtain the kernel.

[0150] In operation 2405, if the kernel (eg, executable image) is confirmed to be trusted, the kernel object is sent by the TEE 201 of the host server 104 to the DP accelerator 405 in operation 2406. Thereafter, the called kernel may be executed by one or more execution units of the DP accelerator 405.

[0151] Fig.25 is a flow chart illustrating an example of a method according to one embodiment. Process 2500 may be performed by processing logic that may include software, hardware, or a combination thereof. For example, process 2500 may be performed by a host system such as Fig.23 The host 104) executes. Fig.25, at box 2501, processing logic receives a request from an application at a runtime library executed within a trusted execution environment (TEE) of a host system to call a predetermined function to perform a predetermined operation. At box 2502, in response to the request, the processing logic identifies a kernel object associated with the predetermined function. At box 2503, the processing logic confirms the executable image of the kernel object using a public key corresponding to a private key used to sign the executable image of the kernel object. At box 2504, in response to successfully confirming the executable image of the kernel object, the processing logic transmits the confirmed executable image of the kernel object to a data processing (DP) accelerator via a bus to be executed by the DP accelerator to perform the predetermined operation.

[0152] In one embodiment, the runtime library is configured to confirm the kernel object by decrypting the signature of the kernel object using a public key corresponding to the private key, wherein the kernel object is transmitted to the DP accelerator in an unencrypted form. In another embodiment, the processing logic further confirms the integrity of the kernel object by hashing the executable image of the kernel object using a predetermined hash function.

[0153] In one embodiment, the kernel object is stored in a non-secure location of a permanent storage device. In another embodiment, the kernel object is one of many kernel objects stored in the permanent storage device, wherein the runtime library maintains a list of public keys for confirming the kernel object that are associated with the kernel object respectively.

[0154] In one embodiment, the DP accelerator includes: one or more execution units configured to execute an executable image of a kernel object to represent an application in a distributed manner. In one embodiment, the public key is obtained from a trusted server, and the public key is provided by a provider of the kernel object, and wherein the kernel object includes: a signature signed by the provider using a private key.

[0155] Fig.26 2600 is a block diagram illustrating an example of a host server communicatively coupled to a DP accelerator for kernel attestation according to one embodiment. Kernel attestation includes: confirming the integrity of a kernel that has been uploaded to the DP accelerator to ensure that the kernel has not been modified by a third party in transit. The integrity of the kernel can be confirmed by confirming the signature of the kernel. System 2600 may be Fig. 9 System 900. Fig.26In one embodiment, the host server 104 includes: TEE 201, TEE 201 includes: user application 203, runtime library 205, attestation module 2601 and kernel summary storage 2603. Kernel summary storage 2603 can store multiple kernel summaries corresponding to kernels that have been uploaded to different DP accelerators. In one embodiment, the kernel summary refers to a non-encrypted hash value of the kernel, or any type of function of the kernel (e.g., checksum, CRC, etc.). Kernel summary storage 2603 can also store a mapping of the kernel ID and DP accelerator ID of the kernel summary. The mapping can identify which kernels have been uploaded to which DP accelerators. Based on the kernel summary information from kernel summary storage 2603, the attestation module 2601 can attest the kernel based on the kernel summary information from kernel summary storage 2603.

[0156] Reference Fig.26 , the DP accelerator 405 may include: a security unit 1020, an attestation unit 2605, an execution unit 2607, and a storage device 2609. The storage device 2609 may include: a kernel object 2611. The attestation unit 2605 may communicate with the attestation module 2601 via an attestation protocol. The storage device 2609 may be one or more storage devices storing the kernel object 2611. The kernel object 2611 may include: one or more kernels (and corresponding kernel IDs) previously uploaded to the DP accelerator 405. The execution unit 2607 may execute one or more called kernels from the kernel object 2611.

[0157] In one embodiment, the user application 203 (or runtime library 205) can determine whether the kernel object has been updated to the DP accelerator 405 by generating a kernel digest to query whether the generated kernel digest is found in the kernel digest information from the kernel digest storage 2603 to determine whether the kernel is already resident on the DP accelerator. Alternatively, the kernel ID can be queried to determine whether the kernel is already resident on the DP accelerator. If found, then the certification begins, otherwise the user application 203 (or runtime library 205) confirms the kernel object (as described above) and generates a kernel digest for the kernel to be stored in the kernel summary storage 2603. Then, the user application 203 (or runtime library 205) uploads a copy of the kernel binary file to the DP accelerator. In a subsequent execution session, in response to a call to the kernel, the kernel can be certified by the user application (or runtime library).

[0158] Fig. 27 is a flow chart illustrating an exemplary attestation protocol according to one embodiment. Fig.26 Example 2700 is performed between the attestation module 2601 of the host server 104 and the attestation unit 2605 of the DP accelerator 405. Fig. 27 In operation 2701, the host server 104 requests an attestation key from the DP accelerator 405. In operation 2702, in response to the request, the DP accelerator 405 generates a public / private attestation key pair (e.g., PK_ATT, SK_ATT) and signs the PK_ATT using a private root key (e.g., SK_RK) associated with the DP accelerator 405.

[0159] In operation 2703, the DP accelerator 405 sends back a message with a PK_ATT and a signed (PK_ATT) to the host server 104. In operation 2704, the host server 104 receives the message, decrypts the signed PK_ATT using a public root key (e.g., PK_RK) associated with the DP accelerator 405, and compares the received PK_ATT with the decrypted PK_ATT to confirm the signed PK_ATT. In one embodiment, the host system has previously received the PK_RK associated with the DP accelerator from the DP accelerator or from a trusted server over the network. If the received PK_ATT matches the decrypted PK_ATT, the host server 104 has confirmed that the PK_ATT was indeed generated by the DP accelerator 405. Note that operations 2701-2704 may be performed at any time prior to operation 2705 for attestation. In other words, the same attestation key may be used for a predetermined period of time (e.g., one week), and the attestation key is not associated with any attested kernel, e.g., the attestation key may be used for many kernels.

[0160] In operation 2705, the host server 104 sends the command "CMD_DO_ATTESTATION" along with the kernel ID of the kernel to the DP accelerator 405 to request a reference. In operation 2706, in response to receiving the command request, the DP accelerator 405 measures the kernel integrity of the kernel. In one embodiment, the executable image of the kernel (as part of the kernel object 2611) is hashed to generate a kernel digest. The kernel digest is then signed with SK_ATT along with a timestamp. Here, the timestamp may be provided by a processor such as Fig. 20 The time unit 2003 is generated by the time unit.

[0161] In operation 2707, the DP accelerator 405 sends a message with the signed kernel digest along with the timestamp to the host server 104. In operation 2708, in response to receiving the message, the host server 104 decrypts the signed kernel digest along with the timestamp using PK_ATT. The host server 104 then checks the timestamp to confirm that the message has not passed for more than a predetermined period of time (e.g., one day). The host server 104 then confirms that the kernel digest belongs to a kernel previously uploaded to the DP accelerator. In one embodiment, the host server 104 receives the kernel digest from the kernel digest information query of the kernel digest memory 2603. If an entry matching the DP accelerator ID of the DP accelerator 405 is found, the kernel certification is successful. Otherwise, the certification fails. In operation 2709, the host server 104 may send the certification or confirmation result to the DP accelerator 405. Based on the result, execution of the kernel by the execution unit of the DP accelerator 405 is allowed or denied.

[0162] Fig.28A and Fig.28B 28 is a flow chart illustrating an exemplary method according to some embodiments. Processes 2800 and 2820 may be performed by processing logic that may include software, hardware, or a combination thereof. For example, process 2800 may be performed by host server 104, and process 2820 may be performed by Fig.26 The DP accelerator 405 is executed. Fig.28A At box 2801, processing logic receives a public attestation key (PK_ATT) or a signed PK_ATT from a data processing (DP) accelerator via a bus at a host system. At box 2802, processing logic uses a public root key (PK_RK) associated with the DP accelerator to confirm the PK_ATT. At box 2803, in response to successfully confirming the PK_ATT, processing logic transmits a kernel identifier (ID) to the DP accelerator to request certification of a kernel object stored in the DP accelerator. At box 2804, in response to receiving a kernel digest or a signed kernel digest corresponding to a kernel object from the DP accelerator, processing logic uses the PK_ATT to confirm the kernel digest. At box 2805, processing logic sends the confirmation result to the DP accelerator for the DP accelerator to access the kernel object based on the confirmation result.

[0163] In one embodiment, the processing logic also transmits a request for attestation to the DP accelerator, wherein the DP accelerator generates an attestation key pair having a PK_ATT and a private attestation key (SK_ATT) in response to the request for attestation. The processing logic then receives an encrypted PK_ATT signed using the private root key (SK_RK) of the DP accelerator from the DP accelerator. In another embodiment, the processing logic also decrypts the encrypted PK_ATT at the host system using a public root key (PK_RK) associated with the DP accelerator, and confirms that the PK_ATT received from the DP accelerator is the same as the decrypted PK_ATT. In one embodiment, the public root key (PK_RK) associated with the DP accelerator can be received by the server 104 from a trusted server over a network.

[0164] In one embodiment, the kernel digest is generated by hashing the executable image of the kernel object by the DP accelerator. In another embodiment, the kernel digest is signed using a private attestation key (SK_ATT) corresponding to the PK_ATT. In another embodiment, the kernel digest is signed together with a timestamp generated at a certain point in time, where the timestamp is used by the host system to confirm that the kernel digest was generated within a predetermined time period. In one embodiment, the host system receives the PK_RK associated with the DP accelerator from a predetermined trusted server over a network.

[0165] Reference Fig.28B In block 2821, in response to receiving an attestation request from a host system, processing logic generates an attestation key pair having a public attestation key (PK_ATT) and a private attestation key (SK_ATT) at a data processing (DP) accelerator. At block 2822, processing logic transmits the PK_ATT or a signed PK_ATT from the DP accelerator to the host system, wherein the DP accelerator is coupled to the host system via a bus. At block 2823, processing logic receives a kernel identifier (ID) identifying a kernel object from the host system, wherein the kernel ID is received in response to successfully confirming the PK_ATT. At block 2824, in response to the kernel ID, processing logic generates a kernel digest by hashing an executable image of the kernel object. At block 2825, processing logic transmits the kernel digest or the signed kernel digest to the host system to allow the host system to confirm and attest the kernel object before accessing the kernel object to be executed within the DP accelerator.

[0166] In one embodiment, the processing logic also signs the PK_ATT using a private root key (SK_RK) associated with the DP accelerator and sends the signed PK_ATT to the host system to allow the host system to confirm that the PK_ATT is from the DP accelerator. In another embodiment, the host system is configured to decrypt the signed PK_ATT using a public root key (PK_RK) corresponding to the SK_RK and confirm the PK_ATT by comparing the PK_ATT received from the DP accelerator with the decrypted PK_ATT.

[0167] In one embodiment, the processing logic also signs the kernel digest using SK_ATT and sends the signed kernel digest to the host system to allow the host system to confirm that the kernel digest is sent by the DP accelerator. In another embodiment, the host system is configured to decrypt the signed kernel digest using PK_ATT and confirm the kernel digest by comparing the kernel digest received from the DP accelerator with the decrypted kernel digest. In another embodiment, the processing logic also generates a timestamp and signs the kernel digest together with the timestamp, wherein the timestamp is used by the host system to confirm the freshness of the kernel digest.

[0168] The DP accelerator communicatively coupled to the host server may be further verified as the DP accelerator expected by the host server. This assurance may be achieved through a third-party trusted server and / or certification authority.

[0169] Fig.29 2900 is a block diagram illustrating an example of a host server communicatively coupled to a trusted server and a DP accelerator according to one embodiment. DP accelerator verification refers to confirming the certificate of the DP accelerator from the trusted server. The trusted server may be a third-party certification authority or a local server. The system 2900 may be Fig. 9 System 900. Fig.29 In one embodiment, the host server 104 includes: TEE 201, TEE 201 includes: key confirmation module 2901 and PK_RK(s) 2903. PK_RK(s) 2903 can store a public key associated with the DP accelerator. The key confirmation module 2901 can confirm the public key of the DP accelerator via a trusted server (such as trusted server 2921). The trusted server 2921 can include: DP accelerator certificate 2923.

[0170] Reference Fig.29, the DP accelerator may include: a security unit 1020, and the security unit 1020 may include: a key confirmation unit 2905 and a memory 2913. The memory 2913 may include: a SK_RK 2907, an accelerator ID (e.g., a serial number and / or a UUID) 2909, and a version number 2911. The version number may represent a firmware version of the DP accelerator 405, and the version number may be updated according to the firmware version of the DP accelerator 405. The key confirmation unit 2905 may communicate with a key confirmation module (such as a key confirmation module 2901 of the host server 104) to provide the host server 104 with information about the DP accelerator (e.g., an accelerator ID 2909 and / or a version number 2911).

[0171] As a preliminary matter, in one embodiment, the host server 104 may already have a copy of the PK_RK associated with the DP accelerator 405. However, when the DP accelerator 405 is initially introduced to the host server 104, or when the DP accelerator 405 is reintroduced, the PK_RK of the DP accelerator 405 may need to be authenticated or reauthenticated against the host server 104.

[0172] Fig.30 3000 is a flow chart illustrating an exemplary DP accelerator verification protocol according to one embodiment. Protocol 3000 may be an exemplary embodiment of validating the PK_RK of DP accelerator 405. Figure 29-Figure 30 , the protocol 3000 can be executed between the key confirmation module 2901 of the host server 104 and the key confirmation unit 2905 of the DP accelerator 405.

[0173] Reference Fig.30 In operation 3001, the host server 104 requests the accelerator ID from the accelerator 405. In operation 3002, in response to the request, the DP accelerator 405 returns the accelerator ID 2909 to the host server 104 (e.g., the serial number or UUID of the DP accelerator). In operation 3003, the host server 104 sends the received accelerator ID to the trusted server 2921. Here, the trusted server 2921 can be a certification authority, a third-party trusted server, or a local trusted server with certificate information about the DP accelerator 405. In operation 3004, in response to the request, the trusted server 2921 sends the certificate associated with the accelerator ID of the DP accelerator 405 to the host server 104.

[0174] In operation 3005, the host server 104 extracts certificate information (e.g., public key PK_RK) from the certificate associated with the accelerator ID and stores the certificate information in a local memory, such as PK_RK(s) 2903, together with the accelerator ID. In one embodiment, the extracted PK_RK of the DP accelerator 405 that has been previously obtained may be confirmed against an existing PK_RK for the DP accelerator 405 (e.g., an existing PK_RK that is part of PK_RK(s) 2903). Optionally, the certificate information may be confirmed by confirming a certificate chain of a trusted server 2921. A certificate chain is an ordered list of certificates that enables a recipient to confirm whether a sender and a trusted server (e.g., a certification authority) are trustworthy. In operation 3006, based on the confirmation and / or the certificate information (e.g., PK_RK), the host server 104 then requests to establish a secure connection (e.g., one or more secure channels) with the DP accelerator 405.

[0175] Note that thereafter, the host server 104 may use PK_RK to decrypt secure messages sent by the DP accelerator 405, where the secure messages were encrypted by SK_RK. These messages may include: a confirmation message associated with the attestation key pair (e.g., PK_ATT, SK_ATT) to confirm the signature of the public attestation key to attest the kernel object stored in the DP accelerator, as described above. The message may also include: a confirmation message for the temporary public / private key pair (e.g., PK_d, SK_d), and the session key for the DP accelerator 405, as described above. In some embodiments, the randomly generated number is sent along with the SK_RK. Fig.29 The version number 2911 of the session can be used to generate a certification key pair and a temporary public key / private key pair. In this case, if the version number 2911 is updated due to a firmware upgrade, for example, the certification key pair and the temporary public key / private key pair of the session will expire.

[0176] DP accelerators can also be based on the accelerator version number ( Fig.29 The version number 2911 of the accelerator) and / or a random number generated by a random number generator to generate a public / private certification key pair (e.g., PK_ATT, SK_ATT). Similarly, the accelerator version number ( Fig.29 version number 2911) and / or a random number generated by a random number generator to generate a temporary public / private key pair (e.g., PK_d, SK_d, where SK_d is used to establish a session key associated with a communication session between the host system and the DP accelerator).

[0177] Fig.31 is a flow chart illustrating an example of a method according to one embodiment. Process 3100 may be performed by processing logic that may include software, hardware, or a combination thereof. For example, process 3100 may be performed by a host system such as, Fig.29 The host 104) executes. Fig.31 At box 3101, processing logic receives an accelerator ID that uniquely identifies the DP accelerator from a DP accelerator at a host system, wherein the host system is connected to the DP accelerator via a bus. At box 3102, processing logic transmits the accelerator ID to a predetermined trusted server via a network. At box 3103, processing logic receives a certificate from a predetermined trusted server via a network, wherein the certificate includes: a public key (PK_RK) associated with the DP accelerator. At box 3104, optionally, in one embodiment, processing logic confirms that the certificate is associated with a predetermined trusted server, for example, by confirming a certificate chain of the trusted server. At box 3105, process logic extracts a public root key (PK_RK) from the certificate and confirms the extracted PK_RK using the PK_RK previously sent by the DP accelerator to authenticate that the DP accelerator is indeed the DP accelerator it claims to be. At box 3106, processing logic establishes a secure channel with the DP accelerator based on the confirmation using the PK_RK to securely exchange data between the host system and the DP accelerator.

[0178] In one embodiment, the DP accelerator includes: one or more execution units for performing data processing operations on behalf of an application hosted in a host system. In one embodiment, a predetermined trusted server is associated with a provider of the application. In one embodiment, the predetermined trusted server is associated with a provider of the DP accelerator. In one embodiment, a signature generated for the DP accelerator is also confirmed using PK_RK.

[0179] In another embodiment, the host system utilizes PK_RK to establish a session key associated with a communication session between the host system and the DP accelerator. In another embodiment, the host system utilizes PK_RK to confirm a signature of a public certification key to certify a kernel object stored in the DP accelerator.

[0180] Note that some or all of the components described and shown above may be implemented in software, hardware, or a combination thereof. For example, such a component may be implemented as software installed and stored in a permanent storage device that may be loaded and executed by a processor (not shown) in a memory to perform the processes or operations described throughout this application. Alternatively, such a component may be implemented as executable code programmed or embedded into dedicated hardware, such as an integrated circuit (e.g., a dedicated IC or ASIC), a digital signal processor (DSP), or a field programmable gate array (FPGA), which may be accessed from an application via a corresponding driver and / or an operating system. In addition, such a component may be implemented as specific hardware logic in a processor or processor core as part of an instruction set that may be accessed by a software component via one or more specific instructions.

[0181] Fig.32 1 is a block diagram illustrating an example of a data processing system that may be used with one embodiment of the present invention. For example, system 1500 may represent any of the above-described data processing systems that perform any of the above-described processes or methods, such as a client device or server (e.g., clients 101-102 and server 104, as described above) as described above.

[0182] System 1500 may include many different components. These components may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules suitable for use on a circuit board such as a motherboard or plug-in card of a computer system, or otherwise incorporated into a chassis of a computer system.

[0183] It should also be noted that system 1500 is intended to illustrate a high-level view of many components of a computer system. However, it should be understood that additional components may be present in some implementations, and in addition, different arrangements of the components shown may appear in other implementations. System 1500 may represent a desktop, laptop computer, tablet computer, server, mobile phone, media player, personal digital assistant (PDA), Smartwatch, personal communicator, gaming device, network router or hub, wireless access point (AP) or repeater, set-top box or a combination thereof. In addition, although only a single machine or system is shown, the term "machine" or "system" should also be understood to include any set of machines or systems that individually or collectively execute a set (or multiple sets) of instructions to execute any one or more methods discussed herein.

[0184] In one embodiment, system 1500 includes: processor 1501, memory 1503 and devices 1505-1508 via bus or interconnect 1510. Processor 1501 may represent a single processor or multiple processors including a single processor core or multiple processor cores. Processor 1501 may represent one or more general-purpose processors, such as a microprocessor, a central processing unit (CPU), etc. More specifically, processor 1501 may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. Processor 1501 may also be one or more special-purpose processors, such as an application-specific integrated circuit (ASIC), a cellular or baseband processor, a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, a graphics processor, a network processor, a communication processor, an encryption processor, a coprocessor, an embedded processor, or any other type of logic capable of processing instructions.

[0185] Processor 1501 may be a low power multi-core processor socket (such as an ultra low voltage processor) that may act as a main processing unit and central hub for communicating with various components of the system. Such a processor may be implemented as a system on a chip (SoC). Processor 1501 is configured to execute instructions for performing the operations and steps discussed herein. System 1500 may also include a graphics interface that communicates with an optional graphics subsystem 1504 that may include a display controller, a graphics processor, and / or a display device.

[0186] The processor 1501 may communicate with the memory 1503, which, in one embodiment, may be implemented via a plurality of memory devices to provide a fixed amount of system memory. The memory 1503 may include: one or more volatile storage (or memory) devices, such as random access memory (RAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), static RAM (SRAM), or other types of storage devices. The memory 1503 may store information including sequences of instructions executed by the processor 1501 or any other device. For example, executable code and / or data of various operating systems, device drivers, firmware (e.g., input-output basic system or BIOS), and / or applications may be loaded into the memory 1503 and executed by the processor 1501. The operating system may be any type of operating system, for example, of Operating system, Apple Mac of Or other real-time or embedded operating systems, such as VxWorks.

[0187] System 1500 may also include IO devices such as devices 1505-1508, including: network interface device 1505, optional input device 1506, and other optional IO devices 1507. Network interface device 1505 may include: a wireless transceiver and / or a network interface card (NIC). The wireless transceiver may be a WiFi transceiver, an infrared transceiver, a Bluetooth transceiver, a WiMax transceiver, a wireless cellular phone transceiver, a satellite transceiver (e.g., a global positioning system (GPS) transceiver) or other radio frequency (RF) transceiver, or a combination thereof. The NIC may be an Ethernet card.

[0188] Input device 1506 may include: a mouse, a touchpad, a touch-sensitive screen (which may be integrated with display device 1504), a pointing device such as a stylus, and / or a keyboard (e.g., a physical keyboard or a virtual keyboard displayed as part of the touch-sensitive screen). For example, input device 1506 may include: a touch screen controller coupled to a touch screen. The touch screen and touch screen controller may, for example, use any of a variety of touch-sensitive technologies to detect contact and movement or disconnection thereof, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more contact points with the touch screen.

[0189] IO devices 1507 may include: audio devices. Audio devices may include: speakers and / or microphones to facilitate voice-enabled functions, such as voice identification, voice replication, digital recording, and / or telephone functions. Other IO devices 1507 may also include: universal serial bus (USB) ports, parallel ports, serial ports, printers, network interfaces, bus bridges (e.g., PCI-PCI bridges), sensors (e.g., motion sensors such as accelerometers, gyroscopes, magnetometers, light sensors, compasses, proximity sensors, etc.), or combinations thereof. Devices 1507 may also include: imaging processing subsystems (e.g., cameras), which may include: optical sensors (e.g., charge coupled devices (CCDs) or complementary metal oxide semiconductor (CMOS) optical sensors) for facilitating camera functions (e.g., recording photos and video clips). Certain sensors may be coupled to interconnect 1510 via a sensor hub (not shown), while other devices (such as keyboards or thermal sensors) may be controlled by embedded controllers (not shown), depending on the specific configuration or design of system 1500.

[0190] In order to provide permanent storage of information such as data, applications, one or more operating systems, etc., a mass storage (not shown) may also be connected to the processor 1501. In various embodiments, in order to enable thinner and lighter system designs and improve system responsiveness, such mass storage may be implemented via a solid-state device (SSD). However, in other embodiments, the mass storage may be implemented primarily using a hard disk drive (HDD) and a small amount of SSD memory to act as an SSD cache to enable non-volatile storage of context states and other such information during power-off events, so that fast power-up can occur when system activities are restarted. A flash memory device may also be connected to the processor 1501, for example, via a serial peripheral interface (SPI). The flash memory device may provide non-volatile storage of system software, including: basic input / output software (BIOS) and other firmware for the system.

[0191] The storage device 1508 may include: a computer-accessible storage medium 1509 (also referred to as a machine-readable storage medium or a computer-readable medium) on which one or more sets of instructions or software (e.g., modules, units, and / or logic 1528) are stored, implementing any one or more of the methods or functions described herein. The processing module / unit / logic 1528 may represent any of the above components, for example, Figure 2 Host server 104, Figure 2 Runtime library 205, Figure 4 DP Accelerator 405, Figure 4 IO manager 401 or IO interface 415, Fig. 9 and Fig.14 HCM 901 or ACM 915, and Fig.17 MM 1701, Fig. 20 The security unit 1020 and the time unit 2003 are as described above. The processing module / unit / logic 1528 may also reside completely or at least partially in the memory 1503 and / or in the processor 1501 during the execution of the data processing system 1500, and the memory 1503 and the processor 1501 also constitute a machine-accessible storage medium. The processing module / unit / logic 1528 may also be transmitted or received over a network via the network interface device 1505.

[0192] Computer-readable storage medium 1509 may also be used to permanently store some of the software functions described above. Although computer-readable storage medium 1509 is shown as a single medium in the exemplary embodiment, the term "computer-readable storage medium" should be considered to include: a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more sets of instructions. The term "computer-readable storage medium" should also be considered to include: any medium capable of storing or encoding a set of instructions executed by a machine and causing the machine to perform any one or more methods of the present invention. Therefore, the term "computer-readable storage medium" should be considered to include, but is not limited to: solid-state memory, optical and magnetic media, or any other non-temporary machine-readable medium.

[0193] The processing modules / units / logic 1528, components, and other features described herein may be implemented as discrete hardware components or integrated into the functionality of hardware components (such as ASICS, FPGAs, DSPs, or similar devices). In addition, the processing modules / units / logic 1528 may be implemented as firmware or functional circuits within a hardware device. In addition, the processing modules / units / logic 1528 may be implemented in any combination of hardware devices and software components.

[0194] Note that while system 1500 is illustrated using various components of a data processing system, system 1500 is not intended to represent any particular architecture or manner of interconnecting the components; as such details are not germane to embodiments of the present invention. It will also be understood that network computers, handheld computers, mobile phones, servers, and / or other data processing systems having fewer or perhaps more components may also be used with embodiments of the present invention.

[0195] Some portions of the preceding detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities.

[0196] It should be remembered, however, that all of these terms and similar terms will be associated with the appropriate physical quantities and are merely convenient labels adapted for these quantities. Unless clearly indicated otherwise from the above discussion, it should be understood that throughout the specification, discussions utilizing terms such as those described in the following claims refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memory into other data similarly represented as physical quantities within the computer system's memory or registers or other such information storage, transmission, or display devices.

[0197] The techniques shown in the figures can be implemented using code and data stored and executed on one or more electronic devices. Such electronic devices use computer-readable media, such as non-transitory computer-readable storage media (e.g., magnetic disks, optical disks, random access memory, read-only memory, flash memory devices, phase-change memory) and transitory computer-readable transmission media (e.g., electrical, optical, acoustic or other forms of propagated signals - e.g., carrier waves, infrared signals, digital signals).

[0198] The program code for implementing the method of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0199] The processes or methods depicted in the preceding figures may be performed by processing logic comprising hardware (e.g., circuitry, dedicated logic, etc.), firmware, software (e.g., embodied on a non-transitory computer-readable medium), or a combination of both. Although the processes or methods are described above in terms of some sequential operations, it should be understood that some of the operations described may be performed in a different order. Furthermore, some operations may be performed in parallel rather than sequentially.

[0200] In the foregoing description, embodiments of the present invention have been described with reference to specific exemplary embodiments of the present invention. It is apparent that various modifications may be made thereto without departing from the broader spirit and scope of the present invention as set forth in the appended claims. Therefore, the description and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. A computer-implemented method for verifying a kernel object, wherein: The kernel object is to be executed by a data processing DP accelerator connected to a host system, and the method comprises: At a runtime library executed in a trusted execution environment (TEE) of the host system, receiving a request from an application to call a predetermined function to perform a predetermined operation; In response to the request, identifying a kernel object associated with the predetermined function, the kernel object being an object of a binary file including the predetermined function; Determining, using a kernel summary memory, whether the executable image of the kernel object has been uploaded to the DP accelerator; The kernel summary memory stores kernel summaries of kernel objects previously uploaded to the DP accelerator. In response to the executable image not being uploaded to the DP accelerator, confirming the executable image using a public key corresponding to a private key, the private key being used to sign the executable image; and in response to successfully confirming the executable image, determining a kernel digest of the kernel object based on the executable image, storing the kernel digest of the kernel object in the kernel digest memory, and transmitting the executable image to the DP accelerator through a bus, so that the DP accelerator executes the executable image to perform the predetermined operation; In response to the executable image having been uploaded to the DP accelerator, a kernel digest of the kernel object in the kernel digest memory is verified for consistency with the kernel digest of the kernel object fed back by the DP accelerator; and a verification result of the consistency verification is fed back to the DP accelerator through a bus, so that the DP accelerator performs the predetermined operation based on the verification result.

2. The method according to claim 1, wherein: The runtime library is configured as: The kernel object is validated by decrypting a signature of the kernel object using the public key corresponding to the private key, wherein the kernel object is to be transmitted to the DP accelerator in an unencrypted form.

3. The method according to claim 2, further comprising: The integrity of the kernel object is confirmed by performing a hash operation on the executable image of the kernel object using a predetermined hash function.

4. The method according to claim 1, wherein: The kernel object is stored in an unsecure location in persistent storage.

5. The method according to claim 4, wherein: The kernel object is one of a plurality of kernel objects stored in the persistent storage device, wherein the runtime library maintains a list of public keys respectively associated with the kernel objects and used to authenticate the kernel objects.

6. The method according to claim 1, wherein: The DP accelerator includes one or more execution units, and the one or more execution units are configured to: The executable image of the kernel object is executed on behalf of the application in a distributed manner.

7. The method according to claim 1, wherein: The public key is obtained from a trusted server, and the public key is provided by a provider of the kernel object, and wherein the kernel object includes: a signature signed by the provider using the private key.

8. A non-transitory machine-readable medium having instructions stored therein, the instructions, when executed by a processor, causing the processor to perform operations comprising: At a runtime library executed in a trusted execution environment TEE of a host system, receiving a request from an application to call a predetermined function to perform a predetermined operation; In response to the request, identifying a kernel object associated with the predetermined function, the kernel object being an object of a binary file including the predetermined function; Determining, using a kernel summary memory, whether the executable image of the kernel object has been uploaded to a data processing DP accelerator; In response to the executable image not being uploaded to the DP accelerator, validating the executable image using a public key corresponding to a private key, the private key being used to sign the executable image; as well as In response to successfully validating the executable image, determining a kernel digest of the kernel object based on the executable image, storing the kernel digest of the kernel object to the kernel digest memory, and transmitting the executable image to the DP accelerator via a bus for execution by the DP accelerator to perform the predetermined operation; In response to the executable image being uploaded to the DP accelerator, verifying the consistency of the kernel digest of the kernel object in the kernel digest memory with the kernel digest of the kernel object fed back by the DP accelerator; The verification result of the consistency verification is fed back to the DP accelerator through a bus, so that the DP accelerator performs the predetermined operation based on the verification result.

9. The machine-readable medium of claim 8, wherein: The runtime library is configured as: The kernel object is validated by decrypting a signature of the kernel object using the public key corresponding to the private key, wherein the kernel object is to be transmitted to the DP accelerator in an unencrypted form.

10. The machine-readable medium of claim 9, wherein: The operations also include: The integrity of the kernel object is confirmed by performing a hash operation on the executable image of the kernel object using a predetermined hash function.

11. The machine-readable medium of claim 8, wherein: The kernel object is stored in an unsecure location in persistent storage.

12. The machine-readable medium of claim 11, wherein: The kernel object is one of a plurality of kernel objects stored in the persistent storage device, wherein the runtime library maintains a list of public keys respectively associated with the kernel objects and used to authenticate the kernel objects.

13. The machine-readable medium of claim 8, wherein: The DP accelerator includes one or more execution units, and the one or more execution units are configured to: The executable image of the kernel object is executed on behalf of the application in a distributed manner.

14. The machine-readable medium of claim 8, wherein: The public key is obtained from a trusted server, and the public key is provided by a provider of the kernel object, and wherein the kernel object includes: a signature signed by the provider using the private key.

15. Host system, including: processor; as well as a memory coupled to the processor to store instructions that, when executed by the processor, cause the processor to perform operations comprising: At a runtime library executed in a trusted execution environment TEE of the host system, receiving a request from an application to call a predetermined function to perform a predetermined operation; In response to the request, identifying a kernel object associated with the predetermined function, the kernel object being an object of a binary file including the predetermined function; Determining, using a kernel summary memory, whether the executable image of the kernel object has been uploaded to a data processing DP accelerator; In response to the executable image not being uploaded to the DP accelerator, validating the executable image using a public key corresponding to a private key, the private key being used to sign the executable image; and In response to successfully validating the executable image, determining a kernel digest of the kernel object based on the executable image, storing the kernel digest of the kernel object to the kernel digest memory, and transmitting the executable image to the DP accelerator via a bus for execution by the DP accelerator to perform the predetermined operation; In response to the executable image being uploaded to the DP accelerator, verifying the consistency of the kernel digest of the kernel object in the kernel digest memory with the kernel digest of the kernel object fed back by the DP accelerator; The verification result of the consistency verification is fed back to the DP accelerator through a bus, so that the DP accelerator performs the predetermined operation based on the verification result.

16. The system of claim 15, wherein: The runtime library is configured as: The kernel object is validated by decrypting a signature of the kernel object using the public key corresponding to the private key, wherein the kernel object is to be transmitted to the DP accelerator in an unencrypted form.

17. The system of claim 16, wherein: The operations also include: The integrity of the kernel object is confirmed by performing a hash operation on the executable image of the kernel object using a predetermined hash function.

18. The system of claim 15, wherein: The kernel object is stored in an unsecure location in persistent storage.

19. The system of claim 18, wherein: The kernel object is one of a plurality of kernel objects stored in the persistent storage device, wherein the runtime library maintains a list of public keys respectively associated with the kernel objects and used to authenticate the kernel objects.

20. The system of claim 15, wherein: The DP accelerator includes one or more execution units, and the one or more execution units are configured to: The executable image of the kernel object is executed on behalf of the application in a distributed manner.

21. The system of claim 15, wherein: The public key is obtained from a trusted server, and the public key is provided by a provider of the kernel object, and wherein the kernel object includes: a signature signed by the provider using the private key.

22. Computer program product, comprising a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images