Virtual machine creation method, device, system, storage medium and program product

Abstract

Embodiments of the present application provide a virtual machine creation method, device, system, storage medium and program product. In the embodiments, a physical TKM in a processor can provide a plurality of key spaces, and a usage mode allocation view of each key space is preset. According to the usage mode allocation view of the key space, a target identifier of a virtual machine to be created is determined from an identifier set of a key space corresponding to a target usage mode required by the virtual machine to be created, and effective management of key space resources is achieved. Through the preset usage mode allocation view, pre-planning and registration of the key space on the physical machine are completed. When the virtual machine is created, only the identifier of the appropriate key space needs to be automatically selected according to the target usage mode, and a new vTKM instance does not need to be dynamically applied to the physical TKM, thereby avoiding delay caused by waiting for TKM hardware resource allocation in the virtual machine creation process, and helping to improve the creation efficiency of the virtual machine.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and particularly relates to a virtual machine creation method, device, system, storage medium and program product. BACKGROUND

[0002] With the wide application of cloud computing and virtualization technology, data security and privacy protection has become one of the core challenges in the design of information systems. Cryptographic technology, as a basic means to protect information security, has been widely deployed in various application scenarios. However, the effective implementation of cryptographic technology not only depends on efficient cryptographic operation capability, but also depends on a secure and reliable key management mechanism. As the core of the cryptographic system, the security of the key directly determines the protection capability of the entire system. Once the key is illegally obtained, the security system will face the risk of collapse.

[0003] At present, a large number of application systems still have a relatively extensive problem in key management. Some systems store the key in the form of plaintext in the file system or configuration file, lack basic access control and encryption protection, and are extremely vulnerable to attacks. Although special devices such as hardware security modules (HSM) can provide high-strength security protection, the high cost, complex integration difficulty and increase of physical exposure limit its large-scale deployment in general scenarios.

[0004] Under this background, some trusted key management modules (TKM) are integrated inside the processor. The module supports users to securely store the key inside the chip, and presents an invisible form to the outside, and only references through an index or handle. Users can complete encryption and decryption, signature verification and other operations by calling the interface provided by the TKM, and achieve the security goal of "key available but invisible".

[0005] The TKM on a physical host can provide multiple key spaces and support multiple mutually isolated virtual trusted key management modules (vTKM) for use. Each vTKM can correspond to one or more virtual machines (VM), thereby realizing a flexible key management mode. However, due to the support of multiple use modes of the key space, users can flexibly select a suitable key space use mode according to the application characteristics and security policy of the user, and improve the security and resource utilization of the overall system. Under the diversified key space use mode, the key space management in the virtualization scenario is extremely complex. Therefore, how to effectively manage the key space in the virtual machine creation process with the TKM function is a technical problem to be solved by the person skilled in the art. SUMMARY

[0006] Embodiments of the present application provide a virtual machine creation method, device, system, storage medium and program product, to realize effective management of key space of TKM.

[0007] Embodiments of the present application provide a virtual machine creation method, applicable to a service device, wherein a physical trusted key management module (TKM) is arranged in a processor of the service device; a plurality of key spaces are registered in the physical TKM; and the method comprises the following steps.

[0008] In response to a virtual machine creation request, a target usage mode of a key space required by a virtual machine to be created is determined.

[0009] According to a preset usage mode distribution view of the plurality of key spaces, a first identifier set of a key space corresponding to the target usage mode is determined; the usage mode distribution view is used to reflect respective usage modes of the plurality of key spaces; and the first identifier set comprises an identifier of the key space corresponding to the target usage mode.

[0010] A target identifier is determined for the virtual machine to be created from the first identifier set.

[0011] According to a target key space corresponding to the target identifier, configuration information of the virtual machine to be created is generated.

[0012] According to the configuration information of the virtual machine to be created, a virtual machine with TKM function is created.

[0013] Embodiments of the present application also provide a cloud service system, comprising: at least one service device; a plurality of physical TKMs arranged in a processor of the service device; a plurality of key spaces registered in the physical TKMs; and the service device is used to execute steps in the above virtual machine creation method.

[0014] Embodiments of the present application also provide an electronic device, comprising: a memory and a processor; wherein the memory is used to store a computer program;

[0015] The processor is coupled to the memory, and is used to execute the computer program to execute steps in the above virtual machine creation method.

[0016] Embodiments of the present application also provide a computer readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to execute steps in the above virtual machine creation method.

[0017] Embodiments of the present application also provide a computer program product comprising a computer program, which, when executed by one or more processors, causes the one or more processors to execute steps in the above virtual machine creation method.

[0018] In the embodiment of the present application, the physical TKM in the processor can provide a plurality of key spaces, and is preset with a usage mode allocation view of each key space. When a virtual machine creation request arrives, a target identifier of the virtual machine to be created can be determined from an identifier set of a key space corresponding to a target usage mode required by the virtual machine to be created according to the usage mode allocation view of the key space, and the key space corresponding to the target identifier is the key space allocated to the virtual machine to be created, thereby realizing effective management of key space resources. The pre-planning and registration of the key space are completed on the physical machine through the preset usage mode allocation view. When the virtual machine is created, only the identifier of the appropriate key space needs to be automatically selected according to the target usage mode, and there is no need to dynamically apply for a new vTKM instance to the physical TKM, thereby effectively avoiding the delay caused by waiting for the TKM hardware resource allocation in the virtual machine creation process, and helping to improve the creation efficiency of the virtual machine. BRIEF DESCRIPTION OF DRAWINGS

[0019] The accompanying drawings, which are included to provide a further understanding of the present application, form a part of the present application and illustrate the illustrative embodiments of the present application and together with the description serve to explain the present application. In the drawings:

[0020] Figure 1 It is a schematic diagram of the architecture of the traditional key management system;

[0021] Figure 2 It is a schematic diagram of the data encryption and decryption process of the traditional key management system;

[0022] Figure 3 It is a schematic diagram of the architecture of the TKM provided in the embodiment of the present application;

[0023] Figure 4 It is a schematic diagram of the key management architecture based on the TKM provided in the embodiment of the present application;

[0024] Figure 5 It is a schematic diagram of the usage mode of the key space provided in the embodiment of the present application;

[0025] Figure 6 It is a schematic diagram of the structure of the cloud service system provided in the embodiment of the present application;

[0026] Figure 7 It is a schematic diagram of the structure of another cloud service system provided in the embodiment of the present application;

[0027] Figure 8 It is a schematic diagram of the traditional virtual machine creation process;

[0028] Figure 9 And Figure 10A schematic diagram of a view of allocation of key space provided by an embodiment of the present application in a private use mode;

[0029] Figure 11 A schematic diagram of a view of allocation of key space provided by an embodiment of the present application in a private use mode;

[0030] Figure 12 A schematic diagram of a view of allocation of key space provided by an embodiment of the present application in a shared use mode;

[0031] Figure 13 A schematic diagram of a view of allocation of key space provided by an embodiment of the present application in a hybrid use mode;

[0032] Figure 14 A schematic diagram of a view of allocation of key space provided by an embodiment of the present application in another private use mode;

[0033] Figure 15 A schematic diagram of a view of allocation of key space provided by an embodiment of the present application in another shared use mode;

[0034] Figure 16 A schematic diagram of a view of allocation of key space provided by an embodiment of the present application in another hybrid use mode;

[0035] Figure 17 A schematic diagram of a flow of a virtual machine creation method provided by an embodiment of the present application;

[0036] Figure 18a A schematic diagram of a flow of another virtual machine creation method provided by an embodiment of the present application;

[0037] Figure 18b A schematic diagram of an update process of shared identification parameters and private identification parameters provided by an embodiment of the present application;

[0038] Figure 19 A schematic diagram of a flow of another virtual machine creation method provided by an embodiment of the present application;

[0039] Figure 20 A schematic diagram of a creation process of a virtual machine with TKM function and CCP function provided by an embodiment of the present application;

[0040] Figure 21 A schematic diagram of a data flow path for password calculation of a virtual machine with TKM function and CCP function provided by an embodiment of the present application;

[0041] Figure 22 A schematic diagram of a structure of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0042] In order to make the purposes, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be described below in connection with specific embodiments of the present application and corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0043] It should be noted that, in the case of the embodiments of the present application involving user information, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the embodiments of the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0044] The concepts or terms involved in the embodiments of the present application will be explained first.

[0045] Crypto Co-Processor (CCP): physical CCP, an encryption and decryption co-processor embedded in a processor (such as CPU), which is a hardware module for encryption and decryption processing, and can improve the encryption and decryption processing speed.

[0046] Virtual CCP (vCCP): a virtual encryption and decryption co-processor that transmits to a virtual machine through virtualization technology, so that the virtual machine has the function of a physical CCP.

[0047] Mediated Device (MDEV device): MDEV device refers to a Virtual Function Input / Output (VFIO) mediated device (VFIO-MDEV device), which is a framework in the Linux (an operating system) kernel for managing and virtualizing devices. MDEV device is a virtualized device managed by the MDEV framework, which allows user space applications to interact with IO devices through the VFIO interface. Using MDEV device can achieve virtualization acceleration, device isolation and device function customization.

[0048] Virtual machine configuration component (e.g., prepareVM): The virtual machine configuration component is a component for generating a configuration file of a virtual machine in a virtual machine creation process, integrated in a resource management configuration and virtual machine creation management tool. The configuration file of the virtual machine can be an Extensible Markup Language (XML) file.

[0049] Resource management configuration and virtual machine creation management tool (e.g., kvm-config, etc.): A script tool used for setting virtual machine environment information, assembling a virtual machine configuration file, and the like, in order to support a virtualization function in cloud service virtualization.

[0050] Trusted key management module (TKM): A trusted key management module developed inside a processor, which is a hardware module inside the processor, and based on which a key management function can be provided.

[0051] Virtual trusted key management module (vTKM): Based on a physical host supporting a TKM, a TKM instance used by a virtual machine implemented through a virtualization technology can be allocated.

[0052] Some conventional key management methods will be described by way of example.

[0053] A hardware security module (HSM) is a computer hardware device that safeguards and manages digital keys used by strong authentication systems and provides related cryptographic operations. They are generally connected directly to a computer or network server in the form of an expansion card or external device. The HSM provides tamper-evident and tamper-resistant functions. The former design makes tampering leave traces, and the latter design makes tampering cause the HSM to destroy protected information such as keys. Each HSM includes one or more secure co-processors to prevent tampering or bus probing. Many HSM systems also provide a mechanism for securely backing up external keys, which can be backed up in the form of data packets and stored on a computer disk or other medium, or securely stored on an external portable device such as a smart card or other secure token. Since HSMs are usually part of a public key infrastructure (PKI) or a critical infrastructure such as a network bank, multiple HSMs are generally used to achieve high availability. Some HSMs have designs such as dual power supply and no need to stop the machine to replace components such as cooling fans, to ensure high availability requirements in data center environments.

[0054] Key management services under cloud computing architecture usually need to access the corresponding HSM cluster through the network to realize the related key management services, mostly one HSM provides services to multiple tenants in the form of network and Application Programming Interface (API). Figure 1

[0055] As shown in Figure 1 , the KMS architecture includes three main levels: key management layer, management and control layer, and service layer. Among them, the key management layer includes: (1) Hardware Security Module (HSM): dedicated hardware for key generation and storage, providing physical isolation and encryption protection, invisible to the upper layer; (2) Key operation, i.e. key management system: supporting national cryptographic algorithm (SM2, SM4, etc.) and international standard algorithm (AES-256, RSA-4096, etc.), key generation, encryption and decryption, signature, etc. Operations are completed inside the HSM, and the plaintext of the key is not exposed. Among them, SM is a commercial cipher in the national cryptographic algorithm, and SM is the Chinese pinyin abbreviation of "commercial" and "secret" in "commercial cipher". SM2 is a commercial cipher in the national cryptographic algorithm, which is a public key encryption algorithm based on elliptic curve encryption, and is a non-symmetric encryption algorithm. SM3 is a message digest algorithm, and SM4 is a symmetric encryption algorithm. AES-256 refers to the Advanced Encryption Standard (AES) - 256-bit key length, and AES is a symmetric encryption algorithm widely used in data encryption and protection. "256" means the length of the key is 256 bits. RSA-4096 refers to Rivest-Shamir-Adleman (RSA) - 4096-bit key length. RSA is a non-symmetric encryption algorithm commonly used for secure data transmission. It uses a pair of keys - a public key (for encryption) and a private key (for decryption). "4096" indicates that the length of the key is 4096 bits. The longer the key length, the stronger the computing power required to crack the key, so it is also more secure.

[0056] The key management layer also includes: (3) Key database, used to store key metadata (such as key identification, policy, status, version) and audit logs, etc.

[0057] The management and control layer (i.e. Figure 1 encrypted instance) includes: (1) Cloud encryption machine based on authoritative cryptographic agency authentication, providing tenant-isolated virtual cryptographic machine instances, supporting cloud data encryption and decryption services (i.e.​Figure 1 decryption service in Figure 1 ); (2) identity authentication and backup policy (i.e. Figure 1 authentication service in ); (3) function encapsulation: function encapsulation implements key management, data encryption, and cryptographic algorithm functions, and provides API (i.e.

[0058] in Figure 1 ) or software development kit (SDK) access methods. Figure 1 Figure 1 The service layer includes: (1) network service layer: adding load balancing (i.e. Figure 1 "load balancing" in ) and multi-active modules (not shown), ensuring the reliability of services or applications; (2) application service layer: virtual machines (such as virtual machines 1 and 2) call SDK to encapsulate data encryption (such as file, database field encryption, etc.), such as

[0059] "application encryption" in to meet the needs of service scenarios and implement application-level data encryption and decryption; (3) audit service layer (i.e.

[0060] "audit log" in Figure 2 ): recording key operations, caller identity, Internet Protocol (IP) address, and time stamp, etc.

[0061] The following will be described with reference to the actual application scenario, taking data file encryption and decryption operations as an example to illustrate the flow process of data key in the KMS architecture. Figure 2As shown, in the decryption process, the virtual machine accesses the API provided by the KMS through the network to call the decryption module in the encryption instance. After the KMS authenticates the virtual machine, the KMS returns the correct data key to the virtual machine. The virtual machine can decrypt the ciphertext of the key pair key of the data key to obtain the plaintext of the data key. Then, the virtual machine uses the plaintext of the data key to decrypt the ciphertext of the application data to obtain the plaintext of the application data. In the whole process, the data key in the KMS system and the encryption and decryption keys used by the virtual machine are not the same. The data key is used to encrypt and decrypt the virtual machine side key itself, avoiding the transmission of the data key and protecting the security of the HSM data key.

[0062] Although the HSM scheme improves the security level, the HSM scheme increases the hardware cost and the complexity of the mainboard hardware design, and also increases the physical exposure surface, which is easy to be attacked by bus type physical attacks. Some processors implement a trusted key management module (TKM) based on a security processor (PSP) and a cryptographic co-processor (CCP). Users can store keys in the TKM. When the user uses it, only the index or handle of the key in the TKM needs to be specified, and the cryptographic operation can be efficiently completed by calling the interface provided by the TKM. The TKM can achieve the effect of "available but invisible" of the key to the user, and protect the key. The TKM system architecture is as shown in Figure 3 .

[0063] As shown in Figure 3 , the TKM system can include a management tool, an operating system (OS) driver, and a central processing unit (CPU). The management tool provides a user interface or a command line tool for managing and configuring the entire TKM system, which can be used to initialize and configure the device, manage security resources such as keys and certificates, and monitor the state and logs of the TKM system. The OS driver acts as a bridge between the operating system and the hardware, and is responsible for coordinating resources and scheduling tasks. As shown in Figure 3 , the OS driver can provide a TKM management interface and a TKM application interface. The TKM management interface connects the management tool and the TKM driver to manage and control the TKM system, and can transmit management instructions and parameters, feedback system state and results, etc. The TKM application interface can also provide a standard interface and a key application interface. The standard interface defines a standard protocol and specification for interaction with external systems, provides a unified data exchange format and communication mechanism, and ensures compatibility with other standard-compliant systems. The TKM application interface provides a cryptographic service interface for the upper layer application.

[0064] The central processing unit (CPU) can include a physical TKM. The TKM is responsible for key management and secure storage, managing internal keys, application keys, and device keys, as well as storing device certificates, etc. The TKM can provide secure storage services to ensure the security of keys and sensitive data. Internal keys refer to keys used within the system to protect other keys and data. Application keys refer to keys generated and managed by specific applications for encrypting application data. Device keys are keys bound to the identity of the device for device authentication and secure communication. Device certificates refer to digital certificates that prove the identity and legitimacy of the device.

[0065] As shown in Figure 3 , the CPU can also include a CCP. The CCP is a hardware implementation of encryption algorithms such as SM2, SM3, SM4, and True Random Number Generator (TRNG), etc. The CCP can implement local hardware acceleration of encryption algorithms to improve encryption and decryption processing speed. The TKM can provide key services to the CCP, i.e., key management for keys required by the CCP's encryption and decryption processes.

[0066] Compared with the traditional separate password card solution or the solution of accessing the HMS cluster through the network to obtain key services, the TKM can implement a system architecture based on local hardware for key management and use. This architecture not only has endogenous security characteristics, but also supports the local implementation of key management and cryptographic calculations. Figure 4 A schematic diagram of the key management process based on the TKM is shown.

[0067] As shown in Figure 4 , when an application program (such as applications 1-4 in Figure 4 ) needs to perform encryption, decryption, signature, etc., it can send a request to the physical TKM module by calling the TKM application interface or the TKM management interface. The key request issued by the application program is passed to the OS layer, and the OS is responsible for forwarding the request to the underlying physical TKM.

[0068] After the host OS receives the request of the application, the request is preliminarily parsed and processed to ensure that it meets the security specifications and determine the specific type of the request (such as encryption and decryption, key generation, etc.), and then the request is forwarded to the physical TKM of the hardware layer through a specific channel (such as a dedicated bus or API call). After the physical TKM receives the request, the request is further parsed and processed by using the internal security mechanism (such as TRNG random number generator, hardware encryption engine, etc.). If the request is for requesting key generation, the physical TKM generates a random key by using the built-in true random number generator (TRNG), stores the newly generated key in the secure area inside the physical TKM, and assigns a unique key identifier. If the request is for requesting the use of the key, such as encryption and decryption or digital signature, the physical TKM looks up the corresponding key according to the key identifier in the request. For the embodiment in which the physical CCP is arranged inside the processor, the physical TKM can transmit the key to the physical CCP through the channel between the TKM and the physical CCP, and the physical CCP can complete the corresponding cryptographic operation inside. In the whole process, the whole process key is always kept inside the physical TKM and is not exposed to any software layer or external device, ensuring the security of the key. The keys used by different applications are logically isolated inside the physical TKM, preventing illegal access across applications.

[0069] In a virtualized environment, multiple virtual machines (VMs) on the same physical machine share the same physical host resources. In order to ensure data isolation and security between different users or applications, the physical TKM can isolate multiple key spaces. The key space is a logically isolated key management unit provided by the physical TKM for different virtual machines (VMs). Each key space is an independent key storage and management environment for isolating the key resources of different virtual machines or security domains. The keys between different key spaces cannot directly communicate with each other, ensuring the confidentiality and integrity of the keys. When a virtual machine starts and binds to the specific identifier of the vTKM, the virtual machine can only access the keys in the key space corresponding to the identifier and cannot access the keys in other key spaces by force.

[0070] The physical TKM of a physical machine can provide multiple (denoted as M) key spaces, and can support the use of M mutually isolated virtual TKMs (vTKMs). M≥2, and is an integer. The number of virtual machines sharing the vTKM key resource is not limited without limiting physical resources. The vTKM can provide three use modes of key space: (1) exclusive mode, i.e., a virtual machine exclusively uses a key space; (2) different virtual machines sharing mode, i.e., multiple virtual machines share a key space; and (3) virtual machine and physical machine sharing mode, i.e., a virtual machine and a physical machine share the same key space. Therefore, the use mode of the key space refers to the allocation manner of the key space between the virtual machine and the physical machine. The diversified use mode of the key space provides great flexibility for users to formulate application deployment forms that meet their own key security requirements. For example, as shown in FIG. 8, the host and the application of VM1 share the same key space 0; VM2 and VM3 share the same key space 1, but do not share the same key space with the host; and VM4 exclusively uses the key space 2. This enables the same physical host to support the running of services or applications under multiple different keys, thereby ensuring the secure isolation of respective services or applications. Figure 5

[0071] The above-mentioned multiple use modes of the key space not only provide convenience for users to select various application scenarios, but also bring challenges of complexity to the creation of virtual machines. Specifically, for a full-exclusive TKM environment required by a user, how to sequentially allocate M key spaces, especially how to ensure that the key spaces are not in conflict in the workflow of multiple virtual machine creation requests in a concurrent scenario. For a full-shared vTKM environment required by a user, the virtual machine to be created needs to use an occupied key space, and then join a certain group of existing shared key virtual machines; or needs to apply for an identifier of a new key space, and serve as the first virtual machine of a new key space virtual machine group. For a mixed exclusive and shared mode, the problem is even more complex. The above-mentioned problems in the two full-shared scenarios and the full-exclusive scenario still exist in this scenario. Therefore, in the virtualization scenario, the key space management is extremely complex. Therefore, in the process of creating a virtual machine with a TKM function, how to effectively manage the key space is a technical problem to be solved by those skilled in the art.

[0072] ​To address the aforementioned technical issues, in some embodiments of this application, the physical TKM in the processor can provide multiple key spaces and has a pre-configured usage mode allocation view for each key space. When a virtual machine creation request arrives, the target identifier for the virtual machine to be created can be determined from the set of identifiers of key spaces corresponding to the target usage mode required by the virtual machine to be created, based on the key space usage mode allocation view. The key space corresponding to this target identifier is the key space allocated to the virtual machine to be created, thus achieving effective management of key space resources. The pre-planning and registration of key spaces are completed on the physical machine through the pre-configured usage mode allocation view. When a virtual machine is created, it only needs to automatically select the appropriate key space identifier according to its target usage mode, without needing to dynamically request a new vTKM instance from the physical TKM. This effectively avoids delays caused by waiting for TKM hardware resource allocation during virtual machine creation, helping to improve virtual machine creation efficiency.

[0073] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0074] It should be noted that the same reference numerals in the following figures and embodiments denote the same object or the same step. Therefore, once an object or step is defined in one figure or embodiment, it does not need to be discussed further in subsequent figures and embodiments.

[0075] Figure 6 This is a schematic diagram of the structure of the cloud service system provided in an embodiment of this application. Figure 6 As shown, Figure 6 As shown, a cloud service system includes at least one service device 10. Generally, a cloud service system includes multiple service devices 10. Multiple means two or more (including two).

[0076] The processor 101 of the service device 10 includes a physical TKM 102. The physical TKM 102 has key management and cryptographic operation functions, as shown in Table 1 below.

[0077] Table 1. Schematic diagram of TKM's key management and cryptographic operation functions.

[0078]

[0079] In Table 1, ECB is the Electronic Codebook (ECB) mode, which is the simplest block cipher mode of operation. It divides the plaintext into blocks, and each block is independently encrypted using the same key. CBC is the Cipher Block Chaining (CBC) mode. In the CBC mode, each plaintext block is XORed with the previous ciphertext block before encryption. CFB is the Cipher Feedback (CFB) mode. CFB mode converts a block cipher into a stream cipher, encrypting only a small amount of data at a time. The current ciphertext block depends on all previous plaintext blocks. Output Feedback Mode (OFB) is a stream cipher mode, but unlike CFB, it is based on the feedback of the encryptor's output rather than the ciphertext. Counter Mode (CTR): In the CTR mode, each block uses a unique counter value, which is encrypted as part of the keystream, then XORed with the plaintext block to obtain the ciphertext block.

[0080] Hash-based Message Authentication Code (HMAC) is a technique that uses a cryptographic hash function and a key to generate a message authentication code, which is used to verify the integrity and authenticity of a message. HMAC uses a specific hash function and a key. First, the key is combined with a specific padding before and after the original message for hash operation. Specifically, the calculation process of HMAC involves two hash operations: first, the key and an internal separator are connected and hashed together with the message; then the same key and an external separator are connected and hashed again with the result of the previous step.

[0081] Cipher-based Message Authentication Code (CMAC) is a technique that uses a block cipher algorithm to create a message authentication code, mainly used to verify the integrity and authenticity of a message. CMAC is based on a block cipher working in a specific mode (usually a symmetric encryption algorithm), which divides the message into fixed-length blocks and processes these blocks in a manner similar to the CBC mode. CMAC also includes an additional sub-key generation step, which helps to enhance security.

[0082] It is worth noting that the key management and key operation functions of the physical TKM shown in Table 1 are only exemplary and do not constitute a limitation, nor do they limit the physical TKM to only having the functions shown in Table 1, nor do they require the physical TKM to have all the functions shown in Table 1.

[0083] like Figure 6 As shown, service device 10 may include hardware and a host operating system (OS). The hardware includes processor 101 and a basic input / output system (BIOS) 103. BIOS 103 meets relevant security requirements and enables the security capabilities of processor 101.

[0084] like Figure 7 As shown, the host operating system (host OS) has modules such as TKM driver, Virtual Function I / O (VFIO), MDEV, etc., as well as the security certificates required for the processor's corresponding security hardware, suites, etc.

[0085] Service devices can be virtualized into one or more virtual machines. For example... Figure 7 As shown, multiple containers or container groups (such as Pods) can run on a virtual machine. The virtual machine provides the necessary hardware and software resources and security capabilities for their operation. Containers are... Figure 8 The container scheduling and orchestration components in the container (i.e. Figure 7 The container scheduling and orchestration component manages and schedules containers. It is the container scheduling and orchestration engine, supporting automated deployment, large-scale scalability, and application containerization management. Multiple containers or container groups run a customer's own applications or services. Service devices can be virtualized into one or more virtual machines using virtualization technologies. For example, service devices can be virtualized into one or more virtual machines using Quick Emulator (QEMU) and Kernel-based Virtual Machine (KVM) technology. Therefore, a virtual machine can appear as a QEMU process. QEMU provides a user-space emulator that can simulate complete system hardware, including processors (such as CPUs), memory, and storage devices (such as disks). KVM is a module loaded into the kernel of an operating system (such as Linux) that provides hardware-accelerated virtualization capabilities. Using KVM in conjunction with QEMU can significantly improve the performance of virtual machines.

[0086] exist Figure 7In VFIO-PCI, a user-space driver framework for operating systems, is designed to provide direct access to Peripheral Component Interconnect (PCI) devices and supports various device types, including TKM. It is primarily used to implement device passthrough functionality, allowing virtual machines to directly access physical devices and achieve near-native performance.

[0087] `.ko` files are kernel modules of operating systems (such as Linux). Among them, `vfio.ko` provides basic device passthrough functionality and user-space driver support, supporting various device types and offering core passthrough capabilities. `vfio-pci.ko` is a module specifically designed for PCI devices, providing PCI device registration, mapping, and management functions, primarily supporting PCI device passthrough. `vfio-mdev.ko` and `mdev.ko` are two modules in the Linux kernel that jointly support device passthrough and device emulation. The `mdev.ko` module is a functional module in the Linux kernel used for managing and emulating devices. It allows for the dynamic creation and destruction of devices, thus supporting hot-plugging and dynamic configuration. `vfio-mdev.ko` is a module based on the Vfio framework used to support passthrough functionality for discrete devices. It allows virtual machines to directly access certain functional units of physical devices, thereby achieving higher performance and flexibility. `ct.ko` is a module related to encryption technology, part of a specific system or device driver, used to implement encryption functions. `kvm.ko` is a module file in the Linux kernel representing a core component of KVM. kvm.ko is responsible for providing basic support for hardware virtualization, enabling users to run virtual machines on top of the Linux kernel.

[0088] The following section will first explain the creation process of a traditional virtual machine. For example... Figure 8 The traditional virtual machine creation process shown may include the following steps:

[0089] 1. Users can initiate virtual machine creation requests through the platform's white-screen entry point or background command interface. The virtual machine creation request reaches the management component running on the service device.

[0090] 2. The management component generates the necessary parameters contained in the virtual machine configuration file (such as an XML file) based on the virtual machine creation request, and passes these necessary parameters to the virtual machine configuration component (such as the prepareVM component) in the resource management configuration and virtual machine creation management tool.

[0091] The necessary parameters contained in the virtual machine configuration file can include part of the hardware configuration parameters of the virtual machine, such as the number of processors and the size of CPU memory.

[0092] The virtual machine configuration component (such as the prepareVM component) generates the hardware configuration information of the virtual machine according to these parameters. The hardware configuration information can be implemented in the format of an XML file.

[0093] 3. The virtual machine configuration component (such as the prepareVM component) returns the generated part of the hardware configuration information of the virtual machine to the management and control component.

[0094] 4. The management and control component transmits part of the hardware configuration information to the virtual machine configuration file assembly component (StartVMx).

[0095] The virtual machine configuration file assembly component can assemble part of the hardware configuration information of the virtual machine and other configuration information into a complete virtual machine configuration file (such as an XML file). The other configuration information can include, but is not limited to, basic attribute information of the virtual machine, security configuration parameters, and authentication data. The basic attributes of the virtual machine can include the name of the virtual machine, the image identifier, the instance type of the virtual machine, and the geographic location area where the virtual machine is located. The security configuration parameters can include security group ID and firewall rules. The authentication data can include username and password.

[0096] 5. The virtual machine configuration file assembly component transmits the complete virtual machine configuration file to the virtual machine management component (such as libvirt). The virtual machine configuration file assembly component can call the libvirt interface to transmit the virtual machine configuration file to libvirt to start the virtual machine.

[0097] Among them, libvirt is a software library and tool set for managing virtualization functions on a machine. It provides a unified Application Programming Interface (API) so that developers can manage multiple virtualization technologies through the API, including but not limited to KVM and QEMU. Libvirt has virtual machine management functions such as starting, stopping, suspending, or resuming virtual machines; it also has storage management functions such as managing virtual disks and storage pools, and network management functions such as configuring and managing virtual networks.

[0098] The virtual machine management component (such as libvirt) can convert the virtual machine configuration file into command line parameters suitable for QEMU, and perform necessary configuration work at the operating system level. Specifically, the virtual machine management component starts the virtual machine, and the virtual machine management component can parse various parameters in the virtual machine configuration file, such as memory size, CPU number, disk information, network interface information, and the like; further, according to the parsed configuration information, a command line suitable for starting the virtual machine is assembled. The command line for starting the virtual machine can include: selecting a suitable virtualization engine (such as QEMU), setting the processor, memory, and other hardware parameters, specifying the location of the disk image, and configuring the network interface parameters.

[0099] 6. The virtual machine management component (such as libvirt) starts the QEMU process by using the command line parameters suitable for QEMU.

[0100] 7. The QEMU cooperates with the KVM kernel module to start the virtual machine according to the converted command line parameters.

[0101] The virtual machine runs as a process on the host machine. When performing sensitive operations such as IO, a virtual machine exit (VMexit) event is triggered, causing the control to be transferred from the user mode QEMU to the kernel mode KVM module.

[0102] 8. After receiving the virtual machine exit message, the KVM module analyzes the reason for the virtual machine exit and performs corresponding processing, and then passes the data to the QEMU and performs a virtual machine entry (VMentry) operation again, so that the control is transferred to the user mode QEMU.

[0103] The interaction between steps 7 and 8 continues, indicating that the virtual machine is running. When this interaction starts to work, it indicates that the virtual machine has been created and is in a running state.

[0104] The foregoing embodiment simply exemplarily illustrates the creation process of a conventional virtual machine. In the embodiment of the present application, in order to create a virtual machine with TKM function, the virtual machine needs to be configured with vTKM resource, i.e. the key space of the physical TKM, so that the virtual machine has TKM function. Therefore, during the creation of the virtual machine, TKM-related configuration information needs to be generated for the virtual machine. The virtual machine with TKM function can be referred to as a vTKM virtual machine. The physical TKM can provide a plurality of (denoted as M) key spaces. M≥2, and is an integer. Each key space corresponds to a unique identifier (Virtual Identifier, VID).

[0105] In creating a virtual machine supporting vTKM, a key entity needs to be created inside the physical TKM. The specific operation includes: available key space (Key Space), and a unique virtual identifier is generated by the TKM for it, which is used to uniquely identify the key space. Before starting the virtual machine, the VID needs to be configured as a parameter into the start configuration of the virtual machine, and passed to the host kernel (Host Kernel) of the host machine. After the host kernel receives the VID, it will bind it with the virtual machine to be started, and establish the association between the virtual machine and the key space represented by the VID.

[0106] Further, the physical TKM identifies the VID at the firmware level, and associates the corresponding vTKM entity (i.e. the key space corresponding to the VID) with the virtual machine. In this way, when the virtual machine runs, all its requests related to key management, encryption and decryption operations, etc. will be passed to the physical TKM through the hardware assisted mechanism, and the TKM will perform the corresponding security operations in the key space corresponding to the VID. This binding mechanism ensures that each virtual machine can only access its exclusive key space resources, realizes key isolation and security guarantee in the virtualization environment, and provides a foundation support for building a trusted computing environment.

[0107] Among them, the key space of the physical TKM generally has 3 usage modes, including: (1) exclusive mode, that is, a virtual machine exclusively uses a key space; (2) different virtual machines share mode, that is, multiple virtual machines share a key space; (3) virtual machine and physical machine share mode, that is, a virtual machine and a physical machine share the same key space.

[0108] In the embodiments of the present application, in order to effectively manage the key space of the physical TKM, a key space management mechanism based on a preset key space usage mode allocation view (Preset Allocation View, PAV) is proposed. Among them, the usage mode allocation view is used to reflect the usage mode of each of the plurality of key spaces. In the embodiments of the present application, the specific implementation form of the usage mode allocation view is not limited. In some embodiments, the usage mode allocation view can be implemented as a correspondence between the identifiers (VIDs) of the plurality of key spaces of the physical TKM and the usage modes. The user can flexibly configure the correspondence according to actual needs. In the correspondence between the plurality of key spaces of the physical TKM and the usage modes, each key space corresponds to a usage mode.

[0109] In other embodiments, the usage mode allocation view can include a shared identifier parameter (index_share) and an exclusive identifier parameter (index_exclusive). The configuration rules of the usage mode allocation view can be pre-set, for example, as follows: Figure 9 and Figure 10As shown, the key space can be divided into three categories—shared key space, dedicated key space, and undefined key space—using shared and dedicated identifier parameters. Undefined key space refers to key space whose usage mode is not predefined or configured. Specifically, as... Figure 9 As shown, the shared key space can expand in ascending order starting from the smallest key space identifier, such as the range of shared key space identifiers being [0, index_share] or [0, index_share]; the exclusive key space can expand in descending order starting from the largest key space identifier, such as the range of exclusive key space identifiers being [index_exclusive, M-1] or (index_exclusive, M-1). Correspondingly, the undefined key space can be represented as (index_share, index_exclusive) or [index_share, index_exclusive]. In this embodiment, the shared identifier parameter is used to set the upper limit value of the key space identifier in the shared mode; index_exclusive is used to set the lower limit value of the key space identifier in the exclusive mode. The shared mode can include: virtual machine and physical machine sharing mode and different virtual machine sharing mode. Among them, the undefined key space can contain 0, 1 or more key spaces. Specifically, it is determined by the values ​​of index_share and index_exclusive. The number of key spaces contained in the undefined key space is equal to index_exclusive - index_share - 1.

[0110] In this embodiment, the value of the shared identifier parameter should be less than or equal to the value of the exclusive identifier parameter. For ease of description, the value of the shared identifier parameter is simply referred to as the shared identifier parameter value; and the value of the exclusive identifier parameter is simply referred to as the exclusive identifier parameter value. That is, the shared identifier parameter value should be less than or equal to the exclusive identifier parameter value. If the shared identifier parameter value is equal to the exclusive identifier parameter value, and equal to the minimum configurable identifier, then if the physical TKM does not have a key space with a specified usage mode, the entire key space of the physical TKM is in exclusive mode; if the physical TKM has a key space with a specified usage mode, then all other key spaces of the physical TKM besides the key space with a specified usage mode are in exclusive mode.

[0111] For example, such as Figure 11As shown, the processor manufacturer pre-specifies the identifier of the key space in the virtual machine and physical machine shared mode. For example, the key space with VID=0 is the key space in the virtual machine and physical machine shared mode. In this embodiment, the shared identifier parameter value is equal to the exclusive identifier parameter value, and is equal to the minimum configurable identifier, i.e., index_share=index_exclusive=1. Therefore, it can be determined that the key space of the physical TKM, except for the key space with VID=0, is all in exclusive mode (i.e., exclusive key space).

[0112] If the shared identifier parameter value is equal to the exclusive identifier parameter value and equal to the maximum configurable identifier, then if the physical TKM does not have a key space with a specified usage mode, the entire key space of the physical TKM will be in shared mode between different virtual machines; if the physical TKM has a key space with a specified usage mode, then all other key spaces of the physical TKM except for the key space with a specified usage mode will be in shared mode between different virtual machines.

[0113] like Figure 12 As shown, the physical TKM can provide 64 key spaces, i.e., M=64; the identifiers of the 64 key spaces are 0-63. The processor manufacturer pre-specifies the identifiers of the key spaces in the virtual machine and physical machine shared mode, such as the key space with VID=0 being the key space in the virtual machine and physical machine shared mode. In this embodiment, the shared identifier parameter value is equal to the exclusive identifier parameter value, and is also equal to the maximum configurable identifier, i.e., index_share=index_exclusive=(M-1)=63. Therefore, it can be determined that all the key spaces of the physical TKM, except for the key space with VID=0, are in the shared mode between different virtual machines.

[0114] If the shared identifier parameter value is less than the exclusive identifier parameter value, and the shared identifier parameter value is greater than or equal to the minimum configurable identifier (e.g., 1), while the exclusive identifier parameter value is less than the maximum configurable identifier (e.g., (M-1), then the physical TKM's key space is deployed in a mixed shared and exclusive mode. For example, ... Figure 13 As shown, if 1 ≤ index_share < index_exclusive ≤ 63, then the physical TKM key space can be deployed in a mixed mode of shared and exclusive modes. Figure 13 In this context, the key space with VID=0 is a pre-specified key space shared by the virtual machine and the physical machine. Figure 13 The number of undefined key spaces is determined by the shared identifier parameter value and the unique identifier parameter value. For example, Figure 13If the shared-identity parameter = 20 and the exclusive-key parameter = 42, it can be determined that the key space of VID between 1 and 20 is the key space of the shared mode among different virtual machines; the key space of VID between 21 and 41 is the undefined key space; and the key space of VID between 42 and 63 is the key space of the exclusive mode.

[0115] In some other embodiments of the present application, as shown in Figure 10 the exclusive key space can be expanded in ascending order from the small identity of the key space, such as the identity range of the exclusive key space can be [1, index_exclusive] or [1, index_exclusive]. In Figure 10 , VID = 0 is the pre-designated key space of the shared mode between the virtual machine and the physical machine. The shared key space can be expanded in descending order from the large identity of the key space, such as the identity range of the exclusive key space can be [index_share, M-1] or (index_share, M-1]. Accordingly, the undefined key space can be represented as (index_exclusive, index_share) or [index_exclusive, index_share]. In this embodiment, the shared-identity parameter is used to set the lower limit value of the identity of the key space of the shared mode among different virtual machines; index_exclusive is used to set the upper limit value of the identity of the key space of the exclusive mode. Among them, the key space contained in the undefined key space can be 0, 1 or more. The specific value is determined by index_share and index_exclusive. The number of key spaces contained in the undefined key space is equal to index_share - index_exclusive - 1.

[0116] In this embodiment, the value of the shared-identity parameter should be greater than or equal to the value of the exclusive-identity parameter. If the value of the shared-identity parameter is equal to the value of the exclusive-identity parameter, and is equal to the minimum configurable identity, in the case that there is no key space of the physical TKM designated with the use mode, the key space of the physical TKM is all in the shared mode among different virtual machines; if there is a key space of the physical TKM designated with the use mode, then the key space of the physical TKM except the key space designated with the use mode is all in the shared mode among different virtual machines.

[0117] For example, as shown in Figure 14As shown, the processor manufacturer pre-specifies the identifier of the key space in the virtual machine and physical machine shared mode. For example, the key space with VID=0 is the key space in the virtual machine and physical machine shared mode. In this embodiment, the shared identifier parameter value is equal to the exclusive identifier parameter value, and is equal to the minimum configurable identifier, i.e., index_share=index_exclusive=1. Therefore, it can be determined that the key space of the physical TKM, except for the key space with VID=0, is all in the shared mode between different virtual machines.

[0118] If the shared identifier parameter value is equal to the exclusive identifier parameter value and equal to the maximum configurable identifier, then if there is no key space in the physical TKM with a specified usage mode, then all key spaces in the physical TKM will be in exclusive mode; if the physical TKM has a key space with a specified usage mode, then all other key spaces in the physical TKM except for the key spaces with specified usage modes will be in exclusive mode.

[0119] like Figure 15 As shown, the physical TKM can provide 64 key spaces, i.e., M=64; the identifiers of the 64 key spaces are 0-63. The processor manufacturer pre-specifies the identifiers of the key spaces in the virtual machine and physical machine shared mode, such as the key space with VID=0 being the key space in the virtual machine and physical machine shared mode. In this embodiment, the shared identifier parameter value is equal to the exclusive identifier parameter value, and is also equal to the maximum configurable identifier, i.e., index_share=index_exclusive=(M-1)=63. Therefore, it can be determined that all key spaces of the physical TKM except for the key space with VID=0 are in exclusive mode.

[0120] If the exclusive identifier parameter value is less than the shared identifier parameter value, and the exclusive identifier parameter value is greater than or equal to the minimum configurable identifier (e.g., 1), while the shared identifier parameter value is less than the maximum configurable identifier (e.g., (M-1), then the physical TKM's key space is deployed in a mixed mode of shared and exclusive modes. For example, if... Figure 16 As shown, if 1 ≤ index_exclusive < index_share ≤ 63, then the physical TKM key space is deployed in a mixed mode of shared mode and exclusive mode. Figure 16 In this context, the key space with VID=0 is a pre-specified key space shared by the virtual machine and the physical machine. Figure 16 The number of undefined key spaces is determined by the shared identifier parameter value and the unique identifier parameter value. For example, Figure 16If the exclusive identifier parameter is 20 and the shared key parameter is 42, then the key space with VID between 1 and 20 can be determined as the exclusive key space; the key space with VID between 21 and 41 is the undefined key space; and the key space with VID between 42 and 63 is the key space in the shared mode of different virtual machines.

[0121] For the key space allocation view, which characterizes the key space usage patterns using shared and exclusive identifier parameters, the shared mode expands in ascending order, and the exclusive mode expands in descending order; or, the shared mode expands in descending order, and the exclusive mode expands in ascending order. This facilitates efficient management and allocation of the key space subsequently. Users can adjust the shared and exclusive identifier parameters to scale the undefined key space as needed, providing greater flexibility for users to develop service deployment patterns that meet their own key security requirements. This pre-allocation mechanism for key space usage patterns reduces the resource overhead of key space management compared to the traditional vTKM virtual machine key space management method. This is because the creation requirements for different vTKM virtual machines in different clusters vary depending on actual needs. Traditional key space management allocates vTKM instances on physical machines sequentially according to their key space identifiers, from smallest to largest. For example, virtual machine 1 is allocated a key space with VID=1, virtual machine 2 with VID=2, and the usage mode of the key space is set according to the actual needs of the virtual machine. This results in a disordered and chaotic distribution of key space usage modes on the physical machine, leading to increased VID management overhead and burden for virtual machine startup and release. This embodiment expands the shared mode in ascending order and the dedicated mode in descending order; or, the shared mode expands in descending order and the dedicated mode expands in ascending order. This ensures a centralized distribution of key spaces with the same usage mode, guaranteeing an orderly distribution of vTKM resources on the physical machine. This simplifies development complexity and facilitates cluster management and the construction of related automated operation and maintenance tools.

[0122] The implementation of the key space usage mode allocation view shown in the foregoing embodiments is merely illustrative and does not constitute a limitation. A user can send a virtual machine creation request to the service device. In response to the virtual machine creation request, the service device can schedule resources in the physical TKM's key space according to a preset usage mode allocation view, and use the scheduled key space to create a virtual machine with TKM functionality. It should be noted that the key space usage mode allocation view can be pre-configured by the service device before responding to the virtual machine creation request. For example, it can be a default usage mode allocation view, or a user-configured usage mode allocation view before the service device responds to the virtual machine scenario request. When the service device responds to the virtual machine scenario request and initiates the virtual machine creation process, it can directly use the preset usage mode allocation view to schedule the key space to create a virtual machine with TKM functionality.

[0123] The virtual machine creation method provided by the embodiment of the present application is exemplarily described below from the perspective of a service device.

[0124] Figure 17 A flowchart of a virtual machine creation request provided by the embodiment of the present application is shown in FIG. 2. As shown in FIG. 2, the virtual machine creation method mainly includes the following steps. Figure 17

[0125] 1701. In response to a virtual machine creation request, a target usage mode of a key space required by a virtual machine to be created is determined.

[0126] 1702. According to a preset usage mode distribution view of multiple key spaces, a first identifier set of a key space corresponding to the target usage mode is determined.

[0127] 1703. A target identifier for the virtual machine to be created is determined from the first identifier set.

[0128] 1704. Configuration information of the virtual machine to be created is generated according to a target key space corresponding to the target identifier.

[0129] 1705. A virtual machine with TKM function is created according to the configuration information of the virtual machine to be created.

[0130] In the embodiment, a physical TKM is arranged in a processor of a service device, which is a hardware module in the processor. The physical TKM has pre-registered multiple (denoted as M) key spaces. Multiple means 2 or more (including 2). The key spaces of the physical TKM have been registered before the creation of a virtual machine, so that when the virtual machine is created, only a selection needs to be made from the existing key spaces, avoiding the time loss of the work flow of the virtual machine creation to the physical TKM for applying a vTKM instance.

[0131] In the embodiment of the present application, the M key spaces can be registered to the physical TKM during the environment deployment stage of the service device or in the process of starting the virtual machine with TKM function by the user. Specifically, a TKM management environment can be prepared, it is ensured that the service device has deployed a processor supporting TKM and has installed a matching TKM driver, firmware and management tool, etc. Further, a unique identifier can be allocated to each key space, and these identifiers need to be one-to-one corresponding to the binding relationship of the subsequent virtual machine. Then, an independent security policy can be configured for each key space. The service device can call a TKM registration interface to submit a registration request to the physical TKM. The physical TKM hardware will verify the legality of the registration request, and create an isolated key storage area in the physical TKM for each key space. Thus, the registration of multiple key spaces is completed.

[0132] ​Based on the pre-registered multiple key space and the usage mode distribution view of key space, the user can initiate a virtual machine creation request to the service device. In some embodiments, the virtual machine creation request can include the identification of the usage mode (defined as the target usage mode) of the key space required by the virtual machine to be created, such as the name or number of the target usage mode, etc. Accordingly, in step 1701, the target usage mode of the key space required by the virtual machine to be created can be determined in response to the virtual machine creation request. For embodiments in which the virtual machine creation request includes the identification of the target usage mode, the target usage mode can be determined according to the identification of the usage mode carried by the virtual machine creation request. For embodiments in which the virtual machine creation request does not include the identification of the target usage mode, the default usage mode can be determined as the target usage mode.

[0133] Further, in step 1702, the first identification set W of the key space corresponding to the target usage mode can be determined according to the pre-set usage mode distribution view of the multiple key spaces. The first identification set W includes the identification of the key space corresponding to the target usage mode, which can be interpreted as the set of identifications of the key space with the target usage mode. The first identification set W can include one or more identifications. Multiple means two or more (including two). In some embodiments, the usage mode distribution view is implemented as the correspondence between the identifications of the multiple key spaces and the usage modes. Accordingly, the target usage mode can be queried in the correspondence, and the identifications corresponding to the target usage mode can be obtained from the correspondence. The set of these identifications is denoted as the first identification set W.

[0134] In other embodiments, the usage mode distribution view is implemented as the shared identification parameter value and the exclusive identification parameter value. In embodiments in which the shared mode is expanded in ascending order of the identification of the key space, and the exclusive mode is expanded in descending order of the identification of the key space, the shared identification parameter value is less than or equal to the exclusive identification parameter value. In embodiments in which the shared mode is expanded in descending order of the identification of the key space, and the exclusive mode is expanded in ascending order of the identification of the key space, the shared identification parameter value is greater than or equal to the exclusive identification parameter value.

[0135] In this embodiment, the target parameter value adapted to the target usage mode can be determined from the shared identification parameter value and the exclusive identification parameter value. Specifically, in the case that the target usage mode is the shared mode for different virtual machines, the shared identification parameter value (i.e., the value of index_share) can be determined as the target parameter value. In the case that the target usage mode is the exclusive mode, the exclusive identification parameter value (i.e., the value of index_exclusive) can be determined as the target parameter value.

[0136] Further, the first identifier set W corresponding to the target usage mode can be determined according to the target parameter value. In this embodiment, the target parameter value can be dynamically selected from the two preset parameters according to the target usage mode of the key space required by the virtual machine to be created, so that the target parameter can be selected on demand, and the key space corresponding to the usage mode can be determined. On the other hand, the key space corresponding to the target usage mode can be directly determined according to the target parameter value of the target usage mode, without traversing the usage mode of each key space, which helps to improve the efficiency of subsequent key space allocation. The first identifier set W is implemented as a fixed-length list, which has very low maintenance cost and occupies a small amount of storage resources.

[0137] In some embodiments, in the embodiment in which the sharing mode is expanded in ascending order of the identifier of the key space, and the exclusive mode is expanded in descending order of the identifier of the key space, if the sharing identifier parameter value is less than or equal to the exclusive identifier parameter value, then: if the target usage mode is the different virtual machine sharing mode, the first identifier set W corresponding to the different virtual machine sharing mode can be determined according to the identifiers of the plurality of key spaces that are less than or equal to the sharing identifier parameter value. Specifically, if the identifiers that are less than or equal to the sharing identifier parameter value contain the identifiers of the key spaces specified for other usage modes, the identifiers of the key spaces specified for other usage modes can be removed from the identifiers of the plurality of key spaces that are less than or equal to the sharing identifier parameter value, to obtain the first identifier set W corresponding to the different virtual machine sharing mode. If the identifiers that are less than or equal to the sharing identifier parameter value do not contain the identifiers of the key spaces specified for other usage modes, the identifiers of the plurality of key spaces that are less than or equal to the sharing identifier parameter value can be determined as the first identifier set W corresponding to the different virtual machine sharing mode.

[0138] Correspondingly, if the target usage mode is the exclusive mode, the first identifier set W corresponding to the exclusive mode can be determined according to the identifiers of the plurality of key spaces that are greater than or equal to the exclusive identifier parameter value. Specifically, if the identifiers that are greater than or equal to the exclusive identifier parameter value contain the identifiers of the key spaces specified for other usage modes, the identifiers of the key spaces specified for other usage modes can be removed from the identifiers of the plurality of key spaces that are greater than or equal to the exclusive identifier parameter value, to obtain the first identifier set W corresponding to the exclusive mode. If the identifiers that are greater than or equal to the exclusive identifier parameter value do not contain the identifiers of the key spaces specified for other usage modes, the identifiers of the plurality of key spaces that are greater than or equal to the exclusive identifier parameter value can be determined as the first identifier set W corresponding to the exclusive mode.

[0139] In the embodiment, since the different virtual machine sharing mode is extended in ascending order of the identifiers of the key spaces and the exclusive mode is extended in descending order of the identifiers of the key spaces, the identifier less than or equal to the sharing identifier parameter value is directly determined as the identifier of the key space in the different virtual machine sharing mode and the identifier greater than or equal to the exclusive identifier parameter value is directly determined as the identifier of the key space in the exclusive mode without considering the key spaces specified as other use modes (such as the physical machine and virtual machine sharing mode). The first identifier set corresponding to the target use mode is determined in this way, which is simple and efficient in operation and has high efficiency.

[0140] In some other embodiments, in the embodiment in which the different virtual machine sharing mode is extended in descending order of the identifiers of the key spaces and the exclusive mode is extended in ascending order of the identifiers of the key spaces, the sharing identifier parameter value is greater than or equal to the exclusive identifier parameter value. Accordingly, the aforementioned determining the first identifier set W corresponding to the target use mode according to the target parameter value can be implemented as follows: if the target use mode is the different virtual machine sharing mode, the first identifier set W corresponding to the different virtual machine sharing mode can be determined according to the identifiers of the key spaces greater than or equal to the sharing identifier parameter value. Specifically, if the identifiers greater than or equal to the sharing identifier parameter value contain the identifiers of the key spaces specified as other use modes, the identifiers of the key spaces specified as other use modes can be removed from the identifiers of the key spaces greater than or equal to the sharing identifier parameter value to obtain the first identifier set W corresponding to the different virtual machine sharing mode. If the identifiers greater than or equal to the sharing identifier parameter value do not contain the identifiers of the key spaces specified as other use modes, the identifiers of the key spaces greater than or equal to the sharing identifier parameter value can be determined as the first identifier set W corresponding to the different virtual machine sharing mode.

[0141] Accordingly, if the target use mode is the exclusive mode, the first identifier set W corresponding to the exclusive mode can be determined according to the identifiers of the key spaces less than or equal to the exclusive identifier parameter value. Specifically, if the identifiers less than or equal to the exclusive identifier parameter value contain the identifiers of the key spaces specified as other use modes, the identifiers of the key spaces specified as other use modes can be removed from the identifiers of the key spaces less than or equal to the exclusive identifier parameter value to obtain the first identifier set W corresponding to the exclusive mode. If the identifiers less than or equal to the exclusive identifier parameter value do not contain the identifiers of the key spaces specified as other use modes, the identifiers of the key spaces less than or equal to the exclusive identifier parameter value can be determined as the first identifier set W corresponding to the exclusive mode.

[0142] In the embodiment, since the different virtual machine sharing mode is expanded in descending order of the identifier of the key space, and the exclusive mode is expanded in ascending order of the identifier of the key space, the identifier greater than or equal to the sharing identifier parameter value is directly determined as the identifier of the key space in the different virtual machine sharing mode, and the identifier less than or equal to the exclusive identifier parameter value is directly determined as the identifier of the key space in the exclusive mode, without considering the key space specified as other use modes (such as the physical machine and virtual machine sharing mode). The first identifier set corresponding to the target use mode is determined in the above manner, and the operation is simple and efficient, and has high efficiency.

[0143] In some embodiments of the present application, the target use mode can be the virtual machine and physical machine sharing mode. The manufacturer of the processor pre-specifies the identifier of the key space corresponding to the virtual machine and physical machine sharing mode. The identifier of the key space corresponding to the physical machine sharing mode can be one or more. More refers to more than two and less than M. Accordingly, the identifier of the key space pre-specified as the virtual machine and physical machine sharing mode can be determined as the first identifier set W corresponding to the virtual machine and physical machine sharing mode.

[0144] After the first identifier set corresponding to the target use mode is determined, in step 1703, the target identifier can be determined for the virtual machine to be created from the first identifier set W. Wherein, the target use mode is different, and the implementation manner of determining the target identifier for the virtual machine to be created from the first identifier set W is different. The specific implementation manner of step 1703 will be exemplarily described below in combination with the target use mode being the exclusive mode, the different virtual machine sharing mode and the virtual machine and physical machine sharing mode.

[0145] Embodiment 1: The target use mode is the exclusive mode.

[0146] The target use mode is the exclusive mode, that is, the virtual machine to be created exclusively uses a key space, and then an unoccupied key space needs to be selected from the key space in the exclusive mode. Specifically, the second identifier set A of the currently idle key space can be determined from the first identifier set corresponding to the exclusive mode.

[0147] In some embodiments, accordingly, the identifier list of the unoccupied (i.e. idle) key space can be maintained for the exclusive mode. Whenever a key space is allocated, the identifier of the key space is deleted from the identifier list. Based on this, step 1703 can be implemented as: determining the target identifier for the virtual machine to be created from the identifier list of the idle key space of the exclusive mode maintained.

[0148] In some embodiments, the third identifier set U of the currently occupied key spaces corresponding to the target usage mode is obtained. Specifically, after obtaining the full identifier set W of the key spaces in the exclusive mode of the service device and the third identifier set U of the currently occupied key spaces, the second identifier set A of the currently idle key spaces can be determined according to the first identifier set W and the third identifier set U. Wherein, A = W-U, that is, for any identifier in the first identifier set W , if exists in the first identifier set, but does not exist in the second identifier set U, then is an identifier of a currently idle key space. Using the same method, the identifiers of all currently idle key spaces corresponding to the exclusive mode can be determined, and the second identifier set A is obtained.

[0149] In some embodiments, the identifier list of the used key spaces can also be maintained for the exclusive mode (i.e., the target usage mode), and the identifier list is used to store the identifiers of the used key spaces corresponding to the exclusive mode. Accordingly, the foregoing step 1703 can be implemented as: obtaining the identifier set of the used key spaces stored in the identifier list of the used key spaces corresponding to the exclusive mode (i.e., the target usage mode) maintained by the service device as the third identifier set U of the currently occupied key spaces.

[0150] Wherein, the identifier set of the used key spaces is a dynamic identifier list, and whenever a virtual machine in the exclusive mode is created, the identifier of the key space occupied by the currently created virtual machine is updated to the identifier set of the used key spaces. Moreover, whenever a virtual machine is destroyed, the key space occupied by the destroyed virtual machine is released, and accordingly, the identifier of the key space occupied by the destroyed virtual machine needs to be deleted from the identifier set of the used key spaces. This implementation can quickly check the used identifier set when a new virtual machine requests to be created, to determine which key spaces are still available, without the need to scan the usage of the entire system in real time, which can improve the allocation speed of the key space resources. However, this implementation needs to store the usage of the key space resources and also needs to maintain and update the usage of the key space resources, which occupies a larger storage space and has a certain processing overhead for maintaining and updating the usage of the key space resources, which will reduce the performance of the virtual machine running the application or service.

[0151] In order to reduce the processing overhead of maintaining and updating the usage of the key space resource, in some embodiments, instead of maintaining the used key space identifier set, a third identifier set U of the key space currently occupied by the exclusive mode (i.e., the target usage mode) can be obtained in real time when a virtual machine creation request arrives. Specifically, the identifier set U0 of the key space currently occupied can be obtained in response to the virtual machine creation request through a virtualization management command. The virtualization management command is a command line used to manage virtual machine resources in a virtualization environment, through which resource information occupied by a virtual machine can be obtained. In this embodiment, the information of the key space occupied by the virtual machine is obtained through the virtualization management command. The virtualization management command can be a virsh command. Virsh is a command line tool for interacting with libvirt, which is a software layer for managing virtualization on a machine. Virsh provides a series of commands to manage virtual machine, network, storage pool and other virtualization resources. In this embodiment, the identifier set U0 of the key space currently occupied is obtained through the virtualization management command, without the need to maintain and update the usage of the key space resource, which can save the processing overhead of maintaining and updating the usage of the key space resource, reduce the code complexity, and also save the storage space for storing the usage of the key space resource.

[0152] In some embodiments, the currently running virtual machines on the service device can be determined through a list command (such as a virsh list command) in the virtualization management command. The virsh list command is a command for displaying the status of currently running virtual machines (VMs). It lists all running virtual machines and provides their basic information, such as identifier information (ID), name and current state, etc.

[0153] Further, the configuration information of the currently running virtual machine can be obtained through a configuration file export command (such as a virsh dumpxml command) in the virtualization management command. The virsh dumpxml command is a command for exporting the configuration file of a virtual machine. This command can view and backup the detailed configuration information of a virtual machine, including hardware specifications, network settings, disk information, etc. In this embodiment, since the virtual machine is configured with a key space resource, the virsh dumpxml command can also view the key space resource information of the virtual machine.

[0154] Further, the identification set of the key space used by the currently running virtual machine can be obtained from the configuration information of the currently running virtual machine as the identification set U0. In this embodiment, the identification set U0 of the currently occupied key space is obtained through a virtualization management command (such as a virsh list command and a virsh dumpxml command), without the need to maintain and update the use of the key space resource, thereby saving the processing overhead of maintaining and updating the use of the key space resource, and also saving the storage space for storing the use of the key space resource.

[0155] After the identification set U0 of the currently occupied key space is determined, the identification of the key space of the target use mode can be determined from the identification set U0. Specifically, the identification belonging to the first identification set W can be obtained from the identification set U0 as the identification of the key space of the target use mode. Further, the determined identification of the key space of the target use mode can be determined as the third identification set U of the currently occupied key space corresponding to the exclusive mode.

[0156] Further, the second identification set A of the currently idle key space corresponding to the exclusive mode can be determined according to the first identification set W and the third identification set U. Specifically, the set of identifications not belonging to the third identification set U can be obtained from the first identification set W to obtain the second identification set A of the currently idle key space corresponding to the exclusive mode. Since the second identification set A stores the identification of the currently idle key space, the target identification for the to-be-created virtual machine can be determined from the second identification set A. Since the second identification set A stores the identification of the currently idle key space, the target identification for the to-be-created virtual machine is directly selected from the second identification set A, and the key space corresponding to the target identification is necessarily idle key space, without the need to traverse and query all key spaces whether they are occupied before allocation, thereby improving the key space resource allocation efficiency and further helping to improve the virtual machine creation efficiency.

[0157] In the embodiments of the present application, the specific implementation of determining the target identification for the to-be-created virtual machine from the second identification set A is not limited. In some embodiments, the second identification set A can be sorted, and the largest identification or the smallest identification in the sorted second identification set can be selected as the target identification. The second identification set A can be sorted in ascending order or in descending order. Alternatively, the identification at a set position can be selected from the second identification set A as the target identification. For example, the identification at the first position or the last position can be selected as the target identification. Alternatively, the identification at a set other position can be selected as the target identification, and the like.

[0158] The foregoing manner of sequentially selecting the identifier or the identifier at the set position simplifies the logic and simplifies the allocation logic. Since the identifier itself is an ordered identifier, selecting the minimum identifier, the maximum identifier, or the identifier at the set position means that an unused key space can be quickly located without the need for complex algorithms to determine which key space is suitable for allocation. However, the manner of sequentially selecting the identifier requires a certain processing overhead for sorting the identifiers of the second identifier set A. On the other hand, when multiple concurrent virtual machine creation requests arrive, there is a key space resource conflict.

[0159] Specifically, assuming that two concurrent virtual machine creation requests (i.e., virtual machine creation requests 1 and 2) arrive at the same time, the service device allocates, in response to the virtual machine creation request 1, a key space corresponding to the minimum identifier (assuming to be ) of the second identifier set A to the virtual machine corresponding to the virtual machine creation request 1; for the virtual machine creation request 2, the minimum identifier of the second identifier set A obtained by the service device is also , which will cause the virtual machines corresponding to the virtual machine creation requests 1 and 2 to be allocated to the same key space, causing the two to contend for the same key space, resulting in a key space resource conflict, and further causing the virtual machine creation to fail.

[0160] Similarly, the manner of selecting the identifier at the set position will also cause a key space resource conflict when multiple concurrent virtual machine creation requests arrive. Assuming that two concurrent virtual machine creation requests (i.e., virtual machine creation requests 1 and 2) arrive at the same time, the service device allocates, in response to the virtual machine creation request 1, a key space corresponding to the identifier at the first position (assuming to be ) of the second identifier set A to the virtual machine corresponding to the virtual machine creation request 1; for the virtual machine creation request 2, the identifier at the first position of the second identifier set A obtained by the service device is also , which will cause the virtual machines corresponding to the virtual machine creation requests 1 and 2 to be allocated to the same key space, causing the two to contend for the same key space, resulting in a key space resource conflict, and further causing the virtual machine creation to fail.

[0161] To solve the key space resource conflict problem caused by the sequential selection of the identification and the selection of the identification at the set position, in some embodiments, the key space resource conflict problem can be solved by locking. Specifically, for any virtual machine creation request X in the concurrent multiple virtual machine creation requests, before responding to the virtual machine creation request X, the identification list of the used key space maintained by the service device is locked; then, in response to the virtual machine creation request X, a third identification set U of the currently occupied key space is obtained from the identification list of the used key space maintained by the service device; then, according to the first identification set W corresponding to the exclusive mode and the third identification set U corresponding to the exclusive mode, a second identification set A of the currently idle key space corresponding to the exclusive mode is determined, and the minimum identification, the maximum identification or the identification at the set position is selected from the second identification set A as a target identification. Then, the key space corresponding to the target identification is allocated to the virtual machine requested to be created by the virtual machine creation request X. After the virtual machine requested to be created by the virtual machine creation request X is requested to be created, the aforementioned target identification (minimum identification, maximum identification or identification at the set position) is deleted from the identification list, and the lock of the identification list is released. Then, another virtual machine creation request in the concurrent multiple virtual machine creation requests can be locked again for the maintained identification list of the used key space, and the above steps are repeated in turn until the virtual machines requested to be created by the concurrent multiple virtual machine creation requests are created. This way of locking the identification list of the used key space maintained by the service device can avoid the key space resource conflict caused by the concurrent multiple virtual machine creation requests competing for the key space resources. However, this way changes the parallel allocation of the key space resources for the concurrent multiple virtual machine creation requests into a serial execution, which is low in key space resource allocation efficiency and increases the creation time of the virtual machines. On the other hand, the locking and releasing logic is complex, the code complexity is high, and the computing resource overhead of the service device is large.

[0162] To solve the problem caused by the above locking and releasing, in other embodiments, a random number selection mechanism is introduced. Specifically, a random number Index greater than or equal to 0 and less than or equal to the length of the second identification set A can be generated. That is, Index ∈ [0, len(A)]. len(A) represents the length of the second identification set A, that is, the total number of identifications in the second identification set A.

[0163] In some embodiments, an internal system variable of the operating system of the service device can be obtained as a random seed, and a random number greater than or equal to 0 and less than or equal to the total number of identifiers in the second identifier set A can be generated with the total number of identifiers in the second identifier set A as a parameter. Specifically, the internal variable of the operating system can be input as a random seed into a pseudo-random number generation algorithm to initialize the internal state of the random number generator to obtain an initialized random number generator. Further, the initialized random number generator can be invoked to request the generation of a random integer in the interval [0, len(A)]. The output of the random number generator is the final random number generated in this embodiment. Using the internal variable of the operating system as a random seed does not require additional library support, and the random number generation speed is relatively fast. However, due to the lower randomness of the internal variable of the operating system, the randomness of the generated random number is also relatively low.

[0164] In other embodiments, a system random number can be obtained as a random seed, and a random number greater than or equal to 0 and less than or equal to the total number of identifiers in the second identifier set A can be generated with the total number of identifiers in the second identifier set A as a parameter. Specifically, the system random number can be input as a random seed into a pseudo-random number generation algorithm to initialize the internal state of the random number generator to obtain an initialized random number generator. Further, the initialized random number generator can be invoked to request the generation of a random integer in the interval [0, len(A)]. The output of the random number generator is the final random number generated in this embodiment. Since the system random number is a random number based on the system entropy pool, it has relatively high randomness. The system entropy pool refers to a mechanism in the operating system for generating random numbers. The entropy pool collects data (i.e., "entropy") from various uncertain sources and uses these data to generate high-quality random numbers. Therefore, the system random number as a random seed has strong randomness. However, this random number generation method requires access to the system entropy pool, and the generation speed is relatively slow.

[0165] In yet other embodiments, the current timestamp can be used as a random seed, and a random number greater than or equal to 0 and less than or equal to the length of the second identifier set A can be generated with the length of the second identifier set A as a parameter. Since the current timestamp is unique, using the current timestamp as a random seed can ensure that the generated random number is different each time, i.e., the generated random number has strong randomness. On the other hand, the current timestamp is the system timestamp of the service device, which can be easily and quickly obtained, and thus the random number generation speed is relatively fast.

[0166] Specifically, the current timestamp can be input as a random seed into a pseudo-random number generation algorithm for initializing the internal state of the random number generator to obtain an initialized random number generator. This step ensures that the subsequent generated random number is based on the current timestamp, with good randomness and unpredictability. Further, the initialized random number generator can be called to request the generation of a random integer in the interval [0, len(A)]. The output of the random number generator is the final generated random number in this embodiment.

[0167] The random number generation method shown in the foregoing embodiments is only exemplary and does not constitute a limitation. After generating a random number Index greater than or equal to 0 and less than or equal to the length of the second identifier set, the target identifier corresponding to the random number Index in the second identifier set A can be determined. Specifically, the identifier in the second identifier set A with a bit order equal to that of the random number Index can be taken as the target identifier. Assuming that the random number Index is equal to 2, the second identifier in the second identifier set A is taken as the target identifier. Further, the target key space corresponding to the target identifier can be determined as the target key space allocated to the virtual machine to be created.

[0168] This embodiment can reduce the key space resource conflict of multiple virtual machine creation requests by generating a random number Index greater than or equal to 0 and less than or equal to the total number of identifiers in the second identifier set for key space resource selection. Moreover, this embodiment randomly selects a value in the length interval of the available resource window A (i.e., the second identifier set A of the free key space), as long as the randomly selected values are different, the corresponding key space resources must be unoccupied and allocable. Without the need for other data structures and overheads to maintain the context state before and after the allocation of the key space resource to be allocated, the locking and unlocking operations of the atomic operation are avoided, the code logic complexity is reduced, the key space resource allocation efficiency is improved, and the virtual machine creation efficiency is further improved. Although the random number cannot guarantee 100% no conflict of the same resource, the conflict probability can be tolerated in actual applications.

[0169] In the case that the usage mode distribution view of the key space remains unchanged, the currently occupied key space resource corresponding to the exclusive mode is updated with the startup and destruction of the previous virtual machine each time a virtual machine with TKM function in exclusive mode is created. However, the available resource window (i.e. the second identifier set A of the current idle key space corresponding to the exclusive mode) is always a subset of the total resource window W (i.e. the first identifier set W of the total key space corresponding to the exclusive mode) corresponding to the exclusive mode. The available resource window (i.e. the second identifier set A of the current idle key space corresponding to the exclusive mode) is like sliding in a box with length W. Therefore, the available resource window (i.e. the second identifier set A of the current idle key space corresponding to the exclusive mode) is a sliding window in a broad sense. The random selection of the available target identifier in the available resource window through the random number can ensure that there is no conflict with the key space used by the exclusive mode. Therefore, the management and distribution mechanism of the key space can be called the slide window random selection (SWRS) mechanism, i.e. as shown in Figure 18a “vTKM-SWRS”, if the target usage mode is the exclusive mode, the SWRS mechanism can be used to determine the target identifier of the key space for the virtual machine to be created.

[0170] The foregoing embodiment exemplarily gives a specific implementation manner of determining the identifier of the key space for the virtual machine to be created in the case that the target usage mode of the key space required by the virtual machine to be created is the exclusive mode, but does not constitute a limitation.

[0171] Embodiment 2: The target usage mode is the different virtual machine sharing mode.

[0172] The target usage mode of the key space required by the virtual machine to be created is a different virtual machine sharing mode, i.e., different virtual machines share the same key space. In this mode, the virtual machine to be created can join an occupied key space corresponding to the different virtual machine sharing mode, or use a new key space corresponding to the different virtual machine sharing mode as the first virtual machine of a virtual machine group corresponding to the key space, i.e., the virtual machine to be created is specified not to join the occupied key space. The virtual machine creation request can include an identifier of the target usage mode required by the virtual machine to be created. In this embodiment, the identifier is an identifier of the different virtual machine sharing mode. The virtual machine creation request further includes representation information specifying that the virtual machine to be created joins the occupied key space or representation information specifying that the virtual machine to be created does not join the occupied key space. If the virtual machine creation request includes the representation information specifying that the virtual machine to be created does not join the occupied key space, i.e., the target usage mode is the different virtual machine sharing mode and the virtual machine to be created is specified not to join the occupied key space, the first identifier set W of the key space corresponding to the different virtual machine sharing mode is determined in the foregoing step 1702.

[0173] Correspondingly, step 1703 can be implemented as: determining the second identifier set A of the currently idle key space from the first identifier set W of the key space corresponding to the different virtual machine sharing mode. The specific implementation manner of determining the second identifier set A of the currently idle key space from the first identifier set W of the key space corresponding to the different virtual machine sharing mode can refer to the related content of determining the second identifier set of the currently idle key space from the first identifier set of the key space corresponding to the exclusive mode. The difference is that in the specific implementation manner of determining the second identifier set of the currently idle key space from the first identifier set of the key space corresponding to the exclusive mode, the determined identifiers or identifier sets of various key spaces are identifiers or identifier sets of the key space of the exclusive mode; in this embodiment, the determined identifiers or identifier sets of various key spaces are identifiers or identifier sets of the key space of the different virtual machine sharing mode.

[0174] After determining the second identifier set A of the currently idle key space corresponding to the different virtual machine sharing mode, a target identifier can be determined for the virtual machine to be created from the second identifier set A. The specific implementation manner and technical effects of determining the target identifier for the virtual machine to be created from the second identifier set A can refer to the related content of determining the target identifier for the virtual machine to be created from the second identifier set A of the key space corresponding to the exclusive mode, which will not be described here again. For example, as shown in FIG. 7, the second identifier set A of the currently idle key space corresponding to the different virtual machine sharing mode includes identifiers 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10. The target identifier for the virtual machine to be created is determined as identifier 1 from the second identifier set A. Figure 18aAs shown, if the target usage mode is the different virtual machines sharing mode, and the joining occupied key space is not specified, the SWRS mechanism can be used to determine the target identification for the virtual machine to be created. For details, refer to the foregoing content of determining the target identification for the virtual machine in the exclusive mode using the SWRS mechanism, which will not be described here.

[0175] In this embodiment and the foregoing embodiment where the target usage mode is the exclusive mode, the virtualization management command is used to determine the running state of each virtual machine and the VID usage of the key space occupied thereby. When a virtual machine is started, its workflow automatically detects the VID resources occupied by all the running virtual machines on the current physical host. For the virtual machine instances that have been stopped or powered off, the starting workflow does not reclaim the VID resources previously occupied thereby, because these resources are automatically released at the same time when the virtual machine instances die. This mechanism ensures that the VID resources occupied by the historically powered-off virtual machines can be re-joined into the available resource pool for allocation by the subsequent starting workflow, thereby realizing the dynamic rolling update of the available VID resources without additional processing logic or cost consumption. Specifically, when a virtual machine terminates, the VID used thereby is automatically returned to the available resource pool, so that it can be re-allocated when needed next, thereby improving the resource utilization and the overall flexibility of the system.

[0176] In some other embodiments, if the virtual machine creation request includes the representation information specifying the joining of the occupied key space, i.e., the target usage mode is the different virtual machines sharing mode and the joining of the occupied key space is specified, the first identification set W of the key space corresponding to the different virtual machines sharing mode is determined in the foregoing step 1702. Accordingly, the foregoing step 1703 can be implemented as: determining the third identification set of the currently occupied key space corresponding to the different virtual machines sharing mode (i.e., the target usage mode). The first identification set W includes the third identification set. For details of determining the third identification set of the currently occupied key space corresponding to the different virtual machines sharing mode (i.e., the target usage mode), refer to the foregoing content of determining the third identification set of the currently occupied key space corresponding to the exclusive mode and the technical effects thereof, which will not be described here. The difference is that the foregoing determination of the identification or identification set of the currently occupied key space corresponding to the exclusive mode uses the identification or identification set of the key space corresponding to the exclusive mode, and the determination in this embodiment uses the identification or identification set of the key space corresponding to the different virtual machines sharing mode, but the technical solutions and implementation manners are the same.

[0177] Further, a target identifier for the to-be-created virtual machine can be determined from the third identifier set corresponding to the current occupied key space of different virtual machine sharing modes (i.e., target usage modes). In this embodiment, the newly created virtual machine is not assigned a new key space, but joins an already existing key space, and the sharing access capability of the same key space among multiple virtual machines can be implemented. This mechanism of sharing the same key space among multiple virtual machines can support dynamic discovery and joining of an existing shared key space at runtime, and enhances flexibility and scalability.

[0178] In some embodiments, the virtual machine creation request specifies a key space to be joined, i.e., the virtual machine creation request contains a specified identifier (VID). As shown in FIG. 4A, if the virtual machine creation request specifies a VID, the specified identifier in the third identifier set corresponding to the current occupied key space of different virtual machine sharing modes (i.e., target usage modes) can be determined as the target identifier assigned to the to-be-created virtual machine, as shown in "select the specified VID". Figure 18a Figure 18a The implementation provides a flexible access mechanism for explicitly specifying a key space, allows a user to explicitly specify a VID when creating a virtual machine, and enhances the flexibility of binding between a virtual machine and a key space.

[0179] In other embodiments, the virtual machine creation request does not specify a key space to be joined, i.e., the virtual machine creation request does not contain a specified identifier (VID). Accordingly, as shown in FIG. 4B, if the virtual machine creation request does not specify a VID, an identifier can be randomly determined from the third identifier set corresponding to the current occupied key space of different virtual machine sharing modes (i.e., target usage modes) as the target identifier assigned to the to-be-created virtual machine, as shown in "randomly select a VID from the used VIDs". Figure 18a Figure 18a This implementation is simple, and only needs to randomly select an identifier from the third identifier set, and has small computational overhead. Alternatively, an identifier with the least reference times can be determined from the third identifier set corresponding to the current occupied key space of different virtual machine sharing modes (i.e., target usage modes) as the target identifier. The identifier corresponds to a record of reference times, and each time a key space corresponding to the identifier is assigned to a virtual machine, the reference times of the identifier are increased by 1. Accordingly, the reference times of the identifier refer to the number of virtual machines currently occupying the key space corresponding to the identifier. This implementation preferentially selects a VID of a less used key space, avoids resource skew, and helps to achieve load balancing. On the other hand, preferentially selecting a VID of a less used key space can avoid overload of some key spaces, and helps to improve overall key space utilization.

[0180] Embodiment 3: The target usage mode is a virtual machine and physical machine sharing mode. ​​

[0181] In another embodiment, as shown in FIG. 6, the target usage mode is the virtual machine sharing mode with the physical machine. The key space of the virtual machine sharing mode with the physical machine can be one or more. More than one means 2 or more (including 2). For the embodiment in which the key space of the virtual machine sharing mode with the physical machine is one, the identification in the first identification set corresponding to the virtual machine sharing mode with the physical machine is one. In this case, the identification in the first identification set corresponding to the virtual machine sharing mode with the physical machine can be determined as the target identification. For example, as shown in FIG. 6, the identification in the first identification set corresponding to the virtual machine sharing mode with the physical machine is VID=0. In this case, VID=0 is selected as the target identification of the virtual machine to be created. Figure 18a Figure 18a For the embodiment in which the key space of the virtual machine sharing mode with the physical machine is more than one, the identification in the first identification set corresponding to the virtual machine sharing mode with the physical machine is more than one. In this case, one identification in the first identification set corresponding to the virtual machine sharing mode with the physical machine (i.e., the target usage mode) can be randomly selected as the target identification. This method is simple and has small computational overhead, as it only requires randomly selecting one identification from the third identification set. Alternatively, the identification with the least reference times in the first identification set corresponding to the virtual machine sharing mode with the physical machine (i.e., the target usage mode) can be determined as the target identification. The reference times of an identification refer to the number of virtual machines currently occupying the key space corresponding to the identification. This implementation method preferentially selects a VID with a less used key space, thereby avoiding resource skew and helping to achieve load balancing. On the other hand, preferentially selecting a VID with a less used key space can avoid overloading some key spaces and help to improve overall key space utilization.

[0182] The foregoing embodiments exemplarily provide specific implementation methods for determining the target identification of the key space for the virtual machine to be created in various usage modes. After the target identification is determined, the key space corresponding to the target identification can be determined as the target key space allocated to the virtual machine to be created. Accordingly, in step 1704, the configuration information of the virtual machine to be created can be generated according to the target key space corresponding to the target identification. Specifically, the resource path of the target key space is converted into a format of a virtual machine configuration file, such as an XML format, to obtain a key space resource configuration file of the virtual machine to be created. Then, the key space resource configuration file of the virtual machine to be created is added to the initial configuration file of the virtual machine to be created to obtain the configuration file of the virtual machine to be created.

[0183] The foregoing embodiments exemplarily provide specific implementation methods for determining the target identification of the key space for the virtual machine to be created in various usage modes. After the target identification is determined, the key space corresponding to the target identification can be determined as the target key space allocated to the virtual machine to be created. Accordingly, in step 1704, the configuration information of the virtual machine to be created can be generated according to the target key space corresponding to the target identification. Specifically, the resource path of the target key space is converted into a format of a virtual machine configuration file, such as an XML format, to obtain a key space resource configuration file of the virtual machine to be created. Then, the key space resource configuration file of the virtual machine to be created is added to the initial configuration file of the virtual machine to be created to obtain the configuration file of the virtual machine to be created.

[0184] Specifically, as shown in FIG. 6, the target key space corresponding to the target identification is VID=0. In this case, the resource path of VID=0 is converted into an XML format to obtain a key space resource configuration file of the virtual machine to be created. Then, the key space resource configuration file of the virtual machine to be created is added to the initial configuration file of the virtual machine to be created to obtain the configuration file of the virtual machine to be created. Figure 18a ​As shown in the "conversion configuration XML file", the resource path of the target key space can be converted into the format (such as XML format) of the virtual machine configuration file to obtain the key space resource configuration file of the to-be-created virtual machine, such as a key space XML file. Further, the key space resource configuration file of the to-be-created virtual machine can be added to the initial configuration file of the to-be-created virtual machine by the prepareVM component to obtain the configuration file of the to-be-created virtual machine. The initial configuration file of the to-be-created virtual machine can be a domain configuration file, such as a domain XML (Domain XML) file, obtained by the prepareVM component from the parameters issued by the management component to the prepareVM component. The initial configuration file contains the configuration information of the virtual machine, including but not limited to hardware configuration information such as processor, memory, disk, network interface, and driver, and startup parameters. Figure 18a As shown in the "prepareVM component", the prepareVM component adds the key space resource configuration file of the to-be-created virtual machine to the initial configuration file of the to-be-created virtual machine to obtain a domain XML (Domain XML) file, which is the configuration file of the to-be-created virtual machine. The configuration file contains the key space resource configuration information of the virtual machine and other resource configuration information. The other resource configuration information refers to the configuration information of other resources required by the virtual machine in addition to the key space, including but not limited to hardware configuration information such as processor, memory, disk, network interface, and driver, and startup parameters.

[0185] Further, since the configuration information of the to-be-created virtual machine contains the resource information of the key space to which the to-be-created virtual machine is assigned, in step 1705, the virtual machine with TKM function can be created according to the configuration information of the to-be-created virtual machine.

[0186] Specifically, the virtual machine manager (VMM) can be used to determine the resources corresponding to the target key space according to the resource path of the target key space, and then create a virtual machine with TKM function according to the resources corresponding to the target key space and other resource configuration information. The other resource configuration information includes but is not limited to hardware configuration information such as processor, memory, disk, network interface, and driver, and startup parameters.

[0187] The VMM can include a QEMU module and a KVM module. Accordingly, a virtual machine instance can be created by the QEMU module, and the information in the configuration file of the to-be-created virtual machine can be loaded. The QEMU module can use the interface provided by the KVM module to initialize the resources of the virtual machine, such as processor, memory, storage, and target key space, according to the target key space and other resource configuration information, to obtain a virtual machine with TKM function.

[0188] In the embodiments of the present application, the physical TKM in the processor can provide a plurality of key spaces, and is preset with a usage mode allocation view of each key space. When a virtual machine creation request arrives, a target identifier of the virtual machine to be created can be determined from an identifier set of a key space corresponding to a target usage mode required by the virtual machine to be created according to the usage mode allocation view of the key space, and the key space corresponding to the target identifier is the key space allocated to the virtual machine to be created, thereby achieving effective management of key space resources. Through the pre-set usage mode allocation view, pre-planning and registration of key spaces on the physical machine are completed. When the virtual machine is created, only the identifier of the appropriate key space needs to be automatically selected according to the target usage mode, and there is no need to dynamically apply for a new vTKM instance to the physical TKM, thereby effectively avoiding the delay caused by waiting for TKM hardware resource allocation during the virtual machine creation process, and helping to improve the creation efficiency of the virtual machine.

[0189] It is worth noting that for a virtual machine creation workflow, if the usage mode allocation view of the key space does not change during the execution of a virtual machine creation workflow, the virtual machine creation process with TKM function provided by the embodiments of the present application can be directly executed. In some embodiments, the virtual machine creation workflow is accompanied by a change in the usage mode allocation view, and therefore the usage mode allocation view configuration process needs to be executed first, and then the virtual machine creation process with TKM function provided by the embodiments of the present application is executed. Specifically, before responding to the virtual machine creation request (i.e., before step 1701), the service device can obtain a first configuration value of the shared identifier parameter and a second configuration value of the exclusive identifier parameter. It can be determined whether the first configuration value and the second configuration value satisfy the parameter update condition.

[0190] In the embodiments of the present application, the specific implementation form of the parameter update condition is not limited. In some embodiments, the parameter update condition includes at least one of the following conditions: (1) the first configuration value and the second configuration value belong to a set identifier range; (2) the size relationship between the first configuration value and the second configuration value satisfies a set size relationship condition; (3) in the identifier set corresponding to each usage mode divided by the first configuration value and the second configuration value, there is no identifier occupied by the virtual machine of the other usage mode.

[0191] The set identification range is determined by the total number M of the key space provided by the physical TKM. The set identification range is generally (0, M), that is, the first configuration value and the second configuration value should belong to (0, M). For the shared key space, the identification can be expanded in ascending order from the small number of the identification of the key space, and for the exclusive key space, the identification can be expanded in descending order from the large number of the identification of the key space. For the shared key space, the identification can be expanded in descending order from the large number of the identification of the key space, and for the exclusive key space, the identification can be expanded in ascending order from the small number of the identification of the key space. The set size relationship condition is that the first configuration value is less than or equal to the second configuration value.

[0192] Based on the above parameter update condition, determining whether the first configuration value and the second configuration value satisfy the corresponding parameter update condition can include performing at least one of the following determination operations:

[0193] Determination operation 1 (i.e. Figure 18b Determination operation 1): Determine whether the shared identification parameter and the exclusive identification parameter are changed, that is, whether the first configuration value is the same as the shared parameter value of the currently used space allocation view, and whether the second configuration value is the same as the exclusive parameter value of the currently used space allocation view. If the first configuration value is different from the shared parameter value of the currently used space allocation view, and / or the second configuration value is different from the exclusive parameter value of the currently used space allocation view, it is determined that the shared identification parameter and the exclusive identification parameter are changed. In Figure 18b , the original parameter value represents the exclusive parameter value of the currently used space allocation view and the shared parameter value of the currently used space allocation view. The new parameter value refers to the first configuration value and the second configuration value. The determination operation 1 can identify the case of “configuration unchanged”; if the new and old configurations are consistent, no update action needs to be performed, and invalid operation can be avoided.

[0194] Determination operation 2 (i.e. Figure 18b Determination operation 2 in the above): Determine whether the first configuration value and the second configuration value belong to the set identification range.

[0195] Determination operation 3 (i.e. Figure 18b Determination operation 3 in the above): Determine whether the size relationship between the first configuration value and the second configuration value satisfies the set size relationship condition.

[0196] Among them, the determination operation 2 and the determination operation 3 can ensure that the new configuration value is within the legal range supported by the physical TKM, and conforms to the currently used VID allocation strategy (ascending / descending expansion direction), to prevent system abnormalities caused by parameter out-of-range or logical errors.

[0197] Determination operation 4 (i.e. Figure 18bIn the judgment operation 4): Based on the first configuration value and the second configuration value, determine the candidate identifier set corresponding to each of the multiple usage modes; for any usage mode X, determine whether the usage mode corresponding to the currently occupied identifier in the candidate identifier set of usage mode X is all usage mode X.

[0198] The judgment operation 4 ensures that there is no cross-occupation between the VID sets covered by different usage modes under the new configuration, that is, a VID should not belong to both shared and exclusive usage modes at the same time; it also ensures that existing virtual machines will not lose access to their bound key space due to parameter updates.

[0199] It should be noted that judgment operations 1-4 can be performed individually or in combination. When judgment operations 1-3 can be performed individually, if the result of the performed judgment operation is yes, it is determined that the first configuration value and the second configuration value meet the corresponding parameter update conditions. If the result of the performed judgment operation is no, it is determined that the first configuration value and the second configuration value do not meet the corresponding parameter update conditions.

[0200] When multiple judgment operations are implemented in combination, if the results of multiple judgment operations are yes, then the first configuration value and the second configuration value are determined to meet the corresponding parameter update conditions. If the results of multiple judgment operations are no, then the first configuration value and the second configuration value are determined not to meet the corresponding parameter update conditions. For example, if... Figure 18b As shown, if judgment operations 1-4 are implemented in combination, then all judgment results of judgment operations 1-4 are "yes," meaning that the shared identifier parameter and the exclusive identifier parameter have changed, the first configuration value and the second configuration value belong to the set identifier range, the size relationship between the first configuration value and the second configuration value satisfies the set size relationship condition, and all currently occupied identifiers in the candidate identifier set for any usage mode X correspond to usage mode X, then it is determined that the first configuration value and the second configuration value satisfy the corresponding parameter update conditions. If the judgment results of judgment operations 1-4 are all "no," then it is determined that the first configuration value and the second configuration value do not satisfy the corresponding parameter update conditions.

[0201] Furthermore, if both the first configuration value and the second configuration value meet the parameter update conditions, the first configuration value is set to the shared identifier parameter value; and the second configuration value is set to the exclusive identifier configuration value (i.e., Figure 18bThe "Configure Usage Mode Allocation View" operation is performed within the configuration. Correspondingly, if the first and second configuration values ​​do not meet the parameter update conditions, the virtual machine creation process can be executed based on the default usage mode allocation view, or the virtual machine creation process can be terminated, and an error message can be returned to the device that issued the virtual machine creation request. This error message may include the reason for the error, such as the usage mode allocation view update failure. This embodiment provides a usage mode allocation view allocation interface for the key space, allowing users to independently adjust the usage mode of the key space according to actual needs, which helps to improve the flexibility of the key space usage mode.

[0202] In some embodiments, if the server device's processor only has a physical TKM, then the key space allocation method provided in the foregoing embodiments can be used to allocate a TKM key space to the virtual machine and create a virtual machine with TKM functionality. In other embodiments, such as Figure 7 As shown, the processor may also include a physical CCP 107. Correspondingly, the host OS also deploys a CCP driver. This embodiment of the processor setting up a physical TKM and a physical CCP, together, enables a cloud platform architecture supporting local cryptographic computation and key-related functions based on an intrinsically secure chip. This allows for local key management and local encryption / decryption processing, improving encryption / decryption speed and reducing investment in external cryptographic machines, key cards, and key management clusters.

[0203] The processor 101 may have one or more physical CCPs 107. "Multiple" means two or more (including two). Generally, the processor 101 has multiple physical CCPs 107.

[0204] The physical CCP 107 implements cryptographic processing in hardware, enabling on-premises processing of cryptographic algorithms and accelerating key processing. Compared to software-based cryptographic processing, the physical CCP 107 offers significantly faster cryptographic processing speed.

[0205] exist Figure 7In the shown MDEV framework, a real physical device (i.e. a physical CCP) is registered as a parent device by a vendor driver into the MDEV framework, and then an MDEV device is created under the parent device through a sysfs interface provided by the MDEV framework. The MDEV device is an abstract and logical device. The MDEV device is further registered into the VFIO framework by an MDEV driver (e.g. VFIO-MDEV). From the perspective of the VFIO framework, the MDEV device is a VFIO device. Finally, in QEMU, an MDEV device can be assigned to a virtual machine. The call of an MDEV device related operation function by the virtual machine is routed to the driver of the parent device (i.e. the vendor driver, i.e. the related operation function of the physical CCP driver), and thus the virtual machine can use the capability of the physical CCP. Each operation of QEMU on the VFIO group / device will go through the address of the QEMU vCCP device -> memory reading -> KVM exit -> VFIO-MDEV -> VFIO -> physical CCP, so as to ensure that the vendor driver can capture the access request of the virtual machine's operating system (Guest OS) to the MDEV device, and thus the virtual machine can access the physical CCP.

[0206] According to the above process of the virtual machine having the CCP function, it is necessary to allocate a vCCP resource to the virtual machine during the creation of the virtual machine, which requires generating vCCP related configuration information for the virtual machine during the creation of the virtual machine. It is necessary to allocate appropriate vCCP resources to the virtual machine during the creation of the virtual machine. However, the number of vCCP resources on a service device is large and disordered, and the allocation of vCCP resources has certain limitations. Specifically, one physical CCP can generate multiple MDEV devices, and multiple means two or more. For the convenience of subsequent description, the number of MDEV devices is represented by P, P≥2, and is an integer. Each MDEV device corresponds to one vCCP, i.e. one physical CCP can be virtualized into P vCCPs. A service device has N physical CCPs. N≥1, and is an integer.

[0207] N physical CCPs on a service device can be virtualized into N*P vCCPs. In order to prevent the load imbalance and processing bottleneck caused by the centralized task of vCCP encryption calculation on one or more physical CCPs, it is stipulated that the same virtual machine can only use the vCCPs virtualized by different physical CCPs. This is mainly because if the virtual machine uses vCCPs in which multiple vCCPs correspond to the same physical CCP, all encryption calculation tasks may be concentrated on the same physical CCP, while other physical CCPs are idle, resulting in physical CCP load imbalance and processing bottleneck. Therefore, it is stipulated that the same virtual machine can only use vCCPs virtualized by different physical CCPs, that is, the same virtual machine can only use vCCPs corresponding to different physical CCPs. Therefore, the number of vCCPs that a virtual machine can use is [1, N], which means that a service device can support [M, N*P] virtual machines with CCP function. The number of vCCPs allocated to the multiple virtual machines deployed on the service device can be the same or different, which is determined by the demand of the user corresponding to the virtual machine. The physical CCP can be transmitted to the virtual machine (VM) in the form of an MDEV device, so that the virtual machine has the CCP capability, that is, the virtual machine has a vCCP. One MDEV device corresponds to one vCCP, and can support [M, N*P] virtual machines with CCP function.

[0208] Suppose that a virtual machine needs to use Q vCCPs, Q ∈ [1, N], then there are choices for allocating vCCPs to the virtual machine. represents selecting Q physical CCPs from N physical CCPs, and selecting one vCCP from the vCCP corresponding to each of the Q physical CCPs. i represents the i-th physical CCP in the selected Q physical CCPs; represents the number of currently idle vCCPs in the vCCP corresponding to the i-th physical CCP in the selected Q physical CCPs. Wherein, ∈ [1, P]. A large number of vCCP resources undoubtedly makes the management of vCCP resources particularly complex. Therefore, how to efficiently manage vCCP resources is a technical problem to be solved in the field.

[0209] The vCCP resource management method provided by the embodiments of the present application will be exemplarily described below. When N = 1, that is, a service device has one physical CCP, the vCCP resource corresponds to the same physical CCP, and the allocation and management of the vCCP resource is relatively simple, that is, one currently idle vCCP is configured for each virtual machine. Therefore, the embodiments of the present application mainly take N ≥ 2, that is, a service device contains multiple physical CCPs, as an example to exemplarily describe the management method of the vCCP resource.

[0210] In the embodiments of the present application, in order to facilitate the management of vCCP resources, the vCCP resources can be grouped. Specifically, according to the number K of vCCP supported by the virtual machine, the vCCP corresponding to the plurality of physical CCPs can be divided into a plurality of vCCP groups. Each vCCP group contains vCCP corresponding to different physical CCPs. In this way, it can be prevented that the vCCP of the same vCCP group competes for the same physical CCP, causing resource conflict

[0211] It is assumed that the number K of vCCP supported by the virtual machine satisfies 1≤K≤N. N represents the number of physical CCPs on the service device. In order to facilitate the management of vCCP resources, the CCP capabilities provided by the virtual machine deployed on one service device can be made the same, that is, the virtual machines deployed on the same service device have the same number of vCCP, that is, all have K vCCP. Then, according to the number K of vCCP supported by the virtual machine, the vCCP corresponding to the plurality of physical CCPs on the service device can be divided into vCCP groups, and each vCCP group contains K vCCP, and the K vCCP correspond to K different physical CCPs. Specifically, the K vCCP corresponding to K different physical CCPs can be divided into the same vCCP group to obtain vCCP groups.

[0212] In some embodiments, considering that the virtual machine needs to provide CCP computing capability for the running container, each container always obtains all the CCP resources on the virtual machine, and the containers compete for the CCP resources, which is essentially the same as the multi-process competing for the CCP resources. In order to guarantee the CCP capability of the container, for a single virtual machine, the maximum number N of vCCP that the virtual machine can have can be given to the virtual machine, that is, the number of physical CCPs available on the service device, and the N vCCP are taken as a vCCP group, and there are P vCCP groups in total. Correspondingly, according to the number N of vCCP supported by the virtual machine, the N vCCP corresponding to N different physical CCPs can be divided into the same vCCP group to obtain P vCCP groups. After the above grouping, the plurality of physical CCPs on the service device are divided into a plurality of vCCP groups, and each vCCP group contains vCCP corresponding to different physical CCPs.

[0213] In the embodiments of the present application, the vCCP group is taken as a scheduling unit, and an index can be configured for each vCCP group. Wherein, , represents an integer set. . i=0,1, …, . Correspondingly, the set of all vCCP groups that can be used for allocation can be defined as a resource window W, and the length of W is the number of vCCP Each vCCP group contains K vCCPs. The resource window W is a set of indexes of available vCCP groups, i.e., multiple vCCP groups, which can be represented as: . represents an index of a vCCP group, and corresponds to the K vCCPs contained in the (i+1)th vCCP group. In some embodiments, K=N, and the length of the resource window W, i.e., the number of indexes contained in the resource window W, is P. The resource window W can be represented as: . Wherein, , , i=0, 1, …, .

[0214] After completing the grouping of vCCP resources, the vCCP resource management is performed in the vCCP group as a scheduling unit. In this embodiment, a virtual machine creation request can be sent to the service device. The service device can respond to the virtual machine creation request to perform resource scheduling on the vCCP group, and perform scheduling on the key space of the physical TKM using the virtual machine creation method provided in the foregoing embodiments, and create a virtual machine with TKM function and CCP function using the scheduled vCCP group and target key space. It should be noted that the grouping of vCCP resources can be a pre-completed operation, or an operation completed by the service device in response to the virtual machine creation request. Specifically, the service device can group the vCCP resources when it first receives the virtual machine creation request, and does not need to group the vCCP resources again when it receives the virtual machine creation request subsequently, and can directly use the vCCP groups completed by grouping to perform vCCP resource scheduling to create a virtual machine with CCP function.

[0215] Based on the foregoing grouping management of the vCCP resources of the service device, as Figure 19 Step 1901 shows that in response to the virtual machine creation request, in addition to determining the target usage mode of the key space required by the virtual machine to be created, a target vCCP group for the virtual machine to be created can also be determined from the idle vCCP groups. For the implementation of steps 1902 and 1903, please refer to the description of steps 1702 and 1703 described above, which will not be repeated here.

[0216] In some embodiments, based on the index of the foregoing vCCP group, the index set of the currently idle vCCP group can be determined in response to the virtual machine creation request; and the target index of the to-be-created virtual machine is determined from the index set of the currently idle vCCP group, and the vCCP group corresponding to the target index is determined as the target vCCP group. For the specific implementation of determining the index set of the currently idle vCCP group, please refer to the implementation of determining the currently idle second identifier set A corresponding to the target usage mode. The technical means implemented are the same, only the objects to be determined are different. For the specific implementation and technical effects of determining the target index of the to-be-created virtual machine from the index set of the currently idle vCCP group, please refer to the implementation and technical effects of determining the target identifier from the currently idle second identifier set A corresponding to the target usage mode. The technical means implemented are the same, only the objects to be determined are different.

[0217] Correspondingly, the foregoing step 1704 can be implemented as step 1904, that is, generating the configuration information of the to-be-created virtual machine according to the target key space corresponding to the target identifier and the target virtual CCP group. Specifically, the resource path of the target key space is converted into the format of the virtual machine configuration file, such as the XML format, to obtain the key space resource configuration file of the to-be-created virtual machine; and the resource path of the target vCCP group is converted into the format of the virtual machine configuration file, such as the XML format, to obtain the vCCP resource configuration file of the to-be-created virtual machine; then, the key space resource configuration file and the vCCP resource configuration file of the to-be-created virtual machine are added to the initial configuration file of the to-be-created virtual machine to obtain the configuration file of the to-be-created virtual machine.

[0218] Specifically, the key space resource configuration file and the vCCP resource configuration file of the to-be-created virtual machine can be added to an initial configuration file of the to-be-created virtual machine by the prepareVM component to obtain a configuration file of the to-be-created virtual machine. The initial configuration file of the to-be-created virtual machine can be a domain configuration file, such as a domain XML (Domain XML) file, obtained by the prepareVM component from parameters issued to the prepareVM component by the management component. The initial configuration file contains configuration information of the virtual machine, including but not limited to hardware configuration information such as processor, memory, disk, network interface, and driver, and startup parameters. The prepareVM component adds the key space resource configuration file of the to-be-created virtual machine to the initial configuration file of the to-be-created virtual machine to obtain a domain XML (Domain XML) file, that is, a configuration file of the to-be-created virtual machine. The configuration file contains key space resource configuration information of the virtual machine, vCCP resource configuration information of the virtual machine, and other resource configuration information. Details about the other resource configuration information are not described herein. Accordingly, the foregoing step 1705 can be implemented as step 1905, that is, creating a virtual machine with TKM function and CCP function according to the configuration information of the to-be-created virtual machine.

[0219] In this embodiment, the vCCPs corresponding to the physical CCPs are grouped and managed to obtain a plurality of vCCP groups. When a virtual machine creation request arrives, a target vCCP group is determined for the to-be-created virtual machine from the currently idle vCCP groups. Then, the configuration information of the to-be-created virtual machine can be generated according to the target vCCP group, and the management of the vCCP resources is achieved. Since the target vCCP group is selected from the currently idle vCCP groups, the target vCCP group must be an idle vCCP group, and there is no need to traverse and query all vCCPs to determine whether they are occupied before allocation, which can improve the vCCP resource allocation efficiency and further improve the virtual machine creation efficiency.

[0220] On the other hand, this embodiment can make the virtual machine have both TKM function and CCP function, implement key management of the virtual machine based on the TKM function of the virtual machine, and also implement local encryption and decryption data processing based on the CCP function of the virtual machine, thereby improving the encryption and decryption speed of data.

[0221] It is worth mentioning that the user can autonomously select whether to start the vTKM virtual machine and the virtual machine of the vCCP function. If the user selects to start the vTKM virtual machine and does not select to start the virtual machine of the vCCP function, the virtual machine with only the TKM function can be created by using the virtual machine creation method with the TKM function provided in the foregoing embodiments. If the user selects to start the vTKM virtual machine and selects to start the virtual machine of the vCCP function, the virtual machine with the TKM function and the CCP function can be created by using the virtual machine creation method with the TKM function and the CCP function provided in the foregoing embodiments. If the user does not select to start the vTKM virtual machine and only selects to start the virtual machine of the vCCP function, the virtual machine with only the CCP function can be created by using the virtual machine creation method with the CCP function provided in the foregoing embodiments.

[0222] It is worth mentioning that because the currently occupied vCCP resources are updated according to the startup and destruction of the previous virtual machine each time the virtual machine with the TKM function and the CCP function is requested to be created, but the available resource window (i.e., the target index set of the foregoing currently idle vCCP) is always a subset of the full resource window (i.e., the index set of all vCCP groups available on the service device), the available resource window (i.e., the target index set of the foregoing currently idle vCCP) is like sliding in a bar of length W, and therefore, the available resource window (i.e., the target index set of the foregoing currently idle vCCP) is a sliding window in a broad sense. By randomly selecting the available target vCCP group in the available resource window through the random number, it can be ensured that there is no conflict with the used vCCP resources. Therefore, the management and allocation mechanism of the vCCP resources can be called a slide window random selection mechanism (SWRS). The key space management in the creation method of the vTKM virtual machine provided in the foregoing embodiments is implemented based on a preset usage mode allocation view (PAV), and therefore the key management mechanism provided in the foregoing embodiments can be called a preset allocation view based vTKM vid management allocation mechanism (PAVX). In the PAVX, PAV represents the core feature of the scheme, and X represents a series of descriptions that follow.

[0223] The method for implementing the virtual machine creation by using the PAVX mechanism and the SWRS mechanism will be specifically described below in combination with the internal software architecture of the service device shown in the following Figure 20 Figure 20 ​The middle management component, the virtual machine configuration component (such as the prepareVM component), the virtualization management component, QEMU, KVM and the vCCP resource management component are all deployed on the service device, and the service device can schedule the corresponding components to execute the method logic of the component. As shown in Figure 20 , the virtual machine creation method mainly includes the following steps:

[0224] 1. A user can initiate a virtual machine creation request through a platformized white screen portal or a background command interface. The virtual machine creation request reaches the management component running on the service device.

[0225] 2. The management component obtains the necessary parameters contained in the virtual machine configuration file (such as an XML file) according to the virtual machine creation request, and passes the necessary parameters to the virtual machine configuration component (such as the prepareVM component) in the resource management configuration and virtual machine creation management tool.

[0226] For the description of steps 1 and 2, please refer to the related content of the foregoing Figure 8 , which will not be described here again.

[0227] The virtual machine configuration component (such as the prepareVM component) generates the initial configuration file of the virtual machine to be created according to these parameters.

[0228] 3. The virtual machine configuration component (such as the prepareVM component) calls the vCCP resource management component. The vCCP resource management component uses the SWRS mechanism to determine the target vCCP group for the virtual machine to be created, and generates the CCP resource configuration file of the virtual machine to be created.

[0229] 4. The vCCP resource management component passes the CCP resource configuration file to the virtual machine configuration component (such as the prepareVM component). The virtual machine configuration component (such as the prepareVM component) adds the CCP resource configuration file of the virtual machine to be created to the initial configuration file of the virtual machine to be created.

[0230] 5. The virtual machine configuration component (such as the prepareVM component) calls the TKM resource management component. The TKM resource management component uses the PAVX mechanism to determine the target identifier of the key space for the virtual machine to be created, and generates the key space resource configuration file of the virtual machine to be created.

[0231] 6. The virtual machine configuration component (such as the prepareVM component) passes the key space resource configuration file to the virtual machine configuration component (such as the prepareVM component). The virtual machine configuration component (such as the prepareVM component) also adds the key space resource configuration file of the virtual machine to be created to the initial configuration file of the virtual machine to be created, to obtain the virtual machine configuration file of the virtual machine to be created.

[0232] 7. The virtual machine configuration component (e.g., prepareVM component) sends the configuration file of the virtual machine to be created to the management component.

[0233] 8. The management component passes the virtual machine configuration file to the virtual machine configuration file assembly component (e.g., StartVMx) in the management component.

[0234] The virtual machine configuration file assembly component assembles the configuration file of the virtual machine and other configuration information into a complete virtual machine configuration file.

[0235] 9. The virtual machine configuration file assembly component sends the complete virtual machine configuration file to the virtualization management component (e.g., libvirt).

[0236] 10. The virtualization management component (e.g., libvirt) can convert the virtual machine configuration file into command line parameters suitable for QEMU, perform necessary operating system level configuration work, and start the QEMU process using the command line parameters suitable for QEMU.

[0237] 11. QEMU cooperates with the KVM kernel module to start the virtual machine according to the converted command line parameters, and obtains a virtual machine with TKM function and CCP function.

[0238] 12. After the KVM module receives the virtual machine exit message, it analyzes the reason for the virtual machine exit and performs corresponding processing, then passes the data to QEMU and executes the virtual machine entry (VMentry) operation again, so that the control right is transferred to QEMU in the user mode.

[0239] The interaction between steps 11 and 12 continues, indicating that the virtual machine is running. When this interaction starts to work, it indicates that the virtual machine has been created and is in a running state.

[0240] Figure 21 Data path diagram for password calculation of virtual machine with TKM function and CCP function. For example, Figure 21As shown, for virtual machines with TKM and CCP functions, applications on the virtual machine can send a password calculation request to the virtual machine's corresponding key space when password calculations are required, such as data encryption or decryption. The physical TKM responds to this request by obtaining the key corresponding to the request. For example, it can obtain a user identifier from the request and, based on that, retrieve the corresponding key from its locally managed keys; this is the key for the password calculation request. The physical TKM can then transmit the key to the virtual machine's corresponding CCP resource, specifically the vCCP group within the physical CCP. The physical CCP can then invoke the vCCP group to perform password processing on the data to be processed using the key. For example, it can use the key to decrypt the data to be decrypted in the password calculation request, obtaining the plaintext; or it can use the key to decrypt the data to be encrypted in the password calculation request, obtaining the ciphertext. Finally, the physical CCP can return the password-processed data to the application deployed on the virtual machine. Figure 21 In the illustrated virtual machine, for the embodiment where the password calculation request is a data encryption request, the application deployed on the virtual machine can also write the ciphertext of the data to be encrypted into the database to ensure data security. For the embodiment where the password calculation request is a data decryption request, the application deployed on the virtual machine can read the ciphertext of the data to be decrypted from the database according to actual needs; and according to... Figure 21 The method shown is provided to the physical CCP for decryption.

[0241] exist Figure 21 In the data encryption process, the data flow path is as follows: application data to be encrypted moves from the application to the virtual machine to the host OS to the physical TKM in the processor to the physical CCP to the ciphertext of the application data to the host OS to the virtual machine to the application to the database. During data decryption, the data flow path is as follows: ciphertext of the data to be decrypted stored in the database to the application, the virtual machine to the host OS, the physical TKM to the physical CCP to the plaintext of the data to be decrypted to the host OS to the virtual machine to the application. According to... Figure 21 As shown in the illustrated cryptographic computation data path, key management is implemented locally within the processor of the physical machine hosting the virtual machine, which possesses TKM and CCP capabilities. This eliminates the need for external cryptographic machines or HSM hardware, reducing the physical attack surface of bus-based attacks and improving data security. Furthermore, the internal CCP within the processor accelerates cryptographic computation. Since both key and data processing are performed within the processor during encryption and decryption, the risk of plaintext exposure is reduced, further enhancing data security.

[0242] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can also be executed by different devices as the execution subject. For example, the execution subject of steps 1701 and 1702 can be device A; for another example, the execution subject of step 1701 can be device A, and the execution subject of step 1702 can be device B; and the like.

[0243] In addition, in some of the processes described in the above embodiments and the accompanying drawings, a plurality of operations appearing in a certain order are included, but it should be clear that these operations can be executed in the order appearing in the text or in parallel, and the serial numbers of the operations, such as 1701, 1702, etc., are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes can include more or fewer operations, and the operations can be executed in sequence or in parallel.

[0244] Correspondingly, the embodiments of the present application also provide a computer readable storage medium storing computer instructions, when the computer instructions are executed by one or more processors, causing the one or more processors to execute the steps in the virtual machine creation method provided by the above embodiments.

[0245] The computer readable storage medium includes volatile or non-volatile or their combination, and can be removable or non-removable. Examples of the computer readable storage medium include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), electrical programmable read only memory (EPROM), erasable programmable read only memory (EPROM), programmable read only memory (PROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital video disc (DVD) or other optical storage, magnetic cassette, disk storage or other magnetic storage device, or any other non-transmission medium.

[0246] The embodiment of the present application also provides a computer program product, comprising a computer program, which causes one or more processors to execute the steps in the virtual machine creation method provided by the foregoing embodiments when the computer program is executed by the one or more processors.

[0247] In the embodiment of the present application, the specific implementation form of the computer program product is not limited. In some embodiments, the computer program product can be implemented as an application (APP), a small program, a computer-side client, a program module, a plug-in, an installation package, a software development kit (SDK), an image file of an optical disc, a plug-in or a software in the form of software as a service (SaaS), but is not limited thereto.

[0248] The computer program product should be understood as being capable of realizing each process or a combination of multiple processes in the above method by a computer program or instructions. In addition, the computer program or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing devices, so that the processor of the general-purpose computer, the special-purpose computer, the embedded processor or other programmable data processing devices can be realized as a device for realizing the corresponding functions in the above method embodiments.

[0249] Figure 22 The structure schematic diagram of the electronic device provided by the embodiment of the present application is shown in FIG. 2. As shown in FIG. 2, the electronic device comprises a memory 22a and a processor 22b. The memory 22a is configured to store computer programs and can be configured to store other various data to support the operation on the computing platform. Examples of the data include instructions, data structures, contact data, phonebook data, messages, pictures, videos and the like of any application or method for operating on the electronic device. Figure 22

[0250] The processor 22b comprises a physical TKM 22b1. The processor 22b is coupled to the memory 22a and is configured to execute the computer programs for executing the steps in the virtual machine creation method provided by the foregoing embodiments. The specific implementation of each step can be referred to the related description of the foregoing embodiments, which will not be described here.

[0251] In some optional implementations, as shown in FIG. 2, the electronic device can further comprise optional components such as a communication component 22c, a power supply component 22d, a display component 22e and an audio component 22f. Figure 22 Figure 22 In the embodiment of the present application, only part of the components are shown schematically, which does not mean that the electronic device must contain all the components shown in FIG. 2, nor does it mean that the electronic device can only include the components shown in FIG. 2. Figure 22 Figure 22 ​​​The illustrated components.

[0252] In addition, Figure 22 The components in the dashed box are optional components, not mandatory components, and can be determined according to the product form of the electronic device. The electronic device in the embodiment can be implemented as a terminal device such as a desktop computer, a notebook computer, a mobile phone or an Internet of Things device; or a server device such as a traditional server, a cloud server or a server cluster.

[0253] In the embodiment of the present application, the memory is used to store the computer program and can be configured to store other various data to support the operation on the device where it is located. Among them, the processor can execute the computer program stored in the memory to realize the corresponding control logic. The memory can be realized by any type of volatile or non-volatile storage device or their combination, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), electrically erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0254] In the embodiment of the present application, the processor can be any hardware processing device that can execute the above method logic. Alternatively, the processor can be a central processing unit (CPU), a graphics processing unit (GPU) or a microcontroller unit (MCU); it can also be a programmable device such as a field programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), a complex programmable logic device (CPLD), etc.; or an advanced reduced instruction set computer (RISC) processor (Advanced RISC Machines, ARM) or a system on chip (System on Chip, SoC), etc., but not limited to this.

[0255] In embodiments of the present application, the communication component is configured to facilitate wired or wireless communication between the device in which it is located and other devices. The device in which the communication component is located can access a wireless network based on a communication standard, such as 2G or 3G, 4G, 5G, or a combination thereof. In an example embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0256] In embodiments of the present application, the display component can include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the display component includes a touch panel, the display component can be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touch, swiping, and gestures on the touch panel. The touch sensor can not only sense the boundary of a touch or swiping action, but also detect duration and pressure related to the touch or swiping action.

[0257] In embodiments of the present application, the power component is configured to provide power to various components of the device in which it is located. The power component can include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which the power component is located.

[0258] In embodiments of the present application, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive an external audio signal when the device in which the audio component is located is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal can be further stored in a memory or transmitted via the communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. For example, for a device with a language interaction function, voice interaction with a user can be implemented through the audio component, etc.

[0259] It should be noted that the terms "first", "second", and the like in this document are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order or limit the types of "first" and "second".

[0260] It should also be noted that the terms "include", "contain" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of another identical element in the process, method, article or device including the above element.

[0261] The above merely provides example of the present application, but not for limiting the present application. For those skilled in the art, the present application can have various modifications and changes. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application, should be included in the scope of claims of the present application.

Claims

1. A virtual machine creation method suitable for a service device, characterized by, A physical trusted key management module (TKM) is arranged in a processor of the service device; a plurality of key spaces are registered with the physical TKM; and the method comprises: In response to a virtual machine creation request, determining a target usage mode of a key space required by a virtual machine to be created; According to a preset usage mode allocation view of the plurality of key spaces, determining a first identifier set of the key space corresponding to the target usage mode; the usage mode allocation view is used to reflect respective usage modes of the plurality of key spaces; the respective usage modes of the plurality of key spaces are one of a private mode, a different virtual machine sharing mode and a virtual machine and physical machine sharing mode; and the first identifier set comprises identifiers of the key space corresponding to the target usage mode; From the first identifier set, determining a target identifier for the virtual machine to be created; According to a target key space corresponding to the target identifier, generating configuration information of the virtual machine to be created; According to the configuration information of the virtual machine to be created, creating a virtual machine with TKM function.

2. The method of claim 1, wherein, The usage mode allocation view comprises a shared identifier parameter value and a private identifier parameter value; According to the preset usage mode allocation view, determining the first identifier set corresponding to the target usage mode comprises: From the shared identifier parameter value and the private identifier parameter value, determining a target parameter value adapted to the target usage mode; According to the target parameter value, determining the first identifier set.

3. The method of claim 2, wherein, From the shared identifier parameter value and the private identifier parameter value, determining a target parameter value adapted to the target usage mode comprises: In a case where the target usage mode is the different virtual machine sharing mode, determining the shared identifier parameter value as the target parameter value; Or, In a case where the target usage mode is the private mode, determining the private identifier parameter value as the target parameter value.

4. The method of claim 3, wherein, The shared identifier parameter value is less than or equal to the private identifier parameter value, and according to the target parameter value, determining the first identifier set comprises: In a case where the target usage mode is the different virtual machine sharing mode, according to identifiers of the plurality of key spaces that are less than or equal to the shared identifier parameter value, determining the first identifier set; Or, In a case where the target usage mode is the private mode, according to identifiers of the plurality of key spaces that are greater than or equal to the private identifier parameter value, determining the first identifier set.

5. The method of claim 3, wherein, The shared identifier parameter value is greater than or equal to the private identifier parameter value, and according to the target parameter value, determining the first identifier set comprises: In a case where the target usage mode is the different virtual machine sharing mode, according to identifiers of the plurality of key spaces that are greater than or equal to the shared identifier parameter value, determining the first identifier set; Or, In a case where the target usage mode is the private mode, according to identifiers of the plurality of key spaces that are less than or equal to the private identifier parameter value, determining the first identifier set.

6. The method of claim 2, wherein, Before responding to the virtual machine creation request, the method further comprises: obtaining a first configuration value of a shared identification parameter and a second configuration value of a private identification parameter; in a case where the first configuration value and the second configuration value satisfy a parameter update condition, setting the first configuration value as the shared identification parameter value, and setting the second configuration value as the private identification parameter value.

7. The method of claim 6, wherein, The method further comprises performing at least one of the following judgment operations, which comprises: judging whether the first configuration value and the second configuration value belong to a set identification range; judging whether a size relationship between the first configuration value and the second configuration value satisfies a set size relationship condition; determining a plurality of use modes each corresponding to a candidate identification set according to the first configuration value and the second configuration value; for any use mode, judging whether all use modes corresponding to currently occupied identifications in the candidate identification set of the any use mode are the any use mode; The method further comprises: in a case where the judgment results of the at least one judgment operation are all yes, determining that the first configuration value and the second configuration value satisfy the parameter update condition.

8. The method of claim 1, wherein, The target use mode is a private mode, or the target use mode is a different virtual machine sharing mode and a specified not-joined occupied key space; The method further comprises: determining a second identification set of a currently idle key space from the first identification set; the second identification set comprises identifications of the currently idle key space; determining the target identification for the to-be-created virtual machine from the second identification set.

9. The method of claim 8, wherein, The method further comprises: obtaining a third identification set of a currently occupied key space corresponding to the target use mode; the third identification set comprises identifications of the currently occupied key space; obtaining, from the first identification set, identifications not belonging to the third identification set as identifications of the currently idle key space; the identifications of the currently idle key space constitute the second identification set.

10. The method of claim 9, wherein, The method further comprises: obtaining the third identification set through a virtualization management command, or obtaining the identifications of the currently occupied key space from an identification list of an occupied key space maintained by the service device; the identifications of the currently occupied key space constitute the third identification set.

11. The method of claim 8, wherein, The method further comprises: generating a random number greater than or equal to 0 and less than or equal to a total number of identifications in the second identification set; determining that an identification with a bit order in the second identification set as the random number is the target identification.

12. The method of claim 11, wherein, The method further comprises: taking a current timestamp as a random seed, and taking the length of the second identification set as a parameter to generate the random number.

13. The method of claim 10, wherein, The method further comprises: After the virtual machine to be created is created, the target identifier is added to an identifier list of an occupied key space maintained by the service device.

14. The method according to any one of claims 1 to 13, characterized in that, The target usage mode is a different virtual machine sharing mode and specifies to join an occupied key space; and the target identifier is determined from the first identifier set for the virtual machine to be created, including: A third identifier set of a currently occupied key space corresponding to the target usage mode is determined; and the first identifier set includes the third identifier set; The target identifier is determined from the third identifier set.

15. The method of claim 14, wherein, The target identifier is determined from the third identifier set, including: A specified identifier is obtained from the virtual machine creation request; and the specified identifier is determined as the target identifier; and the third identifier set includes the specified identifier; Or, An identifier is randomly determined from the third identifier set as the target identifier; Or, An identifier with the least reference times is determined from the third identifier set as the target identifier; and the reference times of an identifier refer to a number of virtual machines currently occupying a key space corresponding to the identifier.

16. The method according to any one of claims 1 to 13, characterized in that, The target usage mode is a virtual machine and physical machine sharing mode; and the target identifier is determined from the first identifier set for the virtual machine to be created, including: The first identifier set includes one identifier; and the identifier in the first identifier set is determined as the target identifier; Or, The first identifier set includes multiple identifiers; and an identifier is randomly selected from the first identifier set as the target identifier; Or, The first identifier set includes multiple identifiers; and an identifier with the least reference times is determined from the first identifier set as the target identifier; and the reference times of an identifier refer to a number of virtual machines currently occupying a key space corresponding to the identifier.

17. The method according to any one of claims 1 to 13, characterized in that, A plurality of physical cryptographic coprocessors (CCPs) are arranged in a processor of the service device; each physical CCP is virtualized into a plurality of virtual CCPs; virtual CCPs corresponding to the plurality of physical CCPs are divided into a plurality of virtual CCP groups, and virtual CCPs included in each virtual CCP group correspond to different physical CCPs; The method includes: In response to the virtual machine creation request, a target virtual CCP group is determined for the virtual machine to be created from currently idle virtual CCP groups; The configuration information of the virtual machine to be created is generated according to the target key space corresponding to the target identifier, including: The configuration information of the virtual machine to be created is generated according to the target key space corresponding to the target identifier and the target virtual CCP group; The virtual machine with a TKM function is created according to the configuration information of the virtual machine to be created, including The virtual machine with a TKM function and a CCP function is created according to the configuration information of the virtual machine to be created.

18. A cloud service system, characterized by It includes: At least one service device; a plurality of physical TKMs are arranged in a processor of the service device; and a plurality of key spaces are registered in the physical TKMs; The service device is used to perform steps in the method of any one of claims 1-17.

19. An electronic device, comprising: It includes: a memory and a processor; the processor comprising a physical TKM; wherein the memory is configured to store a computer program; the processor coupled to the memory is configured to execute the computer program for performing steps of the method of any one of claims 1-17.

20. A computer readable storage medium having stored thereon computer instructions, wherein, computer program, which when executed by one or more processors, causes the one or more processors to perform steps of the method of any one of claims 1-17.

21. A computer program product, characterised in that, computer program, which when executed by one or more processors, causes the one or more processors to perform steps of the method of any one of claims 1-17.

Images