Construction method of trusted root architecture and application method and device of trusted system

Abstract

The invention relates to a construction method of a trusted root architecture and an application method and device of a trusted system. The method comprises the following steps: performing entity division on a trusted root on a hardware entity in a server to obtain a plurality of trusted root instances, and performing interface docking on a target trusted root instance in the plurality of trusted root instances and a main system in the server, and performing interface docking on other trusted root instances in the plurality of trusted root instances and a plurality of virtual machines in the server to construct a trusted system of the plurality of trusted root instances. According to the construction method, the trusted roots corresponding to all the trusted computing systems run in the hardware entity and are protected by the hardware entity, the security of each trusted system can be improved, the trusted root instance in each trusted system can directly call the data processing module of the hardware to process data, and the data processing efficiency is improved. The method is not limited by a software data processing algorithm, and can greatly improve the data processing rate, thereby improving the data processing performance of each trusted system.

Description

Technical Field

[0001] This application relates to the field of virtual machine technology, and in particular to a method for constructing a trusted root architecture, a method for applying a trusted system, and an apparatus. Background Technology

[0002] In a trusted computing system, the Root of Trust (ROT) is usually unique and bound to a hardware entity. With the development of cloud computing, host systems and virtual machine systems coexist on the same server, requiring collaboration between the ROT to build a trusted computing system.

[0003] In traditional technologies, the root of trust (ROT) in a single hardware entity is typically virtualized to generate multiple virtual root of trust (vROT) systems within the host server system. These vROTs are then uniformly authenticated and managed by the ROTs within the hardware entity. The virtual root of trust (vROT) then serves as the root for building a trusted computing system for virtual machines.

[0004] However, traditional virtual machine trusted computing systems suffer from low security and performance issues. Summary of the Invention

[0005] Therefore, it is necessary to provide a method for constructing a trusted root architecture, an application method for a trusted system, and an apparatus for addressing the aforementioned technical problems, which can improve the security and performance of the trusted root system.

[0006] Firstly, this application provides a method for constructing a trusted root architecture, including:

[0007] The trusted root on the hardware entity in the server is partitioned into multiple trusted root instances.

[0008] The target trusted root instance among multiple trusted root instances is interfaced with the main system in the server, and other trusted root instances among multiple trusted root instances are interfaced with multiple virtual machines in the server, so as to build a trusted system with multiple trusted root instances.

[0009] In one embodiment, the trusted root on the hardware entity in the server is partitioned to obtain multiple trusted root instances, including;

[0010] Based on the hardware virtualization function, the trusted root on the hardware entity in the server is divided into multiple trusted root instances; the hardware virtualization function includes single root I / O virtualization function or indirect device I / O virtualization function.

[0011] In one embodiment, the trusted roots on the hardware entities in the server are partitioned according to the hardware virtualization function to obtain multiple trusted root instances, including:

[0012] If the hardware entity supports single root I / O virtualization, then the trusted root in the hardware entity is partitioned according to the single root I / O virtualization function to obtain multiple trusted root instances.

[0013] If the hardware entity supports indirect device I / O virtualization, then the trusted root in the hardware entity is partitioned according to the indirect device I / O virtualization function to obtain multiple trusted root instances;

[0014] If the hardware entity supports both single root I / O virtualization and indirect device I / O virtualization, then the single root I / O virtualization function is selected to partition the trusted root in the hardware entity to obtain multiple trusted root instances. Alternatively, either the single root I / O virtualization function or the indirect device I / O virtualization function can be selected to partition the trusted root in the hardware entity to obtain multiple trusted root instances.

[0015] In one embodiment, a target trusted root instance among multiple trusted root instances is interfaced with the main system in the server, and other trusted root instances among the multiple trusted root instances are interfaced with multiple virtual machines in the server to construct a trusted system with multiple trusted root instances, including:

[0016] Choose any one of the multiple trusted root instances as the target trusted root instance to interface with the main system, or choose a trusted root instance from the multiple trusted root instances whose processing performance matches that of the main system as the target trusted root instance to interface with the main system.

[0017] Additionally, for each virtual machine, select any other trusted root instance from multiple other trusted root instances to interface with the virtual machine, or select another trusted root instance from multiple other trusted root instances whose processing performance matches that of the virtual machine to interface with the virtual machine.

[0018] In one embodiment, the plurality of trusted root instances also includes a backup trusted root instance, and the method further includes:

[0019] If an interface connection failure with the main system is detected, the backup trusted root instance will be connected to the main system.

[0020] If a failure to interface with the virtual machine is detected, the backup trusted root instance will be connected to the virtual machine.

[0021] In one embodiment, a target trusted root instance among multiple trusted root instances is interfaced with the main system in the server, and other trusted root instances among the multiple trusted root instances are interfaced with multiple virtual machines in the server to construct a trusted system with multiple trusted root instances, including:

[0022] Establish a transmission channel between the interface of the target trusted root instance and the interface of the main system, as well as a transparent transmission channel between the interfaces of other trusted root instances and the interface of the virtual machine, in order to construct a trusted system with multiple trusted root instances.

[0023] In one embodiment, the method further includes:

[0024] The storage space in the hardware entity is divided into multiple storage subspaces; each storage subspace corresponds one-to-one with a multiple root of trust instance.

[0025] Multiple task queues are set up in the hardware entity; different task queues correspond to different data processing modules in the hardware entity.

[0026] In one embodiment, the method further includes:

[0027] During the execution of the target task by each trusted root instance, the data processing module corresponding to the target task of each trusted root instance is called to perform data processing.

[0028] In one embodiment, during the execution of the target task by each trusted root instance, a data processing module corresponding to the target task of each trusted root instance is invoked to perform data processing, including:

[0029] During the execution of the target task for each trusted root instance, the usage status of the data processing module corresponding to the target task of the trusted root instance is determined.

[0030] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0031] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0032] In one embodiment, the method further includes:

[0033] If a faulty trusted root instance reports an alarm, the target task is transferred to a backup trusted root instance in the hardware entity for data processing. The connection between the faulty trusted root instance and the corresponding virtual machine or host is disconnected, and the backup trusted root instance is interfaced with the corresponding virtual machine or host.

[0034] Secondly, this application also provides a method for applying a trusted system, the method being applied to the trusted system as described in the first aspect, the method comprising:

[0035] For any trusted root instance in the trusted system, obtain the target task received by the trusted root instance and determine the usage status of the data processing module corresponding to the target task;

[0036] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0037] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0038] Thirdly, this application also provides a means for constructing a trusted root architecture, comprising:

[0039] The partitioning module is used to partition the trusted roots on the hardware entities in the server into multiple trusted root instances.

[0040] The building module is used to interface the target trusted root instance among multiple trusted root instances with the main system in the server, and to interface other trusted root instances among multiple trusted root instances with multiple virtual machines in the server, so as to build a trusted system with multiple trusted root instances.

[0041] Fourthly, this application also provides an application apparatus for a trusted system, comprising:

[0042] The acquisition module is used to acquire the target task received by any trusted root instance in the trusted system, and to determine the usage status of the data processing module corresponding to the target task.

[0043] The calling module is used to call the data processing module corresponding to the target task to perform data processing when the usage status is available.

[0044] The waiting module is used to send the target task to the task queue corresponding to the data processing module for processing when the usage status is occupied.

[0045] Fifthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0046] The trusted root on the hardware entity in the server is partitioned into multiple trusted root instances.

[0047] The target trusted root instance among multiple trusted root instances is interfaced with the main system in the server, and other trusted root instances among multiple trusted root instances are interfaced with multiple virtual machines in the server, so as to build a trusted system with multiple trusted root instances.

[0048] Sixthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0049] For any trusted root instance in the trusted system, obtain the target task received by the trusted root instance and determine the usage status of the data processing module corresponding to the target task;

[0050] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0051] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0052] Seventhly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0053] The trusted root on the hardware entity in the server is partitioned into multiple trusted root instances.

[0054] The target trusted root instance among multiple trusted root instances is interfaced with the main system in the server, and other trusted root instances among multiple trusted root instances are interfaced with multiple virtual machines in the server, so as to build a trusted system with multiple trusted root instances.

[0055] Eighthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0056] For any trusted root instance in the trusted system, obtain the target task received by the trusted root instance and determine the usage status of the data processing module corresponding to the target task;

[0057] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0058] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0059] Ninthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0060] The trusted root on the hardware entity in the server is partitioned into multiple trusted root instances.

[0061] The target trusted root instance among multiple trusted root instances is interfaced with the main system in the server, and other trusted root instances among multiple trusted root instances are interfaced with multiple virtual machines in the server, so as to build a trusted system with multiple trusted root instances.

[0062] In a tenth aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0063] For any trusted root instance in the trusted system, obtain the target task received by the trusted root instance and determine the usage status of the data processing module corresponding to the target task;

[0064] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0065] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0066] The aforementioned method for constructing a trusted root architecture, the method for applying a trusted system, and the apparatus involve partitioning the trusted root on the hardware entity in the server to obtain multiple trusted root instances. A target trusted root instance among these instances interfaces with the main system in the server, and other trusted root instances interface with multiple virtual machines in the server, thereby constructing a trusted system with multiple trusted root instances. Since the trusted system with multiple trusted root instances is constructed by partitioning the hardware entity, the data processing module in the hardware entity can be directly invoked to provide trusted services to the host in the main system and the virtual machines in the virtual machine system. Compared with existing technologies that use virtual trusted roots built on the host hard drive to provide trusted services, this improves data processing speed and thus enhances the performance of the trusted system. Furthermore, since the hardware entity is a non-removable chip in the server, partitioning the hardware entity to obtain multiple trusted root instances avoids the collapse of the trusted system due to the loss of trusted roots, thereby improving the security of the trusted system. Attached Figure Description

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

[0068] Figure 1 This is a schematic diagram of a trust system in traditional technologies;

[0069] Figure 2 This is a diagram of the internal structure of a server in one embodiment;

[0070] Figure 3 This is a flowchart illustrating the construction method of a trusted root architecture in one embodiment;

[0071] Figure 4 This is a schematic diagram of the trusted root architecture in one embodiment;

[0072] Figure 5 This is a flowchart illustrating the construction method of the trusted root architecture in another embodiment;

[0073] Figure 6 This is a flowchart illustrating the construction method of the trusted root architecture in another embodiment;

[0074] Figure 7 This is a flowchart illustrating the construction method of the trusted root architecture in another embodiment;

[0075] Figure 8 This is a flowchart illustrating the construction method of the trusted root architecture in another embodiment;

[0076] Figure 9 This is a schematic diagram illustrating the division of hardware entities in one embodiment;

[0077] Figure 10 This is a flowchart illustrating the construction method of the trusted root architecture in another embodiment;

[0078] Figure 11 This is a flowchart illustrating the construction method of the trusted root architecture in another embodiment;

[0079] Figure 12 This is a flowchart illustrating the construction method of the trusted root architecture in another embodiment;

[0080] Figure 13 This is a flowchart illustrating the application method of a trusted system in one embodiment;

[0081] Figure 14 This is a flowchart illustrating the construction method of the trusted root architecture in another embodiment;

[0082] Figure 15 This is a structural block diagram of a device for constructing a trusted root architecture in one embodiment;

[0083] Figure 16 This is a structural block diagram of an application device for a trusted system in one embodiment. Detailed Implementation

[0084] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0085] In related technologies, within a trusted computing system, the Root of Trust (ROT) is typically unique and bound to a hardware entity. However, with the development of cloud computing, host systems and virtual machine systems coexist on the same server, requiring independent ROTs to build independent trusted computing systems. Therefore, multiple ROT instances need to coexist on the same server device to achieve the construction of a trusted system for the entire cloud computing system. In existing trusted systems, a hardware entity is typically selected and bound to a single ROT. Then, through virtualization technology, multiple virtual roots of trust (vROTs) are generated on the host hard drive, uniformly authenticated and managed by the ROTs. The vROTs then serve as the roots to build the trusted computing system for the virtual machines. For example, see [link to relevant documentation]. Figure 1 The diagram illustrates a trusted architecture where n virtual roots of trust (vROTs) are constructed within the main server system. The ROTs in the hardware entity manage and control these n vROTs in a unified manner. Furthermore, each of the n vROTs corresponds to one of the n virtual machines, forming its own trusted system. The host machine also corresponds to a ROT in the hardware entity, forming its own trusted system. In this architecture, because the vROTs not only need to interact with the host but also need to manage and control multiple vROTs in a unified manner, the workload is heavy, and system lag and poor performance are likely to occur.

[0086] Furthermore, since vROT is essentially software code stored on hard drive, establishing a relationship with hardware entities through ROT, and its key keys and data are not stored in the hardware entities but rather as data on the hard drive, the security of existing trusted computing entities built with vROT as the root is relatively low. At the same time, vROT cannot directly use the hardware entity's acceleration algorithm modules like ROT can; it can only use software algorithms instead, thus limiting algorithm performance and consequently reducing the performance of the entire trusted system.

[0087] In view of this, this application proposes a method for constructing a trusted root architecture, which can improve the security and performance of the trusted root system.

[0088] It should be noted that the beneficial effects or technical problems solved by the embodiments of this application are not limited to this one, but may also be other implicit or related problems. For details, please refer to the description of the embodiments below.

[0089] The trusted root architecture construction method provided in this application embodiment can be applied to, for example, Figure 2The server shown includes a processor, memory, input / output (I / O) interfaces, a communication interface, hardware entities, n virtual machines, and a host. The hardware entities are connected to the host and the n virtual machines via a system bus. The processor, memory, and I / O interfaces are connected via the system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor, host, and virtual machines provide computing and control capabilities. The host and memory include non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operating system and computer programs in the non-volatile storage media to run. The server's database stores data for building a trusted root architecture or application data for a trusted system. The server's I / O interfaces are used for exchanging information between the processor and external devices. The server's communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for building a trusted root architecture or an application method for a trusted system.

[0090] The following embodiments will specifically illustrate the construction and application methods of the trusted root architecture provided in this application.

[0091] In one embodiment, such as Figure 3 As shown, a method for constructing a trusted root architecture is provided, which can be applied to... Figure 2 Taking the server in the example of this, the explanation includes:

[0092] S201, perform entity partitioning on the trusted roots on the hardware entities in the server to obtain multiple trusted root instances.

[0093] Among them, the hardware entity is a trusted hardware chip, which is an important component of the trusted system. It is usually composed of a trusted metric root (RTM), a trusted storage root (RTS), and a trusted reporting root (RTR).

[0094] In this embodiment, when it is necessary to construct independent ROT trusted computing systems based on a trusted computing architecture, multiple ROT instances generally need to coexist on the same server. Traditionally, multiple independent ROT trusted computing systems can be constructed by building multiple vROTs. However, in this embodiment, the server can construct multiple independent ROT trusted computing systems by virtualizing the ROTs on the hardware entity. Specifically, the server can first determine the number of virtual machines on the server, and then determine the number of trusted root instances needed based on the number of virtual machines and the number of hosts. Optionally, the number of trusted root instances is the sum of the number of virtual machines and the number of hosts; alternatively, the number of trusted root instances can be the sum of the number of virtual machines, the number of hosts, and the number of spare trusted root instances. For example, if the number of hosts is 1 and the number of virtual machines is n, then the corresponding number of trusted root instances can be n+1. When the server determines the number of trusted root instances based on the above steps, it can divide the physical resources of the hardware entity according to this number to obtain multiple trusted root instances. Each trusted root instance supports the same functions. The physical resources of the hardware entity can include physical interfaces, memory, accelerators, communication modules, etc. It should be noted that when constructing multiple root trust instances, the root trust (ROT) within a hardware entity can be specifically split into multiple identical or different root trust instances; alternatively, relevant hardware entity virtualization technologies can be used to virtualize the hardware entity based on the root trust (ROT) within the hardware entity, thereby converting a single hardware entity's ROT into multiple root trust (ROTs). The aforementioned identical or different root trust instances refer to the storage space or the type of business data processed by the root trust (ROT). In other words, when initially dividing root trust instances based on the number of virtual machines, not only the number of virtual machines but also the business processing type of the virtual machines can be considered to divide the corresponding number and type of ROT instances. This ensures that each ROT instance corresponds one-to-one with a virtual machine, forming an independent trust system without interference. Alternatively, each ROT instance can correspond one-to-one with the type of virtual machine, forming an independent trust system without interference. After the hardware entities are divided, a corresponding trusted root identifier can be assigned to each trusted root instance, and multiple trusted root instances can be matched with hosts and virtual machines. The correspondence between multiple trusted root instances and hosts and virtual machines can be recorded in a mapping table so that when building each trusted system, the mapping table can be directly called to find the corresponding connected host or virtual machine based on the identifier of each trusted root instance to build the trusted system.

[0095] S202, interface the target trusted root instance among multiple trusted root instances with the main system in the server, and interface the other trusted root instances among multiple trusted root instances with multiple virtual machines in the server, so as to build a trusted system with multiple trusted root instances.

[0096] The target root instance can be any one of multiple root instances. Optionally, the interface can be a Peripheral Component Interconnect Express (PCIe) interface, and the interface docking process may include determining the transmission speed and link width, calculating throughput, designing the physical link, and selecting the protocol version.

[0097] In this embodiment, after the server divides multiple trusted root instances on the hardware entity, it can sequentially or according to a preset order perform interface docking operations on each trusted root instance, enabling each trusted root instance to connect with each host in the main system of the server and with each virtual machine in the server, forming their own independent data transmission links. For example, the interface corresponding to the target trusted root is docked with the interface corresponding to the main system in the server to construct the trusted system of the main system; other trusted root instances are mapped one-to-one with virtual machines, and other trusted root instances are paired with virtual machines to determine the mapping relationship between other trusted root instances and virtual machines. Based on this mapping relationship, the interfaces corresponding to other trusted root instances among the multiple trusted root instances are docked with the interfaces corresponding to multiple virtual machines in the server to obtain the trusted system of each virtual machine. It should be noted that any other trusted root instance can be paired with any virtual machine, or, according to the business data type or the type of business processed by the virtual machine, the virtual machine can be paired with a trusted root instance. The specific pairing strategy can be determined in advance according to business requirements and virtual machine type. For example, see... Figure 4 The server architecture shown establishes a trusted system for Trusted Root Instance 0 by connecting the host in the main system to Trusted Root Instance 0 via an interface; a trusted system for Trusted Root Instance 1 by connecting to Virtual Machine 1 via an interface; a trusted system for Trusted Root Instance 2 by connecting to Virtual Machine 2 via an interface; and a trusted system for Trusted Root Instance n by connecting to Virtual Machine n via an interface. These n trusted systems are independent and do not interfere with each other. Furthermore, it should be noted that after establishing trusted systems for multiple Trusted Root Instances, the virtual machines within each trusted system can identify the corresponding connected Trusted Root Instance, thus ensuring the independence of each trusted system.

[0098] In the above-mentioned method for constructing a trusted root architecture, the trusted root on the hardware entity in the server is divided into entities to obtain multiple trusted root instances. Then, the target trusted root instance in the multiple trusted root instances is interfaced with the main system in the server, and the other trusted root instances in the multiple trusted root instances are interfaced with multiple virtual machines in the server to construct a trusted system with multiple trusted root instances. The aforementioned construction method enables the creation of multiple trusted root instances within a hardware entity. This means that all trusted roots corresponding to the trusted computing systems operate within the hardware entity and are protected by it. Compared to existing methods that form trusted systems by constructing multiple virtual trusted roots, the construction method of this application, due to the protection mechanism and non-removable nature of the hardware entity, can improve the security of each trusted system constructed from multiple trusted root instances. Furthermore, since the trusted systems of multiple trusted root instances are independently set up and managed and controlled by their respective trusted root instances, the data transmission performance of each trusted root system can be improved. Simultaneously, the trusted root instance in each trusted system can directly call the hardware's data processing module for data processing, without being limited by software data processing algorithms, which can greatly improve the data processing rate and thus enhance the data processing performance of each constructed trusted system.

[0099] In one embodiment, an implementation of the above S201 is provided, wherein the above "entity partitioning of trusted roots on hardware entities in the server to obtain multiple trusted root instances" includes: partitioning trusted roots on hardware entities in the server according to hardware virtualization functions to obtain multiple trusted root instances; the hardware virtualization functions include single root I / O virtualization functions or indirect device I / O virtualization functions.

[0100] Among them, Single Root I / O Virtualization (SR-IOV) is a PCIe device virtualization technology that can virtualize a single physical PCIe device into multiple virtual devices (VFs) and directly allocate them to each virtual machine. Indirect Device I / O Virtualization (vfio-mdev) enables direct I / O device virtualization, allowing virtual machines to directly access the physical device's memory space through the interface. Specifically, vfio-mdev can perform fine-grained partitioning of the physical resources of a PCIe device, virtualizing a high-performance PCIe device into multiple smaller PCIe devices with independent functions. Optionally, the hardware entity can be considered a PCIe device.

[0101] In this embodiment, when the server partitions trusted root instances of a hardware entity, it can utilize SR-IOV technology to divide the hardware entity into multiple virtual devices, allowing multiple virtual machines to directly access it; alternatively, it can utilize vfio-mdev technology to perform fine-grained partitioning of the physical resources of the hardware entity, virtualizing a high-performance PCIe device into multiple smaller PCIe devices with independent functions. Optionally, since the hardware entity can support either single-root I / O virtualization or indirect device I / O virtualization, or both, the server can select either single-root I / O virtualization or indirect device I / O virtualization as the target function based on its virtualization capabilities. This target function is then used to partition the trusted root on the hardware entity in the server, resulting in multiple trusted root instances.

[0102] In the above-mentioned embodiments, the trusted root in the hardware entity is partitioned by the single root I / O virtualization function or the indirect device I / O virtualization function, which improves the success rate and accuracy of partitioning the hardware entity, thereby improving the reliability of the trusted root instance.

[0103] In one embodiment, such as Figure 5 As shown, the above "entity partitioning of trusted roots on hardware entities in the server to obtain multiple trusted root instances" includes:

[0104] S301, if the hardware entity supports single root I / O virtualization, then the trusted root in the hardware entity is divided into multiple trusted root instances based on the single root I / O virtualization function.

[0105] In this embodiment, it is first determined whether the hardware entity supports the single root I / O virtualization function. If the hardware entity supports the single root I / O virtualization function, the hardware entity is divided into multiple virtual devices according to the single root I / O virtualization function, resulting in multiple trusted root instances.

[0106] As an optional implementation, a first target module that supports single root I / O virtualization can be identified, and all modules contained in the hardware entity can be identified, thereby determining whether the first target module is included among all modules. If it is included, the hardware entity supports single root I / O virtualization; if it is not included, the hardware entity does not support single root I / O virtualization.

[0107] As another alternative implementation, the identifiers of the functions supported by the hardware entity can be pre-encapsulated into an identifier library. Before performing entity partitioning on the trusted root on the hardware entity in the server, the first identifier of the single root I / O virtualization function is determined, thereby determining whether the identifier library includes the first identifier. If it is included, the hardware entity supports the single root I / O virtualization function; if it is not included, the hardware entity does not support the single root I / O virtualization function.

[0108] As another optional implementation, all components and scripts stored in the hardware entity are traversed to determine whether the hardware entity stores the component or script corresponding to the single root I / O virtualization function. If so, the hardware entity supports the single root I / O virtualization function; if not, the hardware entity does not support the single root I / O virtualization function.

[0109] S302, if the hardware entity supports the indirect device I / O virtualization function, then the trusted root in the hardware entity is divided into multiple trusted root instances according to the indirect device I / O virtualization function.

[0110] In this embodiment, it is determined whether the hardware entity supports the indirect device I / O virtualization function. If it does, the physical resources of the hardware entity are divided into fine-grained parts according to the indirect device I / O virtualization function, thereby realizing the entity partitioning of the trusted root in the hardware entity and ensuring the feasibility of entity partitioning.

[0111] As an optional implementation, a second target module that supports indirect device I / O virtualization can be identified, and all modules contained in the hardware entity can be identified, thereby determining whether the second target module is included among all modules. If it is included, the hardware entity supports indirect device I / O virtualization; if it is not included, the hardware entity does not support indirect device I / O virtualization.

[0112] As another alternative implementation, the identifiers of the functions supported by the hardware entity can be pre-encapsulated into an identifier library. Before performing entity partitioning on the trusted root on the hardware entity in the server, a second identifier for the indirect device I / O virtualization function is determined, thereby determining whether the identifier library includes the second identifier. If it does, the hardware entity supports the indirect device I / O virtualization function; if it does not, the hardware entity does not support the indirect device I / O virtualization function.

[0113] As another optional implementation, all components and scripts stored in the hardware entity are traversed to determine whether the hardware entity stores components or scripts corresponding to the indirect device I / O virtualization function. If so, the hardware entity supports the indirect device I / O virtualization function; otherwise, the hardware entity does not support the indirect device I / O virtualization function.

[0114] S303, if the hardware entity supports single root I / O virtualization and indirect device I / O virtualization, then select the single root I / O virtualization function to partition the trusted root in the hardware entity to obtain multiple trusted root instances; or, select either the single root I / O virtualization function or the indirect device I / O virtualization function to partition the trusted root in the hardware entity to obtain multiple trusted root instances.

[0115] In this embodiment, since the single-root I / O virtualization function can directly divide a hardware entity into multiple virtual devices, the entity partitioning of trusted roots within the hardware entity based on the single-root I / O virtualization function ensures efficiency. Therefore, when the hardware entity supports both single-root I / O virtualization and indirect device I / O virtualization, the entity partitioning of trusted roots within the hardware entity can be prioritized based on the single-root I / O virtualization function to obtain multiple trusted root instances. Alternatively, either the single-root I / O virtualization function or the indirect device I / O virtualization function can be selected as the target function, thereby partitioning the trusted roots within the hardware entity based on the target function to obtain multiple trusted root instances, making entity partitioning more flexible.

[0116] In the above application embodiments, the trusted root in the hardware entity can be directly partitioned based on the single root I / O virtualization function to ensure the efficiency of partitioning the trusted root in the hardware entity. The trusted root in the hardware entity can also be partitioned based on the indirect device I / O virtualization function to ensure the feasibility of partitioning the trusted root.

[0117] In one embodiment, one implementation of S202 above is provided, such as... Figure 6 As shown, the above-mentioned "interface connection between the target trusted root instance among multiple trusted root instances and the main system in the server, and interface connection between other trusted root instances among multiple trusted root instances and multiple virtual machines in the server to construct a trusted system with multiple trusted root instances" includes:

[0118] S401, select any one of the multiple trusted root instances as the target trusted root instance to interface with the main system, or select a trusted root instance whose processing performance matches that of the main system as the target trusted root instance to interface with the main system.

[0119] Processing performance can include processing speed, storage capacity, etc.

[0120] In this embodiment, the processing performance of each trusted root instance can be the same or different. When the processing performance of each trusted root instance is the same, or when the processing performance of each trusted root instance can meet the processing requirements of the main system, any trusted root instance is selected from multiple trusted root instances as the target trusted root instance, and the target trusted root instance is interfaced with the main system to construct the trusted system corresponding to the main system.

[0121] Alternatively, when the processing performance of each trusted root instance is different, the processing performance of each trusted root instance is determined, as well as the target processing performance required by the main system. A trusted root instance with a processing performance greater than or equal to the target processing performance is selected from the trusted root instances as the first candidate trusted root instance. Further, any trusted root instance from the first candidate trusted root instances is selected as the target trusted root instance to interface with the main system. Alternatively, the trusted root instance with the best processing performance among the first candidate trusted root instances is selected as the target trusted root to interface with the main system, thereby constructing the trusted system corresponding to the main system.

[0122] S402: For each virtual machine, select any other trusted root instance from multiple other trusted root instances to interface with the virtual machine, or select another trusted root instance from multiple other trusted root instances whose processing performance matches that of the virtual machine to interface with the virtual machine.

[0123] In this embodiment, for each virtual machine, when the processing performance of each trusted root instance is the same, or when the processing performance of each trusted root instance can meet the processing requirements of the virtual machine, any trusted root instance is selected from multiple trusted root instances as another trusted root instance, and the other trusted root instances are interfaced with the virtual machine to construct the trusted system corresponding to the virtual machine. Alternatively, when the processing performance of each trusted root instance is different, the processing performance of each trusted root instance and other processing performance required by the virtual machine are determined, and a trusted root instance with processing performance greater than or equal to other processing performance is selected from the trusted root instances as a second candidate trusted root instance. Further, any trusted root instance is selected from the second candidate trusted root instances as another trusted root instance to interface with the virtual machine, or the trusted root instance with the best processing performance among the second candidate trusted root instances is selected as another trusted root to interface with the virtual machine, thereby constructing the trusted system corresponding to the virtual machine.

[0124] Optionally, the virtual machines can be sorted according to their processing performance requirements. For example, the virtual machines can be sorted from largest to smallest processing performance requirements, and then other trusted root instances corresponding to each virtual machine can be determined in turn based on the sorting results.

[0125] In the above application embodiments, for the main system and each virtual machine, the main system or virtual machine can be randomly combined with each trusted root instance, or the trusted root instance can be matched with the corresponding trusted root instance according to the processing performance of each trusted root instance. When randomly combined, the efficiency of building an optional system can be improved. When the trusted root instance is matched with the corresponding trusted root instance according to the processing performance of each trusted root instance, the processing requirements of the main system or virtual machine can be guaranteed to be met.

[0126] In one embodiment, such as Figure 7 As shown, the multiple trusted root instances also include backup trusted root instances. The application method of the above trusted system also includes:

[0127] S203, if the interface connection with the main system fails, the backup trusted root instance will be connected to the main system.

[0128] In this embodiment, the trusted root instances on the hardware entities in the server are partitioned according to the hardware virtualization function. The number of trusted root instances obtained can be greater than the total number of the main system and virtual machines. That is, after building a trusted system with multiple trusted root instances, there are idle trusted root instances in the hardware entities, which can be used as backup trusted root instances. When the main system fails to connect to the interface, for example, when the server detects that the main system has not established a connection with the corresponding trusted root instance, the trusted root instance corresponding to the main system is replaced with a backup trusted root instance, and the backup trusted root instance is connected to the interface to build the trusted system.

[0129] Optionally, the hardware entity may have one or more standby trusted root instances.

[0130] S204, if a failure to connect to the virtual machine is detected, the backup trusted root instance will be connected to the virtual machine.

[0131] In this embodiment of the application, if any virtual machine fails to connect to the interface, for example, if the server detects that the virtual machine has not established a connection with the corresponding trusted root instance, the trusted root instance corresponding to the virtual machine is replaced with a backup trusted root instance, and the backup trusted root instance is connected to the interface to build a trusted system.

[0132] In the above application embodiments, a backup trusted root instance is reserved in the hardware entity. When the main system or virtual machine fails to connect with the trusted root instance, the backup trusted root instance is used to reconnect, thereby improving the success rate and fault tolerance of building a trusted system.

[0133] In one embodiment, an implementation of the above-mentioned S202 is provided, wherein the above-mentioned "interface interface between the target trusted root instance in the multiple trusted root instances and the main system in the server, and interface between the other trusted root instances in the multiple trusted root instances and the multiple virtual machines in the server to construct a trusted system of multiple trusted root instances" includes: establishing a transmission channel between the interface of the target trusted root instance and the interface of the main system, and a transparent transmission channel between the interfaces of the other trusted root instances and the interfaces of the virtual machines to construct a trusted system of multiple trusted root instances.

[0134] In this embodiment, a connection is established between the hardware entity and the chip corresponding to the main system through a physical medium. For example, a crossover network cable is used to connect the interface of the hardware entity to the interface of the chip corresponding to the main system, thereby establishing a transmission channel between the interface of the target trusted root instance and the interface of the main system. In addition, a wireless pass-through module can be set in the server, so that the main system is used as a pass-through third-party system. The pass-through channel between the interface of other trusted root instances and the interface of the virtual machine is established through the wireless pass-through module, without the need for additional physical connections when building the trusted system of the virtual machine.

[0135] In the above-mentioned embodiments, establishing a transmission channel between the interface of the target trusted root instance and the interface of the main system ensures the privacy and security of data transmission between the target trusted root and the main system, and the data transmission latency is low with minimal performance loss; establishing a transparent transmission channel between the interfaces of other trusted root instances and the interfaces of virtual machines does not require additional hardware or network configuration, and reduces the resources consumed by data processing.

[0136] In one embodiment, such as Figure 8 As shown, the above-mentioned method for constructing a trusted root architecture also includes:

[0137] S205, the storage space in the hardware entity is divided into multiple storage subspaces; each storage subspace corresponds one-to-one with a multiple trusted root instance.

[0138] In this embodiment, the storage space in the hardware entity can be evenly divided according to the number of trusted root instances to obtain multiple storage subspaces of the same size, and these subspaces can be allocated to multiple trusted root instances, so that each storage subspace corresponds one-to-one with a trusted root instance; alternatively, the capacity requirements of the host system and each virtual machine for the trusted system can be obtained, and the storage space in the hardware entity can be divided according to these capacity requirements to obtain multiple storage subspaces, and the storage subspaces can be allocated to the trusted root instances corresponding to the host system or virtual machines according to their capacity. For example, as... Figure 5As shown, the storage space in the hardware entity is divided to obtain the storage subspace corresponding to Trusted Root Instance 0, the storage subspace corresponding to Trusted Root Instance 1, and the storage subspace corresponding to Trusted Root Instance 2.

[0139] S206 sets up multiple task queues in the hardware entity; different task queues correspond to different data processing modules in the hardware entity.

[0140] The data processing module is located in the hardware entity and belongs to the hardware circuit.

[0141] In this embodiment of the application, the hardware entity may include multiple data processing modules, such as... Figure 5 As shown, the data processing module can be any of the following: a data encryption module, a random number generation module, etc. The data encryption module can be any of the following: an asymmetric encryption algorithm SM2 module, a hash algorithm SM3 module, a symmetric encryption algorithm SM4 module, etc.; the random number generation module can be a True Random Number Generator (TRNG) module. In the hardware entity, task queues are set up for each data processing module to ensure a one-to-one correspondence between the task queues and the data processing modules. Multiple task queues can process data processing tasks in parallel. When a data processing module receives a data processing task, it can first add the task to the task queue to wait. When the data processing task meets the processing requirements, it will be processed. For example, if the hardware entity includes an asymmetric encryption algorithm SM2 module, a hash algorithm SM3 module, a symmetric encryption algorithm SM4 module, and a random number generation module, then the hardware entity will have a task queue corresponding to the asymmetric encryption algorithm SM2 module, a task queue corresponding to the symmetric encryption algorithm SM4 module, and a task queue corresponding to the random number generation module.

[0142] Optional, such as Figure 9 As shown, occupancy symbols can be established for each data processing module. These symbols are used to indicate whether the data processing module is occupied or available.

[0143] Optionally, an RTOS or embedded Linux can be introduced into the hardware entity to enable multi-task parallel processing, thereby ensuring the independent operation of each trusted root instance.

[0144] In the above-mentioned embodiments, the storage space in the hardware entity is divided so that multiple storage subspaces correspond one-to-one with multiple trusted root instances, thereby realizing the hardware partitioning of the hardware entity, allocating independent storage space to each trusted root instance, and ensuring that the data processing tasks of each trusted root instance do not affect each other; multiple task queues are set in the hardware entity, which improves the utilization rate of the processing resources of the processing module.

[0145] In one embodiment, such as Figure 10 As shown, the above-mentioned method for constructing a trusted root architecture also includes:

[0146] S207, During the execution of the target task by each trusted root instance, the data processing module corresponding to the target task of each trusted root instance is called to perform data processing.

[0147] In this embodiment, the hardware entity may include an SM2 module, an SM3 module, an SM4 module, and a TRNG module. The hardware entity can pre-store the correspondence between task identifiers and data processing modules for each data processing task. This allows the determination of the corresponding data processing module for a target task based on its task identifier and the pre-defined correspondence, and the invocation of that data processing module to process the target task. For example, the data processing module corresponding to task identifier 1 may be the SM2 module, the data processing module corresponding to task identifier 2 may be the SM3 module, the data processing module corresponding to task identifier 3 may be the SM4 module, and the data processing module corresponding to task identifier 4 may be the TRNG module.

[0148] The method in this application embodiment calls the data processing module corresponding to the target task of each trusted root instance to perform data processing, ensuring the accuracy of data processing and completing the provision of trusted services to the main system or virtual machine under the trusted system.

[0149] In one embodiment, one implementation of the above-described S207 is provided, such as... Figure 11 As shown, the above-mentioned "during the execution of the target task in each trusted root instance, calling the data processing module corresponding to the target task of each trusted root instance for data processing" includes:

[0150] S501, during the execution of the target task for each trusted root instance, determine the usage status of the data processing module corresponding to the target task of the trusted root instance.

[0151] The usage status of the data processing module includes either an available status or a occupied status.

[0152] In this embodiment, the usage status of the data processing module can be determined by whether the processing process of the data processing module corresponding to the target task is idle. If it is idle, the data processing module is available; if it is not idle, the data processing module is occupied. Alternatively, the usage status of the data processing module can be determined based on the occupancy sign of the data processing module corresponding to the target task. For example, if the occupancy sign is 0, the data processing module is available; if the occupancy sign is 1, the data processing module is occupied.

[0153] S502, if the usage status is available, then call the data processing module corresponding to the target task to perform data processing.

[0154] In this embodiment, if the usage status is available, and the data processing module corresponding to the target task currently has no data processing task being processed, then the data processing module corresponding to the target task is directly invoked for data processing. For example, if the data processing module corresponding to the target task is an SM2 module, then the SM2 algorithm is invoked to encrypt the target task; if the data processing module corresponding to the target task is an SM3 module, then the SM3 algorithm is invoked to encrypt the target task; if the data processing module corresponding to the target task is an SM4 module, then the SM4 algorithm is invoked to encrypt the target task; if the data processing module corresponding to the target task is a TRNG module, then TRNG is invoked to generate random numbers for the target task.

[0155] S503, if the usage status is occupied, the target task is sent to the task queue corresponding to the data processing module to wait for processing.

[0156] In this embodiment of the application, when the usage state is occupied, the target task is sent to the task queue corresponding to the data processing module to wait for processing. When the target task is at the first position in the task queue and the data processing module corresponding to the target task denies that the usage state is available, the data processing module corresponding to the target task is called to perform data processing.

[0157] In the above application embodiments, a task queuing mechanism is introduced when the hardware entity includes multiple trusted root instances to avoid data chaos or data blockage caused by multiple trusted root instances calling the same data processing module at the same time.

[0158] In one embodiment, such as Figure 12 As shown, the above-mentioned "during the execution of the target task in each trusted root instance, calling the data processing module corresponding to the target task of each trusted root instance for data processing" also includes:

[0159] S504 If an alarm message is reported on a faulty trusted root instance, the target task is transferred to the backup trusted root instance in the hardware entity for data processing. The connection between the faulty trusted root instance and the corresponding virtual machine or host is disconnected, and the backup trusted root instance is interfaced with the corresponding virtual machine or host.

[0160] In this embodiment, when the server detects an alarm message reported by a faulty trusted root instance, it determines that there is a faulty trusted root instance in the hardware entity, and then parses the alarm message to obtain the information of the faulty trusted root instance, thereby determining the location of the trusted root instance. Furthermore, it disconnects the connection between the faulty trusted root instance and the corresponding virtual machine or the corresponding host, transfers the target task in the faulty trusted root instance to the backup trusted root, such as the existing data processing information of the target task, the processing progress of the target task, etc., and interfaces the backup trusted root instance with the corresponding virtual machine or host.

[0161] Optionally, the trusted root instance may report an alarm to the server when it is unable to execute a task issued by the host system or virtual machine; or, the trusted root instance may report an alarm to the server when it is unable to transmit the processed data to the host system or virtual machine; or, if a hardware entity detects that the trusted root instance has not received the target task within a preset time period or has not called the data processing module to process data within a preset time period, it may instruct the trusted root to report an alarm to the server, or the hardware entities may report alarms to each other.

[0162] Optionally, the hardware entity may have one or more standby trusted root instances.

[0163] In the above application embodiments, when the trusted root instance fails, the server promptly obtains the failure status of the trusted root instance based on the alarm information reported by the trusted root instance, and uses the backup trusted root instance pre-established in the hardware entity to replace the failed trusted root instance, so that the trusted system can continue to provide trusted services to the main system or virtual machine, thereby improving the fault tolerance of the trusted system.

[0164] In one embodiment, such as Figure 13 As shown, based on the above Figures 3 to 12 The architecture of the trusted root instance in this embodiment provides an application method for a trusted system. The following description uses the application of this method to the aforementioned trusted system as an example:

[0165] S601: For any trusted root instance in the trusted system, obtain the target task received by the trusted root instance and determine the usage status of the data processing module corresponding to the target task.

[0166] In this embodiment, within the trusted hierarchy of the main system, the trusted root instance receives the target task sent by the main system; within the trusted hierarchy of the virtual machine, the trusted root instance receives the target task sent by the virtual machine. The usage status of a data processing module can be determined by checking whether its processing process is idle. If idle, the data processing module is available; if not idle, it is occupied. Alternatively, the usage status of a data processing module can be determined based on its occupancy flag. For example, if the occupancy flag is 0, the data processing module is available; if it is 1, it is occupied.

[0167] S602, if the usage status is available, then call the data processing module corresponding to the target task to perform data processing.

[0168] In this embodiment, if the usage status is available, and the data processing module corresponding to the target task currently has no data processing task being processed, then the data processing module corresponding to the target task is directly invoked for data processing. For example, if the data processing module corresponding to the target task is an SM2 module, then the SM2 algorithm is invoked to encrypt the target task; if the data processing module corresponding to the target task is an SM3 module, then the SM3 algorithm is invoked to encrypt the target task; if the data processing module corresponding to the target task is an SM4 module, then the SM4 algorithm is invoked to encrypt the target task; if the data processing module corresponding to the target task is a TRNG module, then TRNG is invoked to generate random numbers for the target task.

[0169] S603, if the usage status is occupied, the target task is sent to the task queue corresponding to the data processing module to wait for processing.

[0170] In this embodiment of the application, when the usage state is occupied, the target task is sent to the task queue corresponding to the data processing module to wait for processing. When the target task is at the first position in the task queue and the data processing module corresponding to the target task denies that the usage state is available, the data processing module corresponding to the target task is called to perform data processing.

[0171] In the above-described application method of the trusted system, for any trusted root instance in the trusted system, the target task received by the trusted root instance is obtained, and the usage status of the data processing module corresponding to the target task is determined. When the usage status is available, the data processing module corresponding to the target task is called to perform data processing; when the usage status is occupied, the target task is sent to the task queue corresponding to the data processing module to wait for processing. By directly calling the data processing module in the hardware entity to provide trusted services to the host in the main system and the virtual machine in the virtual machine system, the data processing speed is improved, thereby improving the performance of the trusted system. Furthermore, since the hardware entity is a non-removable chip in the server, dividing the hardware entity into multiple trusted root instances avoids the collapse of the trusted system due to the loss of trusted roots, thus improving the security of the trusted system. At the same time, when the hardware entity includes multiple trusted root instances, a task queuing mechanism is introduced to prevent multiple trusted root instances from calling the same data processing module at the same time, which could lead to data corruption or data congestion.

[0172] In one embodiment, a complete method for constructing and applying a trusted root architecture is also provided, such as... Figure 14 As shown, it includes:

[0173] S1, determine whether the hardware entity supports single root I / O virtualization and / or indirect device I / O virtualization; if it supports single root I / O virtualization, proceed to S2; if it supports indirect device I / O virtualization, proceed to S3; if it supports both single root I / O virtualization and indirect device I / O virtualization, proceed to S4.

[0174] S2, based on the single root I / O virtualization function, divides the trusted root in the hardware entity into entities to obtain multiple trusted root instances.

[0175] S3, based on the indirect device I / O virtualization function, divide the trusted root in the hardware entity into entities to obtain multiple trusted root instances.

[0176] S4, select the single root I / O virtualization function to partition the trusted root in the hardware entity to obtain multiple trusted root instances, or select either the single root I / O virtualization function or the indirect device I / O virtualization function to partition the trusted root in the hardware entity to obtain multiple trusted root instances.

[0177] S5 divides the storage space in the hardware entity into multiple storage subspaces; each storage subspace corresponds one-to-one with a multiple trusted root instance.

[0178] S6 sets up multiple task queues in the hardware entity; different task queues correspond to different data processing modules in the hardware entity.

[0179] S7. Select any one of the multiple trusted root instances as the target trusted root instance to interface with the main system, or select a trusted root instance whose processing performance matches that of the main system as the target trusted root instance to interface with the main system.

[0180] S8, for each virtual machine, selects any other trusted root instance from multiple other trusted root instances to interface with the virtual machine, or selects another trusted root instance from multiple other trusted root instances whose processing performance matches that of the virtual machine to interface with the virtual machine.

[0181] S9. Establish a transmission channel between the interface of the target trusted root instance and the interface of the main system, as well as a transparent transmission channel between the interfaces of other trusted root instances and the interface of the virtual machine, in order to construct a trusted system with multiple trusted root instances.

[0182] S10, if the interface connection with the main system fails, the backup trusted root instance will be connected to the main system.

[0183] S11, if a failure to connect to the virtual machine is detected, the backup trusted root instance will be connected to the virtual machine.

[0184] S12, during the execution of the target task for each trusted root instance, determine the usage status of the data processing module corresponding to the target task of the trusted root instance.

[0185] S13, if the usage status is available, then call the data processing module corresponding to the target task to perform data processing.

[0186] S14. If the usage status is occupied, the target task is sent to the task queue corresponding to the data processing module for processing.

[0187] S15, if an alarm message is reported on a faulty trusted root instance, the target task is transferred to the backup trusted root instance in the hardware entity for data processing, and the connection between the faulty trusted root instance and the corresponding virtual machine or host is disconnected, and the backup trusted root instance is interfaced with the corresponding virtual machine or host.

[0188] In the above-mentioned method for constructing a trusted root architecture, the trusted root on the hardware entity in the server is divided into entities to obtain multiple trusted root instances. Then, the target trusted root instance in the multiple trusted root instances is interfaced with the main system in the server, and the other trusted root instances in the multiple trusted root instances are interfaced with multiple virtual machines in the server to construct a trusted system with multiple trusted root instances. The aforementioned construction method enables the creation of multiple trusted root instances within a hardware entity. This means that all trusted roots corresponding to the trusted computing systems operate within the hardware entity and are protected by it. Compared to existing methods that form trusted systems by constructing multiple virtual trusted roots, the construction method of this application, due to the protection mechanism and non-removable nature of the hardware entity, can improve the security of each trusted system constructed from multiple trusted root instances. Furthermore, since the trusted systems of multiple trusted root instances are independently set up and managed and controlled by their respective trusted root instances, the data transmission performance of each trusted root system can be improved. Simultaneously, the trusted root instance in each trusted system can directly call the hardware's data processing module for data processing, without being limited by software data processing algorithms, which can greatly improve the data processing rate and thus enhance the data processing performance of each constructed trusted system.

[0189] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0190] Based on the same inventive concept, this application also provides a trusted root architecture construction apparatus for implementing the aforementioned trusted root architecture construction method. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more trusted root architecture construction apparatus embodiments provided below can be found in the limitations of the trusted root architecture construction method described above, and will not be repeated here.

[0191] In one embodiment, such as Figure 10 As shown, a device for constructing a trusted root architecture is provided, comprising: a first partitioning module 10 and a construction module 11, wherein:

[0192] The first partitioning module 10 is used to partition the trusted roots on the hardware entities in the server to obtain multiple trusted root instances.

[0193] Module 11 is used to interface the target trusted root instance among multiple trusted root instances with the main system in the server, and to interface other trusted root instances among multiple trusted root instances with multiple virtual machines in the server, so as to build a trusted system with multiple trusted root instances.

[0194] In one embodiment, the first partitioning module 10 includes: a partitioning unit, configured to partition the trusted roots on the hardware entities in the server according to the hardware virtualization function, thereby obtaining multiple trusted root instances; the hardware virtualization function includes a single root I / O virtualization function or an indirect device I / O virtualization function.

[0195] In one embodiment, the aforementioned partitioning unit is specifically used to partition the trusted roots in the hardware entity according to the single root I / O virtualization function when the hardware entity supports the single root I / O virtualization function, thereby obtaining multiple trusted root instances; when the hardware entity supports the indirect device I / O virtualization function, it is used to partition the trusted roots in the hardware entity according to the indirect device I / O virtualization function, thereby obtaining multiple trusted root instances; when the hardware entity supports both the single root I / O virtualization function and the indirect device I / O virtualization function, the single root I / O virtualization function is selected to partition the trusted roots in the hardware entity to obtain multiple trusted root instances, or either the single root I / O virtualization function or the indirect device I / O virtualization function is selected to partition the trusted roots in the hardware entity to obtain multiple trusted root instances.

[0196] In one embodiment, the above-mentioned construction module 11 includes: a first docking unit and a second docking unit, wherein:

[0197] The first docking unit is used to select any one of the multiple trusted root instances as the target trusted root instance to dock with the main system, or to select a trusted root instance whose processing performance matches that of the main system as the target trusted root instance to dock with the main system.

[0198] The second docking unit is used to select any other trusted root instance from multiple other trusted root instances to dock with the virtual machine for each virtual machine, or to select another trusted root instance from multiple other trusted root instances whose processing performance matches that of the virtual machine for docking.

[0199] In one embodiment, the application apparatus of the above-mentioned trusted system further includes: a first detection module and a second detection module, wherein:

[0200] The first detection module is used to connect the backup trusted root instance to the main system if the interface connection with the main system fails.

[0201] The second detection module is used to connect the backup trusted root instance to the virtual machine if an interface connection failure is detected.

[0202] In one embodiment, the above-mentioned construction module 11 includes: a construction unit, used to establish a transmission channel between the interface of the target trusted root instance and the interface of the main system, and a transparent transmission channel between the interfaces of other trusted root instances and the interface of the virtual machine, so as to construct a trusted system with multiple trusted root instances.

[0203] In one embodiment, the above-mentioned trusted root architecture construction apparatus further includes: a second partitioning module and a setting module, wherein:

[0204] The second partitioning module is used to partition the storage space in the hardware entity to obtain multiple storage subspaces; each storage subspace corresponds one-to-one with a multiple root trust instance.

[0205] The configuration module is used to set up multiple task queues in the hardware entity; different task queues correspond to different data processing modules in the hardware entity.

[0206] In one embodiment, the above-mentioned trusted root architecture construction apparatus further includes: a second invocation module, used to invoke the data processing module corresponding to the target task of each trusted root instance for data processing during the execution of the target task by each trusted root instance.

[0207] In one embodiment, the second invocation module includes: a determining unit, an invocation unit, and a issuing unit, wherein:

[0208] The determination unit is used to determine the usage status of the data processing module corresponding to the target task of each trusted root instance during the execution of the target task.

[0209] The calling unit is used to call the data processing module corresponding to the target task to perform data processing when the usage status is available.

[0210] The dispatch unit is used to dispatch the target task to the task queue corresponding to the data processing module for processing when the usage status is occupied.

[0211] In one embodiment, the application device of the above-mentioned trusted system further includes: a transfer module, which is used to transfer the target task to a backup trusted root instance in the hardware entity for data processing when an alarm information is reported on a faulty trusted root instance, disconnect the connection between the faulty trusted root instance and the corresponding virtual machine or the corresponding host, and interface the backup trusted root instance with the corresponding virtual machine or host.

[0212] The modules in the aforementioned trusted root architecture construction device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0213] Based on the same inventive concept, this application also provides an application apparatus for implementing the application method of the trusted system described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more embodiments of the trusted system application apparatus provided below can be found in the limitations of the trusted system application method described above, and will not be repeated here.

[0214] In one embodiment, such as Figure 11 As shown, a trusted system application device is provided, comprising: an acquisition module 12, a first invocation module 13, and a waiting module 14, wherein:

[0215] The acquisition module 12 is used to acquire the target task received by any trusted root instance in the trusted system and determine the usage status of the data processing module corresponding to the target task.

[0216] The first calling module 13 is used to call the data processing module corresponding to the target task to perform data processing when the usage status is available.

[0217] The waiting module 14 is used to send the target task to the task queue corresponding to the data processing module for processing when the usage status is occupied.

[0218] Each module in the application device of the aforementioned trusted system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0219] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram can be referred to as shown below. Figure 1 The diagram shows the internal structure of the server.

[0220] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0221] The trusted root on the hardware entity in the server is partitioned into multiple trusted root instances.

[0222] The target trusted root instance among multiple trusted root instances is interfaced with the main system in the server, and other trusted root instances among multiple trusted root instances are interfaced with multiple virtual machines in the server, so as to build a trusted system with multiple trusted root instances.

[0223] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0224] Based on the hardware virtualization function, the trusted root on the hardware entity in the server is divided into multiple trusted root instances; the hardware virtualization function includes single root I / O virtualization function or indirect device I / O virtualization function.

[0225] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0226] If the hardware entity supports single root I / O virtualization, then the trusted root in the hardware entity is partitioned according to the single root I / O virtualization function to obtain multiple trusted root instances.

[0227] If the hardware entity supports indirect device I / O virtualization, then the trusted root in the hardware entity is partitioned according to the indirect device I / O virtualization function to obtain multiple trusted root instances;

[0228] If the hardware entity supports both single root I / O virtualization and indirect device I / O virtualization, then the single root I / O virtualization function is selected to partition the trusted root in the hardware entity to obtain multiple trusted root instances. Alternatively, either the single root I / O virtualization function or the indirect device I / O virtualization function can be selected to partition the trusted root in the hardware entity to obtain multiple trusted root instances.

[0229] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0230] Choose any one of the multiple trusted root instances as the target trusted root instance to interface with the main system, or choose a trusted root instance from the multiple trusted root instances whose processing performance matches that of the main system as the target trusted root instance to interface with the main system.

[0231] Additionally, for each virtual machine, select any other trusted root instance from multiple other trusted root instances to interface with the virtual machine, or select another trusted root instance from multiple other trusted root instances whose processing performance matches that of the virtual machine to interface with the virtual machine.

[0232] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0233] If an interface connection failure with the main system is detected, the backup trusted root instance will be connected to the main system.

[0234] If a failure to interface with the virtual machine is detected, the backup trusted root instance will be connected to the virtual machine.

[0235] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0236] Establish a transmission channel between the interface of the target trusted root instance and the interface of the main system, as well as a transparent transmission channel between the interfaces of other trusted root instances and the interface of the virtual machine, in order to construct a trusted system with multiple trusted root instances.

[0237] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0238] The storage space in the hardware entity is divided into multiple storage subspaces; each storage subspace corresponds one-to-one with a multiple root of trust instance.

[0239] Multiple task queues are set up in the hardware entity; different task queues correspond to different data processing modules in the hardware entity.

[0240] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0241] During the execution of the target task by each trusted root instance, the data processing module corresponding to the target task of each trusted root instance is called to perform data processing.

[0242] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0243] During the execution of the target task for each trusted root instance, the usage status of the data processing module corresponding to the target task of the trusted root instance is determined.

[0244] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0245] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0246] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0247] For any trusted root instance in the trusted system, obtain the target task received by the trusted root instance and determine the usage status of the data processing module corresponding to the target task;

[0248] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0249] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0250] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0251] If a faulty trusted root instance reports an alarm, the target task is transferred to a backup trusted root instance in the hardware entity for data processing. The connection between the faulty trusted root instance and the corresponding virtual machine or host is disconnected, and the backup trusted root instance is interfaced with the corresponding virtual machine or host.

[0252] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0253] The trusted root on the hardware entity in the server is partitioned into multiple trusted root instances.

[0254] The target trusted root instance among multiple trusted root instances is interfaced with the main system in the server, and other trusted root instances among multiple trusted root instances are interfaced with multiple virtual machines in the server, so as to build a trusted system with multiple trusted root instances.

[0255] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0256] Based on the hardware virtualization function, the trusted root on the hardware entity in the server is divided into multiple trusted root instances; the hardware virtualization function includes single root I / O virtualization function or indirect device I / O virtualization function.

[0257] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0258] If the hardware entity supports single root I / O virtualization, then the trusted root in the hardware entity is partitioned according to the single root I / O virtualization function to obtain multiple trusted root instances.

[0259] If the hardware entity supports indirect device I / O virtualization, then the trusted root in the hardware entity is partitioned according to the indirect device I / O virtualization function to obtain multiple trusted root instances;

[0260] If the hardware entity supports both single root I / O virtualization and indirect device I / O virtualization, then the single root I / O virtualization function is selected to partition the trusted root in the hardware entity to obtain multiple trusted root instances. Alternatively, either the single root I / O virtualization function or the indirect device I / O virtualization function can be selected to partition the trusted root in the hardware entity to obtain multiple trusted root instances.

[0261] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0262] Choose any one of the multiple trusted root instances as the target trusted root instance to interface with the main system, or choose a trusted root instance from the multiple trusted root instances whose processing performance matches that of the main system as the target trusted root instance to interface with the main system.

[0263] Additionally, for each virtual machine, select any other trusted root instance from multiple other trusted root instances to interface with the virtual machine, or select another trusted root instance from multiple other trusted root instances whose processing performance matches that of the virtual machine to interface with the virtual machine.

[0264] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0265] If an interface connection failure with the main system is detected, the backup trusted root instance will be connected to the main system.

[0266] If a failure to interface with the virtual machine is detected, the backup trusted root instance will be connected to the virtual machine.

[0267] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0268] Establish a transmission channel between the interface of the target trusted root instance and the interface of the main system, as well as a transparent transmission channel between the interfaces of other trusted root instances and the interface of the virtual machine, in order to construct a trusted system with multiple trusted root instances.

[0269] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0270] The storage space in the hardware entity is divided into multiple storage subspaces; each storage subspace corresponds one-to-one with a multiple root of trust instance.

[0271] Multiple task queues are set up in the hardware entity; different task queues correspond to different data processing modules in the hardware entity.

[0272] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0273] During the execution of the target task by each trusted root instance, the data processing module corresponding to the target task of each trusted root instance is called to perform data processing.

[0274] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0275] During the execution of the target task for each trusted root instance, the usage status of the data processing module corresponding to the target task of the trusted root instance is determined.

[0276] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0277] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0278] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0279] For any trusted root instance in the trusted system, obtain the target task received by the trusted root instance and determine the usage status of the data processing module corresponding to the target task;

[0280] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0281] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0282] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0283] If a faulty trusted root instance reports an alarm, the target task is transferred to a backup trusted root instance in the hardware entity for data processing. The connection between the faulty trusted root instance and the corresponding virtual machine or host is disconnected, and the backup trusted root instance is interfaced with the corresponding virtual machine or host.

[0284] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0285] The trusted root on the hardware entity in the server is partitioned into multiple trusted root instances.

[0286] The target trusted root instance among multiple trusted root instances is interfaced with the main system in the server, and other trusted root instances among multiple trusted root instances are interfaced with multiple virtual machines in the server, so as to build a trusted system with multiple trusted root instances.

[0287] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0288] Based on the hardware virtualization function, the trusted root on the hardware entity in the server is divided into multiple trusted root instances; the hardware virtualization function includes single root I / O virtualization function or indirect device I / O virtualization function.

[0289] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0290] If the hardware entity supports single root I / O virtualization, then the trusted root in the hardware entity is partitioned according to the single root I / O virtualization function to obtain multiple trusted root instances.

[0291] If the hardware entity supports indirect device I / O virtualization, then the trusted root in the hardware entity is partitioned according to the indirect device I / O virtualization function to obtain multiple trusted root instances;

[0292] If the hardware entity supports both single root I / O virtualization and indirect device I / O virtualization, then the single root I / O virtualization function is selected to partition the trusted root in the hardware entity to obtain multiple trusted root instances. Alternatively, either the single root I / O virtualization function or the indirect device I / O virtualization function can be selected to partition the trusted root in the hardware entity to obtain multiple trusted root instances.

[0293] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0294] Choose any one of the multiple trusted root instances as the target trusted root instance to interface with the main system, or choose a trusted root instance from the multiple trusted root instances whose processing performance matches that of the main system as the target trusted root instance to interface with the main system.

[0295] Additionally, for each virtual machine, select any other trusted root instance from multiple other trusted root instances to interface with the virtual machine, or select another trusted root instance from multiple other trusted root instances whose processing performance matches that of the virtual machine to interface with the virtual machine.

[0296] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0297] If an interface connection failure with the main system is detected, the backup trusted root instance will be connected to the main system.

[0298] If a failure to interface with the virtual machine is detected, the backup trusted root instance will be connected to the virtual machine.

[0299] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0300] Establish a transmission channel between the interface of the target trusted root instance and the interface of the main system, as well as a transparent transmission channel between the interfaces of other trusted root instances and the interface of the virtual machine, in order to construct a trusted system with multiple trusted root instances.

[0301] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0302] The storage space in the hardware entity is divided into multiple storage subspaces; each storage subspace corresponds one-to-one with a multiple root of trust instance.

[0303] Multiple task queues are set up in the hardware entity; different task queues correspond to different data processing modules in the hardware entity.

[0304] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0305] During the execution of the target task by each trusted root instance, the data processing module corresponding to the target task of each trusted root instance is called to perform data processing.

[0306] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0307] During the execution of the target task for each trusted root instance, the usage status of the data processing module corresponding to the target task of the trusted root instance is determined.

[0308] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0309] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0310] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0311] For any trusted root instance in the trusted system, obtain the target task received by the trusted root instance and determine the usage status of the data processing module corresponding to the target task;

[0312] If the usage status is available, the data processing module corresponding to the target task will be invoked to process the data.

[0313] If the usage status is occupied, the target task will be sent to the task queue corresponding to the data processing module for processing.

[0314] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0315] If a faulty trusted root instance reports an alarm, the target task is transferred to a backup trusted root instance in the hardware entity for data processing. The connection between the faulty trusted root instance and the corresponding virtual machine or host is disconnected, and the backup trusted root instance is interfaced with the corresponding virtual machine or host.

[0316] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0317] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0318] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for constructing a trusted root architecture, characterized in that, The method includes: The trusted root on the hardware entity in the server is partitioned into multiple trusted root instances. The target trusted root instance among the multiple trusted root instances is interfaced with the main system in the server, and the other trusted root instances among the multiple trusted root instances are interfaced with multiple virtual machines in the server, so as to construct a trusted system with multiple trusted root instances.

2. The method according to claim 1, characterized in that, The trusted root on the hardware entity in the server is partitioned into multiple trusted root instances, including: Based on the hardware virtualization function, the trusted roots on the hardware entities in the server are partitioned into multiple trusted root instances; the hardware virtualization function includes single root I / O virtualization function or indirect device I / O virtualization function.

3. The method according to claim 2, characterized in that, The step of partitioning the trusted roots on the hardware entities in the server according to the hardware virtualization function to obtain the multiple trusted root instances includes: If the hardware entity supports the single root I / O virtualization function, then the trusted root in the hardware entity is divided into multiple trusted root instances according to the single root I / O virtualization function. If the hardware entity supports the indirect device I / O virtualization function, then the trusted roots in the hardware entity are partitioned according to the indirect device I / O virtualization function to obtain multiple trusted root instances; If the hardware entity supports the single root I / O virtualization function and the indirect device I / O virtualization function, then the single root I / O virtualization function is selected to partition the trusted root in the hardware entity to obtain multiple trusted root instances. Alternatively, either the single root I / O virtualization function or the indirect device I / O virtualization function is selected to partition the trusted root in the hardware entity to obtain multiple trusted root instances.

4. The method according to any one of claims 1-3, characterized in that, The step of interface-connecting the target trusted root instance among the plurality of trusted root instances with the main system in the server, and interface-connecting the other trusted root instances among the plurality of trusted root instances with multiple virtual machines in the server, to construct a trusted system with multiple trusted root instances, includes: Alternatively, one can select any trusted root instance from the plurality of trusted root instances as the target trusted root instance to interface with the main system, or select a trusted root instance from the plurality of trusted root instances whose processing performance matches that of the main system as the target trusted root instance to interface with the main system. Furthermore, for each virtual machine, any one of the multiple other trusted root instances is selected to interface with the virtual machine, or, from the multiple other trusted root instances, another trusted root instance whose processing performance matches that of the virtual machine is selected to interface with the virtual machine.

5. The method according to any one of claims 1-3, characterized in that, The plurality of trusted root instances also includes a backup trusted root instance, and the method further includes: If an interface connection failure with the main system is detected, the backup trusted root instance will be connected to the main system. If a failure to interface with the virtual machine is detected, the backup trusted root instance will interface with the virtual machine.

6. The method according to any one of claims 1-3, characterized in that, The step of interface-connecting the target trusted root instance among the plurality of trusted root instances with the main system in the server, and interface-connecting the other trusted root instances among the plurality of trusted root instances with multiple virtual machines in the server, to construct a trusted system with multiple trusted root instances, includes: Establish a transmission channel between the interface of the target trusted root instance and the interface of the main system, as well as a transparent transmission channel between the interfaces of the other trusted root instances and the interface of the virtual machine, to construct a trusted system with multiple trusted root instances.

7. The method according to any one of claims 1-3, characterized in that, The method further includes: The storage space in the hardware entity is divided into multiple storage subspaces; each of the multiple storage subspaces corresponds one-to-one with the multiple trusted root instances. Multiple task queues are set in the hardware entity; different task queues correspond to different data processing modules in the hardware entity.

8. The method according to claim 1, characterized in that, The method further includes: During the execution of the target task by each of the trusted root instances, the data processing module corresponding to the target task of each trusted root instance is invoked to perform data processing.

9. The method according to claim 8, characterized in that, During the execution of the target task by each of the trusted root instances, the data processing module corresponding to the target task of each trusted root instance is invoked for data processing, including: During the execution of the target task for each of the trusted root instances, the usage status of the data processing module corresponding to the target task of the trusted root instance is determined. If the usage status is available, then the data processing module corresponding to the target task is invoked to process the data; If the usage status is occupied, the target task is sent to the task queue corresponding to the data processing module for processing.

10. The method according to claim 8, characterized in that, The method further includes: If a faulty trusted root instance reports an alarm, the target task is transferred to a backup trusted root instance in the hardware entity for data processing. The connection between the faulty trusted root instance and the corresponding virtual machine or host is disconnected, and the backup trusted root instance is interfaced with the corresponding virtual machine or host.

11. A method for applying a trusted system, characterized in that, The method is applied to the trusted system as described in claims 1-7, and the method includes: For any trusted root instance in the trusted system, obtain the target task received by the trusted root instance, and determine the usage status of the data processing module corresponding to the target task; If the usage status is available, then the data processing module corresponding to the target task is invoked to process the data; If the usage status is occupied, the target task is sent to the task queue corresponding to the data processing module for processing.

12. A device for constructing a trusted root architecture, characterized in that, The device includes: The first partitioning module is used to partition the trusted roots on the hardware entities in the server into multiple trusted root instances. The construction module is used to interface the target trusted root instance among the multiple trusted root instances with the main system in the server, and to interface the other trusted root instances among the multiple trusted root instances with multiple virtual machines in the server, so as to build a trusted system of multiple trusted root instances.

13. An application device for a trusted system, characterized in that, The device includes: The acquisition module is used to acquire the target task received by any trusted root instance in the trusted system, and determine the usage status of the data processing module corresponding to the target task. The first calling module is used to call the data processing module corresponding to the target task to perform data processing when the usage status is available. The waiting module is used to send the target task to the task queue corresponding to the data processing module for processing when the usage status is occupied.

14. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1-11.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 11.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-11.

Images