Cloud platform based on trusted infrastructure unit

Abstract

The invention discloses a cloud platform based on a trusted infrastructure unit, a hardware trusted root hTCM is used for trusted support of a TIPU card and does not participate in scheduling and management, a virtual machine trusted root vTCM schedules to a physical host and a virtual machine according to requirements, trusted measurement and support of related trusted functions are carried out, and the trusted function of the TIPU card is realized. An encryption and decryption engine of TIPU card hardware encrypts secret key materials associated with uuid numbers and state information of a simulated virtual machine trusted root vTCM, then the secret key materials and the state information are stored in a remote safety storage medium, identity authentication is carried out through an integrated USB Key, an IPU-TCM physical drive accesses a hardware TCM, and a vTCM simulator calls the IPU-TCM physical drive to execute function operation and resource management. By integrating the hardware trusted root, the virtualization technology and the efficient communication mechanism, a comprehensive trusted measurement unloading solution is provided for the cloud platform, the overall safety of the cloud environment is enhanced, and the resource use efficiency is optimized.

Description

Technical Field

[0001] The present application relates to the technical field of cloud environment, and in particular to a cloud platform based on a trusted infrastructure unit. Background Art

[0002] Trusted root as the source of trust is the core component of trusted computing technology. The traditional trusted cryptography module (TCM) is only applicable to single machines and can ensure the security and reliability of single-machine systems. After virtualization design improvements, there are currently three main solutions for providing trusted root virtualization for cloud environments: pure software-based trusted root virtualization solutions, hardware-based trusted root virtualization solutions, and trusted root paravirtualization solutions. Among them, the trusted root based on pure software simulation provides an access interface consistent with the hardware trusted root, which can realize most of the functions of the trusted root. Only a few functions with high security requirements are executed by the physical trusted root. However, the pure software solution has poor isolation, lacks hardware protection for cryptographic resources, and the efficiency of soft algorithms cannot be compared with hardware, so the efficiency is low. Hardware-based trusted root virtualization isolates the design of the trusted root at the hardware level to implement multiple trusted root instances in the hardware, such as the hardware virtualization solution of the TCM hardware trusted root based on SR_IOV. Compared with the pure software TCM virtualization solution, this solution has higher security isolation and execution algorithm efficiency.

[0003] The paravirtualization solution of the root of trust refers to scheduling the solution of the physical root of trust at the virtual machine monitor level, and virtualizing the resources inside the root of trust at the same time, so as to realize the sharing of the physical root of trust by the virtual machine. However, these three existing virtualization solutions cannot solve the problem of providing the physical TCM with the trusted measurement function for both the physical host and the virtual machine. The existing technology proposes the C-TCM design solution to solve this problem. C-TCM is designed based on the traditional cloud platform, combining the hardware root of trust virtualization solution and the paravirtualization solution. By adding a management mechanism for deploying the virtual root of trust at the hypervisor layer, the host and virtual machine root of trust can share the C-TCM resources.

[0004] However, in the prior art cloud platform based on Trusted Infrastructure Process Unit (TIPU), when designing the trusted roots of physical hosts and virtual machines, it is necessary to consider unloading the hardware trusted roots to the TIPU card instead of integrating them into the physical host. Therefore, the three conventional TCM virtualization solutions and C-TCM are not suitable for the current new cloud platform scenarios based on the Trusted Infrastructure Process Unit, because the designs of these solutions are all built in the physical server and cannot provide trusted measurement functions for the TIPU card system itself, the operating system of the physical machine, and the operating system of the virtual machine at the same time. Summary of the invention

[0005] The purpose of this application is to provide a cloud platform based on a trusted infrastructure unit in order to overcome the existing technical defects, so as to solve the related functions such as trusted measurement and trusted startup required for DPU devices and HOST servers in the cloud platform environment.

[0006] The purpose of this application is achieved through the following technical solutions:

[0007] In a first aspect, the present application proposes a cloud platform based on a trusted infrastructure unit, wherein the cloud platform includes TIPU card hardware and a computing node of a physical server, wherein the TIPU card hardware and the computing node of the physical server are physically connected via a PCIE bridge, wherein the TIPU card hardware includes TIPU-TCM hardware and a TIPU-TCM operating system, wherein the TIPU-TCM operating system accesses the TIPU-TCM hardware via a physical driver, and wherein the TIPU-TCM hardware supports hardware-level virtualization and provides a hardware trusted root hTCM and multiple virtual machine trusted roots vTCM;

[0008] The hardware trusted root hTCM is used for the trusted support of the TIPU card itself and does not participate in scheduling and management. The virtual machine trusted root vTCM is scheduled to the physical host and virtual machine according to demand to perform trusted measurement and support related trusted functions;

[0009] The hardware trusted root hTCM and the virtual machine trusted root vTCM generate a uuid number when allocating devices to distinguish the user entity corresponding to the command;

[0010] The encryption and decryption engine of the TIPU card hardware encrypts the key material associated with the uuid number and the status information of the simulated virtual machine trusted root vTCM, and then stores it in a remote secure storage medium. Identity authentication is performed through the integrated USB Key. After successful authentication, the encryption and decryption engine decrypts the data, and the data is used in a controlled TIPU-TCM simulation environment.

[0011] The IPU-TCM operating system deploys the IPU-TCM physical driver and the vTCM simulator. The IPU-TCM physical driver is used to access the hardware TCM, and the vTCM simulator is used to call the IPU-TCM physical driver to perform functional operations and resource management.

[0012] In a feasible implementation, the vTCM simulator is also used to simulate and manage the life cycle, including virtual trusted root creation, virtual trusted root initialization, vTCM suspension / resumption, and vTCM destruction, to ensure the security and reliability of the user's entire usage cycle.

[0013] In a feasible implementation, the vTCM simulator creates a virtual root of trust: creates an initial vTCM context based on the user's uuid number, establishes a mapping between the uuid number and the vTCM, and allocates secure storage space and simulates the corresponding register environment.

[0014] In a feasible implementation, the vTCM simulator performs virtual trusted root initialization: initializes the vTCM context, uses the hardware trusted root hTCM to generate keys and certificates for the virtual machine trusted root vTCM, collects and measures the cloud platform status through the hardware trusted root hTCM at startup, forms a measurement baseline value, and stores the keys and certificates to a secure remote storage medium and simulation registers through an encryption and decryption engine.

[0015] In a feasible implementation, the vTCM simulator suspends / resumes the vTCM: the context and register information are encrypted and stored in a remote storage medium, and when the vTCM is resumed, the context and register information are decrypted and reloaded into the vTCM simulator to restore the original operating state.

[0016] In a feasible implementation, the vTCM simulator destroys the vTCM: when the user associated with the vTCM simulator does not exist, the corresponding vTCM simulator performs a destruction operation, and the destruction operation includes clearing the context memory of the vTCM simulator, remotely stored context information, and register data.

[0017] In a feasible implementation, the vTCM simulator further includes a front-end driver and a back-end driver;

[0018] The front-end driver is used to present the vTCM simulated by the back-end driver to the user, and is responsible for accepting and transmitting the user's request for the use of the trusted root and related operations as well as the corresponding trusted measurement data transmission.

[0019] The back-end driver is used to put the user's usage request into the cache queue of the vTCM simulated by the simulator, and transmit the request result back to the user's front-end driver interface.

[0020] In a feasible implementation, the vTCM simulator is also used to execute request scheduling strategies, process trusted root usage requests delivered by the vTCM backend driver, map the simulated vTCM-Context to the corresponding VF in a time-sharing manner, and introduce a request instruction cache queue to cache all pending vTCM requests.

[0021] In a feasible implementation, the vTCM simulator also performs request instruction scheduling and loading execution, and the request instruction scheduling is: judging that all queues have no timeout instructions, if so, sequentially taking instructions in the vTCM queue with the most instructions into the scheduling queue, if not, putting all timeout instructions into the queue, and then judging whether the scheduling queue is full, if not, returning to judging that all queues have no timeout instructions, if so, performing periodic sleep and then judging whether the scheduling queue is full again;

[0022] The loading execution is: determine whether the scheduling queue is empty. If it is empty, perform periodic sleep and then return to determine whether the scheduling queue is empty. If it is not empty, determine whether there is actually idle VF of vTCM. If not, return to determine whether there is actually idle VF of vTCM. If so, sort the scheduling queues by priority weight, and then take the highest priority for the next scheduling, and return to determine whether the scheduling queue is empty.

[0023] In a feasible implementation, the TIPU card hardware adopts PCI power supply or independent power supply.

[0024] The above-mentioned main scheme of the present application and its further options can be freely combined to form multiple schemes, all of which are schemes that can be adopted and claimed for protection in the present application; and in the present application, (non-conflicting options) options and other options can also be freely combined. After understanding the scheme of the present application, those skilled in the art can understand that there are multiple combinations based on the prior art and common knowledge, all of which are technical schemes to be protected by the present application, and they are not exhaustively listed here.

[0025] The present application discloses a cloud platform based on a trusted infrastructure unit. The hardware trusted root hTCM is used for the trusted support of the TIPU card itself and does not participate in scheduling and management. The virtual machine trusted root vTCM is scheduled to the physical host and virtual machine according to demand to perform trusted measurement and support related trusted functions. The encryption and decryption engine of the TIPU card hardware encrypts the key material associated with the uuid number and the state information of the simulated virtual machine trusted root vTCM, and then stores it in a remote secure storage medium. Identity authentication is performed through an integrated USB Key. The IPU-TCM physical driver accesses the hardware TCM, and the vTCM simulator calls the IPU-TCM physical driver to perform functional operations and resource management. By integrating hardware trusted roots, virtualization technology, and efficient communication mechanisms, a comprehensive trusted measurement offloading solution is provided for the cloud platform, which not only enhances the overall security of the cloud environment, but also optimizes resource utilization efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0027] Figure 1 A schematic diagram of the structure of a cloud platform based on a trusted infrastructure unit proposed in an embodiment of the present application is shown.

[0028] Figure 2 A schematic diagram of request instruction scheduling of the TIPU-TCM simulator proposed in an embodiment of the present application is shown.

[0029] Figure 3 A flowchart of request instruction scheduling proposed in an embodiment of the present application is shown.

[0030] Figure 4 A flowchart of loading execution proposed in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0031] The following describes the embodiments of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0032] Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making any creative work shall fall within the scope of protection of this application.

[0033] In the prior art, the three conventional TCM virtualization solutions and C-TCM are not suitable for the current new cloud platform scenarios based on the TIPU trusted infrastructure processing unit, because these solutions are designed to be built in physical servers and cannot provide trusted measurement functions for the TIPU card system itself, the physical machine's operating system, and the virtual machine's operating system at the same time.

[0034] Therefore, in order to solve the above-mentioned technical problems, the embodiment of the present application proposes a cloud platform based on a trusted infrastructure unit to ensure the core component of system security startup and verification - the physical trusted root, which is configured and integrated into the physical hardware of the TIPU card, and directly interacts with the physical TCM chip through the operating system of the TIPU card. The physical TCM in the TIPU card is configured to support single-root input / output virtualization, which is divided into multiple virtual TCMs (vTCMs), each of which can serve different security contexts, such as operating systems or virtual machines, and hTCM (host TCM) is used to ensure the trust measurement and security functions of the TIPU operating system itself.

[0035] In addition, a vTCM simulator is built inside the TIPU card, which is responsible for the creation, scheduling and lifecycle management of vTCM, providing a consistent management framework for all vTCM instances to ensure that they can run efficiently and safely. In addition, in order to enable the physical server and the virtual machines on it to use vTCM resources seamlessly, the TIPU card has designed a set of universal access interfaces based on front-end and back-end drivers. The driver bridges the communication between TIPU and the host through the PCIe bus to ensure efficient and secure data exchange and instruction transmission. Both the physical layer and the virtual layer can equally perform trust measurements and take necessary security measures, which will be explained in detail below.

[0036] Please refer to Figure 1 , Figure 1 A schematic diagram of the structure of a cloud platform based on a trusted infrastructure unit proposed in an embodiment of the present application is shown, wherein the cloud platform includes TIPU card hardware and computing nodes of a physical server, the TIPU card hardware and the computing nodes of the physical server are physically connected via a PCIE bridge, the TIPU card hardware includes TIPU-TCM hardware and a TIPU-TCM operating system, the TIPU-TCM operating system accesses the TIPU-TCM hardware via a physical driver, the TIPU-TCM hardware supports hardware-level virtualization and provides a hardware trusted root hTCM and multiple virtual machine trusted roots vTCM;

[0037] The hardware trusted root hTCM is used for the trusted support of the TIPU card itself and does not participate in scheduling and management. The virtual machine trusted root vTCM is scheduled to the physical host and virtual machine according to demand to perform trusted measurement and support related trusted functions;

[0038] The hardware trusted root hTCM and the virtual machine trusted root vTCM generate a uuid number when allocating devices to distinguish the user entity corresponding to the command;

[0039] The encryption and decryption engine of the TIPU card hardware encrypts the key material associated with the uuid number and the status information of the simulated virtual machine trusted root vTCM, and then stores it in a remote secure storage medium. Identity authentication is performed through the integrated USB Key. After successful authentication, the encryption and decryption engine decrypts the data, and the data is used in a controlled TIPU-TCM simulation environment.

[0040] The IPU-TCM operating system deploys the IPU-TCM physical driver and the vTCM simulator. The IPU-TCM physical driver is used to access the hardware TCM, and the vTCM simulator is used to call the IPU-TCM physical driver to perform functional operations and resource management.

[0041] Different from the traditional TCM virtualization method, this application adopts an innovative cloud platform architecture, in which the TIPU card is connected to the physical server host through PCIe bridging technology. This connection method ensures high-speed data transmission and low-latency communication, allowing the TIPU card to participate in the system operation as a high-performance, high-security auxiliary processing unit.

[0042] The TIPU card hardware adopts PCI power supply or independent power supply. It is designed with independent power management capabilities, and can be powered by PCIe or independently. This design increases its stability and flexibility. The TIPU card has its own built-in operating system, which can independently perform complex trusted computing tasks without relying entirely on the host system, thus improving the security isolation level of the system.

[0043] In the TIPU-TCM architecture, the hardware TCM chip is directly connected to the TIPU card as a peripheral. The TIPU operating system interacts with the TCM chip through a proprietary physical driver to achieve direct control and access to the hardware TCM resources. The hardware TCM needs to support hardware-level virtualization capabilities. TCM is not just a single security module, but can be differentiated into a hardware root of trust (hTCM) and multiple virtual machine roots of trust (vTCM).

[0044] hTCM is reserved for the TIPU card itself to ensure the trusted startup and basic security services of the TIPU operating system, and does not participate in external resource scheduling. vTCM is dynamically allocated to the physical host or the virtual machine on it, providing customized trust measurement and security services to meet the trust requirements in different scenarios.

[0045] The operating system of the TIPU card is embedded with a physical driver specifically for TCM, which is the bridge for communication between the vTCM simulator and the hardware TCM. When a new vTCM instance needs to be created or managed, the vTCM simulator will perform the corresponding operation by calling this driver. To ensure the accuracy and security of each operation, the system will generate a unique uuid number when assigning hTCM or vTCM to a specific user. As an identity identifier in subsequent interactions, any operation request to TCM must carry this uuid number to verify the correspondence between the requester's authority and the vTCM being operated.

[0046] The key data involved in the vTCM simulation process, including but not limited to signature / verification keys, identity keys, root keys, vTCM register values ​​and related certificates, will be encrypted by the encryption and decryption engine built into the TIPU card. The encrypted data is not directly stored locally, but is securely stored on a remote secure storage device using storage offload technology, which enhances the security of data at rest.

[0047] When accessing critical data, you first need to authenticate yourself through the USB Key on the TIPU card to ensure that only authorized entities can initiate data call requests. Once the authentication is passed, the required data will be transferred to the operating environment of the TIPU-TCM simulator and decrypted again using the TIPU encryption and decryption engine before it can be used by specific applications or services.

[0048] TIPU-TCM's physical drive and secure storage mechanism builds a highly secure and reliable trusted root management environment through sophisticated permission control, data encryption storage, and strict access verification processes, ensuring efficient execution and data protection of trusted measurement and security functions in the cloud platform.

[0049] The vTCM simulator is also used to simulate and manage the life cycle, including virtual trusted root creation, virtual trusted root initialization, vTCM suspension / resumption, and vTCM destruction, to ensure the security and reliability of the user throughout the entire usage cycle.

[0050] When a new virtual machine or application requires a trusted service, the vTCM simulator first creates a new vTCM instance, which involves allocating necessary resources such as memory space, computing resources, and security keys, and assigning the previously mentioned unique UUID to the vTCM.

[0051] The vTCM simulator creates a virtual root of trust: it creates an initial vTCM context based on the user's uuid number, establishes a mapping between the uuid number and the vTCM, allocates secure storage space and simulates the corresponding register environment.

[0052] After receiving the creation request, the vTCM simulator will generate a new vTCM context for the specified user uuid. This context is initialized to be empty and maintains all necessary state information during vTCM operation. Then, a mapping relationship between the user uuid and the newly created vTCM uuid is established to ensure that each operation can be accurately associated with the corresponding vTCM instance for subsequent identification and authorization.

[0053] In order to ensure data security, a dedicated secure storage space is allocated to the newly created vTCM. This space is used to store sensitive information and key materials required for vTCM operation, ensuring data isolation and protection even in a cloud environment. Finally, the necessary register environment is simulated. These registers are used to store the operating status and control information of the vTCM, which are the basis for realizing the functions of the vTCM, including but not limited to security status, control bits, and registers for measurement and verification.

[0054] After creation, the vTCM simulator will perform initialization steps to load necessary key materials, set initial states (such as register values), configure security policies, etc., to ensure that the vTCM is in a known, trusted state and is ready to provide services.

[0055] The vTCM simulator performs virtual root of trust initialization: initializes the vTCM context, uses the hardware root of trust hTCM to generate keys and certificates for the virtual machine root of trust vTCM, collects and measures the cloud platform status through the hardware root of trust hTCM at startup, forms a measurement baseline value, and stores the keys and certificates to secure remote storage media and simulation registers through the encryption and decryption engine.

[0056] In the created vTCM context, further configure the necessary parameters and status information to prepare the environment for loading keys and certificates. Using the powerful security features of the hardware trusted root hTCM, generate a unique key pair and certificate for each vTCM. When the virtual machine or host operating system starts, the hardware trusted root hTCM will perform comprehensive system measurements and collect measurement values ​​of key components including the boot loader, operating system kernel, and driver. These values ​​are aggregated to form a unified measurement baseline value.

[0057] The generated keys, certificates, and measurement reference values ​​are encrypted by the hardware encryption and decryption engine built into the TIPU card, and then securely stored in the remote secure storage medium mounted on the TIPU. They are also stored in the simulated registers for quick access later and to ensure that the data is not illegally tampered with. After initialization, the vTCM simulator marks the vTCM as available. At this point, the user can send instructions through the front-end driver in the operating system and use the vTCM to perform security services such as trusted measurement and encryption operations.

[0058] After initialization is complete, vTCM enters an available state and can respond to commands and requests from associated users. Whether performing trusted measurements, data signing, or other security operations, all interactions with vTCM are accompanied by user-specific uuids to ensure authorization and compliance of operations.

[0059] In the scenario where the virtual machine is suspended or migrated, the vTCM simulator needs to manage the suspended state of the vTCM and save its current state information to ensure that it can return to a safe and consistent state to continue service when it is resumed.

[0060] The vTCM simulator suspends / resumes the vTCM: the context and register information are encrypted and stored in a remote storage medium, and when it is resumed, it is decrypted and reloaded into the vTCM simulator to restore the original operating state.

[0061] Collect the current vTCM context information, including all active states and security-related data, capture and save the current state of the registers, use the hardware encryption and decryption engine to encrypt the collected context and register information, transmit and store the encrypted data to a remote secure storage medium for temporary storage, and wait for subsequent recovery operations.

[0062] When a recovery request is received, the encrypted vTCM context data of the corresponding user is first retrieved from the remote secure storage. The encrypted data is decrypted by the hardware encryption and decryption engine, and the decrypted context information is loaded back into the vTCM simulator to re-establish the vTCM operating environment. Then, based on the previously saved register state information, the internal state of the vTCM is accurately restored, including all necessary register values. After completion, the vTCM is restored to the operating state before suspension and continues to provide secure and reliable services to users.

[0063] When a virtual machine or application no longer requires trusted services or reaches the end of its lifecycle, the vTCM simulator is responsible for securely destroying the vTCM instance, including clearing all sensitive information, releasing occupied resources, and confirming that there is no residual data that can be maliciously exploited.

[0064] vTCM simulator destroys vTCM: When the user associated with the vTCM simulator does not exist, the corresponding vTCM simulator is destroyed. The destruction operation includes clearing the context memory of the vTCM simulator, the context information stored remotely, and the register data.

[0065] First, the simulator releases and clears all memory data structures related to the vTCM, including context information, cached data, etc., to ensure that these data can no longer be accessed. Then, an instruction is sent to the remote secure storage to securely destroy the previously temporarily stored vTCM context information and register data. This process also uses the hardware encryption and decryption engine to securely erase or encrypt and overwrite the original data to prevent security risks caused by residual data. After the destruction operation is completed, the simulator will confirm that all relevant storage space has been properly cleaned, and update the internal management status to mark the vTCM as destroyed, thereby avoiding misoperation or illegal access attempts in the future.

[0066] The vTCM simulator also includes a front-end driver and a back-end driver;

[0067] The front-end driver is used to present the vTCM simulated by the back-end driver to the user, and is responsible for accepting and transmitting the user's request for the use of the trusted root and related operations as well as the corresponding trusted measurement data transmission.

[0068] The back-end driver is used to put the user's usage request into the cache queue of the vTCM simulated by the simulator, and transmit the request result back to the user's front-end driver interface.

[0069] The front-end driver presents the vTCM functions simulated by the back-end in a user-friendly form, allowing developers or applications to interact with vTCM intuitively. It receives any user-initiated requests for the use of the trusted root, such as executing secure computing tasks, obtaining trusted measurement data, etc., and ensures that these requests are correctly formatted and encapsulated. It securely transmits the user's request data and the response data obtained from vTCM (including trusted measurement results) back and forth to ensure the integrity and confidentiality of the information.

[0070] The backend driver receives user requests forwarded by the frontend driver and queues them to the vTCM cache queue in the simulator. This process involves efficient request management and priority setting to ensure that requests are executed in an orderly manner. It is tightly integrated with the vTCM simulator, and queued requests are distributed one by one to the simulated vTCM environment for processing, while monitoring the status of the simulator to respond to any possible abnormalities or errors. After processing, the backend driver extracts the operation results of the vTCM and returns them to the user through the frontend driver interface, completing a complete request-response cycle.

[0071] The vTCM simulator is also used to execute request scheduling policies, process trusted root usage requests delivered by the vTCM backend driver, map the simulated vTCM-Context to the corresponding VF in a time-sharing manner, and introduce a request instruction cache queue to cache all pending vTCM requests.

[0072] The vTCM simulator uses an intelligent scheduling algorithm to dynamically map different vTCM-Contexts (i.e., the context of each virtual trusted root) to the virtualized front end (VF) of the physical TCM chip according to time slice rotation or other advanced scheduling strategies. When physical resources are limited, multiple independently running trusted execution environments are simulated. In addition, in order to handle a large number of trusted root usage requests from back-end drivers, the simulator adopts a queue command request mechanism. All pending requests are temporarily stored in one or more queues, which support priority sorting and can be prioritized and scheduled according to the urgency of the request or user-defined weights, thereby optimizing response time and resource utilization. A waiting timeout threshold is also introduced in queue management to effectively prevent some requests from affecting the responsiveness of the overall system due to long waiting times.

[0073] Figure 2 The schematic diagram of the request instruction scheduling of the TIPU-TCM simulator proposed in the embodiment of the present application is shown. Different vTCM-Contexts have different queues inside, such as R11 (weight 200), R21 (weight 100), R31 (weight 100), R51 (weight 50), etc. The weighted priority indicates that different queues will be prioritized according to the weight when scheduling. The same queue follows the first-in-first-out rule, that is, the instruction that enters the queue first will be processed first.

[0074] Each vTCM context is assigned a dedicated request instruction cache queue when it is created. This means that requests from different vTCM instances are processed in isolation, ensuring the independence and security of request processing. When creating a vTCM, customers are required to specify a unified priority weight value for the request queue of the vTCM. Following the first-in-first-out (FIFO) principle, requests for the same vTCM are processed in the order in which they enter the queue. This approach ensures fairness in request processing and is also easy to understand and maintain. The scheduler takes requests out of the queue and maps them to the virtual front end (VF) of the physical TCM for execution based on the priority weight and FIFO rules in the queue. Requests with high priority or early entry into the queue will be given priority service to ensure that critical operations can be completed in a timely manner. At the same time, a waiting time threshold Tw is set for each vTCM queue. When the specified waiting time in the queue exceeds Tw, it will be given priority to enter the scheduling queue.

[0075] In the initial stage of the above-mentioned intelligent scheduling algorithm, if the number of instructions in the instruction cache queues of all vTCM-Contexts does not reach their respective preset thresholds Twi, it means that the current load is low. At this time, the scheduler selects one instruction from the vTCM-Context queue with the largest number of instructions each time and adds it to the tail of the scheduling queue. When the waiting time of any vTCM-Context instruction in the queue exceeds its specified waiting time threshold Tw, it indicates that these requests are already at risk of delay. The scheduler will immediately add all these timed-out instructions to the tail of the scheduling queue to ensure that they can be processed as soon as possible. The scheduler maintains a scheduling queue of variable length, and before selecting an instruction for execution each time, the queue will be re-sorted according to the customer-defined weight value, and instructions with higher weights will be selected and scheduled for execution first.

[0076] The vTCM simulator also performs request instruction scheduling and load execution. The request instruction scheduling is as follows: determine whether all queues have no timeout instructions. If so, take the instructions in the vTCM queue with the most instructions and put them into the scheduling queue in turn. If not, put all timeout instructions into the queue, and then determine whether the scheduling queue is full. If not, return to determine whether all queues have no timeout instructions. If so, perform periodic sleep and then determine whether the scheduling queue is full again.

[0077] The loading execution is: determine whether the scheduling queue is empty. If it is empty, perform periodic sleep and then return to determine whether the scheduling queue is empty. If it is not empty, determine whether there is actually idle VF of vTCM. If not, return to determine whether there is actually idle VF of vTCM. If so, sort the scheduling queues by priority weight, and then take the highest priority for the next scheduling, and return to determine whether the scheduling queue is empty.

[0078] Figure 3 The flowchart of the request instruction scheduling proposed in the embodiment of the present application is shown, and the instruction cache queues of all vTCM-Contexts are checked to determine whether any instruction in any queue exceeds the predetermined waiting time threshold (i.e., whether there is a timed-out instruction). If there is no timed-out instruction in all queues, the algorithm will select the vTCM queue with the largest number of current instructions, and take out an instruction from it and add it to the tail of the scheduling queue. If there is a timed-out instruction, all timed-out instructions are added to the tail of the scheduling queue, and these tasks that have been waiting for too long are processed first. After processing the timed-out instruction or the normal scheduling step, check whether the scheduling queue is full.

[0079] If the scheduling queue is not full, go back to the first step and continue to check whether there are new timeout instructions or re-schedule the load balancing. If the scheduling queue is full, enter the periodic sleep state and then re-check the status of the scheduling queue. Avoid unnecessary CPU usage and resource waste, and ensure energy saving and consumption reduction when idle.

[0080] Figure 4 The flowchart of loading and execution proposed in the embodiment of the present application is shown. Check whether the scheduling queue is empty. If the scheduling queue is empty, it means that there are no pending instructions at present, and enter a periodic sleep state. After the sleep is over, check again whether the scheduling queue is still empty. If it is still empty, continue to sleep to form a loop until a new instruction is added to the queue. When there are pending instructions in the scheduling queue, it is next determined whether any vTCM (virtual hardware resources, such as virtual functions VF) is currently idle, and whether there are enough execution resources to process the instructions to be scheduled. If all vTCM VFs are occupied, new instructions will not be blindly scheduled, but will return to recheck the idle status of the vTCM VF until available resources are found. Once an idle vTCM VF is found, the instructions in the scheduling queue will be sorted by priority weight, and the instruction with the highest priority will be selected for the next scheduling execution. After execution, return to the starting point again, check whether the scheduling queue is empty, and start a new round of scheduling cycle.

[0081] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0082] First, the unified trusted measurement TCM offloading is realized through the TIPU trusted execution environment, which effectively responds to the trusted measurement and startup requirements of DPU devices and HOST servers in the cloud platform.

[0083] Second, the original TCM virtualization function is transferred to the TIPU card, which significantly releases the CPU, memory and storage resources of the physical server, and reduces the burden originally borne by the host.

[0084] Third, the system built into the TIPU card not only integrates the encryption and decryption engine and hardware USB KEY protection, but also provides an independent, highly secure execution environment for trusted measurement and startup functions. Its isolation and protection level exceeds previous architectures.

[0085] Fourth, thanks to the uKey function integrated in the TIPU card, when storing vTCM-related keys, you can directly use the built-in secret key of the TIPU card and, with the help of the security features of uKey, implement a simpler and more secure key storage solution.

[0086] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A cloud platform based on a trusted infrastructure unit, characterized in that: The cloud platform includes TIPU card hardware and computing nodes of a physical server, the TIPU card hardware and the computing nodes of the physical server are physically connected via a PCIE bridge, the TIPU card hardware includes TIPU-TCM hardware and a TIPU-TCM operating system, the TIPU-TCM operating system accesses the TIPU-TCM hardware via a physical driver, and the TIPU-TCM hardware supports hardware-level virtualization and provides a hardware trusted root hTCM and multiple virtual machine trusted roots vTCM; The hardware trusted root hTCM is used for the trusted support of the TIPU card itself and does not participate in scheduling and management. The virtual machine trusted root vTCM is scheduled to the physical host and virtual machine according to demand to perform trusted measurement and support related trusted functions; The hardware trusted root hTCM and the virtual machine trusted root vTCM generate a uuid number when allocating devices to distinguish the user entity corresponding to the command; The encryption and decryption engine of the TIPU card hardware encrypts the key material associated with the uuid number and the status information of the simulated virtual machine trusted root vTCM, and then stores it in a remote secure storage medium. Identity authentication is performed through the integrated USB Key. After successful authentication, the encryption and decryption engine decrypts the data, and the data is used in a controlled TIPU-TCM simulation environment. The IPU-TCM operating system deploys the IPU-TCM physical driver and the vTCM simulator. The IPU-TCM physical driver is used to access the hardware TCM, and the vTCM simulator is used to call the IPU-TCM physical driver to perform functional operations and resource management.

2. The cloud platform based on the trusted infrastructure unit according to claim 1, characterized in that: The vTCM simulator is also used to simulate and manage the life cycle, including virtual trusted root creation, virtual trusted root initialization, vTCM suspension / resumption, and vTCM destruction, to ensure the security and reliability of the user throughout the entire usage cycle.

3. The cloud platform based on the trusted infrastructure unit according to claim 2, characterized in that: The vTCM simulator creates a virtual root of trust: it creates an initial vTCM context based on the user's uuid number, establishes a mapping between the uuid number and the vTCM, allocates secure storage space and simulates the corresponding register environment.

4. The cloud platform based on the trusted infrastructure unit according to claim 2, characterized in that: The vTCM simulator performs virtual root of trust initialization: initializes the vTCM context, uses the hardware root of trust hTCM to generate keys and certificates for the virtual machine root of trust vTCM, collects and measures the cloud platform status through the hardware root of trust hTCM at startup, forms a measurement baseline value, and stores the keys and certificates to secure remote storage media and simulation registers through the encryption and decryption engine.

5. The cloud platform based on the trusted infrastructure unit according to claim 2, characterized in that: The vTCM simulator suspends / resumes the vTCM: the context and register information are encrypted and stored in a remote storage medium, and when it is resumed, it is decrypted and reloaded into the vTCM simulator to restore the original operating state.

6. The cloud platform based on the trusted infrastructure unit according to claim 2, characterized in that: vTCM simulator destroys vTCM: When the user associated with the vTCM simulator does not exist, the corresponding vTCM simulator is destroyed. The destruction operation includes clearing the context memory of the vTCM simulator, the context information stored remotely, and the register data.

7. The cloud platform based on a trusted infrastructure unit according to claim 1, characterized in that: The vTCM simulator also includes a front-end driver and a back-end driver; The front-end driver is used to present the vTCM simulated by the back-end driver to the user, and is responsible for receiving and transmitting the user's request for the use of the trusted root and related operations as well as the corresponding trusted measurement data transmission; The back-end driver is used to put the user's usage request into the cache queue of the vTCM simulated by the simulator, and transmit the request result back to the user's front-end driver interface.

8. The cloud platform based on a trusted infrastructure unit according to claim 1, characterized in that: The vTCM simulator is also used to execute request scheduling policies, process trusted root usage requests delivered by the vTCM backend driver, map the simulated vTCM-Context to the corresponding VF in a time-sharing manner, and introduce a request instruction cache queue to cache all pending vTCM requests.

9. The cloud platform based on a trusted infrastructure unit according to claim 1, characterized in that: The vTCM simulator also performs request instruction scheduling and load execution. The request instruction scheduling is as follows: determine whether all queues have no timeout instructions. If so, take the instructions in the vTCM queue with the most instructions and put them into the scheduling queue in turn. If not, put all timeout instructions into the queue, and then determine whether the scheduling queue is full. If not, return to determine whether all queues have no timeout instructions. If so, perform periodic sleep and then determine whether the scheduling queue is full again. The loading execution is: determine whether the scheduling queue is empty. If it is empty, perform periodic sleep and then return to determine whether the scheduling queue is empty. If it is not empty, determine whether there is actually idle VF of vTCM. If not, return to determine whether there is actually idle VF of vTCM. If so, sort the scheduling queues by priority weight, and then take the highest priority for the next scheduling, and return to determine whether the scheduling queue is empty.

10. The cloud platform based on a trusted infrastructure unit according to claim 1, characterized in that: The TIPU card hardware adopts PCI power supply or independent power supply.

Images