Hardware security extension-oriented trusted bare metal server resource partitioning method and system

Abstract

The invention provides a trusted bare metal server resource partitioning method and system oriented to hardware security extension, and aims to solve the problems of security isolation and efficient utilization of hardware resources in a cloud computing environment. A resource partitioning technology based on hardware security expansion is introduced, and key components such as a security monitor, an isolation domain manager and a trusted execution environment TEE are combined, so that hardware resource fine partitioning and security management of the trusted bare metal server in the multi-tenant environment are realized. The core lies in that shared hardware is partitioned at a natural boundary (such as a core, a memory and I / O equipment), so that a plurality of untrusted client operating systems can run on shared bare metal hardware, meanwhile, performance overhead and potential safety hazards caused by complex virtualization are avoided, functions similar to virtual machines and bare computer performance are realized, and the method has strong isolation performance and is convenient to operate. And meanwhile, safe starting and remote verification are supported.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing for infrastructure as a service, and provides a new design solution for a trusted execution environment. Specifically, it relates to a method and system for partitioning resources of a trusted bare metal server for hardware security extension. Background Art

[0002] In the field of cloud computing, although virtualization technology is widely used, there are many problems. Traditional virtual machines achieve resource isolation based on a hypervisor. However, the hypervisor is controlled by cloud platform providers, resulting in trust issues between tenants and cloud providers. Therefore, a Trusted Execution Environment (TEE) for confidential computing has emerged. Its characteristic is that the code and data loaded inside it are protected in terms of confidentiality and integrity, relying only on hardware or software that has been formally verified and securely booted as a trusted base, allowing tenants to remotely verify.

[0003] Currently, the trusted execution environment is evolving towards confidential virtual machines. Compared with the early trusted execution environment that provided application-level isolation, confidential virtual machines provide system-level isolation including a full set of virtualized hardware, with better cloud software ecosystem compatibility and practicality. However, in terms of security, although CPU manufacturers continuously add complex functions, confidential virtual machines are still difficult to resist various security threats such as side-channel attacks in vCPU scheduling and hypervisor interface side-channel attacks. In terms of performance, even with hardware-accelerated virtualization, virtualization may still consume a large amount of CPU time under memory-intensive workloads, and operations such as nested address translation will bring significant memory access overhead. In terms of functionality, when tenants need to build a virtualization platform, they can only rely on less efficient software emulation methods.

[0004] At the same time, although bare metal cloud servers can provide better performance, security, and functionality, due to their physical isolation characteristics, they can avoid the risks introduced by the hypervisor. However, their resource management method is relatively extensive. Usually, CPUs and memory need to be bundled and sold by the slice, lacking flexible fine-grained resource partitioning and being difficult to meet the diverse needs of tenants. On actual cloud platforms, mainstream cloud providers such as Amazon EC2 and Microsoft Azure mostly allocate virtual machine resources at the granularity of CPU cores, while memory is statically allocated and I / O is gradually evolving towards full passthrough.

[0005] This current situation has prompted people to seek a new cloud computing architecture that can not only ensure security and performance but also enable flexible resource management. A feasible approach is for the hardware to provide hardware security extensions and offer access control for the packet core to partitioned memory and I / O, so as to directly run the guest operating system on the packet core. The feasibility of this method lies in that, on the one hand, taking the RISC-V architecture processor as an example, it has native hardware security features such as PMP (Physical Memory Protection) and has hierarchical privilege levels, providing a basis for hardware security extensions. Other architectures such as x86 and Arm are also continuously exploring enhancements to similar hardware security features. On the other hand, modern operating systems such as Linux provide a unified interface for firmware, support starting and running on discrete hardware resources specified by the firmware, and can be configured through, for example, ACPI (Advanced Configuration and Power Interface) tables or device tree files.

[0006] Patent application document CN111835576A discloses a method and a server for health detection of a backend server based on DPVS, belonging to the technical field of cloud computing. The method includes: the high-availability process constructs a status detection message for the backend server corresponding to the target client through the kernel protocol stack and sends the status detection message to the DPVS process; the DPVS process forwards the status detection message and its corresponding status response message between the high-availability process and the backend server through SNAT and DNAT operations based on the communication configuration information of the target client received in advance; after the high-availability process obtains the status response message fed back by the backend server, it determines the health status of the backend server according to the parsing result of the status response message. However, this patent cannot completely solve the existing technical problems and also cannot meet the requirements of the present invention. Summary of the Invention

[0007] Aiming at the deficiencies in the prior art, the purpose of the present invention is to provide a method and a system for partitioning resources of a trusted bare-metal server for hardware security extension. Different from confidential virtual machines that rely on hardware virtualization or traditional bare-metal servers with the whole machine as the granularity, the present invention utilizes hardware security extensions that provide isolation protection for the physical address space, combines a lightweight trusted security monitor and an untrusted isolation domain manager, and provides a trusted bare-metal hardware partition within the platform (referred to as an isolation domain, or bare-metal TEE). The isolation domain contains CPU cores, memory, and I / O device resources that are exclusive during their life cycles and runs a modern operating system verified by the tenant. In this way, it provides fine-grained resource management and operation and maintenance capabilities similar to confidential virtual machines, while possessing bare-metal security, performance, and functionality.

[0008] According to the method for partitioning hardware resources of a trusted bare-metal server for hardware security extension provided by the present invention, it includes:

[0009] Step 1: Server platform startup and initialization phase. The cloud vendor purchases a server device that includes a security monitor and starts it. During the platform startup and initialization phase, the security monitor runs at the processor's hardware security privilege level (or special execution mode), takes over all CPU cores, memory, and I / O device resources and records them, allocates a small amount of resources to create a platform management domain (a special isolation domain that can call the isolation domain lifecycle management interface provided by the security monitor), and uses the physical memory protection unit to limit the CPU core in the platform management domain to only access the corresponding memory and I / O resources. Then, the CPU core of the platform management domain enters the platform management domain for execution and starts the isolation domain manager. The isolation domain manager obtains the platform's idle resources from the security allocator and initializes the resource allocator, and then waits for the tenant's network request;

[0010] Step 2: Tenant preparation phase. The remote tenant determines the client operating system kernel and memory file system image, uses the memory file system tool to package the required software environment, embeds the tenant's secure shell protocol SSH public key, and then signs it using the signing tool to obtain the signed software image file;

[0011] Step 3: Tenant request phase. The remote tenant connects to the isolation domain manager running on the cloud platform and initiates a request to create and start the trusted execution environment TEE. In the request, the number of CPU cores, memory size, and I / O device resources exclusively used in the isolation domain are specified, and the software image file to be run in the TEE is passed;

[0012] Step 4: Resource allocation phase. The isolation domain manager checks the current platform's free resources. If the resources requested by the tenant cannot be met, an error is returned. If the resources requested by the tenant can be met, the specific CPU core, memory interval, and I / O device resources are specified, and a request is made to the security monitor to create a TEE. The security monitor checks the legitimacy of the requested resources, and returns a success if it passes, allowing the isolation domain manager to load the software image file. After the isolation domain manager is loaded, a request is made to the security monitor to start the TEE.

[0013] Step 5: Security configuration and measurement phase. Before starting the bare metal server, the security monitor completes the isolation configuration based on the physical memory protection mechanism to ensure that external software cannot access the TEE memory. Then, the loaded TEE memory image is measured and the signature structure is checked. Then, the hardware resource configuration file required for Linux startup in the boot domain is generated based on the hardware resource configuration. The TEE public and private key pairs are derived from the root key based on the measurement value, and they are stored in the agreed memory area respectively, and then the TEE is started;

[0014] Step 6: Start and Meta-Information Preparation Phase. During the TEE startup process, a pair of SSH server public and private keys are randomly generated, the SSH server is started and configured to allow only key-based login. When the TEE startup process is about to end, the network card IP and the SSH server public key are signed using a cryptographic algorithm with the TEE private key, and then sent to the security monitor. This information will be used as an additional message specified by the TEE in the digital report for subsequent construction of the SSH secure connection;

[0015] Step 7: Tenant Verification Phase. The remote tenant obtains the digital report signed by the security monitor through the isolation domain manager. The content of the digital report includes the TEE measurement, the TEE public key, and the hardware resource configuration file. The remote tenant verifies the digital report using the pre-configured firmware trusted root public key, that is, completes the signature verification using the known security monitor public key to confirm the authenticity of the digital report and the platform. The remote tenant compares the TEE measurement in the report with the previously determined expected measurement and checks the hardware resource configuration file to confirm the authenticity of the TEE itself;

[0016] Step 8: Tenant Connection and Usage Phase. The remote tenant verifies the additional message of the TEE using the TEE public key in the report, that is, checks whether the TEE additional message is correctly signed by the TEE private key using a cryptographic algorithm, and obtains the IP address and SSH public key of the TEE. The remote tenant connects to the TEE via the SSH protocol and compares the SSH public key fingerprint of the TEE during the connection process. Only when the fingerprint is correct can a secure connection be formally established, and then the cloud server is used based on the secure connection;

[0017] Step 9: Tenant End-Usage Phase. When the remote tenant has finished using, the isolation domain is stopped and destroyed through the isolation domain manager. The isolation domain manager requests the security monitor to destroy the isolation domain, and the security monitor notifies the isolation domain core to release resources, clear the memory and cache status, and update the idle resources.

[0018] Preferably, in step 1, the server device adopts a RISC-V architecture server device, and the security monitor is a firmware running in the RISC-V machine mode (Machine mode). During the platform security startup process, the initial state integrity is guaranteed and the security monitor private key is derived, and the anti-tampering capability of the platform is provided by initializing the hardware physical memory protection unit PMP (Physical Memory Protection) and IOPMP (Input-Output Physical Memory Protection). The core logic of the security monitor is: after the initialization is completed, at any time when the platform is running, any CPU core is in a certain isolation domain, and can only access the corresponding memory and I / O resources when executing in non-machine mode (also set by PMP and IOPMP, PMP is a physical memory protection mechanism based on the priority segment table, which only allows machine mode settings, thereby allowing or prohibiting a core from accessing the segmented physical memory when executing in non-machine mode, and the PMP check logic is implemented by hardware and cannot be bypassed), and the security monitor ensures that the hardware resources of any two isolation domains do not intersect during their life cycle. To do this, we only need to use an array to mark the idle cores and a segment table to mark the idle memory. The interface logic is easy to formally verify, thus ensuring that the security monitor is trustworthy. The platform management domain only contains a single CPU core, a small amount of memory and storage devices, and the isolation domain manager consists of the Linux kernel and network applications.

[0019] Preferably, in step 2, the client operating system kernel used by the remote tenant is the Linux kernel, the memory file system is compiled through Buildroot, the SSH public key is placed in the .ssh directory of the memory file system for key-only login, the signature tool simulates the measurement process (see step 5), generates the expected measurement based on the national commercial cryptographic hash algorithm SM3, and signs based on the national commercial cryptographic elliptic curve public key cryptography algorithm SM2.

[0020] Preferably, in step 3, the isolation domain manager runs in the platform management domain, and the isolation domain has the privilege of calling the isolation domain lifecycle management provided by the security monitor. The remote tenant connects to the isolation domain manager through the network and initiates a request. When specifying the I / O device resources contained in the isolation domain, it is completed by specifying the device resource configuration options provided by the isolation domain manager.

[0021] Preferably, in step 4, the isolation domain manager manages the platform's free memory resources based on the slab allocator, and the security monitor maintains the free memory resources based on the segment table memory data structure to complete the legality check, ensuring that the resources of the isolation domain requested to be created by the isolation domain manager are all free and do not overlap with other isolation domains. At this time, since the software in the isolation domain has not been loaded yet and the creation process is not completed, the security monitor only allocates and marks the resource occupation. The security monitor opens the access permission to the memory of the newly created isolation domain to the platform management domain to complete the subsequent loading.

[0022] Preferably, in step 5, the isolation configuration of the security monitor is based on the PMP and IOPMP physical memory protection mechanisms. At this time, the isolation domain manager no longer has the access permission to the memory of the newly created isolation domain; the measurement process uses the national commercial cryptographic hashing algorithm SM3 to hash the TEE memory that has completed software loading and the relevant configuration information (such as the loading image size) passed in by the kernel. The hash value is the measurement value; the signature structure contains the expected measurement signed by the user, including two parts: the expected measurement value and the signature value. Checking the signature structure means confirming that the signatory is a legitimate whitelisted developer, and at the same time, the measurement is consistent with the expected measurement in the signature structure. The hardware resource configuration file is a device tree file. On the RISC-V architecture, the firmware (i.e., the security monitor) learns all the hardware resources on the platform through the device tree file at startup. At this time, it will modify the original device tree file according to the actual hardware resources of the isolation domain and load it to the physical address pointed to by the Linux kernel startup parameter to be passed to the Linux kernel.

[0023] According to the trusted bare-metal server hardware resource partitioning system for hardware security extension provided by the present invention, it includes:

[0024] Module M1: Server Platform Startup and Initialization Module. This module is responsible for purchasing server devices with security monitors from cloud providers and, after startup, enabling the security monitor to run at the hardware security privilege level (or special execution mode) of the processor, completing the takeover and recording of all CPU cores, memory, and I / O device resources. Then, a small amount of resources are allocated to create a platform management domain, and the physical memory protection unit is used to restrict the CPU cores within the platform management domain to only access the corresponding memory and I / O resources. Subsequently, the CPU cores in the platform management domain are made to enter the platform management domain for execution, and the isolation domain manager is started. At the same time, the isolation domain manager obtains the platform idle resources from the security allocator and initializes the resource allocator, and then waits for the tenant's network request. In RISC-V architecture server devices, the security monitor is the firmware running in Machine mode, which ensures the integrity of the initial state and exports the security monitor private key during the platform security startup process, provides anti-tampering capabilities during the subsequent operation of the platform by initializing the hardware physical memory protection units PMP and IOPMP, and ensures that the platform management domain only contains a single CPU core, a small amount of memory, and storage devices. The isolation domain manager consists of the Linux kernel and network applications.

[0025] Module M2: Tenant Preparation Module. The remote tenant uses this module to determine the customer operating system kernel and memory file system image, pack the required software environment using the memory file system tool, embed the tenant's Secure Shell Protocol (SSH) public key, and then sign it using the signature tool to obtain the signed software image file. Among them, the customer operating system kernel used by the remote tenant is the Linux kernel, the memory file system is compiled through Buildroot, the SSH public key is placed in the.ssh directory of the memory file system for key-only login, and the signature tool simulates the measurement process (see subsequent Module M5), generates the expected measurement based on the national commercial cryptography hashing algorithm SM3, and performs the signature based on the national commercial cryptography elliptic curve public key cryptography algorithm SM2.

[0026] Module M3: Tenant Request Module. This module implements the network connection between the remote tenant and the isolation domain manager running in the platform management domain, enabling the tenant to initiate requests to create and start a Trusted Execution Environment (TEE), specifying the number of exclusive CPU cores, memory size, and I / O device resources within the isolation domain in the request, and transferring the software image file to be run in the TEE. And when specifying the I / O device resources included in the specified isolation domain, it is completed by specifying the device resource configuration options provided by the isolation domain manager.

[0027] Module M4: Resource Allocation Module. In this module, the isolation domain manager manages the platform's free memory resources based on the slab allocator, checks whether the current platform free resources meet the tenant's requests. If not, it returns an error; if so, it designates specific CPU cores, memory ranges, and I / O device resources and requests the security monitor to create a TEE. The security monitor maintains the free memory resources based on the segment table memory data structure to complete the legality check, ensuring that the resources of the isolation domain requested to be created by the isolation domain manager are all free and do not overlap with other isolation domains. If it passes, it returns successfully, allowing the isolation domain manager to load the software image file. After the isolation domain manager finishes loading, it requests the security monitor to start the TEE. At this time, since the software in the isolation domain has not been loaded yet, the creation process is not completed. The security monitor only allocates and marks the resource occupancy and opens the access permission to the memory of the newly created isolation domain to the platform management domain to complete the subsequent loading.

[0028] Module M5: Security Configuration and Measurement Module. Before starting the bare-metal server, the security monitor completes the isolation configuration through this module based on the PMP and IOPMP physical memory protection mechanisms to ensure that external software cannot access the memory of the TEE. Subsequently, it measures and checks the signature structure of the loaded TEE memory image. The measurement process uses the national commercial cryptographic hashing algorithm SM3 to hash the TEE memory after software loading and the relevant configuration information (such as the size of the loaded image, etc.) passed in by the kernel. The hash value is the measurement value; the signature structure contains the expected measurement signed by the user, including two parts: the expected measurement value and the signature value. Checking the signature structure means confirming that the signing party is a legitimate developer on the whitelist and that the measurement is consistent with the expected measurement in the signature structure. In addition, this module also generates the hardware resource configuration file required for the Linux startup in the boot domain according to the hardware resource configuration (the device tree file on the RISC-V architecture). At startup, it obtains all the hardware resources on the platform through the device tree file. At this time, it will modify the original device tree file according to the actual hardware resources of the isolation domain and load it to the physical address pointed to by the Linux kernel startup parameter and then pass it to the Linux kernel. Finally, it derives the TEE public and private key pairs from the root key according to the measurement value, stores them in the agreed memory areas respectively, and then starts the TEE.

[0029] Module M6: Startup and Meta-Information Preparation Module. During the TEE startup process, this module is responsible for randomly generating a pair of SSH server public and private keys, starting the SSH server and setting up key-only login. When the TEE startup process is about to end, it signs the network card IP and the SSH server public key using the TEE private key with the cryptographic algorithm SM2, and then sends them to the security monitor. This information will be used as the additional message specified by the TEE in the digital report for subsequent construction of the SSH secure connection.

[0030] Module M7: Tenant Verification Module. With the help of this module, a remote tenant can obtain a digital report signed by the security monitor through the isolation domain manager. The content of the digital report includes TEE measurements, the TEE public key, and the hardware resource configuration file. The digital report is verified using the pre-configured trusted root public key of the firmware, that is, the signature verification is completed using the known security monitor public key to confirm the authenticity of the digital report and the platform. The remote tenant compares the TEE measurements in the report with the previously determined expected measurements and checks the hardware resource configuration file to confirm the authenticity of the TEE itself.

[0031] Module M8: Tenant Connection and Usage Module. This module enables a remote tenant to verify additional messages of the TEE using the TEE public key in the report, that is, checks whether the TEE additional message is correctly signed by the TEE private key using the national commercial cryptography algorithm SM2, and obtains the IP address and SSH public key of the TEE. Then the remote tenant connects to the TEE via the SSH protocol and compares the SSH public key fingerprint during the connection process. Only when the fingerprint is correct can a secure connection be formally established, and then the cloud server is used based on the secure connection.

[0032] Module M9: Tenant End-of-Use Module. When the remote tenant finishes using, the isolation domain is stopped and destroyed through the isolation domain manager. The isolation domain manager requests the security monitor to destroy the isolation domain, and the security monitor notifies the isolation domain core to release resources, clear the memory and cache status, and update the idle resources.

[0033] Compared with the prior art, the present invention has the following beneficial effects:

[0034] (1) In terms of software ecosystem compatibility and practicality, compared with the early trusted execution environment that relied on a special programming framework for application-level isolation and required application refactoring, by directly running the Linux system in the bare-metal TEE, the refactoring of secure applications in confidential computing is avoided, and seamless migration of complex applications is achieved.

[0035] (2) In terms of security, the exclusive-core bare-metal hardware partition effectively avoids side-channel attacks based on the core L1 cache and side-channel attacks based on page tables or interfaces, while reducing the size of the TCB and improving the security and verifiability of the system.

[0036] (3) In terms of performance, through hardware partitioning and direct resource access, the bare-metal TEE achieves bare-metal performance, avoiding virtualization overhead. In the RISC-V prototype test, the performance is comparable to that of the bare metal under various workloads.

[0037] (4) In terms of hardware resource utilization, through fine-grained resource partitioning, idle resource management, and dynamic creation and destruction of isolation domains, it provides operation and maintenance capabilities similar to those of public cloud IaaS virtual machines, achieving flexible customization of bare-metal server hardware resources and a relatively high platform resource utilization rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Other features, objects, and advantages of the present invention will become more apparent by reading the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0039] Figure 1 The overall flowchart of an embodiment of the present invention;

[0040] Figure 2 The schematic diagram of the software and hardware system architecture of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0041] The present invention will be described in detail below with reference to specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but do not limit the present invention in any form. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several changes and improvements can be made. These all fall within the protection scope of the present invention.

[0042] Embodiment

[0043] The core of the present invention lies in achieving isolation and protection between isolation domains, resource management and isolation domain lifecycle management, as well as secure boot and remote authentication. The isolation and protection are provided by a security monitor running in machine mode, the resource management and isolation domain lifecycle management are provided by a domain manager running in a special isolation domain, and the secure boot and remote authentication involve the measurement of isolation domains by the security monitor, signature authentication based on the hardware trust root, and the process of establishing a secure channel between the tenant and the cloud server. Through isolated execution and remote authentication, cloud tenants can complete privacy-protected cloud computing with a widely compatible software ecosystem without trusting the cloud provider. The complete operation of the trusted bare-metal server for hardware security extension includes the following steps:

[0044] (1) Server platform startup and initialization phase. The cloud vendor purchases a server device that includes a security monitor and starts it. During the platform startup and initialization phase, the security monitor runs at the processor's hardware security privilege level (or special execution mode), takes over all CPU cores, memory, and I / O device resources and records them, allocates a small amount of resources to create a platform management domain (a special isolation domain that can call the isolation domain lifecycle management interface provided by the security monitor), and uses the physical memory protection unit to limit the CPU core in the platform management domain to only access the corresponding memory and I / O resources. Then, the CPU core of the platform management domain enters the platform management domain for execution and starts the isolation domain manager. The isolation domain manager obtains the platform's idle resources from the security allocator and initializes the resource allocator, and then waits for the tenant's network request;

[0045] (2) Tenant preparation stage. The remote tenant determines the client operating system kernel and memory file system image, uses the memory file system customization tool to package the required software environment, embeds the tenant's SSH (Secure Shell, a type of encrypted network transmission protocol) public key, and then uses the signing tool to sign it to obtain the signed software image file.

[0046] (3) Tenant request phase. The remote tenant connects to the isolation domain manager running on the cloud platform and initiates a request to create and start the TEE. In the request, the tenant specifies the number of CPU cores, memory size, and I / O device resources exclusively used in the isolation domain, and transfers the software image file to be run in the TEE.

[0047] (4) Resource allocation phase. The isolation domain manager checks the idle resources of the current platform and returns an error if the resources requested by the tenant cannot be met. If the resources can be met, it specifies the appropriate CPU core, memory interval and I / O device resources and requests the security monitor to create a bare metal isolation domain. The domain manager checks the idle resources of the current platform to determine whether the resources requested by the tenant can be met. When the idle resources have a sufficient number of CPU cores, a sufficient amount of physical memory and a sufficient number of specified I / O devices, it means that the resources can meet the tenant's request. At this time, the domain manager will specify the appropriate CPU core, memory interval and I / O device resources in the idle resources and request the security monitor to create a TEE. If the above conditions are not met, that is, the number of CPU cores in the idle resources is insufficient, the physical memory size is insufficient, or the number of specified I / O devices is insufficient, an error will be returned. The security monitor will check the legitimacy of the requested resources and return success if it passes, allowing the isolation domain manager to load the software image file. After the isolation domain manager is loaded, it requests the security monitor to start the TEE.

[0048] (5) Security Configuration and Measurement Phase. Before startup, the security monitor completes the isolation configuration to ensure that external software (including the domain manager) cannot access the memory of the TEE. Subsequently, the loaded TEE memory image is measured, and the signature structure is checked. The SM3, a hash algorithm of national commercial cryptography, is used in the measurement process to hash the memory objects representing the isolated resources of the TEE and the TEE memory where software loading is completed. The hash value is the measurement value. The signature structure contains the expected measurement signed by the user (i.e., the developer), including two parts: the expected measurement value and the signature value. Checking the signature structure means confirming that the signatory is a legitimate developer on the whitelist and that the measurement is consistent with the expected measurement in the signature structure. Subsequently, a hardware resource configuration file required for the startup of Linux within the boot domain is generated according to the hardware resource configuration, and the TEE public and private key pair is derived from the root key based on the measurement value and stored in the agreed memory areas respectively, and then the TEE is started.

[0049] (6) Startup and Meta-Information Preparation Phase. During the startup process of the TEE, a pair of SSH server public and private keys is randomly generated, the SSH server is started and configured to allow only key-based login. This pair of keys will play a role in establishing a secure connection later. When the startup process of the TEE is about to end, the network card IP and the SSH server public key are signed using the TEE private key with a cryptographic algorithm and then sent to the security monitor. This information will be used as an additional message specified by the TEE in the digital report, specifically for establishing an SSH secure connection later.

[0050] (7) Tenant Verification Phase. The remote tenant obtains the digital report signed by the security monitor through the isolation domain manager. The content of the digital report includes the TEE measurement, the TEE public key, and the hardware resource configuration file generated in step (4). The remote tenant verifies the digital report using the pre-configured trusted root public key of the firmware, that is, completes the signature verification using the known security monitor public key to confirm the authenticity of the digital report and the platform, ensuring the reliability of the entire operating environment. The remote tenant further carefully compares the TEE measurement in the report with the previously determined expected measurement and checks the hardware resource configuration file to confirm the authenticity of the TEE itself in this way, ensuring that the TEE meets the security requirements in multiple aspects.

[0051] (8) Tenant Connection and Usage Phase. The remote tenant verifies the additional message of the TEE using the TEE public key in the report, that is, checks whether the TEE additional message is correctly signed by the TEE private key using a cryptographic algorithm. After this step, the IP address and SSH public key of the TEE can be successfully obtained, making full preparations for the next step of establishing a secure connection. The remote tenant connects to the TEE via the SSH protocol and compares the SSH public key fingerprint of the TEE during the connection process. Only when the fingerprint is correct will a secure connection be formally established. After that, the cloud server can be used based on the secure connection.

[0052] (9) The tenant ends the use phase. When the remote tenant has finished using the domain, the domain manager can stop and destroy the domain. The domain manager requests the security monitor to destroy the domain, and the security monitor notifies the domain core to release resources, clear memory and cache status, and update idle resources.

[0053] In the step (1), the server device adopts a RISC-V architecture server device, and the security monitor is a firmware running in the RISC-V machine mode. During the platform security startup process, the initial state integrity is guaranteed and the security monitor private key is derived. By initializing the hardware physical memory protection unit PMP (Physical Memory Protection) and IOPMP (Input-Output Physical Memory Protection), it provides its anti-tampering capability during the subsequent operation of the platform. The core logic of the security monitor is: after the initialization is completed, at any time when the platform is running, any CPU core is in a certain isolation domain, and can only access the corresponding memory and I / O resources when executing in non-machine mode (also set by PMP and IOPMP, PMP is a physical memory protection mechanism based on the priority segment table, which only allows machine mode settings, thereby allowing or prohibiting a core from accessing the segmented physical memory when executing in non-machine mode, and the PMP check logic is implemented by hardware and cannot be bypassed). The security monitor ensures that the hardware resources of any two isolation domains do not intersect during their life cycle. To do this, we only need to use an array to mark the idle cores and a segment table to mark the idle memory. The interface logic is easy to formally verify, thus ensuring that the security monitor is trustworthy. The platform management domain only contains a single CPU core, a small amount of memory and storage devices, and the isolation domain manager consists of the Linux kernel and network applications.

[0054] In step (2), the client operating system kernel used by the remote tenant is the Linux kernel, the memory file system is compiled by Buildroot, and the SSH public key is placed in the .ssh directory of the memory file system for key-only login. The signature tool simulates the measurement process (see step 5), generates the expected measurement based on the national commercial cryptographic hash algorithm SM3, and signs based on the national commercial cryptographic elliptic curve public key cryptographic algorithm SM2.

[0055] In the step (3), the isolation domain manager runs in the platform management domain, and the isolation domain has the privilege of calling the isolation domain lifecycle management provided by the security monitor. The remote tenant connects to the domain manager through the network and initiates a request. When specifying the I / O device resources contained in the isolation domain, it is completed by specifying the device resource configuration options provided by the isolation domain manager.

[0056] In step (4), the isolation domain manager manages the platform's free memory resources based on the slab allocator. The security monitor maintains the free memory resources based on the segment table memory data structure to complete the legality check, ensuring that the resources of the isolation domain requested to be created by the isolation domain manager are all free and do not overlap with other isolation domains. At this time, since the software in the isolation domain has not been loaded yet, the creation process is not completed, and the security monitor only allocates and marks the resource occupancy. The security monitor opens the access permission to the memory of the newly created isolation domain to the platform management domain to complete the subsequent loading.

[0057] In step (5), the isolation configuration of the security monitor is based on the PMP and IOPMP physical memory protection mechanisms. At this time, the isolation domain manager no longer has the access permission to the memory of the newly created isolation domain. The measurement process uses the national commercial cryptographic hashing algorithm SM3 to hash the TEE memory that has completed software loading and the relevant configuration information (such as the loading image size) passed in by the kernel. The hash value is the measurement value. The signature structure contains the expected measurement signed by the user, including two parts: the expected measurement value and the signature value. Checking the signature structure confirms that the signing party is a legitimate whitelisted developer, and at the same time, the measurement is consistent with the expected measurement in the signature structure. The hardware resource configuration file is the device tree file. On the RISC-V architecture, the firmware (i.e., the security monitor) learns all the hardware resources on the platform through the device tree file at startup. At this time, it will modify the original device tree file according to the actual hardware resources of the isolation domain and load it to the physical address pointed to by the Linux kernel startup parameter to be passed to the Linux kernel.

[0058] The present invention constructs a bare-metal resource partition (TEE) on the StarFive VisionFive V1 development board as a cloud server. In terms of the hardware platform configuration, the VisionFive V1 development board has a 64-bit multi-core architecture, with the processor being U74 Dual-Core (i.e., including HART0 and 1), the memory configuration being 8G DDR4, having 16 groups of PMP segment configuration registers, and having various peripherals such as 4 UARTs, 1 WIFI, 1 Ethernet, etc. In terms of the isolated domain resource allocation, the bare-metal TEE exclusively occupies HART1, the upper 7G of memory, UART3, and Ethernet, while system devices such as the clock and PLIC interrupt controller are shared securely with the untrusted platform management domain (without affecting the confidentiality and integrity of the cloud server). In terms of software configuration, the secure monitor is developed using OpenSBI. The non-secure platform management domain runs the Fedora operating system, on which the isolated domain manager runs. The isolated domain manager communicates with the secure monitor through ioctl calls to the kernel driver in Fedora and is responsible for tasks such as managing the overall resource allocation of the platform. The user kernel running within the secure domain is based on Linux 5.15 compiled with Buildroot and uses Ramfs as the root file system. As Figure 2 shown, it involves many software modules:

[0059] As Figure 1As shown, the cloud platform, i.e., the VisionFive development board, starts first. After power-on, it enters the security monitor implemented based on OpenSBI for startup and initialization. The security monitor uses the NAPOT mode of PMP to mark physical memory regions, that is, each region has a size that is a power of 2 and the endpoints are aligned, and is represented in the security monitor by a structure containing the starting address and the power. During the initialization process, the security monitor first counts the idle resources of the platform, initializes the idle resources as idle isolation domains without execution context (its core resources are represented by a bitmap with all cores set to 1, and the memory and device resources are represented by the starting address 0x0 and the power 64). In the idle isolation domain, the private memory area of the security monitor is marked (that is, all isolation domains are prohibited from accessing the security monitor memory). Then, according to the static configuration of the isolation domain in the device tree file, the platform management domain is created. In the static configuration, the hardware resources accessible to the platform management domain include HART0, the lower 1G of physical memory (physical addresses from 0x80000000 to 0xC0000000), as well as the L2 cache, clock, interrupt, serial port controller, and SDIO storage and WIFI devices. According to the description of the control register address mapping of these devices in the device tree, a total of 6 additional PMP segment registers are required to allow the CPU core of the platform management domain to access the memory and I / O resources of the platform management domain. The resources included in the idle domain are updated during the creation. Subsequently, the platform management domain is started. The isolation domain manager obtains the idle memory of the platform at startup, initializes the slab memory allocator, records the network cards and storage devices on the platform, and then listens on the network port, waiting for remote tenant requests.

[0060] When a tenant hopes to use the TEE to complete confidential computing, in an offline environment, the remote tenant uses the Linux kernel and the Buildroot memory file system image, integrates the required software environment with the help of a containerized memory file system customization tool (Containerieddeployment tool), and embeds the tenant's SSH public key. Then, using a signature tool (Signtool), a signed software image file is generated according to the tenant developer's private key.

[0061] The remote tenant establishes a connection with the Domain Manager on the cloud platform through a Remote attestation tool, sends a request to create and start a TEE, and clearly specifies the software and hardware configurations of the bare-metal isolation domain. Subsequently, the Domain Manager checks the currently idle resources on the platform. If the tenant's request cannot be met, an error message is returned; if there are sufficient resources, appropriate CPU cores, memory ranges, and I / O device resources are selected, and an SBI ecall is used to apply to the Secure Monitor to create a bare-metal isolation domain. The Domain Life Cycle Management module of the Secure Monitor audits the legality of the requested resources. If it passes, a memory object representing the isolation domain is created, and a success message is returned. The Domain Manager then loads the software image file and requests the Secure Monitor to start the isolation domain after the loading is complete.

[0062] In the startup phase, the Secure Monitor first completes the isolation configuration, then measures the loaded TEE memory image. The Attestation module includes the national cryptographic SM2 algorithm, which is used to verify the signature structure to ensure that the signer is among the legitimate whitelist developers and the measured value matches the expected measurement in the signature structure. Subsequently, a device tree file required for the Linux startup in the boot domain is generated based on the hardware resource configuration, and a TEE public-private key pair is derived from the root key based on the measured value and stored in the specified memory areas respectively. The memory address of the device tree is used as a startup parameter, and then the TEE is started.

[0063] During the startup of the bare-metal server, the SSH service is initialized at the end of the init process, and a pair of SSH server public-private keys are generated for subsequent secure connection establishment. When the TEE startup is nearly complete, the network card IP and the SSH server public key are signed using the TEE private key and sent to the Secure Monitor as an additional message of the TEE in the digital report for subsequent SSH secure connection establishment.

[0064] The remote tenant obtains the digital report signed by the Secure Monitor through the Domain Manager, verifies the report using the pre-configured hardware trusted root public key to ensure the authenticity of the platform and the reliability of the operating environment. Further compare the TEE measurement in the report with the preset expected measurement, and compare the hardware resource configuration shown in the device tree in the report to confirm the security of the TEE. After that, the remote tenant uses the TEE public key in the report to verify the TEE additional message, successfully obtains the IP address and SSH public key of the TEE, and prepares for establishing a secure connection. The remote tenant connects to the TEE using the SSH protocol, compares the SSH public key fingerprint of the TEE, and formally establishes a secure connection after the match is correct, and then uses the cloud server.

[0065] After the remote tenant finishes using it, the isolation domain can be stopped and destroyed through the isolation domain manager. The isolation domain manager requests destruction from the security monitor, and the security monitor will notify the isolation domain core to stop and destroy through IPI. The application core of the isolation domain will clear the cache state and return to the idle domain, and the startup core of the isolation domain will clear the memory, release resources, and update the idle resource information.

[0066] It should be noted that due to the limited resources of the commercial RISC-V development board during the project R & D period, only a single single-core bare-metal TEE is supported in this embodiment. However, the multi-core design is fully considered in the software implementation of the present invention. Therefore, the monitoring cores occupied by the platform management domain on the server RISC-V platform hardly cause loss of hardware utilization. In addition, each bare-metal TEE only needs no more than 8 groups of PMPs to open resource access permissions to start normally, and the PMP configuration on other TEE cores is not affected during the creation or destruction of the bare-metal TEE. Therefore, the present invention can support multiple bare-metal TEEs and has good scalability.

[0067] The resource partitioning method and system of the present invention effectively solve the security and resource management problems in the cloud computing environment. In terms of security, through hardware partitioning at the core granularity, side-channel attacks based on the core L1 cache are effectively avoided, the size of the TCB is reduced, and the security and verifiability of the system are improved. In terms of performance, through hardware partitioning and direct resource access, bare-metal performance is achieved, virtualization overhead is avoided, and in the RISC-V prototype test, the performance is comparable to that of the bare metal under various workloads (such as rv8, CoreMark, IOZone). In terms of hardware resource utilization, through fine-grained resource partitioning, idle resource management, and dynamic creation and destruction of isolation domains, combined with the usage mode of public cloud IaaS virtual machines, flexible customization of bare-metal server hardware resources and high resource utilization are achieved. With the continuous development of cloud computing technology and the continuous progress of hardware security technology, the present invention is expected to be applied in more fields, providing important technical support for the development of cloud computing technology, and having broad application prospects and market value.

[0068] Those skilled in the art know that in addition to implementing the systems, devices, and their respective modules provided by the present invention in the form of pure computer-readable program code, the method steps can be logically programmed to enable the systems, devices, and their respective modules provided by the present invention to be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers to implement the same program. Therefore, the systems, devices, and their respective modules provided by the present invention can be considered as a kind of hardware component, and the modules included therein for implementing various programs can also be regarded as the structure within the hardware component; the modules for implementing various functions can also be regarded as both software programs for implementing the method and the structure within the hardware component.

[0069] The specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. Without conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A trusted bare metal server resource partitioning method for hardware security expansion, characterized in that: include: Step 1: Server platform startup and initialization phase; The cloud vendor purchases a server device that includes a security monitor and starts it. During the platform startup and initialization phase, the security monitor runs at the processor's preset hardware security privilege level or special execution mode, takes over all CPU cores, memory, and I / O device resources and records them, allocates a small amount of resources to create a platform management domain, calls the isolation domain lifecycle management interface provided by the security monitor, uses the physical memory protection unit to restrict the CPU core in the platform management domain to only access the corresponding memory and I / O resources, and then makes the CPU core of the platform management domain enter the platform management domain for execution, and starts the isolation domain manager; the isolation domain manager obtains the platform's idle resources from the security allocator and initializes the resource allocator, and then waits for the tenant's network request; Step 2: Tenant preparation stage; the remote tenant determines the client operating system kernel and memory file system image, uses the memory file system tool to package the required software environment, embeds the tenant's secure shell protocol SSH public key, and then signs it using the signing tool to obtain the signed software image file; Step 3: Tenant request phase; the remote tenant connects to the isolation domain manager running on the cloud platform, initiates a request to create and start the trusted execution environment TEE, specifies the number of CPU cores, memory size, and I / O device resources exclusively used in the isolation domain, and passes the software image file to be run in the TEE; Step 4: Resource allocation stage; The isolation domain manager checks the current platform's free resources. If the resources requested by the tenant cannot be met, an error is returned. If the resources requested by the tenant can be met, the specific CPU core, memory interval, and I / O device resources are specified, and a request is made to the security monitor to create a TEE. The security monitor checks the legality of the requested resources, and returns a success if it passes, allowing the isolation domain manager to load the software image file. After the isolation domain manager is loaded, a request is made to the security monitor to start the TEE. Step 5: Security configuration and measurement phase; Before starting the bare metal server, the security monitor completes the isolation configuration based on the physical memory protection mechanism to ensure that external software cannot access the TEE memory. It then measures and checks the signature structure of the loaded TEE memory image, and then generates the hardware resource configuration file required for Linux startup in the boot domain based on the hardware resource configuration. It derives the TEE public and private key pairs from the root key based on the measurement value, stores them in the agreed memory area respectively, and then starts the TEE. Step 6: Startup and meta-information preparation phase; During the TEE startup process, a pair of SSH server public and private keys are randomly generated, the SSH server is started and key-only login is set; when the TEE startup process is about to end, the network card IP and SSH server public key are signed using the TEE private key using a cryptographic algorithm and then sent to the security monitor. This information will be used as an additional message specified by the TEE in the digital report for the subsequent establishment of an SSH secure connection; Step 7: Tenant verification phase; The remote tenant obtains a digital report signed by the security monitor through the isolation domain manager. The content of the digital report includes TEE measurements, TEE public key and hardware resource configuration file. The remote tenant verifies the digital report using the pre-configured firmware trusted root public key, that is, the signature is completed using the known security monitor public key to confirm the authenticity of the digital report and the platform. The remote tenant compares the TEE measurements in the report with the previously predetermined expected measurements and checks the hardware resource configuration file to confirm the authenticity of the TEE itself. Step 8: Tenant connection and use phase; the remote tenant uses the TEE public key in the report to verify the TEE's additional message, that is, uses a cryptographic algorithm to check whether the TEE additional message is correctly signed by the TEE private key, and obtains the TEE's IP address and SSH public key; the remote tenant connects to the TEE with the help of the SSH protocol, and compares the TEE's SSH public key fingerprint during the connection process. Only when the fingerprint is correct, a secure connection is officially established, and then the cloud server is used based on the secure connection; Step 9: The tenant ends the usage phase; when the remote tenant has finished using the isolation domain, the isolation domain manager stops and destroys the isolation domain. The isolation domain manager requests the security monitor to destroy the isolation domain. The security monitor notifies the isolation domain core to release resources, clear memory and cache status, and update idle resources.

2. The trusted bare metal server resource partitioning method for hardware security extension according to claim 1 is characterized in that: In the step 1, the server device adopts a RISC-V architecture server device, and the security monitor is a firmware running in the RISC-V machine mode. During the platform security startup process, the initial state integrity is guaranteed and the security monitor private key is exported. By initializing the hardware physical memory protection unit PMP and IOPMP, the security monitor provides its anti-tampering capability during the subsequent operation of the platform. The core logic of the security monitor is that after the initialization is completed, any CPU core is in a certain isolation domain at any time when the platform is running, and can only access the corresponding memory and I / O resources when executing in non-machine mode. The security monitor ensures that the hardware resources of any two isolation domains do not intersect during their life cycle. To this end, it is only necessary to use an array to mark the idle core and a segment table to mark the idle memory. The interface logic is easy to formally verify, thereby ensuring that the security monitor is credible. The platform management domain only contains a single CPU core, a small amount of memory and storage devices, and the isolation domain manager consists of the Linux kernel and network applications.

3. The trusted bare metal server resource partitioning method for hardware security extension according to claim 1 is characterized in that: In step 2, the client operating system kernel used by the remote tenant is the Linux kernel, the memory file system is compiled through Buildroot, the SSH public key is placed in the .ssh directory of the memory file system for key-only login, the signing tool simulates the measurement process, generates the expected measurement based on the national commercial cryptographic hash algorithm SM3, and signs based on the national commercial cryptographic elliptic curve public key cryptography algorithm SM2.

4. The trusted bare metal server resource partitioning method for hardware security extension according to claim 1 is characterized in that: In step 3, the isolation domain manager runs in the platform management domain, and the isolation domain has the privilege of calling the isolation domain lifecycle management provided by the security monitor. The remote tenant connects to the isolation domain manager through the network and initiates a request. When specifying the I / O device resources contained in the isolation domain, it is completed by specifying the device resource configuration options provided by the isolation domain manager.

5. The trusted bare metal server resource partitioning method for hardware security extension according to claim 1 is characterized in that: In step 4, the isolation domain manager manages the platform's free memory resources based on the slab allocator, and the security monitor maintains the free memory resources based on the segment table memory data structure to complete the legitimacy check, ensuring that the resources of the isolation domain created by the isolation domain manager are all free and do not overlap with other isolation domains; At this point, since the software in the isolation domain has not been loaded yet, the creation process has not been completed, and the security monitor only allocates and marks resource occupancy; the security monitor opens access rights to the newly created isolation domain memory to the platform management domain to complete subsequent loading.

6. The trusted bare metal server resource partitioning method for hardware security extension according to claim 1 is characterized in that: In step 5, the isolation configuration of the security monitor is based on the PMP and IOPMP physical memory protection mechanisms, and the isolation domain manager no longer has access rights to the newly created isolation domain memory; The measurement process uses the national commercial cryptographic hash algorithm SM3 to hash the TEE memory that has completed software loading and the relevant configuration information passed in by the kernel. The hash value is the measurement value; the signature structure contains the expected measurement of the user's signature, which includes the expected measurement value and the signature value. Checking the signature structure confirms that the signer is a legitimate whitelist developer, and the measurement is consistent with the expected measurement in the signature structure; the hardware resource configuration file is a device tree file. On the RISC-V architecture, the firmware obtains all the hardware resources on the platform through the device tree file at startup. At this time, the original device tree file will be modified according to the actual hardware resources of the isolation domain, and loaded into the physical address pointed to by the Linux kernel startup parameters and passed to the Linux kernel.

7. A RISC-V architecture trusted bare metal server hardware resource partitioning system, characterized in that: include: Module M1: Server platform startup and initialization module; This module is responsible for running the security monitor at the processor's preset hardware security privilege level or special execution mode after the cloud vendor purchases and starts the server device containing the security monitor, completing the takeover and recording of all CPU cores, memory, and I / O device resources. It then allocates a small amount of resources to create a platform management domain, and uses the physical memory protection unit to restrict the CPU cores in the platform management domain to only access the corresponding memory and I / O resources. It then allows the CPU cores in the platform management domain to enter the platform management domain for execution and starts the isolation domain manager. At the same time, the isolation domain manager obtains the platform's idle resources from the security allocator and initializes the resource allocator, and then waits for the tenant's network request. Module M2: Tenant preparation module; remote tenants use this module to determine the client operating system kernel and memory file system image, use the memory file system tool to package the required software environment, embed the tenant's secure shell protocol SSH public key, and then use the signing tool to sign to obtain the signed software image file; Module M3: Tenant request module; This module implements the network connection between the remote tenant and the isolation domain manager running in the platform management domain, enabling the tenant to initiate a request to create and start a trusted execution environment TEE, specify the number of CPU cores, memory size and I / O device resources exclusively in the isolation domain in the request, pass the software image file to be run in the TEE, and when specifying the I / O device resources contained in the isolation domain, it is completed by specifying the device resource configuration options provided by the isolation domain manager; Module M4: Resource allocation module; in this module, the isolation domain manager manages the platform's idle memory resources based on the slab allocator, checks whether the current platform's idle resources meet the tenant's request, and returns an error if not; if they do, it specifies the specific CPU core, memory interval, and I / O device resources, and requests the security monitor to create a TEE; the security monitor maintains the idle memory resources based on the segment table memory data structure to complete the legitimacy check, ensuring that the resources of the isolation domain requested to be created by the isolation domain manager are all idle and do not overlap with other isolation domains. If passed, it returns success, allowing the isolation domain manager to load the software image file. After the isolation domain manager is loaded, it requests the security monitor to start the TEE; Module M5: Security configuration and measurement module; Before starting the bare metal server, the security monitor completes the isolation configuration based on the physical memory protection unit through this module to ensure that external software cannot access the TEE memory. Then it measures and checks the signature structure of the loaded TEE memory image. The measurement process uses a cryptographic hashing algorithm to hash the TEE memory that has completed software loading and the relevant configuration information passed in by the kernel. The hash value is the measurement value. The signature structure contains the expected measurement of the user's signature, which includes the expected measurement value and the signature value. Checking the signature structure confirms that the signer is a legitimate whitelist developer, and the measurement is consistent with the expected measurement in the signature structure. In addition, the module also generates the hardware resource configuration file required for Linux startup in the boot domain according to the hardware resource configuration. At startup, all the hardware resources on the platform are known through the device tree file. At this time, the original device tree file will be modified according to the actual hardware resources of the isolation domain, and loaded to the physical address pointed to by the Linux kernel startup parameter and passed to the Linux kernel. Finally, the TEE public and private key pairs are derived from the root key according to the measurement value, and they are stored in the agreed memory area respectively, and then the TEE is started; Module M6: Startup and meta-information preparation module; During the TEE startup process, this module is responsible for randomly generating a pair of SSH server public and private keys, starting the SSH server and setting up key-only login; When the TEE startup process is about to end, the network card IP and SSH server public key are signed with the TEE private key using the cryptographic algorithm SM2, and then sent to the security monitor. This information will be used as an additional message specified by the TEE in the digital report for the subsequent construction of the SSH secure connection; Module M7: Tenant verification module; remote tenants use this module to obtain a digital report signed by the security monitor through the isolation domain manager. The content of the digital report includes TEE measurements, TEE public keys, and hardware resource configuration files. The digital report is verified using the pre-configured firmware trusted root public key, that is, the signature is completed using the known security monitor public key to confirm the authenticity of the digital report and the platform. The remote tenant compares the TEE measurements in the report with the previously predetermined expected measurements and checks the hardware resource configuration files to confirm the authenticity of the TEE itself. Module M8: Tenant connection and use module; This module enables remote tenants to use the TEE public key in the report to verify the TEE's additional message, that is, to use a cryptographic algorithm to check whether the TEE additional message is correctly signed by the TEE private key, and obtain the TEE's IP address and SSH public key; Then the remote tenant uses the SSH protocol to connect to the TEE, and compares the TEE's SSH public key fingerprint during the connection process. Only when the fingerprint is correct, a secure connection is officially established, and then the cloud server is used based on the secure connection; Module M9: The tenant ends the use of the module; When the remote tenant has finished using the isolation domain, stop and destroy the isolation domain through the isolation domain manager; The isolation domain manager requests the security monitor to destroy the isolation domain, and the security monitor notifies the isolation domain core to release resources, clear memory and cache status, and update idle resources.

Images