An adapter, a heterogeneous trusted execution environment system and a data transmission method

Abstract

The application discloses an adapter, a heterogeneous trusted execution environment system and a data transmission method, and relates to the technical field of confidential computing.The adapter comprises a processor, a front-end interface and a back-end interface.The processor comprises a trusted root interface, a protocol processor, a key processor and a register.The protocol processor establishes a trusted channel with a host, determines a remote attestation report based on a private key and sends the remote attestation report to the host, the key processor generates a shared key to build a trusted execution environment after the host is verified, and the register stores the shared key to establish a data transmission channel between the host and a heterogeneous acceleration device.By adding an independent adapter, the heterogeneous acceleration device does not need to have confidential computing capability, and the host hardware does not need to be modified, thus solving the problems of poor compatibility and high cost caused by hardware modification in conventional solutions, and achieving the technical effects of including ordinary heterogeneous acceleration devices into a trusted execution environment, strong compatibility, good versatility, no hardware modification and cost reduction.

Description

Technical Field

[0001] This application relates to the field of confidential computing technology, and in particular to an adapter, a heterogeneous trusted execution environment system, and a data transmission method. Background Technology

[0002] In the field of confidential computing, to support collaborative computing between central processing units (CPUs) and heterogeneous acceleration devices such as graphics processing units (GPUs), neural processing units (NPUs), and field-programmable gate arrays (FPGAs), data must be available but not visible. This necessitates the construction of a trusted execution environment across these heterogeneous devices. Conventional solutions rely on specific models of heterogeneous acceleration devices that support confidential computing capabilities, thus limiting their compatibility with specific hardware. Alternatively, hardware modifications can be made on the CPU side, but these are costly and prone to compatibility issues with existing systems. Therefore, how to construct a heterogeneous trusted execution environment with strong compatibility and versatility is a crucial technical problem that those skilled in the art urgently need to solve. Summary of the Invention

[0003] This application provides an adapter, a heterogeneous trusted execution environment system, and a data transmission method to at least solve the problems in related technologies, such as poor compatibility due to reliance on heterogeneous acceleration devices that support confidential computing of specific models, and high costs and impact on system compatibility due to CPU-side hardware modifications.

[0004] This application provides an adapter, including a processor, a front-end interface, and a back-end interface; it connects to a host via the front-end interface; and it connects to the processor and at least one heterogeneous acceleration device via the back-end interface; the processor includes a root trusted interface, a protocol processor, a key processor, and registers; The trusted root interface is used to obtain the private key; The protocol processor is connected to the front-end interface, the trusted root interface, the key processor, and the register, respectively, and is used to establish a trusted channel with the host, determine the remote authentication report with the host based on the private key, and send the remote authentication report to the host through the trusted channel; A key processor is used to generate a shared key after the host verifies the remote proof report, in order to build a trusted execution environment; The register is connected to the key processor to store the shared key, thereby establishing a data transmission channel between the host and at least one heterogeneous acceleration device.

[0005] This application also provides a heterogeneous trusted execution environment system, including a host, an adapter, and at least one heterogeneous acceleration device; The host and at least one heterogeneous acceleration device are connected to the adapter.

[0006] This application also provides a data transmission method applied to an adapter; the adapter includes a processor, a front-end interface, and a back-end interface; it is connected to a host via the front-end interface; and connected to the processor and at least one heterogeneous acceleration device via the back-end interface; the processor includes a trusted root interface, a protocol processor, a key processor, and a register; the protocol processor is connected to the front-end interface, the trusted root interface, the key processor, and the register respectively; the register is connected to the key processor; the method includes: The control protocol processor establishes a trusted channel with the host, determines the remote authentication report with the host based on the private key, and sends the remote authentication report to the host through the trusted channel; The control key processor generates a shared key after the host verifies the remote proof report to build a trusted execution environment; The control register stores the shared key to establish a data transmission channel between the host and the heterogeneous acceleration device.

[0007] This application addresses several key challenges. First, by adding an adapter independent of the host and heterogeneous acceleration devices as an intermediary bridge, it eliminates the need for each heterogeneous acceleration device to possess its own confidential computing capabilities. This allows for the integration of these devices into a trusted execution environment without requiring modifications to the hardware architecture of the host and the heterogeneous acceleration devices, thus reducing hardware modification costs and improving compatibility. Second, the composition of the processor's internal components ensures the reliability and efficiency of the trusted execution environment construction. Furthermore, the trusted root interface provides a trusted private key to the adapter and the connected heterogeneous acceleration devices, enabling heterogeneous acceleration devices that previously lacked a trusted root to participate in authentication based on the adapter's trusted root. Third, the protocol processor determines the remote authentication report based on the private key, allowing the host to verify the security status of the heterogeneous acceleration devices, ensuring that data transmission and computation occur within a trusted environment. By establishing a trusted channel, a secure control communication link is provided between the adapter and the host, ensuring that identity certificates and measurement information are not stolen or tampered with during remote authentication, guaranteeing the integrity and confidentiality of the authentication process. Furthermore, the key processor generates a shared key after the host remote authentication is successful. This ensures that key generation only occurs when the host confirms the heterogeneous acceleration device is secure and trustworthy, providing encryption protection for data transmission and preventing unauthorized entities from stealing or tampering with data. Finally, the register stores the shared key, enabling the adapter to establish a secure data transmission channel between the host and the heterogeneous acceleration device based on the shared key. This protects the data transmission path, preventing data leakage or unauthorized access during transmission, forming a trusted execution environment across the host and heterogeneous acceleration device, and achieving secure data transmission and storage.

[0008] Because this application adds an adapter between the host and the heterogeneous acceleration device, and integrates four hardware units—a trusted root interface, a protocol processor, a key processor, and registers—within the processor, the entire process does not require the heterogeneous acceleration device itself to have confidential computing capabilities, nor does it require any modification to the hardware architecture of the CPU or the heterogeneous acceleration device. Therefore, it solves the technical problems of poor compatibility caused by relying on specific models of heterogeneous acceleration devices that support confidential computing, and the high cost and impact on system compatibility caused by CPU-side hardware modifications in conventional solutions. It achieves the technical effects of incorporating ordinary heterogeneous acceleration devices into a trusted execution environment, strong compatibility, good versatility, no hardware modification required, and reduced costs. Attached Figure Description

[0009] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of the structure of an adapter provided in an embodiment of this application; Figure 2 This is a schematic diagram of another adapter provided in an embodiment of this application; Figure 3 This application provides a schematic diagram of the structure for decrypting data on the adapter side when the host supports the device interface security protocol. Figure 4 A schematic diagram of an adapter structure where the host does not support the device interface security protocol is provided in an embodiment of this application; Figure 5 This application provides a schematic diagram of an adapter connecting multiple heterogeneous acceleration devices according to an embodiment of the present application. Figure 6 A schematic diagram of a single-confidential virtual machine supporting multiple heterogeneous acceleration devices is provided in an embodiment of this application; Figure 7 This application provides a schematic diagram illustrating the structure of a single heterogeneous acceleration device where one target device interface supports a confidential virtual machine. Figure 8 This application provides a schematic diagram illustrating the structure of a single heterogeneous acceleration device with multiple target device interfaces supporting a confidential virtual machine, as shown in the embodiments of this application. Figure 9 This application provides a schematic diagram of a heterogeneous confidential computing adapter separated from a TPM module. Figure 10 A flowchart illustrating a data transmission method provided in an embodiment of this application; Figure 11 This is a schematic diagram of a data transmission device provided in an embodiment of this application. Detailed Implementation

[0011] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0012] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0013] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0014] Figure 1 This is a schematic diagram of the structure of an adapter provided in an embodiment of this application, such as... Figure 1 As shown, adapter 1 includes processor 2, front-end interface 3 and back-end interface 4; it is connected to host 5 through front-end interface 3; and it is connected to processor 2 and at least one heterogeneous acceleration device 6 through back-end interface 4; processor 2 includes trusted root interface 7, protocol processor 8, key processor 9 and register 10; Trusted root interface 7 is used to obtain the private key; Protocol processor 8 is connected to front-end interface 3, trusted root interface 7, key processor 9 and register 10 respectively, and is used to establish a trusted channel with host 5, determine the remote proof report with host 5 based on the private key, and send the remote proof report to host 5 through the trusted channel; Key processor 9 is used to generate a shared key after the remote proof report is verified by host 5, in order to build a trusted execution environment; Register 10 is connected to key processor 9 and is used to store a shared key to establish a data transmission channel between host 5 and at least one heterogeneous acceleration device 6.

[0015] Specifically, the adapter sits between the host and the heterogeneous acceleration device, acting as an intermediary bridge connecting them. The host can be a computing device running virtual machines, such as confidential virtual machines, which can run on confidential computing hardware. The heterogeneous acceleration device can consist of GPUs, Data Processing Units (DPUs), NPUs, FPGAs, and other traditional devices that may not have confidential computing protection capabilities. The adapter, or heterogeneous confidential computing adapter, can be constructed from any of the following: FPGA, Application Specific Integrated Circuit (AISC), or System on Chip (SoC). Therefore, the system implementation is flexible and easy, effectively saving costs. The adapter acts as an intermediary bridge between the host and the heterogeneous acceleration device, allowing ordinary heterogeneous acceleration devices to be incorporated into the trusted execution environment without requiring the heterogeneous acceleration device itself to have confidential computing capabilities or any modification to the hardware architecture of the host or the heterogeneous acceleration device.

[0016] Regarding the adapter, it can be attached to the host, to a heterogeneous acceleration device, or even implemented as a separate hardware motherboard. The configuration can be adjusted according to the actual situation.

[0017] The processor can specifically be a secure processor running within the adapter's Trusted Execution Environment (TEE). The TEE can be implemented using memory encryption or access control isolation methods, and the processor is the adapter's core computing and control unit. The processor integrates a trusted root interface, protocol processor, key processor, and registers. The adapter exposes bus interfaces, such as the Peripheral Component Interconnect Express (PCIe) bus interface, which is divided into front-end and back-end interfaces. The front-end interface connects to the host bus, such as the PCIe bus. The back-end interface connects to heterogeneous acceleration devices, which are directly plugged into the adapter's physical interface, such as the PCIe physical interface, ensuring direct physical coupling between the heterogeneous acceleration devices and the adapter.

[0018] The Trusted Root Interface (TPI) is the interface between the processor and the Trusted Root for communication. In this embodiment, it corresponds to the Trusted Platform Module (TPM) proxy within the security processor. The TPI is used to obtain the identity certificate and private key representing the TEE environment from the Trusted Root. The private key is used for signing remote proof reports and negotiating shared keys. Furthermore, TPM management can derive multiple keys based on the Trusted Root, providing key derivation functionality for key negotiation of the Security Protocol and Data Model (SPDM) and the Trusted Execution Environment Device Interface Security Protocol (TDISP), ensuring the security of related keys. The TPI is used to obtain the private key. The TPI can connect to the Trusted Root to obtain the identity certificate and private key representing the Trusted Execution Environment provided by the Trusted Root, which are used for subsequent remote proof signing and shared key negotiation. The Trusted Root can be a TPM module, which is essentially a Trusted Computing Module. A private key, such as the Attestation Identity Key (AIK), is the private key portion of an asymmetric key used to sign remote attestation reports. It is generated by the security processor. The AIK public key is signed by the Endorsement Key (EK) private key, forming a certificate chain for the security processor. The root of trust can be built into the adapter or set independently of the adapter.

[0019] The protocol processor is the unit within the processor responsible for protocol processing. In this embodiment, it corresponds to the integrated remote authentication, SPDM, TDISP, and heterogeneous device management functions. The protocol processor connects to the front-end interface, the root of trust interface, the key processor, and registers. It establishes a trusted channel with the host through the front-end interface, determines the remote authentication report with the host based on the private key, and sends the remote authentication report to the host via the trusted channel. The trusted channel, such as a secure session channel established based on the SPDM protocol, is the control plane communication link between the adapter and the host used for remote authentication and key negotiation. The protocol processor establishes an SPDM session with the host through the front-end interface. At this time, the protocol processor obtains the EK from the root of trust through the root of trust interface. The EK is an asymmetric key, consisting of a public key and a private key. The EK is the unique identifier of the adapter, and its private key is always stored within the root of trust, generated internally and not disclosed externally, to ensure the uniqueness and security of the device identity. To reduce the frequency of EK usage, the AIK signature metric is typically used in SPDM remote authentication. The AIK is also an asymmetric key, consisting of a public key and a private key, and is generated by the processor. The AIK public key is signed by the EK private key to form the processor's certificate chain. The processor's certificate chain is first sent to the host via the SPDM protocol. Simultaneously, the protocol processor checks the heterogeneous acceleration device manager for available device interfaces. If an interface is available, the protocol processor prevents other virtual machines or tenants from accessing that specific interface. The host sends a remote proof challenge value to the protocol processor via the SPDM protocol. The protocol processor then collects the processor's metrics, the heterogeneous acceleration device's specific interface metrics, and the manager's configured metrics through the remote proof module, and combines these with the challenge value to form a remote proof report. The remote proof report is signed using the AIK private key and sent to the host via the SPDM protocol. The remote proof report contains integrity metrics information for the adapter and the heterogeneous acceleration device, used to prove to the host that the adapter and the connected heterogeneous acceleration device are in a secure and trusted state.

[0020] A key processor generates a shared key to build a trusted execution environment (TEA) after the host verifies the remote proof report. The host first verifies the validity of the processor's certificate chain, and then verifies the validity of the remote proof report based on the certificate chain. Additionally, the host can compare the reference values ​​in the remote proof with pre-stored reference values ​​to ensure that specific device interface metrics of the adapter and heterogeneous acceleration devices function as expected. At this point, a shared key is generated based on the host's public key and the processor's AIK public key. The trusted channel based on the shared key provides confidentiality, integrity, replay protection, and message ordering protection. The shared key is a symmetric key negotiated between the adapter and the host after the remote proof is passed, used to protect subsequent secure communication. The TEA is a secure computing environment built within the adapter, which can be implemented using memory encryption or access control isolation methods, providing a secure and reliable transmission bridge for data transmission between the adapter, the host, and heterogeneous acceleration devices.

[0021] The register, connected to the key processor, stores the shared key to establish a data transmission channel between the host and the heterogeneous acceleration devices. This shared key storage enables the adapter to establish a secure data transmission channel between the host and the heterogeneous acceleration devices, protecting data transmission paths such as Direct Memory Access (DMA) and Memory-Mapped Input / Output (MMIO) to prevent data leakage or unauthorized access during transmission. The data transmission channel is a secure path between the host and the heterogeneous acceleration devices for transmitting user data (such as large model parameters and training data).

[0022] In this embodiment, the private key is the AIK private key. It is an asymmetric key generated by the security processor and consists of a public key and a private key. The AIK public key is signed by the EK private key to form the adapter's certificate chain. The AIK private key is used to sign remote verification reports to prove the authenticity and integrity of the reports.

[0023] In this embodiment, the trusted channel is a secure session established between the security processor and the host based on the SPDM protocol. This channel provides confidentiality, integrity, replay protection, and message ordering protection for securely transmitting identity certificates, measurement information, and remote authentication reports during remote authentication.

[0024] The remote proof report is a report generated by the secure processor based on its own measurement information, device interface measurement information of heterogeneous acceleration devices, and measurement information of the heterogeneous acceleration device manager, collected from the root of trust, combined with the challenge value sent by the host, and finally signed using a private key. Unlike traditional remote proofs for confidential computing, the remote proof in this application not only collects remote proof information of its own device, but also primarily collects measurement information of heterogeneous acceleration devices to report to the host that the connected heterogeneous devices are secure and trustworthy.

[0025] The shared key is generated by the key processor based on the public key generated by the host and the AIK public key of the adapter after the host verifies the remote authentication report. The shared key is used to protect the trusted channel and serves as the basis for establishing secure transmission keys, ensuring that key generation only occurs after the host confirms that the heterogeneous acceleration device is secure and trustworthy.

[0026] The data transmission channel is a secure data transmission path established between the host and the heterogeneous acceleration device based on a shared key. In this embodiment, the data transmission channel is specifically a secure hardware transmission channel built based on the TDISP protocol. By configuring the secure transmission key to the host's PCIE Root complex, the adapter's secure processor, and the TEE device interface of the heterogeneous acceleration device, confidential virtual machines can securely transmit data to the TEE device interface of the heterogeneous acceleration device via DMA and MMIO.

[0027] Figure 2 A schematic diagram of another adapter provided in an embodiment of this application is shown below. Figure 2 As shown, in Figure 2The adapter configuration at the software level involves Host 5 running traditional virtual machines, confidential virtual machines A1, and confidential virtual machines A2. Host 5's Host Virtual Machine Monitor (Host VMM) manages these virtual machines. Host 5 also includes a TEE Security Manager (TSM), a TDISP module, an SPDM module, and memory, including both insecure and secure memory. Adapter 1 is located between Host 5 and the heterogeneous acceleration device 6. The processor inside Adapter 1 runs in the TEE environment and includes six functional modules: remote authentication, heterogeneous acceleration device management, root of trust management, device interface security protocol, trusted channel, and root of trust proxy. Adapter 1 also includes a TPM module as a root of trust. The security processor communicates with Host 5's security manager module via the PCIe front end and connects to the heterogeneous acceleration device 6 via the PCIe back end. The heterogeneous acceleration device 6 includes a manager, protected memory, memory, and trusted execution environment device interfaces and traditional device interfaces. Through this structure, Host 5, Adapter 1, and the heterogeneous acceleration device 6 form a heterogeneous trusted execution environment spanning all three.

[0028] After completing remote authentication and key negotiation, the security processor, through the heterogeneous acceleration device manager, can lock the configuration of the TEE device interface and report the configuration in a trusted manner, securely putting the TEE device interface into a running state. At this time, the VMM sets up DMA and MMIO for the TEE device interface and allows the confidential virtual machine to accept the configuration. The confidential virtual machine can start the TEE device interface and communicate with it using trusted DMA and MMIO. The TEE device interface is bound to the protected memory in the heterogeneous acceleration device, and only the TEE device interface, the security processor, and the corresponding confidential virtual machine have access permissions. No device on the host, including the CPU TEE, can directly access the heterogeneous acceleration device; all access requires an adapter.

[0029] For memory copying from a confidential virtual machine to a heterogeneous acceleration device, the confidential virtual machine first sends the encrypted metadata of the copy request, such as the data size, to the security processor of the adapter. The security processor sets the relevant registers of the TEE device interface of the heterogeneous acceleration device, and then sends the data directly to the protected memory corresponding to the TEE device interface via DMA and MMIO based on the secure transmission key. The decryption kernel in the TEE device interface decrypts the encrypted data in the protected memory and stores it in plaintext in the protected register for processing by the TEE device interface; alternatively, decryption can be skipped, and the data can be decrypted and processed directly only when the TEE device interface needs to process the data.

[0030] The adapter's security processor works in conjunction with the heterogeneous acceleration device's manager to create multiple contexts for the device. Each context corresponds to a TEE device interface or a traditional device interface, isolating the protected address space from other address spaces. Each confidential virtual machine establishes a unique key with the TEE device interface for secure communication. Multi-context execution on the heterogeneous acceleration device is handled through context switching within the manager; if the current context has no pending requests, a context switch occurs. If a confidential virtual machine no longer needs the heterogeneous acceleration device's TEE device interface, it can use the security processor to stop the TEE device interface and clear release information to prevent data leakage.

[0031] This application's embodiments, firstly, add an adapter independent of the host and heterogeneous acceleration devices as an intermediate bridge. This allows heterogeneous acceleration devices to be incorporated into the trusted execution environment without requiring them to possess confidential computing capabilities themselves, and without needing to modify the hardware architecture of the host and heterogeneous acceleration devices, reducing hardware modification costs and improving compatibility. Secondly, the composition of the components within the processor ensures the reliability and efficiency of the trusted execution environment construction, and the trusted root interface provides a trusted private key for the adapter and the connected heterogeneous acceleration devices, enabling heterogeneous acceleration devices that originally lacked a trusted root to participate in authentication based on the adapter's trusted root. Thirdly, the protocol processor determines the remote authentication report based on the private key, allowing the host to verify the security status of the heterogeneous acceleration devices, ensuring that data transmission and computation occur in a trusted environment. By establishing a trusted channel, a secure control communication link is provided between the adapter and the host, ensuring that identity certificates, measurement information, etc., are not stolen or tampered with during remote authentication, guaranteeing the integrity and confidentiality of the authentication process. Furthermore, the key processor generates a shared key after the host remote authentication is successful. This ensures that key generation only occurs when the host confirms the heterogeneous acceleration device is secure and trustworthy, providing encryption protection for data transmission and preventing unauthorized entities from stealing or tampering with data. Finally, the register stores the shared key, enabling the adapter to establish a secure data transmission channel between the host and the heterogeneous acceleration device based on the shared key. This protects the data transmission path, preventing data leakage or unauthorized access during transmission, forming a trusted execution environment across the host and heterogeneous acceleration device, and achieving secure data transmission and storage.

[0032] Because this application adds an adapter between the host and the heterogeneous acceleration device, and integrates four hardware units—a trusted root interface, a protocol processor, a key processor, and registers—within the processor, the entire process does not require the heterogeneous acceleration device itself to have confidential computing capabilities, nor does it require any modification to the hardware architecture of the CPU or the heterogeneous acceleration device. Therefore, it solves the technical problems of poor compatibility caused by relying on specific models of heterogeneous acceleration devices that support confidential computing, and the high cost and impact on system compatibility caused by CPU-side hardware modifications in conventional solutions. It achieves the technical effects of incorporating ordinary heterogeneous acceleration devices into a trusted execution environment, strong compatibility, good versatility, no hardware modification required, and reduced costs.

[0033] In some embodiments, when the host supports the device interface security protocol of a trusted execution environment, establishing a data transmission channel between the host and at least one heterogeneous acceleration device includes: The host uses a device interface security protocol to interact with the processor to obtain corresponding interaction information; the interaction information is encrypted and protected according to a shared key to establish a secure transmission key; the secure transmission key is configured in the host, the adapter and at least one heterogeneous acceleration device to establish a data transmission channel between the host and at least one heterogeneous acceleration device.

[0034] Specifically, when the host supports the TDISP protocol, the host's TSM uses the TDISP protocol to establish a secure transmission key IDE_KM for DMA and MMIO data streams with the adapter's security processor.

[0035] When the host supports the device interface security protocol of the Trusted Execution Environment, the process of establishing a data transmission channel between the host and at least one heterogeneous acceleration device is as follows: The host uses device interface security protocols to interact with the processor and obtain corresponding information. Device interface security protocols, such as TDISP, are security protocols used to establish data transmission channels. They are based on trusted channels, such as SPDM sessions, and use these secure channels to construct secure transmission keys for DMA and MMIO. The TSM in the host uses the TDISP protocol to establish secure transmission keys for DMA and MMIO data streams with the adapter's processor, such as IDE_KM. This session is protected by shared key encryption during SPDM.

[0036] Interactive information is encrypted using a shared key to establish a secure transmission key. This secure transmission key, such as IDE_KM, is a key negotiated between the host and adapter via the TDISP protocol to protect the data transmission channel. It is encrypted and protected by the shared key and used for encrypting and decrypting data transmitted through the data transmission channel.

[0037] A secure transmission key is configured on the host, adapter, and at least one heterogeneous acceleration device to establish a data transmission channel between the host and at least one heterogeneous acceleration device. The key is configured in the host's PCIe root complex, the adapter's processor, and the TEE device interface of the heterogeneous acceleration device, ensuring a secure hardware transmission channel between the heterogeneous acceleration device and the host. Data can be securely transferred from the host to the TEE device interface of the heterogeneous acceleration device via DMA or MMIO, thus forming a heterogeneous trusted execution environment. The processor, through the heterogeneous acceleration device manager, can lock the configuration of the TEE device interface and report the configuration in a trusted manner, securely putting the TEE device interface into a running state. No device on the host, including the CPU TEE, can directly access the heterogeneous acceleration device; access is only possible through the adapter.

[0038] After this step is completed, the host, adapter, and heterogeneous acceleration device will have two secure communication sessions. The trusted channel is a software session used for software configuration, such as secure transmission keys and device interface security protocols. The data transmission channel is a hardware session used to protect DMA and MMIO data streams, providing link encryption to ensure the confidentiality and integrity of the link and preventing untrusted MMIO from accessing protected memory in the heterogeneous trusted execution environment.

[0039] This embodiment provides a secure transmission key established through the host, adapter, and heterogeneous acceleration device when the host supports the device interface security protocol. This forms a three-party secure hardware transmission channel, achieving link-layer encryption protection for data transmission and ensuring the confidentiality and integrity of data transmission.

[0040] In some embodiments, the adapter also includes a data buffer; During the data transmission process, the processor receives the data to be accessed sent by the host via the front-end interface; The key processor uses a secure transmission key to decrypt the data to be accessed, thus obtaining the decrypted data to be accessed. The data buffer stores the decrypted data to be accessed, so that it can be sent to at least one heterogeneous acceleration device via the backend interface to complete the data transmission between the host and at least one heterogeneous device.

[0041] Figure 3 This application provides a schematic diagram of the structure of the adapter-side decryption data when the host supports the device interface security protocol, as shown in the embodiment of this application. Figure 3As shown, the data buffer is a storage unit in adapter 1 used to cache data to be transmitted. During data transmission, the processor receives the data to be accessed sent by host 5 via the front-end interface. The data to be accessed is data that host 5 needs to transmit to the heterogeneous acceleration device 6 for processing, such as model parameters or training data of a large model. The key processor decrypts the data to be accessed using a secure transmission key to obtain the decrypted data. Encrypted data sent from host 5's secure memory is directly decrypted using the processor's hardware encryption / decryption function.

[0042] The data buffer stores the decrypted data to be accessed, which is then sent to at least one heterogeneous acceleration device 6 via the backend interface to complete data transmission between the host 5 and at least one heterogeneous device. The data buffer stores decrypted plaintext data, which is then directly sent to the protected memory of the heterogeneous acceleration device 6. Conversely, when data needs to be transferred from the heterogeneous acceleration device 6 to the host 5, the plaintext data from the heterogeneous acceleration device 6 is first sent to the data buffer. Then, the data is hardware encrypted using a secure transmission key, and the data in the data buffer is transferred to the secure memory of the host 5 via DMA and MMIO over the bus.

[0043] This embodiment provides an example of adding a data buffer to the adapter, enabling the adapter to decrypt encrypted data locally and send the decrypted plaintext data to the heterogeneous acceleration device through the data buffer, thereby improving decryption speed and data transmission efficiency.

[0044] In some embodiments, when the host does not support the device interface security protocol of the Trusted Execution Environment, establishing a data transmission channel between the host and at least one heterogeneous acceleration device includes: The host uses a shared key to encrypt the data to be accessed, obtaining the encrypted data; and stores the encrypted data to be accessed in the host's shared storage area. The protocol processor retrieves encrypted data to be accessed from the shared storage area via a front-end interface; The key processor uses a shared key to decrypt the encrypted data to be accessed, and then sends the decrypted data to at least one heterogeneous acceleration device via a backend interface to complete the data transmission between the host and at least one heterogeneous device.

[0045] Specifically, Figure 4 This application provides a schematic diagram of an adapter structure where the host does not support the device interface security protocol, as shown in the embodiment of the present application. Figure 4 As shown, when host 5 does not support the device interface security protocol of the Trusted Execution Environment, the process of establishing a data transmission channel between host 5 and at least one heterogeneous acceleration device 6 is as follows: Host 5 uses the shared key to encrypt the data to be accessed, obtaining encrypted data, and then stores the encrypted data in the shared storage area of ​​Host 5. If the TSM in Host 5 does not support the TDISP protocol, a shared key is first generated via SPDM. Host 5 uses the shared key to encrypt the secure memory data and stores it in secure shared memory.

[0046] The protocol processor retrieves the encrypted data to be accessed from the shared storage area through a front-end interface. Specifically, the protocol processor retrieves the encrypted access data from shared memory via the PCIe bus.

[0047] The key processor uses a shared key to decrypt the encrypted data to be accessed, obtaining the decrypted data, which is then sent to at least one heterogeneous acceleration device 6 via the backend interface, completing the data transmission between the host 5 and at least one heterogeneous device. After decryption using the shared key, plaintext data is transmitted via the PCIe bus to the TEE device interface of the heterogeneous acceleration device 6.

[0048] This embodiment provides a method where, when the host does not support the device interface security protocol, the data is encrypted using a shared key and stored in shared memory. The adapter retrieves the encrypted data from the shared memory, decrypts it, and sends it to the heterogeneous acceleration device. This enables the adapter to be compatible with hosts that do not support the device interface security protocol, thus expanding the application scope.

[0049] In some embodiments, the adapter also includes a data buffer; After the key processor decrypts the data to be accessed using a secure transmission key to obtain the decrypted data, the decrypted data is stored in a data buffer so that it can be sent to at least one heterogeneous acceleration device via a backend interface, thus completing the data transmission between the host and at least one heterogeneous device.

[0050] Specifically, the data buffer is used to cache the decrypted plaintext data, facilitating its subsequent transmission to the TEE device interface of the heterogeneous acceleration device. In this embodiment, by adding a data buffer, even in scenarios where the host does not support the device interface security protocol, the adapter can still perform local decryption and caching of encrypted data, ensuring efficient data transmission. It should be noted that in this embodiment, since the host does not support the TDISP protocol, the secure transmission key can be obtained based on a shared key. After the data is decrypted on the adapter side, it is temporarily stored in the data buffer before being forwarded by the adapter to the heterogeneous acceleration device.

[0051] This embodiment provides a method to add a data buffer in scenarios where the host does not support the TDISP protocol, enabling the adapter to perform data decryption and temporary storage locally, further coordinating data interaction between the host and heterogeneous acceleration devices, and improving the continuity and stability of data transmission.

[0052] In some embodiments, the adapter connects to multiple heterogeneous acceleration devices through multiple back-end interfaces; Use the device interfaces corresponding to the trusted execution environments of multiple heterogeneous acceleration devices as the target device interfaces; The adapter securely isolates the target device interfaces corresponding to multiple heterogeneous acceleration devices and / or multiple heterogeneous trusted execution environments within the same heterogeneous acceleration device based on the constructed heterogeneous trusted execution environment.

[0053] Specifically, Figure 5 This application provides a schematic diagram of an adapter connecting multiple heterogeneous acceleration devices, as shown in the embodiment of the present application. Figure 5 As shown, adapter 1 connects to multiple heterogeneous acceleration devices 6 through multiple back-end interfaces. Adapter 1 has one front-end interface to ensure physical connection to the host, and multiple back-end interfaces to physically connect to multiple heterogeneous acceleration devices 6 via a bus. This means that, physically, adapter 1 can manage multiple heterogeneous acceleration devices 6. Each heterogeneous acceleration device 6 can have multiple device interfaces corresponding to trusted execution environments built into it.

[0054] The device interfaces corresponding to the Trusted Execution Environments (TEEs) of multiple heterogeneous acceleration devices are used as target device interfaces. Device interfaces, such as TEE device interfaces, are interfaces used in heterogeneous acceleration devices for secure communication with the host. Their corresponding device resources, such as physical functions and virtual functions, can be allocated as device interfaces.

[0055] The adapter securely isolates target device interfaces corresponding to multiple heterogeneous acceleration devices and / or multiple heterogeneous trusted execution environments within the same heterogeneous acceleration device, based on the constructed heterogeneous trusted execution environment. Specifically, to isolate different heterogeneous acceleration devices and different device interfaces within the same heterogeneous acceleration device, the adapter generates a different shared key for each device interface when using the SPDM protocol. The secure transmission keys generated using the TDISP protocol are also different, ensuring that data transmission does not interfere with each other. Furthermore, through the heterogeneous device management function in the processor, device interfaces are bound to corresponding hosts, allowing hosts to access only their designated device interfaces and preventing access to unbound interfaces. Within the heterogeneous acceleration device, a manager restricts mutual access between device interfaces, achieving secure isolation of the heterogeneous trusted execution environment.

[0056] This embodiment achieves secure isolation between multiple heterogeneous acceleration devices and between different trusted execution environments within the same heterogeneous acceleration device by setting multiple backend interfaces on the adapter and using different shared keys and secure transmission keys for each target device interface, thereby improving the system's security and multi-tenancy support capabilities.

[0057] In some embodiments, when a heterogeneous trusted execution environment is constructed and the adapter is connected to multiple heterogeneous acceleration devices through multiple back-end interfaces, the multiple heterogeneous acceleration devices correspond to the same shared key and the same secure transmission key.

[0058] Specifically, Figure 6 This application provides a schematic diagram of a single-confidential virtual machine supporting multiple heterogeneous acceleration devices, as shown in the embodiments of this application. Figure 6 As shown, in this scenario, multiple heterogeneous acceleration devices, denoted by B1, B2, ..., BN, correspond to the same shared key and the same secure transmission key. The confidential virtual machine and adapter share a shared key, while the confidential virtual machine, adapter, and multiple heterogeneous acceleration devices share a single secure transmission key, IDE_KM. Thus, when a single heterogeneous acceleration device is insufficient to support large-scale applications such as large models, the adapter supports horizontal scaling, binding more heterogeneous acceleration devices to a single application. These heterogeneous acceleration devices use the same key system within the same heterogeneous trusted execution environment.

[0059] This embodiment simplifies key management in multi-device binding scenarios by allowing multiple heterogeneous acceleration devices in the same heterogeneous trusted execution environment to share the same shared key and secure transmission key, and supports the horizontal scaling of large applications such as large models across multiple heterogeneous acceleration devices.

[0060] In some embodiments, when multiple heterogeneous trusted execution environments are constructed and the adapter is connected to multiple heterogeneous acceleration devices through multiple back-end interfaces, each heterogeneous trusted execution environment is bound to the device interface corresponding to a different trusted execution environment of the same heterogeneous acceleration device; the shared key and secure transmission key of each heterogeneous trusted execution environment are different. Each heterogeneous trusted execution environment corresponds to at least one target device interface, and the shared key and secure transmission key corresponding to each target device interface in each heterogeneous trusted execution environment are the same.

[0061] Specifically, Figure 7 This application provides a schematic diagram illustrating the structure of a single heterogeneous acceleration device where one target device interface supports a confidential virtual machine, as shown in the embodiments of this application. Figure 7 As shown, a heterogeneous acceleration device can build device interfaces for multiple trusted execution environments, represented by D1, D2, etc. Each device interface can be individually bound to a confidential virtual machine, thereby forming multiple heterogeneous trusted execution environments.

[0062] Each heterogeneous trusted execution environment (TEE) is bound to a different TEE device interface within the same heterogeneous acceleration device. The shared key and secure transmission key of each TEE are distinct. Each TEE corresponds to at least one target device interface, and the shared key and secure transmission key for each target device interface within each TEE are the same. In other words, within the same heterogeneous trusted execution environment, the shared key and secure transmission key are identical; even if different heterogeneous trusted execution environments share the same heterogeneous acceleration device, they use different keys due to being bound to different TEE device interfaces, thus achieving mutual isolation.

[0063] Figure 8 This application provides a schematic diagram illustrating the structure of a single heterogeneous acceleration device with multiple target device interfaces supporting a confidential virtual machine, as shown in the embodiments of this application. Figure 8 As shown, multiple target device interfaces are bound to the same confidential virtual machine. For example, in the same heterogeneous acceleration device, there are 4 target device interfaces, and every two target device interfaces are bound to the same confidential virtual machine. In this case, the shared key and secure transmission key corresponding to the two target device interfaces under the same confidential virtual machine are the same.

[0064] This embodiment achieves secure isolation between multiple confidential virtual machines on the same heterogeneous acceleration device by assigning different shared keys and secure transmission keys to different heterogeneous trusted execution environments, thus ensuring data security in multi-tenant scenarios.

[0065] In some embodiments, when the trusted root interface is used to obtain a private key from the trusted root, the trusted root is independent of the adapter settings, and the trusted root communicates with the trusted root interface of the adapter.

[0066] Specifically, Figure 9 This application provides a schematic diagram illustrating a structure where a heterogeneous confidential computing adapter is separated from a TPM module, as shown in the embodiments of this application. Figure 9 As shown, the TPM can reside on the host motherboard and communicate with the adapter via a bus such as the Serial Peripheral Interface (SPI). The TPM agent in the security processor communicates with the TPM via the SPDM protocol. It is worth noting that the EK key in the TPM module is unique; however, the security processor can generate multiple AIK keys and use the EK to sign each AIK key. Each AIK key corresponds to a TEE device interface, meaning that the AIK signing key used for remote authentication in each heterogeneous trusted execution environment is different.

[0067] This embodiment improves the flexibility of the adapter and reduces the implementation difficulty by separating the TPM module from the adapter. At the same time, by using a unique EK and multiple AIKs, it not only ensures the uniqueness of the device identity, but also supports differentiated authentication for multiple heterogeneous trusted execution environments.

[0068] In some embodiments, in a heterogeneous trusted execution environment, when an adapter connects to at least one target device interface corresponding to multiple trusted execution environments under the same heterogeneous acceleration device, the key processor generates a subkey for each target device interface, and the subkeys of each target device interface are different from each other and are not equivalent to the secure transmission key and the shared key.

[0069] Specifically, in a heterogeneous trusted execution environment, when an adapter connects to at least one target device interface corresponding to multiple trusted execution environments under the same heterogeneous acceleration device, the key processor generates subkeys for each target device interface.

[0070] Each target device interface has a unique subkey, and none of them are equivalent to the secure transmission key or the shared key. In other words, even if the secure transmission key and the shared key are the same, different TEE device interfaces will have their own independent subkeys for encryption / decryption or access control of their local data, thereby achieving finer-grained security isolation within the same heterogeneous trusted execution environment.

[0071] This embodiment generates different sub-keys for different target device interfaces in the same heterogeneous trusted execution environment, achieving fine-grained isolation at the interface level. Even if the shared key and the secure transmission key are the same, it can prevent key mixing between different device interfaces, further improving the security of data transmission and storage.

[0072] Furthermore, this application also provides a heterogeneous trusted execution environment system, including a host, an adapter, and at least one heterogeneous acceleration device; The host and at least one heterogeneous acceleration device are connected to the adapter.

[0073] Specifically, such as Figure 1 As shown, the confidential virtual machine in host 5 establishes a security protocol session with the security processor of adapter 1 through TSM. Adapter 1 connects to the heterogeneous acceleration device 6 through the PCIe backend. Host 5, adapter 1, and heterogeneous acceleration device 6 work together to first obtain the private key through the trusted root interface of adapter 1. The protocol processor establishes a trusted channel with host 5 and completes remote authentication. Then, after host 5 verifies the key, the key processor generates a shared key and stores it in a register. Finally, a data transmission channel is established between host 5 and heterogeneous acceleration device 6 based on the shared key, thus forming a heterogeneous trusted execution environment that spans all three.

[0074] For an introduction to the heterogeneous trusted execution environment system provided in this application, please refer to the above method embodiments. This application will not repeat the details here, as it has the same beneficial effects as the adapter described above.

[0075] Furthermore, this application also provides a data transmission method applied to an adapter; the adapter includes a processor, a front-end interface, and a back-end interface; it is connected to a host through the front-end interface; and it is connected to the processor and at least one heterogeneous acceleration device through the back-end interface; the processor includes a trusted root interface, a protocol processor, a key processor, and a register; the protocol processor is connected to the front-end interface, the trusted root interface, the key processor, and the register respectively; and the register is connected to the key processor. Figure 10 This is a flowchart illustrating a data transmission method provided in an embodiment of this application, as shown below. Figure 10 As shown, the method includes: S11: The control protocol processor establishes a trusted channel with the host, determines the remote authentication report with the host based on the private key, and sends the remote authentication report to the host through the trusted channel; S12: The control key processor generates a shared key after the host verifies the remote proof report to build a trusted execution environment; S13: The control register stores the shared key to establish a data transmission channel between the host and the heterogeneous acceleration device.

[0076] Specifically, the protocol processor establishes an SPDM session with the host through a front-end interface. The protocol processor obtains the identity certificate and private key from the trusted root through the trusted root interface. The protocol processor collects measurement information from the adapter and heterogeneous acceleration devices, generates a remote verification report, signs the report with its private key, and sends it to the host via a trusted channel. The host verifies the legitimacy of the certificate chain and the remote verification report.

[0077] After the host verifies the remote authentication report, it generates a shared key based on the host's public key and the adapter's public key, and builds a trusted execution environment in the adapter. The adapter establishes a secure data transmission channel between the host and the heterogeneous acceleration device based on the shared key, protects data transmission paths such as DMA and MMIO, and enables the host to securely access data from the heterogeneous acceleration device.

[0078] For a description of the data transmission method provided in this application, please refer to the above method embodiments. This application will not repeat the description here, as it has the same beneficial effects as the adapter described above.

[0079] In some embodiments, determining a remote authentication report based on a private key and the host includes: Obtain the identity certificate generated by the trusted root through the trusted root interface; Generate a certificate chain based on the identity certificate; Send the certificate chain to the host via a trusted channel; Receive the challenge value sent by the host; Collect the first metric information of the processor and the second metric information of the heterogeneous acceleration device through the back-end interface; The remote proof report is determined based on the first metric information, the second metric information, and the challenge value; The final remote proof report is obtained by signing the remote proof report using the private key.

[0080] Specifically, the TPM management module in the security processor obtains the EK from the TPM through the TPM agent. The EK is an asymmetric key, consisting of a public key and a private key. The EK is the unique identifier of the adapter, and its private key is always stored internally within the TPM and is not disclosed externally. To reduce the frequency of EK usage, the AIK is typically used to sign the metric value in SPDM's remote proof. The AIK is also an asymmetric key, consisting of a public key and a private key, and is generated by the security processor. The AIK public key is signed by the EK private key to form the adapter's certificate chain. The certificate chain is first sent to the confidential virtual machine via the SPDM protocol. After the confidential virtual machine sends the remote proof challenge value to the security processor via the SPDM protocol, the security processor collects the security processor's metric information, the specific device interface metric information of the heterogeneous acceleration device, and the metric information configured by the manager through the remote proof module, and combines it with the challenge value to form a remote proof report. Finally, the remote proof report is signed using the AIK private key.

[0081] This embodiment generates identity certificates through a trusted root, constructs a certificate chain, combines challenge values ​​and multi-party measurement information to form a remote proof report, and uses private key signing to ensure the authenticity, integrity, and non-repudiation of the remote proof report, enabling the host to reliably verify the security status of the adapter and its connected heterogeneous acceleration devices.

[0082] In some embodiments, prior to collecting the second metric information of the heterogeneous acceleration devices via the backend interface, the method further includes: Obtain the idle status of the device interface corresponding to the trusted execution environment of the heterogeneous acceleration device; If a device interface corresponding to a trusted execution environment is idle, then other virtual machines or tenants are prevented from accessing the device interface corresponding to the idle trusted execution environment in order to obtain the second metric information corresponding to the device interface corresponding to the idle trusted execution environment.

[0083] Specifically, the security processor determines whether there is a free device interface for the heterogeneous acceleration device through the device manager. Once a free device interface for the heterogeneous acceleration device is available, the security processor prevents other virtual machines or tenants from accessing the specific device interface of the heterogeneous acceleration device, thereby ensuring the exclusivity and security of the device interface in the process of metric information collection and subsequent binding.

[0084] This embodiment effectively avoids the contamination of measurement information or the preemption of device interfaces by occupying idle TEE device interfaces and preventing other virtual machines or tenants from accessing them, thus ensuring the authenticity and credibility of the heterogeneous acceleration device status on which remote proof is based.

[0085] In some embodiments, the verification process for a remote proof report includes: After receiving the certificate chain and the signed remote verification report, the host verifies the legitimacy of the certificate chain. If the certificate chain's legitimacy verification passes, the legitimacy of the remote proof report is verified based on the certificate chain. If the validity of the remote verification report is verified, then the remote verification report is deemed to have been verified.

[0086] Specifically, the confidential virtual machine first verifies the legitimacy of the security processor's certificate chain; then, based on the certificate chain, it verifies the legitimacy of the remote verification report. Only when the certificate chain is valid and the signature of the remote verification report is valid does the host confirm that the adapter and its connected heterogeneous acceleration devices have passed authentication, and only then does it allow the key processor to generate a shared key and establish a subsequent data transmission channel.

[0087] This embodiment employs a two-level verification mechanism—first verifying the certificate chain, then verifying the remote certification report—to ensure the legitimacy of the adapter's identity and the reliability of the remote certification report's content, preventing unauthorized devices or tampered reports from passing authentication.

[0088] In some embodiments, after the legality verification of the remote proof report passes, the method further includes: The host obtains the measurement reference value from the remote verification report and the pre-stored preset reference value; wherein, the measurement reference value and the preset reference value are both records of the version information and / or hardware parameter information corresponding to the adapter and heterogeneous acceleration device; If the measured reference value and the preset reference value are consistent, then the remote verification report is deemed to have passed verification.

[0089] After the legality verification of the remote certification report is passed, the host obtains the measurement reference value in the remote certification report and the pre-stored preset reference value; wherein, the measurement reference value and the preset reference value are both records of the version information and / or hardware parameter information corresponding to the adapter and heterogeneous acceleration device.

[0090] If the metric reference value matches the preset reference value, the remote proof report is deemed verified. Specifically, the confidential virtual machine can compare the reference value in the remote proof with the pre-stored reference value to ensure that the specific device interface metric information of the adapter and heterogeneous acceleration device functions as expected. This step provides additional integrity verification for the remote proof, preventing situations where the metric value has a valid signature but its content does not meet expectations.

[0091] This embodiment compares the measurement reference value in the remote proof report with the preset reference value to further ensure that the hardware and software status of the adapter and heterogeneous acceleration device meet expectations, thereby improving the security boundary of the heterogeneous trusted execution environment.

[0092] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0093] Embodiments of this application also provide a data transmission device. Figure 11 This is a schematic diagram of the structure of a data transmission device provided in an embodiment of this application, as shown below. Figure 11 As shown, the device includes: The first control module 11 is used to control the protocol processor to establish a trusted channel with the host, determine the remote authentication report with the host based on the private key, and send the remote authentication report to the host through the trusted channel; The second control module 12 is used to control the key processor to generate a shared key after the host verifies the remote proof report, so as to build a trusted execution environment; The third control module 13 is used to control the register to store the shared key in order to establish a data transmission channel between the host and the heterogeneous acceleration device.

[0094] For a description of the features in the embodiment corresponding to the device, please refer to the relevant description of the embodiment corresponding to the data transmission method, which will not be repeated here.

[0095] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described data transmission method embodiments.

[0096] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described data transmission method embodiments when it is run.

[0097] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0098] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described data transmission method embodiments.

[0099] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described data transmission method embodiments.

[0100] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, CPUs, FPGAs, ASICs, Application Specific Standard Products (ASSPs), System-on-a-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), Microcontroller Units (MCUs), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, systems-on-a-chip, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination thereof. The aforementioned computer program (also known as a program, software, software application, application (App), script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0101] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0102] The adapter, heterogeneous trusted execution environment system, and data transmission method provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. An adapter, characterized in that, It includes a processor, a front-end interface, and a back-end interface; it is connected to a host via the front-end interface; and it is connected to the processor and at least one heterogeneous acceleration device via the back-end interface; the processor includes a root trusted interface, a protocol processor, a key processor, and registers. The trusted root interface is used to obtain the private key; The protocol processor is connected to the front-end interface, the trusted root interface, the key processor, and the register, respectively, and is used to establish a trusted channel with the host, determine a remote proof report with the host based on the private key, and send the remote proof report to the host through the trusted channel; The key processor is used to generate a shared key after the host verifies the remote proof report, so as to build a trusted execution environment; The register is connected to the key processor and is used to store the shared key to establish a data transmission channel between the host and at least one heterogeneous acceleration device.

2. The adapter according to claim 1, characterized in that, When the host supports the device interface security protocol of the Trusted Execution Environment, establishing a data transmission channel between the host and at least one heterogeneous acceleration device includes: The host uses the device interface security protocol to interact with the processor to obtain corresponding interaction information; the interaction information is encrypted and protected according to the shared key to establish a secure transmission key; the secure transmission key is configured in the host, the adapter and at least one heterogeneous acceleration device to establish a data transmission channel between the host and at least one heterogeneous acceleration device.

3. The adapter according to claim 2, characterized in that, The adapter also includes a data buffer; During the data transmission process, the processor receives the data to be accessed sent by the host via the front-end interface; The key processor decrypts the data to be accessed using the secure transmission key to obtain the decrypted data to be accessed. The data buffer stores the decrypted data to be accessed, so that it can be sent to at least one heterogeneous acceleration device via the back-end interface to complete the data transmission between the host and at least one heterogeneous device.

4. The adapter according to claim 1, characterized in that, When the host does not support the device interface security protocol of the Trusted Execution Environment, establishing a data transmission channel between the host and at least one heterogeneous acceleration device includes: The host uses the shared key to encrypt the data to be accessed to obtain encrypted data to be accessed; and stores the encrypted data to be accessed in the shared storage area of ​​the host. The protocol processor obtains encrypted data to be accessed from the shared storage area through the front-end interface; The key processor uses the shared key to decrypt the encrypted data to be accessed, and then sends the decrypted data to at least one heterogeneous acceleration device via the backend interface to complete the data transmission between the host and at least one heterogeneous device.

5. The adapter according to claim 4, characterized in that, The adapter also includes a data buffer; After the key processor decrypts the data to be accessed using the shared key to obtain the decrypted data to be accessed, the decrypted data to be accessed is stored in the data buffer so that it can be sent to at least one heterogeneous acceleration device via the back-end interface to complete the data transmission between the host and at least one heterogeneous device.

6. The adapter according to claim 2, characterized in that, The adapter connects to multiple heterogeneous acceleration devices through multiple back-end interfaces; Use the device interfaces corresponding to the trusted execution environments of multiple heterogeneous acceleration devices as the target device interfaces; The adapter securely isolates the target device interfaces corresponding to multiple heterogeneous acceleration devices and / or multiple heterogeneous trusted execution environments within the same heterogeneous acceleration device based on the constructed heterogeneous trusted execution environment.

7. The adapter according to claim 6, characterized in that, When constructing a heterogeneous trusted execution environment, and the adapter is connected to multiple heterogeneous acceleration devices through multiple back-end interfaces, the multiple heterogeneous acceleration devices correspond to the same shared key and the same secure transmission key.

8. The adapter according to claim 6, characterized in that, When constructing multiple heterogeneous trusted execution environments, and the adapter is connected to multiple heterogeneous acceleration devices through multiple back-end interfaces, each heterogeneous trusted execution environment is bound to the device interface corresponding to a different trusted execution environment of the same heterogeneous acceleration device. The shared keys and secure transmission keys of each heterogeneous trusted execution environment are different; Each heterogeneous trusted execution environment corresponds to at least one target device interface, and the shared key and secure transmission key corresponding to each target device interface in each heterogeneous trusted execution environment are the same.

9. The adapter according to claim 1, characterized in that, When the trusted root interface is used to obtain a private key from the trusted root, the trusted root is set independently of the adapter, and the trusted root is communicatively connected to the trusted root interface of the adapter.

10. A heterogeneous trusted execution environment system, characterized in that, Includes a host, an adapter as described in any one of claims 1 to 9, and at least one heterogeneous acceleration device; The host and at least one heterogeneous acceleration device are both connected to the adapter.

11. A data transmission method, characterized in that, The adapter is applied to an adapter; the adapter includes a processor, a front-end interface, and a back-end interface; it is connected to a host through the front-end interface; and it is connected to the processor and at least one heterogeneous acceleration device through the back-end interface; the processor includes a trusted root interface, a protocol processor, a key processor, and registers; the protocol processor is connected to the front-end interface, the trusted root interface, the key processor, and the registers respectively; The register is connected to the key processor; The method includes: The protocol processor is controlled to establish a trusted channel with the host, determine a remote authentication report with the host based on the private key, and send the remote authentication report to the host through the trusted channel; The key processor is controlled to generate a shared key after the host verifies the remote proof report, in order to build a trusted execution environment; The register is controlled to store the shared key in order to establish a data transmission channel between the host and the heterogeneous acceleration device.

12. The data transmission method according to claim 11, characterized in that, The remote authentication report based on the private key and the host includes: Obtain the identity certificate generated by the trusted root via the trusted root interface; Generate a certificate chain based on the identity certificate; The certificate chain is sent to the host via the trusted channel; Receive the challenge value sent by the host; Collect first metric information of the processor and second metric information of the heterogeneous acceleration device via the back-end interface; The remote proof report is determined based on the first metric information, the second metric information, and the challenge value; The remote proof report is signed using the private key to obtain the final remote proof report.

13. The data transmission method according to claim 12, characterized in that, Before collecting the second metric information of the heterogeneous acceleration device via the backend interface, the process also includes: Obtain the idle state of the device interface corresponding to the trusted execution environment of the heterogeneous acceleration device; If a device interface corresponding to a trusted execution environment is idle, then other virtual machines or tenants are prevented from accessing the device interface corresponding to the idle trusted execution environment in order to obtain the second metric information corresponding to the device interface corresponding to the idle trusted execution environment.

14. The data transmission method according to claim 12, characterized in that, The verification process of the remote proof report includes: After receiving the certificate chain and the signed remote proof report, the host verifies the legality of the certificate chain. If the validity of the certificate chain is verified, the validity of the remote proof report is verified based on the certificate chain. If the validity of the remote verification report is verified, then the remote verification report is deemed to have been verified.

15. The data transmission method according to claim 14, characterized in that, After the legality verification of the remote proof report is passed, the following is also included: The host obtains the measurement reference value in the remote proof report and the preset reference value stored in advance; wherein, the measurement reference value and the preset reference value are both records of the version information and / or hardware parameter information corresponding to the adapter and the heterogeneous acceleration device; If the measured reference value and the preset reference value are consistent, then the remote verification report is determined to be verified successfully.

Images