Memory management method and device, equipment, storage medium and computer program

Abstract

The invention discloses a memory management method and device, equipment, a storage medium and a computer program, and belongs to the technical field of computers. The method comprises the following steps: receiving a memory allocation request, wherein the memory allocation request is used for requesting to allocate a memory interval for a target VM; obtaining the sizes, physical addresses and distribution conditions of a plurality of encrypted memory intervals through an operating system kernel, wherein the plurality of encrypted memory intervals correspond to different keys; selecting one encrypted memory interval from the plurality of encrypted memory intervals as a target encrypted memory interval based on the sizes and distribution conditions of the plurality of encrypted memory intervals; and allocating the target encrypted memory interval to the target VM based on the physical address of the target encrypted memory interval. Therefore, due to the fact that the operating system kernel determines the physical address of the encrypted memory interval of the target VM in the memory allocation stage, the corresponding encrypted memory interval can be accessed based on the physical address, a hardware architecture does not need to be changed, and the method can be suitable for different processor architectures.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a memory management method, apparatus, device, storage medium, and computer program. Background Art

[0002] In the hardware architecture of advanced RISC machines (ARM), the hardware resources can be divided into a rich execution environment (REE) side and a trusted execution environment (TEE) side based on the trustzone technology. The security of the TEE side is higher than that of the REE side. The processor can work on the REE side, can also work on the TEE side, and can switch back and forth between the REE side and the TEE side. The REE side includes multiple virtual machines (VMs), and each VM runs a guest operating system (guest OS). However, there is no defined memory encryption implementation scheme in the current ARM architecture, and it is impossible to allocate keys to each VM on the native architecture to encrypt and decrypt the data in the physical memory range corresponding to the VM. In other words, in the case where the ARM architecture does not define a memory encryption scheme of "one virtual machine, one key", it is impossible to encrypt and protect the data stored in the physical memory of each VM, which restricts the large-scale development of the ARM architecture in confidential computing applications. Summary of the Invention

[0003] This application provides a memory management method, apparatus, device, storage medium, and computer program, which can manage multiple encrypted memory ranges in the physical memory without changing the native architecture to implement memory encryption of "one virtual machine, one key". The technical solutions are as follows.

[0004] In a first aspect, a memory management method is provided. The method includes:

[0005] Receiving a memory allocation request for requesting to allocate a memory range for a target virtual machine VM; obtaining the sizes, physical addresses, and allocation statuses of multiple encrypted memory ranges through an operating system kernel, where the allocation status is used to indicate whether the encrypted memory range has been allocated, and the multiple encrypted memory ranges correspond to different keys; selecting an encrypted memory range from the multiple encrypted memory ranges as a target encrypted memory range based on the sizes and allocation statuses of the multiple encrypted memory ranges; and allocating the target encrypted memory range to the target VM based on the physical address of the target encrypted memory range.

[0006] Since the operating system kernel is responsible for creating and managing multiple VMs running in a physical machine, and the operating system kernel can access physical memory, this application indicates the sizes and physical addresses of multiple encrypted memory ranges to the operating system kernel, so that when the operating system kernel creates a VM, it allocates a corresponding encrypted memory range for the VM from the multiple encrypted memory ranges divided from the physical memory, thereby determining the correspondence between the VM and the encrypted memory range in the operating system kernel. In this way, when any VM accesses physical memory through the operating system kernel, the operating system kernel can directly map the virtual address of the VM to the physical address of the encrypted memory range, and then read and write data in the corresponding encrypted memory range based on this physical address in the physical memory. This process does not require changing the hardware architecture and can be applicable to different processor architectures.

[0007] Optionally, before obtaining the sizes, physical addresses, and allocation statuses of multiple encrypted memory ranges through the operating system kernel, the method further includes: reading encrypted memory configuration information in the boot firmware, where the encrypted memory configuration information is used to indicate the number and size of the multiple encrypted memory ranges; dividing the multiple encrypted memory ranges from the physical memory based on the number and size of the multiple encrypted memory ranges; and indicating the sizes and physical addresses of the multiple encrypted memory ranges to the operating system kernel.

[0008] That is, make corresponding modifications to the boot firmware of the physical machine to write the encrypted memory configuration information in the boot firmware. In this way, after the physical machine is powered on and starts, when the boot firmware runs first, it can read the encrypted memory configuration information in the boot firmware and divide multiple encrypted memory ranges from the physical memory.

[0009] Optionally, after dividing the multiple encrypted memory ranges, the processor can mark the multiple memory encrypted ranges as the reserved state, so that when the operating system starts and runs normally, it is not affected by high-privilege code (such as Hypervisor).

[0010] Optionally, after dividing the multiple encrypted memory ranges from the physical memory based on the number and size of the multiple encrypted memory ranges, the method further includes: indicating the physical addresses of the multiple encrypted memory ranges to the memory controller, so that the memory controller generates and stores the keys corresponding to the multiple encrypted memory ranges.

[0011] When multiple VMs are running on a physical machine, when the memory controller accesses physical memory for multiple VMs, it performs memory address translation between the virtual memory range and the physical memory range, and performs data read and write operations in the physical memory. Therefore, after partitioning multiple encrypted memory ranges from the physical memory, it is also necessary to indicate the physical addresses of the multiple encrypted memory ranges to the memory controller, so that the memory controller generates and stores the keys corresponding to the multiple encrypted memory ranges.

[0012] Among them, the keys generated by the memory controller for multiple encrypted memory ranges are different, that is, one encrypted memory range corresponds to one key. In this way, after allocating the encrypted memory range to the VM, it can be ensured that the data of the VM is encrypted and stored using a unique key, implementing a memory encryption scheme of "one virtual machine, one key".

[0013] Optionally, before reading the encrypted memory information in the boot firmware, the method further includes: displaying a configuration interface for instructing the user to input the number and size of the multiple encrypted memory ranges; obtaining the number and size of the multiple encrypted memory ranges from the configuration interface, and writing the number and size of the multiple encrypted memory ranges into the boot firmware.

[0014] Since the boot firmware is the first program to run after the physical machine is started, writing the number and size of multiple encrypted memory ranges into the boot firmware can perform the encrypted memory configuration operation first after the physical machine is powered on and started.

[0015] Optionally, after allocating the target encrypted memory range to the target VM, the method further includes: updating the allocation status of the target encrypted memory range through the operating system kernel to indicate that the target encrypted memory range has been allocated.

[0016] Optionally, the method further includes: in response to a shutdown request of the target VM, releasing the target encrypted memory range, and updating the allocation status of the target encrypted memory range through the operating system kernel to indicate that the target encrypted memory range is not allocated.

[0017] It can be seen that when the operating system kernel stores the sizes and physical addresses of multiple encrypted memory ranges, the operating system kernel can directly allocate encrypted memory ranges for the target VM during the creation of the target VM to determine the correspondence between the target VM and the target encrypted memory ranges; the operating system kernel can access the corresponding target encrypted memory ranges during the operation of the target VM to achieve data reading and writing; the operating system kernel can also release the memory resources of the target encrypted memory ranges in a timely manner when the target VM is shut down. That is to say, this application uses the operating system kernel to allocate and manage physical memory, and when accessing memory, it can directly perform addressing based on the physical address without carrying the associated information of the VM, and thus there is no need to expand the bus.

[0018] Optionally, the hardware resources of the physical machine are divided into a rich execution environment (REE) side and a trusted execution environment (TEE) side. The REE side includes multiple VMs, and the target VM is any one of the multiple VMs.

[0019] Based on the technical concept of this application, even if the security of the REE side is lower than that of the TEE side, it is possible to provide protection for the data of multiple VMs running on the REE side through encrypted memory ranges, ensuring the data security of multiple VMs on the REE side.

[0020] In a second aspect, a memory management device is provided. The memory management device has the function of implementing the behavior of the memory management method in the first aspect above. The memory management device includes at least one module, and this at least one module is used to implement the steps of the memory management method provided in the first aspect above.

[0021] In a third aspect, a computer device is provided. The computer device includes a processor and a memory. The memory is used to store a computer program for executing the memory management method provided in the first aspect above. The processor is configured to execute the computer program stored in the memory to implement the steps of the memory management method described in the first aspect above.

[0022] Optionally, the computer device may further include a communication bus, and this communication bus is used to establish a connection between the processor and the memory.

[0023] In a fourth aspect, a computer-readable storage medium is provided. Instructions are stored in the storage medium, and when the instructions run on a computer, the computer is caused to execute the steps of the memory management method described in the first aspect above.

[0024] In a fifth aspect, there is provided a computer program product including instructions that, when run on a computer, cause the computer to perform the steps of the memory management method described in the first aspect above. Alternatively, there is provided a computer program that, when run on a computer, causes the computer to perform the steps of the memory management method described in the first aspect above.

[0025] The technical effects obtained in the second, third, fourth, and fifth aspects above are similar to those obtained by the corresponding technical means in the first aspect, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 is a schematic structural diagram of a computer device provided by an embodiment of the present application;

[0027] Figure 2 is a schematic flowchart of a memory management method provided by an embodiment of the present application;

[0028] Figure 3 is a schematic diagram of memory management logic under a processor architecture provided by an embodiment of the present application;

[0029] Figure 4 is a schematic diagram of memory management logic under another processor architecture provided by an embodiment of the present application;

[0030] Figure 5 is a schematic flowchart of a memory management process provided by an embodiment of the present application;

[0031] Figure 6 is a schematic structural diagram of a memory management device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0032] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the following will further describe the embodiments of the present application in detail with reference to the accompanying drawings.

[0033] For ease of understanding, before explaining the memory management method provided by the embodiments of the present application in detail, the application background and implementation environment of the embodiments of the present application will be introduced first.

[0034] First, the application background of the embodiments of the present application will be introduced.

[0035] With the rapid development of cloud computing, more and more critical services and high-value data have been migrated to the cloud, making data protection more complex. Among them, for data in use, such as the data of VMs, confidential computing can be used for protection.

[0036] Confidential computing is a technology that protects data in use by executing computations within a hardware-based trusted execution environment. That is, based on the capabilities of the hardware and software of a computer device, a trusted execution environment (TEE) is built and run, so that the programs and data loaded inside the TEE are protected in terms of confidentiality and integrity.

[0037] Currently, the mainstream TEE solutions include the software guard extensions (SGX) technology and the trust domain extensions (TDX) technology of Intel Corporation with the x86 architecture, the secure encrypted virtualization (SEV) technology of AMD Corporation, and the trustzone technology of the ARM architecture, etc. Although the specific implementation methods of these technologies are different, they have all gradually evolved to provide security solutions and services in units of encrypted VMs. Among them, an encrypted VM refers to encrypting and protecting the data in the physical memory range corresponding to the VM, and this data includes the code running the VM, the data generated during the operation of user processes in the VM, etc.

[0038] The SEV technology is a TEE solution at the VM level that isolates the traditional hypervisor (also known as the virtual machine monitor, VMM) outside the trusted computing base (TCB) by means of memory range encryption, hardware instruction extension, an external security control processor, setting additional physical address flags, etc.

[0039] In some embodiments, the SEV technology uses the address space identifier (ASID) of the virtual machine (VM) to label the code and data of the VM, that is, to label the memory range of the VM. During the entire running cycle of the VM, the ASID remains unchanged in the physical memory, ensuring that the data of the VM can be correctly read by the VM and cannot be accessed by other software in the system. When the VM reads and writes data in its corresponding encrypted memory range, the encryption engine based on the Advanced Encryption Standard (AES) uses the key associated with the ASID of the VM to encrypt and decrypt the data read and written in this encrypted memory range. Since each VM is associated with its own key through the ASID, other VMs or the Hypervisor can only access the encrypted data, providing strong isolation between VMs and between the VM and the Hypervisor, ensuring the data security of each VM.

[0040] Since the corresponding relationship between the ASID and the key is stored in the AES encryption engine, when accessing the encrypted memory range of the VM, it is necessary to expand the bus to carry the ASID of the VM through an additional flag bit of the physical address when sending a memory access request to the physical memory. After the physical memory determines the memory range corresponding to the VM based on this physical address, it uses the key corresponding to the ASID to encrypt and decrypt the data read and written in and out of this encrypted memory range.

[0041] It should be noted that when encrypting the data in the memory range corresponding to the VM under the X86 architecture, the memory encryption implementation scheme of the TDX technology is similar to that of the SEV technology. Both need to expand the bus to pass the VM identifier associated with the key of the VM to the physical memory, so as to encrypt and decrypt the data read and written in the physical memory based on the key corresponding to the VM identifier. Therefore, it will not be elaborated here.

[0042] For the trustzone technology of the ARM architecture, the hardware resources of the computer device are divided into the REE side and the TEE side. The physical memory of the computer device is divided into non-secure memory and secure memory. The code and data on the REE side are stored in the non-secure memory, and the code and data on the TEE side are stored in the secure memory. The security of the REE side is lower than that of the TEE side. However, there is no defined memory encryption scheme in the current ARM architecture, and it is impossible to implement the memory encryption scheme of "one virtual machine, one key" on the native ARM hardware architecture.

[0043] Based on this, the embodiments of the present application provide a memory management method to implement the memory encryption scheme of "one virtual machine, one key" on a computer device with an ARM architecture, so as to encrypt the data in the memory ranges of multiple VMs running in the computer device with multiple keys without expanding the bus.

[0044] It should be noted that since the memory management method provided by the embodiments of the present application does not need to change the hardware bus architecture when managing the encrypted memory ranges of multiple VMs, the memory management method can be applied to any computer device running multiple VMs, and is not limited to the ARM architecture.

[0045] Next, the implementation environment of the embodiments of the present application will be introduced.

[0046] Figure 1 is a schematic structural diagram of a computer device shown according to an embodiment of the present application. The computer device is a physical machine on which multiple VMs are created and run. The computer device can be a server or a terminal. Please refer to Figure 1 . The computer device includes at least one processor 101, a communication bus 102, a memory 103, and at least one communication interface 104.

[0047] The processor 101 can be a general-purpose central processing unit (CPU), a network processor (NP), a microprocessor, or can be one or more integrated circuits for implementing the solution of the present application. For example, an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The above PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0048] The communication bus 102 is used to transmit information between the above components. The communication bus 102 can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 1 only a thick line is shown in , but it does not mean that there is only one bus or one type of bus.

[0049] The memory 103 can be a read-only memory (ROM), a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), an optical disc (including a compact disc read-only memory (CD-ROM), a compressed optical disc, a laser disc, a digital versatile disc, a Blu-ray disc, etc.), a magnetic disk storage medium, or any other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 103 can exist independently and be connected to the processor 101 through the communication bus 102. The memory 103 can also be integrated with the processor 101.

[0050] The communication interface 104 uses any device such as a transceiver for communicating with other devices or communication networks. The communication interface 104 includes a wired communication interface and can also include a wireless communication interface. Among them, the wired communication interface can be, for example, an Ethernet interface. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface can be a wireless local area networks (WLAN) interface, a cellular network communication interface, or a combination thereof, etc.

[0051] As an example, the processor 101 can include one or more CPUs, such as Figure 1 the CPU0 and CPU1 shown in

[0052] As an example, the computer device can include multiple processors, such as Figure 1 the processor 101 and the processor 105 shown in

[0053] In some embodiments, the computer device may further include an output device and an input device. The output device communicates with the processor 101 and can display information in various ways. For example, the output device can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device communicates with the processor 101 and can receive user input in various ways. For example, the input device can be a mouse, a keyboard, a touch screen device, or a sensing device, etc.

[0054] In some embodiments, the memory 103 is used to store the program code 110 for executing the solution of this application, and the processor 101 can execute the program code 110 stored in the memory 103. The program code 110 may include one or more software modules, and the computer device can implement the Figure 2 memory management method provided in the following embodiments through the processor 101 and the program code 110 in the memory 103.

[0055] Figure 2 is a flowchart of a memory management method provided by an embodiment of this application. This method is applied to Figure 1 the computer device shown, specifically the processor 101 in the computer device. Among them, the computer device is a physical machine, and multiple VMs can be created and run on it. Please refer to Figure 2 for details. This method includes the following steps.

[0056] Step 201: Receive a memory allocation request, which is used to request to allocate a memory range for the target VM.

[0057] Among them, the hardware resources of the physical machine are divided into the REE side and the TEE side. The REE side includes multiple VMs, and the target VM in step 201 is any one of the multiple VMs.

[0058] In a possible implementation, the memory allocation request is triggered by a physical machine user to instruct the operating system kernel of the physical machine to create a target VM based on the hardware resources and allocate a memory range for the target VM from the physical memory. Moreover, when requesting to allocate a memory range for the target VM, the size of the memory range required by the target VM can be carried in the memory allocation request, so that when the operating system kernel allocates the memory range, it can divide a memory range that meets its requirements from the physical memory for the target VM.

[0059] It should be understood that the memory range allocated to the target VM can be an encrypted memory range or an unencrypted ordinary memory range, depending on whether an encrypted memory range is partitioned in the physical memory and the data security requirements of the target VM. If no encrypted memory range is partitioned in the physical memory, all VMs in the physical machine use ordinary memory ranges; if multiple encrypted memory ranges are partitioned in the physical memory, an encrypted memory range can be allocated to some VMs according to the settings of the physical machine user or to the target VM according to the request of the target VM user. Here, the encrypted memory range refers to a memory range in which data entering and leaving the encrypted memory range is encrypted and decrypted using a key. Only the corresponding VM can access the data in the encrypted memory range, while other VMs cannot access the encrypted memory range or cannot correctly decrypt the ciphertext data stored therein. For an ordinary memory range, plaintext data is stored therein, and other VMs or the virtual machine monitor in this physical machine can also access it.

[0060] When protecting data in units of VMs, an encrypted memory range needs to be allocated to each VM to ensure the data security in the encrypted memory range corresponding to each VM. Therefore, in the embodiments of this application, taking the request of the target VM to allocate an encrypted memory range as an example, the memory management method will be introduced.

[0061] Optionally, the above memory allocation request may also carry memory indication information, which is used to indicate that the memory range allocated to the target VM is an encrypted memory range or an ordinary encrypted memory range. The embodiments of this application do not limit this.

[0062] Step 202: Obtain the sizes, physical addresses, and allocation statuses of multiple encrypted memory ranges through the operating system kernel. The allocation status is used to indicate whether the encrypted memory range has been allocated. The multiple encrypted memory ranges correspond to different keys.

[0063] It should be understood that the operating system kernel, as the first-layer software extension of the physical machine hardware resources, is responsible for managing the processes, memory, device drivers, files, and network systems of the entire physical machine operating system, and determines the performance and stability of the operating system.

[0064] In the embodiments of this application, the operating system kernel can create and manage multiple VMs based on the hardware resources of the physical machine. Based on this, when implementing memory management in this application, the information of multiple encrypted memory ranges partitioned in the physical memory can be directly indicated to the operating system kernel, so that when the operating system kernel creates the target VM, the corresponding relationship between the target VM and the encrypted memory range can be determined, and thus when accessing memory subsequently, the virtual memory range of the target VM can be directly mapped to the corresponding encrypted memory range.

[0065] In some embodiments, before performing the above step 202, the process by which the processor indicates information about multiple encrypted memory regions to the operating system kernel may be as follows: Read the encrypted memory configuration information in the boot firmware, where the encrypted memory configuration information is used to indicate the number and size of multiple encrypted memory regions; Based on the number and size of the multiple encrypted memory regions, divide multiple encrypted memory regions from the physical memory; Indicate the sizes and physical addresses of the multiple encrypted memory regions to the operating system kernel.

[0066] That is, make corresponding modifications to the boot firmware of the physical machine to write the encrypted memory configuration information in the boot firmware. In this way, after the physical machine is powered on and starts, when the boot firmware is first run, it can read the encrypted memory configuration information in the boot firmware and divide multiple encrypted memory regions from the physical memory.

[0067] Optionally, after dividing the multiple encrypted memory regions, the processor may mark the multiple memory encrypted regions as the reserved state, so that when the operating system starts and runs normally, it is not affected by high-privilege code (such as the Hypervisor).

[0068] Among them, the encrypted memory configuration information includes the number and size of the encrypted memory regions set by the physical machine user, indicating that after the processor reads the encrypted memory configuration information, it can divide multiple encrypted memory regions from the physical memory according to the number and size required by the physical machine user.

[0069] In a possible implementation manner, the process of writing the encrypted memory configuration information in the boot firmware may be as follows: Display a configuration interface, where the configuration interface is used to instruct the user to input the number and size of multiple encrypted memory regions; Obtain the number and size of the multiple encrypted memory regions from the configuration interface and write the number and size of the multiple encrypted memory regions into the boot firmware.

[0070] In the case where the encrypted memory configuration information is written in the boot firmware, after the physical machine starts, the processor first reads the encrypted memory configuration information from the boot firmware and determines whether the encrypted memory configuration information has changed. If the encrypted memory configuration information has changed, then re-divide multiple encrypted memory regions from the physical memory according to the updated encrypted memory configuration information, and indicate the sizes and physical addresses of the re-divided multiple encrypted memory regions to the operating system kernel. If the encrypted memory configuration information has not changed, then directly run the multiple VMs deployed in the physical machine according to the original configuration. In other words, in the case where the encrypted memory configuration information has not changed, the action of the processor indicating the sizes and physical addresses of the multiple encrypted memory regions to the operating system kernel is only performed once.

[0071] Indicate the sizes and physical addresses of multiple encrypted memory ranges to the operating system kernel, including at least the following two methods:

[0072] In the first method, after the processor divides multiple encrypted memory ranges, it stores the sizes and physical addresses of the multiple encrypted memory ranges in the system registers of the physical machine, so that after the operating system of the physical machine starts up normally, the operating system kernel can obtain the sizes and physical addresses of the multiple encrypted memory ranges through the system registers.

[0073] As an example, after each system startup, the operating system kernel can first read the sizes and physical addresses of the multiple encrypted memory ranges from the system registers, and update the information of the multiple encrypted memory ranges stored in itself based on the read information.

[0074] As another example, when creating a new VM each time, the operating system kernel can also read the sizes and physical addresses of the multiple encrypted memory ranges from the system registers to allocate an encrypted memory range for the newly created VM.

[0075] In the second method, after the processor divides multiple encrypted memory ranges, it transmits the sizes and physical addresses of the multiple encrypted memory ranges to the operating system kernel through the advanced configuration and power management (ACPI) interface.

[0076] Optionally, the operating system kernel uses a structure array to manage the information of multiple encrypted memory ranges, so that when creating a target VM, based on this structure array, it can query the sizes and allocation status of the multiple encrypted memory ranges. For example, by polling, it sequentially queries the allocation status and range sizes of each encrypted memory range in the structure array, and selects an encrypted memory range to allocate to the target VM.

[0077] In some embodiments, the processor accesses physical memory through a memory controller. The memory controller is an electronic device that controls physical memory within a computer system and is responsible for data exchange between physical memory and the processor. It can be located between the processor and physical memory or integrated in the processor. In the case of running multiple VMs on a physical machine, when multiple VMs access physical memory, the memory controller performs memory address conversion between virtual memory ranges and physical memory ranges and performs data read and write operations in physical memory.

[0078] Based on this, after dividing multiple encrypted memory ranges from physical memory, it is also necessary to indicate the physical addresses of the multiple encrypted memory ranges to the memory controller so that the memory controller generates and stores the keys corresponding to the multiple encrypted memory ranges.

[0079] Optionally, after receiving the physical addresses of multiple encrypted memory ranges, the memory controller may establish the correspondence between the multiple encrypted memory ranges and the keys based on the physical addresses of the multiple encrypted memory ranges, and store the correspondence.

[0080] Among them, the keys generated by the memory controller for multiple encrypted memory ranges are different, that is, one encrypted memory range corresponds to one key. In this way, after allocating the encrypted memory range to the VM, it can be ensured that the data of the VM is encrypted and stored using a unique key, realizing the memory encryption scheme of "one virtual machine, one key".

[0081] In a possible implementation, when encrypting and decrypting the data entering and leaving the physical memory, a memory encryption engine (MEE) is added to the physical machine hardware. The MEE supports the ability to encrypt the data of different encrypted memory ranges using multiple keys. In this way, when the memory controller reads and writes data from the encrypted memory range, the MEE can encrypt and decrypt the read and written data using the key corresponding to the encrypted memory range, ensuring data security.

[0082] Step 203: Select an encrypted memory range from the multiple encrypted memory ranges as the target encrypted memory range based on the sizes and allocation situations of the multiple encrypted memory ranges.

[0083] Among them, the target encrypted memory range is the encrypted memory range that has not been allocated to the VM among the multiple encrypted memory ranges, and the size of the target encrypted memory range meets the code and data storage requirements of the target VM.

[0084] In a possible implementation, the implementation process of the above step 203 may be: determining the unallocated encrypted memory ranges from the multiple encrypted memory ranges as candidate encrypted memory ranges based on the allocation situations of the multiple encrypted memory ranges; determining the target encrypted memory range from the candidate encrypted memory ranges based on the sizes of the candidate encrypted memory ranges, and the size of the target encrypted memory range is not less than the size of the memory range requested by the target VM to be allocated.

[0085] Step 204: Allocate the target encrypted memory range to the target VM based on the physical address of the target encrypted memory range.

[0086] It should be noted that to prevent a situation where one VM maps its virtual memory range to multiple encrypted memory ranges and multiple VMs share one encrypted memory range, when allocating the encrypted memory range to the target VM, the entire target encrypted memory range is allocated to the target VM, that is, only the code and data of the target VM are stored in the target encrypted memory range, and the memory range is not shared with other VMs.

[0087] In a possible implementation, the implementation process of step 204 may be: determining the virtual address of the virtual memory range of the target VM; generating an address mapping relationship between the virtual memory range and the target encrypted memory range based on the physical address of the target encrypted memory range; loading the code of the target VM into the target encrypted memory range, and running the target VM.

[0088] In some embodiments, after allocating the target encrypted memory range to the target VM, it is also necessary to update the allocation status of the target encrypted memory range through the operating system kernel to indicate that the target encrypted memory range has been allocated.

[0089] That is to say, after the operating system kernel allocates the target encrypted memory range to the target VM, it marks that the target encrypted memory range has been allocated, and will not allocate the target encrypted memory range to other VMs for use subsequently, thus avoiding the situation where multiple VMs share an encrypted memory range and ensuring the data security of the target VM.

[0090] In some embodiments, in response to a shutdown request of the target VM, the target encrypted memory range is released, and the allocation status of the target encrypted memory range is updated through the operating system kernel to indicate that the target encrypted memory range is not allocated.

[0091] Similar to the process of creating the target VM, when the operating system kernel manages multiple encrypted memory ranges, if the target VM has been shut down, it promptly releases the encrypted memory range corresponding to the target VM and updates the allocation status of the encrypted memory range. In this way, by promptly updating the allocation status of multiple encrypted memory ranges, the utilization rate of multiple encrypted memory ranges is improved.

[0092] In summary, in the memory management method provided in the embodiments of the present application, the operating system kernel manages information of multiple encrypted memory ranges, such as physical addresses, sizes, and allocation statuses, while the memory controller stores keys of multiple encrypted memory ranges. Based on this, when the target VM accesses physical memory through the operating system kernel, the operating system kernel can directly map the virtual address of the target VM to the physical address of the target encrypted memory range, and then send the physical address of the target encrypted memory range to the memory controller to instruct the memory controller to perform data operations within the target encrypted memory range and encrypt and decrypt the data using the key corresponding to the target encrypted memory range.

[0093] It can be seen that the operating system kernel can directly determine the physical address of the encrypted memory range of the VM based on the allocation status of multiple encrypted memory ranges, and thus access the corresponding encrypted memory range based on this physical address. That is to say, only the physical address is transmitted between the processor and the physical memory, without carrying the identifier of the VM, so there is no need to expand the bus.

[0094] In the embodiments of the present application, since the operating system kernel is responsible for creating and managing multiple VMs running in a physical machine, and the operating system kernel can access physical memory, therefore, the embodiments of the present application indicate the sizes and physical addresses of multiple encrypted memory ranges to the operating system kernel, so that when the operating system kernel creates a VM, it allocates a corresponding encrypted memory range for the VM from multiple encrypted memory ranges divided from the physical memory, thereby determining the correspondence between the VM and the encrypted memory range in the operating system kernel. In this way, when any VM accesses the physical memory through the operating system kernel, the operating system kernel can directly map the virtual address of the VM to the physical address of the encrypted memory range, and then read and write data in the corresponding encrypted memory range based on this physical address in the physical memory. This process does not require changing the hardware architecture and can be applied to different processor architectures.

[0095] To facilitate the understanding of the above memory management method and implement it in a computer device, next, the embodiments of the present application will first take a processor with a typical ARM architecture as an example to explain the process of implementing memory management.

[0096] See Figure 3 , based on this processor architecture, the embodiments of the present application can implement memory management through a combination of software and hardware. At the hardware level, a MEE is added to the physical memory to encrypt and decrypt the reading and writing of data in multiple encrypted memory ranges in the physical memory, thereby ensuring the security of data when entering and leaving the encrypted memory ranges.

[0097] At the software level, encrypted memory configuration information is written into the boot firmware, so that when the physical machine starts up, the processor can divide multiple encrypted memory ranges from the physical memory based on the encrypted memory configuration information in the boot firmware, and instruct the MEE to configure different keys for the multiple encrypted memory ranges. In this way, the configuration of the encrypted memory ranges can be completed during the system startup process. After the configuration of the encrypted memory ranges is completed, the operation starts and runs normally. The processor stores the sizes and physical addresses of the multiple encrypted memory ranges in the system register, so that the operating system kernel can read, store, and manage the sizes and physical addresses of the multiple encrypted memory ranges from the system register to ensure that each VM that needs to use encrypted memory runs in an independent encrypted memory range.

[0098] Among them, without updating the native architecture, a new encrypted memory management module is added to the operating system kernel to manage and allocate multiple encrypted memory ranges, so as to distinguish it from the memory management module (i.e., the KVM module) that realizes the allocation and management of unencrypted ordinary memory ranges in the native architecture.

[0099] When the operating system kernel stores the sizes and physical addresses of multiple encrypted memory ranges, the operating system kernel can directly allocate encrypted memory ranges for the target VM when the target VM is created to determine the correspondence between the target VM and the target encrypted memory ranges; the operating system kernel can access the corresponding target encrypted memory ranges when the target VM is running to implement data reading and writing; the operating system kernel can also release the memory resources of the target encrypted memory ranges in a timely manner when the target VM is shut down.

[0100] In the RAM architecture, the REE side includes the user mode, the kernel mode, and the HYP mode. These three modes correspond to different hardware resources on the REE side, and the privilege levels of these three modes increase in sequence, that is, the privilege level of the user mode is the lowest, and the privilege level of the HYP mode is the highest. Among them, the VM runs in the user mode and the kernel mode on the REE side. That is to say, the guest operating system (guest OS) of the VM runs in the user mode and the kernel mode on the REE side. And the operating system kernel of the physical machine runs in the HYP mode. In the HYP mode, the processor can access all hardware resources (such as registers, memory, caches, peripherals, etc.) of the user mode, the kernel mode, and the HYP mode.

[0101] It should be understood that Figure 3 only the example where the MEE uses the key Key1 to encrypt and decrypt the data in the encrypted memory range (Area1) for entering and exiting VM1 and uses the key Key2 to encrypt and decrypt the data in the encrypted memory range (Area2) for entering and exiting VM2 is given. In actual applications, the physical memory may also include more encrypted memory ranges, and the keys corresponding to each encrypted memory range are different. These encrypted memory ranges can be allocated by the operating system kernel to different VMs.

[0102] In addition, referring to Figure 3 , at the software level, the exception levels of EL0-EL3 are defined in the ARM architecture processor. EL0 is the user level, and EL1 is the kernel level. Therefore, the user VMM program can run at the EL0 and EL1 levels. EL2 and EL3 are virtualization extension levels for implementing virtualization and security extensions. The operating system kernel of the physical machine runs at the EL2 level, and the boot firmware of the physical machine runs at the EL3 level.

[0103] Based on the above Figure 3, Next, taking a physical machine as the server, and the physical machine using virtualization modules such as QEMU and KVM of the Linux operating system to create VMs as an example, the process of implementing memory management will be explained. To distinguish from the multi-key memory encryption (MKMEE) scheme of the hardware, the scheme of implementing memory management based on virtualization components such as QEMU and KVM of the Linux operating system can be called software multi-key memory encryption (SMKMEE).

[0104] Among them, the QEMU module, as an emulator, can complete user program simulation and system virtualization simulation. When performing user program simulation, QEMU can run a binary file compiled for one platform on another different platform; when performing system virtualization simulation, QEMU can simulate a complete system VM, which has its own virtual CPU, chipset, virtual memory, and various virtual external devices, and can present a hardware view identical to that of the physical machine for the operating system and application software running in the VM. The KVM module is a module in the operating system kernel for implementing virtualization. It exports a series of interfaces to the user space, and applications running in user mode can use these interfaces to create VMs.

[0105] When specifically implementing virtualization, the KVM module is responsible for the most core parts of CPU virtualization and memory virtualization, and uses the QEMU module as a user-space component to be responsible for simulating a large number of peripherals, which are collectively referred to as the QEMU-KVM module here.

[0106] See Figure 4 , At the software level, the physical machine user writes encrypted memory configuration information in the memory configuration module in the boot firmware, enables the memory encryption feature of MEE, and divides multiple encrypted memory ranges from the physical memory. Then, the sizes and physical addresses of the multiple encrypted memory ranges are reported to the Linux operating system kernel through system registers or ACPI interfaces.

[0107] In the operating system kernel, the SMKMEE module used to implement the management and allocation of encrypted memory ranges uses a structure array to manage the allocation of multiple encrypted memory ranges, including whether they have been allocated and the handle when the guest process of the allocated VM uses the SMKMEE module. And modify the source code of the QEMU-KVM module to add an option to support creating VMs that use encrypted memory, so that users can indicate whether the VM uses encrypted memory ranges or unencrypted ordinary memory ranges when creating a VM.

[0108] When creating a target VM using the QEMU-KVM module, first query the allocation status of multiple encrypted memory ranges and the sizes of multiple encrypted memory ranges through the SMKMEE module. If a target encrypted memory range that is not allocated and whose size meets the requirements of the target VM is queried, then map the physical address of the target encrypted memory range to the virtual memory range of the target VM through the SMKMEE module, record the corresponding guest handle, and mark the target encrypted memory range as allocated. After the SMKMEE module successfully establishes the address mapping relationship of the target encrypted memory range for the QEMU-KVM module, the QEMU-KVM module loads the target VM into the target encrypted memory range and runs the target VM.

[0109] Among them, when implementing the memory management method provided in the embodiments of the present application, the above SMKMEE module is a newly added driver module in the Linux operating system kernel and is the core component for implementing the above SMKMEE. The main functions it provides include two parts: the memory address mapping between the virtual memory range of the VM guest and the encrypted memory range, and the maintenance and management of information about multiple encrypted memory ranges, such as the allocation status of multiple encrypted memory ranges.

[0110] In some embodiments, the SMKMEE module completes the mapping of physical memory by providing an application programming interface (API) to the user layer, which may include the following interfaces:

[0111] (1) int(*open)(struct inode*, struct file*)

[0112] This interface points to a function named open, and the open function accepts two parameters: struct inode* and struct file*, and returns an int value. In the Linux operating system, struct inode represents the metadata of a file or directory, such as permissions, size, creation time, etc.; struct file represents an open file descriptor, which contains information such as the read / write position and operation mode of the file.

[0113] In addition, when using the open function pointer to open a file and return a file descriptor, if the file opening fails, the function will return an error code (usually -1), otherwise it will return 0 or a non-negative file descriptor.

[0114] In an embodiment of the present application, this interface is used to provide a handle of a driver module (i.e., the SMKMEE module) in the operating system kernel to a legitimate user. When the user obtains the handle of the SMKMEE module by calling this interface, the SMKMEE module will also obtain the handle of this user and use it as the client identifier corresponding to the target VM to be created.

[0115] (2) int(*release)(struct inode*, struct file*)

[0116] This interface points to a function named release, and this release function accepts two parameters: struct inode* and struct file*, and returns an int type value. In the Linux operating system, when a file is no longer in use, it is usually necessary to call the release function to close the file and release related resources.

[0117] When a user process finishes operating on a file and is ready to close the file, it will call this release function. If the file is successfully closed and all resources are released, this release function will return 0 or a non - negative value; if an error occurs when closing the file, this release function will return an error code (usually -1).

[0118] In an embodiment of the present application, when the target VM exits or the QEMU - KVM program is closed, the operating system kernel will automatically call this interface to clean the encrypted memory area of the target VM through the Release function, and update the data structure of multiple encrypted memory areas managed inside the SMKMEE module to indicate that the allocation status of the encrypted memory area corresponding to the target VM is unallocated.

[0119] (3) int(*mmap)(struct file*, struct vm_area_struct*)

[0120] This interface points to a function named mmap, and this mmap function accepts two parameters: struct file* and struct vm_area_struct*, and returns an int type value. In the Linux operating system, mmap is a system call used to map a file or other object into physical memory, and this interface is used to point to the function in the operating system kernel that implements this function.

[0121] In specific implementation, the mmap function is used to create a new physical memory address mapping in the virtual memory range of the client process. The struct file* parameter represents the file to be mapped, and the struct vm_area_struct* parameter is the relevant information about the memory mapping range. If the memory address mapping is successful, the mmap function returns a pointer to the new memory mapping range. If it fails, it returns an error code (usually -1).

[0122] In the embodiment of the present application, by calling this interface, the encrypted memory range can be mapped to the virtual memory range of the target VM to establish a memory address mapping relationship between the virtual memory range of the target VM and the encrypted memory range.

[0123] (4) int(*unlocked_ioctl)(struct file*, unsigned int, unsigned long)

[0124] This interface is used to provide additional user logic processing, supporting custom options and input parameters. In the SMKMEE module, this interface is used to extend / add new options and processing logic.

[0125] (5) int(*compat_ioctl)(struct file*, unsigned int, unsigned long)

[0126] This interface points to a function named compat_ioctl, and the compat_ioctl function accepts three parameters: struct file*, unsigned int, and unsigned long, and returns an int value. In the Linux operating system, the compat_ioctl function is an ioctl operation for handling compatibility issues between traditional (32-bit) and new (64-bit) user spaces, usually implemented by device drivers to support user space programs to interact with devices using the ioctl system call.

[0127] In the embodiment of the present application, by calling this interface, compatibility capabilities can be provided for 32-bit user programs running in a 64-bit operating system kernel.

[0128] To implement the function of mapping the physical memory range to the user space, the SMKMEE module needs to mark the reserved state of multiple encrypted memory ranges divided by the encrypted memory configuration information in the boot firmware, so that the memory address mapping relationship between multiple encrypted memory ranges and the ordinary memory ranges not managed by the operating system kernel is not affected. In specific implementation, the SMKMEE module also needs to use the following functions:

[0129] (1) void* memremap(resource_size_t offset, size_t size, unsigned long flags)

[0130] The memremap function is used to operate on an existing memory mapping, and is typically used in the memory management code of an operating system rather than directly in a user-level program.

[0131] Among them, in the memremap function, offset is a parameter of type resource_size_t, indicating the offset of the memory range to be mapped; size is a parameter of type size_t, indicating the size of the memory range to be mapped; flags is a parameter of type unsigned long, indicating the characteristics of the memory mapping, such as whether it is writable, executable, whether physical pages need to be reserved, etc. The return value of the memremap function is a pointer of type void*, pointing to the newly mapped memory range.

[0132] In the embodiment of this application, this function is provided by the operating system kernel to map a section of memory into cacheable memory.

[0133] (2) int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn, unsigned long size, pgprot_t prot)

[0134] remap_pfn_range is a function in the Linux operating system kernel used to map physical page frames in a memory range. This function is used to handle the situation where the page table entry (PTE) cannot directly represent the physical page frame number (PFN).

[0135] Among them, in the remap_pfn_range function, the vma parameter indicates a pointer to the virtual memory area (VMA) structure of the memory area to be modified; the addr parameter indicates the starting physical address of the mapped memory range; the pfn parameter is the number of the physical page frame; the size parameter indicates the size of the mapped memory range; prot is the memory protection flag, such as readable, writable, executable, etc.

[0136] In an embodiment of the present application, this function is used to map a physical address segment to a target start address, and this function can only map an address size that is an integer multiple of a page (the basic unit of memory management, usually with a size of 4KB).

[0137] Based on the above interfaces and functions, refer to Figure 5 , the memory management process of SMKMEE can implement the memory address mapping from the encrypted memory range to the virtual memory range of the VM through the QEMU-KVM module, the SMKMEE module, and the SMKMEE manager. Specifically, it can include the following steps:

[0138] Step 501: The QEMU-KVM module sends a VM creation request to the SMKMEE module to request the creation of a target VM, where the target VM is the VM that requires the use of the encrypted memory range.

[0139] Among them, this VM creation request can be implemented by calling the above open function.

[0140] Step 502: The SMKMEE module responds to the VM creation request and returns a first message (such as ok) indicating support for creating the target VM.

[0141] Among them, when the SMKMEE module responds to the VM creation request, it may also return a second message (such as error) indicating non-support for creating the target VM.

[0142] Step 503: The QEMU-KVM module responds to the first message and sends a memory allocation request to the SMKMEE module to request the allocation of a corresponding encrypted memory range for the target VM.

[0143] Among them, this memory allocation request can be implemented by calling the above mmap function. The size of the encrypted memory range required by the target VM is carried in the memory allocation request.

[0144] Step 504: The SMKMEE module responds to the memory allocation request and sends a query request to the SMKMEE manager.

[0145] Among them, this query request is used to request the SMKMEE manager to allocate an encrypted memory range for the target VM.

[0146] Step 505: If the SMKMEE manager determines a target encrypted memory range that meets the requirements of the target VM from multiple encrypted memory ranges based on the size of the encrypted memory range required by the target VM, it sends a memory allocation success message to the SMKMEE module, and the memory allocation success message carries the size and physical address of the target encrypted memory range.

[0147] If the SMKMEE manager fails to determine the target encrypted memory range from multiple encrypted memory ranges, it sends a memory allocation failure message (such as error) to the SMKMEE module.

[0148] Step 506: In response to the memory allocation success message, the SMKMEE module sends a memory mapping message to the physical memory to map the target encrypted memory range in the physical memory to the virtual memory range of the target VM.

[0149] Among them, the memory address mapping can be achieved by calling the above-mentioned memremap function.

[0150] Step 507: If the memory mapping is successful, the physical memory returns a memory mapping success message (such as ok) to the SMKMEE module.

[0151] Optionally, if the memory mapping fails, the physical memory returns a memory mapping failure message to the SMKMEE module.

[0152] Step 508: In response to the memory mapping success message, the SMKMEE module sends an update request to the SMKMEE manager.

[0153] Among them, the update request is used to request the SMKMEE manager to update the allocation status of the target encrypted memory range to indicate that the target encrypted memory range has been allocated.

[0154] Step 509: In response to the update request, the SMKMEE manager returns an update success message (such as ok) to the SMKMEE module.

[0155] In the case of update failure, the SMKMEE manager returns an update failure message (such as error) to the SMKMEE module.

[0156] Step 510: If the memory mapping is successful, the SMKMEE module sends the physical address of the target encrypted memory range to the QEMU-KVM module to instruct the QEMU-KVM module to load the target VM into the target encrypted memory for running.

[0157] Step 511: When it is necessary to shut down the target VM, the QEMU-KVM module sends a VM shutdown request to the SMKMEE module to instruct to shut down the target VM.

[0158] Step 512: In response to the target VM shutdown request, the SMKMEE module sends a resource release request to the SMKMEE manager to request to release the memory resources of the target encrypted memory range corresponding to the target VM.

[0159] Among them, the resource release request can carry the identification information of the target encrypted memory range, such as the physical address.

[0160] In specific implementation, the resource release request can be implemented by calling the above-mentioned release function.

[0161] Step 513: In response to the resource release message, the SMKMEE manager returns a resource release success message (such as ok) to the SMKMEE module.

[0162] When the SMKMEE manager fails to release the memory resources of the target encrypted memory range, it returns a resource release failure message (such as error) to the SMKMEE module.

[0163] Step 514: In response to the resource release success message, the SMKMEE module returns a VM shutdown success message to the QEMU-KVM module.

[0164] If the resource release fails, at this time the SMKMEE module returns a VM shutdown failure message to the QEMU-KVM module.

[0165] It should be noted that Figure 5 The requests or messages transmitted between multiple modules are highlighted. For the specific operations performed by each module, reference can be made to the above text description, Figure 5 which is not elaborated herein.

[0166] It should be understood that Figures 3 - 5 The embodiments are merely an exemplary implementation scheme given to explain the memory management method provided by the embodiments of the present application, and do not constitute a limitation on the specific implementation scheme of the memory management method. Based on the same technical concept of the present application, those skilled in the art can also use other virtualization modules, interfaces, functions, etc. to implement memory management, and the embodiments of the present application do not limit this.

[0167] Figure 6 is a schematic structural diagram of a memory management device provided by the embodiments of the present application. The memory management device can be implemented as part or all of a computer device by software, hardware, or a combination of both. Refer to Figure 6 As shown in, the memory management device 600 includes: a receiving module 601, a memory information acquisition module 602, an encrypted memory determination module 603, and an encrypted memory allocation module 604.

[0168] The receiving module 601 is configured to receive a memory allocation request, where the memory allocation request is used to request to allocate a memory range for the target virtual machine VM;

[0169] The memory information acquisition module 602 is configured to obtain the sizes, physical addresses, and allocation statuses of multiple encrypted memory ranges through the operating system kernel. The allocation status is used to indicate whether the encrypted memory range has been allocated, and the multiple encrypted memory ranges correspond to different keys;

[0170] An encrypted memory determination module 603, configured to select an encrypted memory section as a target encrypted memory section from multiple encrypted memory sections based on the sizes and allocation conditions of the multiple encrypted memory sections;

[0171] An encrypted memory allocation module 604, configured to allocate the target encrypted memory section to a target VM based on the physical address of the target encrypted memory section.

[0172] Optionally, the apparatus 600 further includes:

[0173] A configuration information reading module, configured to read encrypted memory configuration information in a boot firmware, where the encrypted memory configuration information is used to indicate the number and size of multiple encrypted memory sections;

[0174] An encrypted memory partitioning module, configured to partition multiple encrypted memory sections from physical memory based on the number and size of the multiple encrypted memory sections;

[0175] A memory information indication module, configured to indicate the sizes and physical addresses of the multiple encrypted memory sections to an operating system kernel.

[0176] Optionally, the apparatus 600 further includes:

[0177] A memory address indication module, configured to indicate the physical addresses of the multiple encrypted memory sections to a memory controller, so that the memory controller generates and stores keys corresponding to the multiple encrypted memory sections.

[0178] Optionally, the apparatus 600 further includes:

[0179] A display module, configured to display a configuration interface, where the configuration interface is used to instruct a user to input the number and size of multiple encrypted memory sections;

[0180] An information writing module, configured to obtain the number and size of the multiple encrypted memory sections from the configuration interface, and write the number and size of the multiple encrypted memory sections into the boot firmware.

[0181] Optionally, the apparatus 600 further includes:

[0182] A memory information update module, configured to update the allocation condition of the target encrypted memory section through the operating system kernel to indicate that the target encrypted memory section has been allocated.

[0183] Optionally, the apparatus 600 further includes:

[0184] A memory release module, configured to release the target encrypted memory section in response to a shutdown request of the target VM, and update the allocation condition of the target encrypted memory section through the operating system kernel to indicate that the target encrypted memory section is not allocated.

[0185] Optionally, the hardware resources of the physical machine are divided into a Rich Execution Environment (REE) side and a Trusted Execution Environment (TEE) side. The REE side includes multiple VMs, and the target VM is any one of the multiple VMs.

[0186] In the embodiments of the present application, since the operating system kernel is responsible for creating and managing multiple VMs running in the physical machine, and the operating system kernel can access the physical memory, therefore, the embodiments of the present application indicate the sizes and physical addresses of multiple encrypted memory ranges to the operating system kernel, so that when the operating system kernel creates a VM, it allocates a corresponding encrypted memory range for the VM from the multiple encrypted memory ranges divided from the physical memory, thereby determining the correspondence between the VM and the encrypted memory range in the operating system kernel. Thus, when any VM accesses the physical memory through the operating system kernel, the operating system kernel can directly map the virtual address of the VM to the physical address of the encrypted memory range, and then read and write data in the corresponding encrypted memory range based on this physical address in the physical memory. This process does not require changing the hardware architecture and can be applicable to different processor architectures.

[0187] It should be noted that when the memory management device provided in the above embodiments manages multiple encrypted memory ranges in the physical memory through the operating system kernel, only the above division of each functional module is used for illustration. In actual applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the memory management device provided in the above embodiments and the embodiments of the memory management method belong to the same concept, and the specific implementation process is detailed in the method embodiments and will not be repeated here.

[0188] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or a wireless manner (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a digital versatile disc (DVD)), or a semiconductor medium (such as a solid state disk (SSD)), etc. It should be noted that the computer-readable storage medium mentioned in the embodiments of the present application can be a non-volatile storage medium, in other words, it can be a non-transitory storage medium.

[0189] It should be understood that the "plurality" mentioned herein refers to two or more. In the description of the embodiments of the present application, unless otherwise specified, " / " means "or". For example, A / B can mean A or B; the "and / or" herein is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, terms such as "first" and "second" are used to distinguish the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the terms such as "first" and "second" do not limit the quantity and execution order, and the terms such as "first" and "second" do not necessarily mean different.

[0190] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of the present application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions.

[0191] The above are the embodiments provided by the present application, which are not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A memory management method, characterized in that: The method comprises: Receive a memory allocation request, where the memory allocation request is used to request allocation of a memory interval for a target virtual machine VM; Acquire, through the operating system kernel, the sizes, physical addresses, and allocation conditions of multiple encrypted memory intervals, wherein the allocation conditions are used to indicate whether the encrypted memory interval has been allocated, and the multiple encrypted memory intervals correspond to different keys; Based on the sizes and allocation conditions of the multiple encrypted memory intervals, selecting an encrypted memory interval from the multiple encrypted memory intervals as a target encrypted memory interval; Based on a physical address of the target encrypted memory interval, the target encrypted memory interval is allocated to the target VM.

2. The method according to claim 1, characterized in that Before obtaining the sizes, physical addresses and allocation conditions of the plurality of encrypted memory intervals through the operating system kernel, the method further includes: Reading encrypted memory configuration information in the boot firmware, the encrypted memory configuration information being used to indicate the number and size of the multiple encrypted memory intervals; Based on the number and size of the multiple encrypted memory intervals, divide the multiple encrypted memory intervals from the physical memory; The sizes and physical addresses of the multiple encrypted memory intervals are indicated to the operating system kernel.

3. The method according to claim 2, characterized in that After dividing the multiple encrypted memory intervals from the physical memory based on the number and size of the multiple encrypted memory intervals, the method further includes: The physical addresses of the multiple encrypted memory intervals are indicated to a memory controller so that the memory controller generates and stores keys corresponding to the multiple encrypted memory intervals.

4. The method according to claim 2, characterized in that Before reading the encrypted memory information in the startup firmware, the method further includes: Displaying a configuration interface, wherein the configuration interface is used to instruct the user to input the number and size of the multiple encrypted memory intervals; The number and size of the multiple encrypted memory intervals are obtained from the configuration interface, and the number and size of the multiple encrypted memory intervals are written into the startup firmware.

5. The method according to any one of claims 1 to 4, characterized in that: After allocating the target encrypted memory interval to the target VM, the method further includes: The allocation status of the target encrypted memory interval is updated by the operating system kernel to indicate that the target encrypted memory interval has been allocated.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: In response to a shutdown request of the target VM, the target encrypted memory interval is released, and the allocation status of the target encrypted memory interval is updated through the operating system kernel to indicate that the target encrypted memory interval is not allocated.

7. The method according to any one of claims 1 to 6, characterized in that: The hardware resources of the physical machine are divided into a rich execution environment (REE) side and a trusted execution environment (TEE) side. The REE side includes multiple VMs, and the target VM is any one of the multiple VMs.

8. A memory management device, characterized in that: The device comprises: A receiving module, used for receiving a memory allocation request, wherein the memory allocation request is used for requesting to allocate a memory interval for a target virtual machine VM; A memory information acquisition module, used to acquire the size, physical address and allocation status of multiple encrypted memory intervals through the operating system kernel, wherein the allocation status is used to indicate whether the encrypted memory interval has been allocated, and the multiple encrypted memory intervals correspond to different keys; an encrypted memory determination module, configured to select an encrypted memory interval from the multiple encrypted memory intervals as a target encrypted memory interval based on the sizes and allocation conditions of the multiple encrypted memory intervals; The encrypted memory allocation module is used to allocate the target encrypted memory interval to the target VM based on the physical address of the target encrypted memory interval.

9. The device according to claim 8, characterized in that The device also includes: A configuration information reading module, used to read the encrypted memory configuration information in the boot firmware, wherein the encrypted memory configuration information is used to indicate the number and size of the multiple encrypted memory intervals; An encrypted memory partitioning module, configured to partition the plurality of encrypted memory intervals from the physical memory based on the number and size of the plurality of encrypted memory intervals; A memory information indication module is used to indicate the sizes and physical addresses of the multiple encrypted memory intervals to the operating system kernel.

10. The device according to claim 9, characterized in that The device also includes: The memory address indication module is used to indicate the physical addresses of the multiple encrypted memory intervals to the memory controller, so that the memory controller generates and stores keys corresponding to the multiple encrypted memory intervals.

11. The device according to claim 9, characterized in that The device also includes: A display module, used to display a configuration interface, wherein the configuration interface is used to instruct a user to input the number and size of the plurality of encrypted memory intervals; An information writing module is used to obtain the number and size of the multiple encrypted memory intervals from the configuration interface, and write the number and size of the multiple encrypted memory intervals into the startup firmware.

12. The device according to any one of claims 8 to 11, characterized in that: The device also includes: A memory information updating module is used to update the allocation status of the target encrypted memory interval through the operating system kernel to indicate that the target encrypted memory interval has been allocated.

13. The device according to any one of claims 8 to 12, characterized in that: The device also includes: A memory release module is used to release the target encrypted memory interval in response to a shutdown request of the target VM, and update the allocation status of the target encrypted memory interval through the operating system kernel to indicate that the target encrypted memory interval is not allocated.

14. The device according to any one of claims 8 to 13, characterized in that The hardware resources of the physical machine are divided into a rich execution environment (REE) side and a trusted execution environment (TEE) side. The REE side includes multiple VMs, and the target VM is any one of the multiple VMs.

15. A computer device, characterized in that: The computer device includes a processor and a memory; The memory is used to store computer programs; The processor is configured to execute the computer program to implement the steps of the method according to any one of claims 1 to 7.

16. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 7 are implemented.

17. A computer program product, characterized in that The computer program product stores computer instructions, and when the computer instructions are executed by a processor, the steps of the method described in any one of claims 1 to 7 are implemented.

Images