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

Abstract

The present application belongs to the technical field of computers, and discloses a memory management method and apparatus, a device, a storage medium, and a computer program. The method comprises: receiving a memory allocation request, the memory allocation request being used to request allocation of a memory range for a target VM; by means of an operating system kernel, acquiring the sizes, physical addresses and allocation conditions of multiple encrypted memory ranges, the multiple encrypted memory ranges corresponding to different keys; on the basis of the sizes and allocation conditions of the multiple encrypted memory ranges, selecting one encrypted memory range from among the multiple encrypted memory ranges to be a target encrypted memory range; and, on the basis of the physical address of the target encrypted memory range, allocating the target encrypted memory range to the target VM. It can thus be seen that, since the operating system kernel has, in the memory allocation stage, determined the physical address of the encrypted memory range of the target VM, the corresponding encrypted memory range can thus be accessed on the basis of the physical address, without needing to change the hardware architecture; the described method can be suitable for different processor architectures.

Description

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

[0001] This application claims priority to Chinese patent application number 202311553381.1, filed on November 20, 2023, entitled “Memory management method, apparatus, device, storage medium and computer program,” the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a memory management method, apparatus, device, storage medium, and computer program. Background Art

[0003] In the hardware architecture of advanced RISC machines (ARM), hardware resources can be divided into a rich execution environment (REE) side and a trusted execution environment (TEE) side based on trustzone technology. The TEE side is more secure than the REE side. The processor can work on the REE side as well as the TEE side, and can switch back and forth between the REE and TEE sides. The REE side includes multiple virtual machines (VMs), each of which runs a guest operating system (guest OS). However, the current ARM architecture does not define a memory encryption implementation scheme, and it is impossible to assign a key to each VM on the native architecture to encrypt and decrypt the data in the physical memory interval corresponding to the VM. In other words, in the absence of a "one virtual machine, one key" memory encryption scheme defined in the ARM architecture, 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.

[0004] Summary of the Invention

[0005] This application provides a memory management method, apparatus, device, storage medium, and computer program that can manage multiple encrypted memory intervals in physical memory without changing the native architecture, thereby implementing "one virtual machine, one key" memory encryption. The technical solution is as follows.

[0006] In a first aspect, a memory management method is provided, the method comprising:

[0007] 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; obtain, through an operating system kernel, the sizes, physical addresses, and allocation status of multiple encrypted memory intervals, where 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; based on the sizes and allocation status of the multiple encrypted memory intervals, select an encrypted memory interval from the multiple encrypted memory intervals as a target encrypted memory interval; and based on the physical address of the target encrypted memory interval, allocate the target encrypted memory interval to the target VM.

[0008] 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 size and physical address of multiple encrypted memory intervals to the operating system kernel, so that when the operating system kernel creates a VM, it allocates a corresponding encrypted memory interval to the VM from the multiple encrypted memory intervals divided by physical memory, thereby determining the correspondence between the VM and the encrypted memory interval 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 interval, thereby reading and writing data in the corresponding encrypted memory interval in physical memory based on the physical address. This process does not require changing the hardware architecture and can be applied to different processor architectures.

[0009] Optionally, before obtaining the size, physical address and allocation status of multiple encrypted memory intervals through the operating system kernel, the method also includes: reading encrypted memory configuration information in the startup firmware, the encrypted memory configuration information is 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, dividing the multiple encrypted memory intervals from the physical memory; and indicating the size and physical address of the multiple encrypted memory intervals to the operating system kernel.

[0010] In other words, the physical machine's boot firmware is modified to store the encrypted memory configuration information in the boot firmware. This allows the physical machine to read the encrypted memory configuration information from the boot firmware when it first runs after powering on, and then divide the physical memory into multiple encrypted memory areas.

[0011] Optionally, after dividing the multiple encrypted memory intervals, the processor may mark the multiple memory encryption intervals as reserved, so that the operating system is not affected by high-level privileged codes (such as Hypervisor) when it starts and runs normally.

[0012] Optionally, 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 also includes: indicating the physical addresses of the multiple encrypted memory intervals to the memory controller so that the memory controller generates and stores the keys corresponding to the multiple encrypted memory intervals.

[0013] When running multiple VMs on a physical machine, the memory controller performs memory address translation between virtual and physical memory intervals when the VMs access physical memory, and performs data read and write operations in physical memory. Therefore, after partitioning multiple encrypted memory intervals from physical memory, the physical addresses of the multiple encrypted memory intervals must be indicated to the memory controller so that the memory controller can generate and store the keys corresponding to the multiple encrypted memory intervals.

[0014] The memory controller generates different keys for each encrypted memory interval, corresponding to a unique key. This ensures that, when an encrypted memory interval is assigned to a VM, the VM's data is encrypted and stored using a unique key, achieving a "one virtual machine, one key" memory encryption solution.

[0015] Optionally, before reading the encrypted memory information in the startup firmware, the method also 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; obtaining the number and size of the multiple encrypted memory intervals from the configuration interface, and writing the number and size of the multiple encrypted memory intervals into the startup firmware.

[0016] Since the boot firmware is the first program to be run after the physical machine is started, the number and size of the multiple encrypted memory intervals are written into the boot firmware so that the encrypted memory configuration operation can be performed first after the physical machine is powered on.

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

[0018] Optionally, the method further includes: releasing the target encrypted memory interval in response to a shutdown request of the target VM, and updating 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.

[0019] This shows that, when the operating system kernel stores the sizes and physical addresses of multiple encrypted memory intervals, the operating system kernel can directly allocate an encrypted memory interval to the target VM when the target VM is created to determine the correspondence between the target VM and the target encrypted memory interval; the operating system kernel can access the corresponding target encrypted memory interval while the target VM is running to read and write data; the operating system kernel can also promptly release the memory resources of the target encrypted memory interval when the target VM is shut down. In other words, this application uses the operating system kernel to allocate and manage physical memory, and when accessing memory, it can directly address based on the physical address, without carrying VM-related information and thus without the need for an extended bus.

[0020] 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.

[0021] Based on the technical concept of this application, even if the security of the REE side is lower than that of the TEE side, the data of multiple VMs running on the REE side can be protected by encrypting the memory interval, thereby ensuring the data security of multiple VMs on the REE side.

[0022] In a second aspect, a memory management device is provided, wherein the memory management device has the function of implementing the memory management method described in the first aspect. The memory management device includes at least one module, which is used to implement the steps of the memory management method described in the first aspect.

[0023] In a third aspect, a computer device is provided, comprising a processor and a memory, wherein the memory is configured to store a computer program for executing the memory management method provided in the first aspect. 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.

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

[0025] In a fourth aspect, a computer-readable storage medium is provided, wherein the storage medium stores instructions. When the instructions are executed on a computer, the computer executes the steps of the memory management method described in the first aspect.

[0026] In a fifth aspect, a computer program product comprising instructions is provided. When the instructions are executed on a computer, the computer is caused to perform the steps of the memory management method described in the first aspect. Alternatively, a computer program is provided. When the computer program is executed on a computer, the computer is caused to perform the steps of the memory management method described in the first aspect.

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

[0028] FIG1 is a schematic structural diagram of a computer device provided in an embodiment of the present application;

[0029] FIG2 is a flow chart of a memory management method provided in an embodiment of the present application;

[0030] FIG3 is a schematic diagram of memory management logic under a processor architecture provided in an embodiment of the present application;

[0031] FIG4 is a schematic diagram of memory management logic under another processor architecture provided in an embodiment of the present application;

[0032] FIG5 is a schematic diagram of a memory management process provided by an embodiment of the present application;

[0033] FIG6 is a schematic structural diagram of a memory management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0035] For ease of understanding, before explaining in detail the memory management method provided in the embodiment of the present application, the application background and implementation environment of the embodiment of the present application are first introduced.

[0036] First, the application background of the embodiments of the present application is introduced.

[0037] With the rapid development of cloud computing, more and more critical services and high-value data are being migrated to the cloud, making data protection more complex. Confidential computing can be used to protect data in use, such as VM data.

[0038] Confidential computing is a technology that protects data in use by performing calculations in a hardware-based trusted execution environment. That is, based on the hardware and software capabilities of computer devices, a trusted execution environment (TEE) is built and run to protect the confidentiality and integrity of programs and data loaded into the TEE.

[0039] Currently, mainstream TEE solutions include Intel's Software Guard Extensions (SGX) and Trust Domain Extensions (TDX) technologies for the x86 architecture, AMD's Secure Encrypted Virtualization (SEV) technology, and the ARM architecture's Trust Zone technology. While these technologies differ in their specific implementations, they have all evolved to provide security solutions and services based on encrypted VMs. Encrypted VMs encrypt and protect data in the physical memory area corresponding to the VM, including code running the VM and data generated by user processes within the VM.

[0040] SEV technology establishes a VM-level TEE solution that isolates the traditional hypervisor (also known as a virtual machine monitor (VMM)) from the trusted computing base (TCB) through memory range encryption, hardware instruction extensions, an external security control processor, and the setting of additional physical address flags.

[0041] In some embodiments, SEV technology uses the VM's address space identifier (ASID) to mark the VM's code and data, that is, to mark the VM's memory interval. During the entire operation cycle of the VM, the ASID remains unchanged in the physical memory, ensuring that the VM's data can be correctly read by the VM and will not be accessed by other software in the system. When the VM reads and writes data in its corresponding encrypted memory interval, an encryption engine based on the Advanced Encryption Standard (AES) uses the key associated with the VM's ASID to encrypt and decrypt the read and write data in the encrypted memory interval. Since each VM is associated with its own key through ASID, other VMs or hypervisors can only access the encrypted data. There is strong isolation between VMs and between VMs and hypervisors, ensuring the data security of each VM.

[0042] Because the correspondence between the ASID and the key is stored in the AES encryption engine, accessing a VM's encrypted memory range requires a bus extension. This allows the VM's ASID to be included in the physical address's extra flag when sending memory access requests to physical memory. The physical memory determines the VM's corresponding memory range based on the physical address and then uses the key associated with the ASID to encrypt and decrypt data read from and written to the encrypted memory range.

[0043] It should be noted that when encrypting data in the memory range corresponding to the VM under the X86 architecture, the memory encryption implementation scheme of TDX technology is similar to that of SEV technology. Both require bus expansion to pass the VM identifier associated with the VM's key to the physical memory, thereby encrypting and decrypting the data read and written in the physical memory based on the key corresponding to the VM identifier. Therefore, it will not be explained in detail here.

[0044] The ARM architecture's trustzone technology divides a computer's hardware resources into the REE side and the TEE side, and also divides the computer's physical memory into non-secure memory and secure memory. REE-side code and data are stored in non-secure memory, while TEE-side code and data are stored in secure memory. The REE side is less secure than the TEE. However, the current ARM architecture doesn't define a memory encryption scheme, making it impossible to implement a "one virtual machine, one key" memory encryption solution on native ARM hardware.

[0045] Based on this, an embodiment of the present application provides a memory management method to implement a "one virtual machine, one key" memory encryption scheme on an ARM architecture computer device, thereby encrypting data in the memory intervals of multiple VMs running in the computer device using multiple keys without the need to expand the bus.

[0046] It should be noted that since the memory management method provided in the embodiment of the present application does not require changing the hardware bus architecture when managing the encrypted memory intervals 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.

[0047] Next, the implementation environment of the embodiments of the present application is introduced.

[0048] Figure 1 is a schematic diagram illustrating the structure of a computer device according to an embodiment of the present application. The computer device serves as a physical machine on which multiple VMs are created and run. The computer device can be a server or a terminal. Referring 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.

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

[0050] Communication bus 102 is used to transmit information between the above components. Communication bus 102 can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 1, but this does not mean that there is only one bus or one type of bus.

[0051] The memory 103 may 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 compact disc, a laser disc, a digital versatile disc, a Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store 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 may exist independently and be connected to the processor 101 via the communication bus 102. The memory 103 may also be integrated with the processor 101.

[0052] 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 may also include a wireless communication interface. For example, the wired communication interface may be an Ethernet interface. The Ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof.

[0053] As an example, the processor 101 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG. 1 .

[0054] As an example, a computer device may include multiple processors, such as processor 101 and processor 105 shown in FIG1 . Each of these processors may be a single-core processor or a multi-core processor. A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0055] 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 a variety of ways. For example, the output device may be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device communicates with the processor 101 and can receive user input in a variety of ways. For example, the input device may be a mouse, a keyboard, a touch screen device, or a sensor device.

[0056] In some embodiments, the memory 103 is used to store program code 110 for executing the solution of the present 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 memory management method provided in the embodiment of Figure 2 below through the processor 101 and the program code 110 in the memory 103.

[0057] FIG2 is a flowchart of a memory management method provided in an embodiment of the present application. This method is applied to the computer device shown in FIG1 , specifically processor 101 in the computer device. The computer device functions as a physical machine on which multiple VMs can be created and run. Referring to FIG2 , the method includes the following steps.

[0058] Step 201: Receive a memory allocation request, where the memory allocation request is used to request allocation of a memory interval for a target VM.

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

[0060] In one possible implementation, the memory allocation request is triggered by a physical machine user, instructing the physical machine's operating system kernel to create a target VM based on hardware resources and allocate a memory interval for the target VM from physical memory. Furthermore, when requesting to allocate a memory interval for the target VM, the memory allocation request may include the size of the memory interval required by the target VM, allowing the operating system kernel to allocate a memory interval from physical memory that meets the target VM's needs.

[0061] It should be understood that the memory interval allocated to the target VM can be an encrypted memory interval or an unencrypted ordinary memory interval, depending on whether the encrypted memory interval is divided in the physical memory and the data security requirements of the target VM. If the encrypted memory interval is not divided in the physical memory, all VMs in the physical machine use the ordinary memory interval; if multiple encrypted memory intervals are divided in the physical memory, encrypted memory intervals can be allocated to certain VMs according to the settings of the physical machine user, or to the target VM according to the request of the target VM user. The encrypted memory interval here refers to a memory interval that uses a key to encrypt and decrypt data entering and leaving the encrypted memory interval. Only the corresponding VM can access the data in the encrypted memory interval, while other VMs cannot access the encrypted memory interval or cannot correctly decrypt the ciphertext data stored therein. As for the ordinary memory interval, plaintext data is stored therein and can also be accessed by other VMs or virtual machine hypervisors in the physical machine.

[0062] When protecting data on a per-VM basis, each VM needs to be allocated an encrypted memory range to ensure data security within the encrypted memory range corresponding to each VM. Therefore, this embodiment of the application uses the target VM requesting the allocation of an encrypted memory range as an example to introduce the memory management method.

[0063] Optionally, the above memory allocation request may further carry memory indication information, where the memory indication information is used to indicate whether the memory interval allocated to the target VM is an encrypted memory interval or a common memory encryption interval. This embodiment of the present application does not impose any restrictions on this.

[0064] Step 202: Obtain the size, physical address, and allocation status of multiple encrypted memory intervals through the operating system kernel, where the allocation status is used to indicate whether the encrypted memory interval has been allocated. The multiple encrypted memory intervals correspond to different keys.

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

[0066] In an embodiment of the present application, the operating system kernel can create and manage multiple VMs based on the hardware resources of a physical machine. Based on this, when implementing memory management, the embodiment of the present application can directly indicate information about multiple encrypted memory intervals divided in physical memory to the operating system kernel. This allows the operating system kernel to determine the correspondence between the target VM and the encrypted memory interval when creating the target VM, and thus directly map the target VM's virtual memory interval to the corresponding encrypted memory interval during subsequent memory accesses.

[0067] In some embodiments, before executing the above step 202, the implementation process of the processor indicating the information of multiple encrypted memory intervals to the operating system kernel can be: reading 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 intervals; based on the number and size of the multiple encrypted memory intervals, dividing multiple encrypted memory intervals from the physical memory; and indicating the size and physical address of the multiple encrypted memory intervals to the operating system kernel.

[0068] In other words, the physical machine's boot firmware is modified to store the encrypted memory configuration information in the boot firmware. This allows the physical machine to read the encrypted memory configuration information from the boot firmware when it first runs after powering on, and then divide the physical memory into multiple encrypted memory areas.

[0069] Optionally, after dividing the multiple encrypted memory intervals, the processor may mark the multiple memory encryption intervals as reserved, so that the operating system is not affected by high-level privileged codes (such as Hypervisor) when it starts and runs normally.

[0070] The encrypted memory configuration information includes the number and size of the encrypted memory intervals set by the physical machine user, to instruct the processor to divide the physical memory into multiple encrypted memory intervals according to the number and size required by the physical machine user after reading the encrypted memory configuration information.

[0071] In one possible implementation, the implementation process of writing encrypted memory configuration information in the startup firmware can be: displaying a configuration interface, which is used to instruct the user to enter the number and size of multiple encrypted memory intervals; obtaining the number and size of the multiple encrypted memory intervals from the configuration interface, and writing the number and size of the multiple encrypted memory intervals into the startup firmware.

[0072] When the encrypted memory configuration information is written into 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, the physical memory is re-divided into multiple encrypted memory intervals according to the updated encrypted memory configuration information, and the sizes and physical addresses of the multiple re-divided encrypted memory intervals are indicated to the operating system kernel. If the encrypted memory configuration information has not changed, the multiple VMs deployed in the physical machine are directly run according to the original configuration. In other words, if the encrypted memory configuration information has not changed, the processor only performs the action of indicating the sizes and physical addresses of the multiple encrypted memory intervals to the operating system kernel once.

[0073] Indicating the sizes and physical addresses of multiple encrypted memory intervals to the operating system kernel includes at least the following two methods:

[0074] In the first method, after the processor divides the encrypted memory intervals, the sizes and physical addresses of the multiple encrypted memory intervals are stored in the system registers of the physical machine, so that after the operating system of the physical machine is normally started, the operating system kernel can obtain the sizes and physical addresses of the multiple encrypted memory intervals through the system registers.

[0075] As an example, the operating system kernel may read the sizes and physical addresses of multiple encrypted memory intervals from the system register each time the system is started, and update the information of the multiple encrypted memory intervals stored in the kernel based on the read information.

[0076] As another example, the operating system kernel may also read the sizes and physical addresses of multiple encrypted memory intervals from the system register each time a new VM is created, so as to allocate an encrypted memory interval to the newly created VM.

[0077] In the second method, after the processor divides multiple encrypted memory intervals, it transmits the sizes and physical addresses of the multiple encrypted memory intervals to the operating system kernel through the Advanced Configuration and Power Management Interface (ACPI) interface.

[0078] Optionally, the operating system kernel uses a structure array to manage information about multiple encrypted memory intervals. When creating a target VM, the kernel can query the sizes and allocation status of the multiple encrypted memory intervals based on the structure array. For example, the kernel can query the allocation status and size of each encrypted memory interval in the structure array in a round-robin manner, and then select one encrypted memory interval to allocate to the target VM.

[0079] In some embodiments, the processor accesses physical memory through a memory controller. A memory controller is an electronic device within a computer system that controls physical memory and is responsible for exchanging data between physical memory and the processor. It can be located between the processor and physical memory or integrated into the processor. When multiple VMs are running on a physical machine, the memory controller performs memory address translation between virtual and physical memory intervals when multiple VMs access physical memory, and performs data read and write operations in physical memory.

[0080] Based on this, after dividing multiple encrypted memory intervals from the physical memory, the physical addresses of the multiple encrypted memory intervals need to be indicated to the memory controller so that the memory controller generates and stores the keys corresponding to the multiple encrypted memory intervals.

[0081] Optionally, after receiving the physical addresses of the multiple encrypted memory intervals, the memory controller may establish corresponding relationships between the multiple encrypted memory intervals and the keys based on the physical addresses of the multiple encrypted memory intervals, and store the corresponding relationships.

[0082] The memory controller generates different keys for each encrypted memory interval, corresponding to a unique key. This ensures that, when an encrypted memory interval is assigned to a VM, the VM's data is encrypted and stored using a unique key, achieving a "one virtual machine, one key" memory encryption solution.

[0083] In one possible implementation, a memory encryption engine (MEE) is added to the physical machine hardware to encrypt and decrypt data entering and leaving physical memory. This MEE supports the use of multiple keys to encrypt data in different encrypted memory intervals. This allows the MEE to encrypt and decrypt data read and written from an encrypted memory interval using the key corresponding to that encrypted memory interval, ensuring data security.

[0084] Step 203: Based on the sizes and allocation conditions of the multiple encrypted memory intervals, select an encrypted memory interval from the multiple encrypted memory intervals as a target encrypted memory interval.

[0085] The target encrypted memory interval is an encrypted memory interval that is not allocated to a VM among the multiple encrypted memory intervals, and the size of the target encrypted memory interval meets the code and data storage requirements of the target VM.

[0086] In one possible implementation, the implementation process of the above-mentioned step 203 can be: based on the allocation status of multiple encrypted memory intervals, determine an unallocated encrypted memory interval from the multiple encrypted memory intervals as a candidate encrypted memory interval; based on the size of each candidate encrypted memory interval, determine a target encrypted memory interval from the candidate encrypted memory interval, and the size of the target encrypted memory interval is not less than the size of the memory interval requested to be allocated by the target VM.

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

[0088] It should be noted that in order to prevent a VM from mapping its virtual memory interval to multiple encrypted memory intervals, and multiple VMs from sharing one encrypted memory interval, when allocating an encrypted memory interval to the target VM, the entire target encrypted memory interval is allocated to the target VM. That is, the target encrypted memory interval only stores the target VM's code and data, and does not share memory intervals with other VMs.

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

[0090] In some embodiments, after the target encrypted memory interval is allocated to the target VM, the allocation status of the target encrypted memory interval needs to be updated through the operating system kernel to indicate that the target encrypted memory interval has been allocated.

[0091] That is, after the operating system kernel allocates the target encrypted memory interval to the target VM, it marks the target encrypted memory interval as allocated and will no longer allocate the target encrypted memory interval to other VMs for use, thereby avoiding the situation where multiple VMs share an encrypted memory interval and ensuring the data security of the target VM.

[0092] In some embodiments, 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.

[0093] Similar to the process of creating a target VM, when managing multiple encrypted memory intervals, the operating system kernel promptly releases the encrypted memory interval corresponding to the target VM if the target VM is shut down, and updates the allocation of that encrypted memory interval. This improves the utilization of multiple encrypted memory intervals by promptly updating their allocations.

[0094] In summary, in the memory management method provided in the embodiments of the present application, the operating system kernel manages information about multiple encrypted memory intervals, such as physical addresses, sizes, and allocations, while the memory controller stores keys for multiple encrypted memory intervals. Based on this, when a 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 interval, and then send the physical address of the target encrypted memory interval to the memory controller to instruct the memory controller to perform data operations within the target encrypted memory interval and use the key corresponding to the target encrypted memory interval to encrypt and decrypt the data.

[0095] This shows that the operating system kernel can directly determine the physical address of the VM's encrypted memory interval based on the allocation of multiple encrypted memory intervals, and then access the corresponding encrypted memory interval based on this physical address. In other words, only the physical address is transmitted between the processor and physical memory, without the VM's identification, so there is no need for an extended bus.

[0096] In an embodiment 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, the embodiment of the present application indicates the sizes and physical addresses of multiple encrypted memory intervals to the operating system kernel, so that when the operating system kernel creates a VM, it allocates a corresponding encrypted memory interval to the VM from the multiple encrypted memory intervals divided by physical memory, thereby determining the correspondence between the VM and the encrypted memory interval 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 interval, thereby reading and writing data in the corresponding encrypted memory interval in physical memory based on the physical address. This process does not require changing the hardware architecture and can be applied to different processor architectures.

[0097] To facilitate understanding of the above memory management method and its implementation in a computer device, the embodiment of the present application will now explain the process of implementing memory management by taking a typical ARM architecture processor as an example.

[0098] Referring to Figure 3, based on this processor architecture, the present embodiment can implement memory management through a combination of software and hardware. At the hardware level, an MEE is added to the physical memory to encrypt and decrypt data read and written to multiple encrypted memory intervals in the physical memory, thereby ensuring the security of data when entering and leaving the encrypted memory intervals.

[0099] At the software level, encrypted memory configuration information is written into the boot firmware. This allows the processor to partition multiple encrypted memory intervals from the physical memory based on the encrypted memory configuration information in the boot firmware when the physical machine boots up. It also instructs the MEE to configure different keys for each of the multiple encrypted memory intervals. This allows the configuration of the encrypted memory intervals to be completed during the system boot process. After the encrypted memory intervals are configured, the system boots and runs normally. The processor stores the sizes and physical addresses of the multiple encrypted memory intervals in system registers, allowing the operating system kernel to read, store, and manage the sizes and physical addresses of the multiple encrypted memory intervals from the system registers to ensure that each VM that requires encrypted memory runs in a separate encrypted memory interval.

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

[0101] When the operating system kernel stores the sizes and physical addresses of multiple encrypted memory intervals, the operating system kernel can directly allocate an encrypted memory interval to the target VM when the target VM is created to determine the correspondence between the target VM and the target encrypted memory interval; the operating system kernel can access the corresponding target encrypted memory interval when the target VM is running to realize data reading and writing; the operating system kernel can also release the memory resources of the target encrypted memory interval in time when the target VM is shut down.

[0102] Under the RAM architecture, the REE side includes user mode, kernel mode, and 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, user mode has the lowest privilege level and HYP mode has the highest privilege level. Among them, the VM runs in user mode and kernel mode on the REE side, that is, the VM's client operating system (guest OS) runs in user mode and kernel mode on the REE side. The operating system kernel of the physical machine runs in HYP mode. In HYP mode, the processor can access all hardware resources (such as registers, memory, cache, peripherals, etc.) in user mode, kernel mode, and HYP mode.

[0103] It should be understood that Figure 3 only uses the example of MEE using key Key1 to encrypt and decrypt data in the encrypted memory interval (Area1) entering and leaving VM1, and using key Key2 to encrypt and decrypt data in the encrypted memory interval (Area2) entering and leaving VM2. In actual applications, the physical memory can also include more encrypted memory intervals, and the keys corresponding to each encrypted memory interval are different. These encrypted memory intervals can be allocated to different VMs by the operating system kernel.

[0104] Furthermore, as shown in Figure 3, at the software level, ARM architecture processors are divided into exception levels EL0-EL3. EL0 is the user level, and EL1 is the kernel level. Therefore, user VMM programs can run at EL0 and EL1. EL2 and EL3 are virtualization extension levels used to implement virtualization and security extensions. The operating system kernel of a physical machine runs at EL2, while the boot firmware of a physical machine runs at EL3.

[0105] Based on Figure 3, the following explains the memory management process, using a physical machine as a server, where virtualization modules such as QEMU and KVM in the Linux operating system are used to create VMs. To distinguish it from hardware-based multi-key memory encryption (MKMEE) solutions, memory management solutions based on virtualization modules such as QEMU and KVM in the Linux operating system are referred to as software multi-key memory encryption (SMKMEE).

[0106] The QEMU module, as an emulator, can perform both user program simulation and system virtualization simulation. When simulating user programs, QEMU can run binary files compiled for one platform on a different platform. When simulating system virtualization, QEMU can simulate a complete system VM, complete with its own virtual CPU, chipset, virtual memory, and various virtual peripherals, presenting the operating system and application software running in the VM with a hardware view identical to that of the physical machine. The KVM module is a module within the operating system kernel used to implement virtualization. It exports a series of interfaces to user space, which applications running in user mode can use to create VMs.

[0107] When implementing virtualization, the KVM module is responsible for the core CPU virtualization and memory virtualization parts, and uses the QEMU module as a user-mode component to complete the simulation of a large number of peripherals. They are collectively referred to as QEMU-KVM modules.

[0108] As shown in Figure 4, at the software level, the physical machine user writes encrypted memory configuration information into the memory configuration module in the boot firmware, enables MEE's memory encryption feature, and divides the physical memory into multiple encrypted memory intervals. The sizes and physical addresses of these encrypted memory intervals are then reported to the Linux operating system kernel via system registers or the ACPI interface.

[0109] In the operating system kernel, the SMKMEE module, which manages and allocates encrypted memory ranges, uses a structure array to manage the allocation status of multiple encrypted memory ranges, including whether they are allocated and the handles used by the client process of the allocated VM when using the SMKMEE module. The source code of the QEMU-KVM module has also been modified to add an option to support the creation of VMs using encrypted memory. This allows users to specify whether the VM should use encrypted memory ranges or unencrypted normal memory ranges when creating a VM.

[0110] When using the QEMU-KVM module to create a target VM, the SMKMEE module is first used to query the allocation status and sizes of multiple encrypted memory intervals. If an unallocated target encrypted memory interval is found and its size meets the requirements of the target VM, the physical address of the target encrypted memory interval is mapped to the virtual memory interval of the target VM through the SMKMEE module, and the corresponding client handle is recorded, marking the target encrypted memory interval as allocated. When the SMKMEE module successfully establishes the address mapping relationship of the target encrypted memory interval for the QEMU-KVM module, the QEMU-KVM module loads the target VM into the target encrypted memory interval and runs the target VM.

[0111] Among them, the above-mentioned SMKMEE module is a new driver module added to the Linux operating system kernel when implementing the memory management method provided in the embodiment of the present application. It is the core component for implementing the above-mentioned SMKMEE. Its main functions include two parts: memory address mapping between the VM customer's virtual memory interval and the encrypted memory interval, and maintenance and management of information of multiple encrypted memory intervals, such as the allocation status of multiple encrypted memory intervals.

[0112] 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:

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

[0114] This interface points to a function called open, which accepts two parameters: a struct inode* and a struct file*, and returns an int value. In the Linux operating system, a struct inode represents metadata about a file or directory, such as permissions, size, and creation time; a struct file represents an open file descriptor, which contains information such as the file's read and write locations and operation modes.

[0115] 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.

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

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

[0118] This interface points to a function called release, which accepts two parameters: struct inode* and struct file*, and returns an int 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.

[0119] When a user process completes the file operation and is ready to close the file, it calls the release function. If the file is successfully closed and all resources are released, the release function returns 0 or a non-negative value; if an error occurs when closing the file, the release function returns an error code (usually -1).

[0120] 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 the interface to clean up the encrypted memory interval of the target VM through the Release function, and update the data structure of multiple encrypted memory intervals managed by the SMKMEE module to indicate that the allocation status of the encrypted memory interval corresponding to the target VM is unallocated.

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

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

[0123] In its implementation, the mmap function creates a new physical memory address mapping within the client process's virtual memory range. The struct file* parameter represents the file to be mapped, while the struct vm_area_struct* parameter contains information about the memory mapping range. If the memory address is successfully mapped, the mmap function returns a pointer to the new memory mapping range. If it fails, it returns an error code (usually -1).

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

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

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

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

[0128] 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 a value of type int. In the Linux operating system, the compat_ioctl function is an ioctl operation used to handle compatibility issues between traditional (32-bit) and new (64-bit) user spaces. It is usually implemented by device drivers to support user space programs using ioctl system calls to interact with devices.

[0129] In the embodiment of the present application, by calling this interface, compatibility can be provided for a 32-bit user program to run in a 64-bit operating system kernel.

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

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

[0132] The memremap function is used to operate on an existing memory mapping and is typically used from within the operating system's memory management code rather than directly from user-level programs.

[0133] 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, and whether physical pages need to be reserved. The return value of the memremap function is a pointer of type void*, pointing to the newly mapped memory range.

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

[0135] (2)int remap_pfn_range(structvm_area_struct*vma, unsigned long addr, unsigned long pfn, unsigned long size, pgprot_t prot)

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

[0137] Among them, in the remap_pfn_range function, the vma parameter indicates the pointer to the memory area structure (virtual memory area, VMA) 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.

[0138] In an embodiment of the present application, the function is used to map a physical address to the starting address of the target, and the function can only map address sizes that are integer multiples of a page (the basic unit of memory management, usually 4KB in size).

[0139] Based on the above interfaces and functions, as shown in Figure 5, the SMKMEE memory management process can implement memory address mapping from the encrypted memory range to the VM's virtual memory range through the QEMU-KVM module, the SMKMEE module, and the SMKMEE manager. Specifically, it may include the following steps:

[0140] 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 a VM that requires the use of an encrypted memory interval.

[0141] The VM creation request may be implemented by calling the above-mentioned open function.

[0142] 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.

[0143] In response to the VM creation request, the SMKMEE module may also return a second message (such as error) that does not support the creation of the target VM.

[0144] Step 503: In response to the first message, the QEMU-KVM module sends a memory allocation request to the SMKMEE module to request allocation of a corresponding encrypted memory interval for the target VM.

[0145] The memory allocation request can be implemented by calling the mmap function. The memory allocation request carries the size of the encrypted memory range required by the target VM.

[0146] Step 504: The SMKMEE module sends a query request to the SMKMEE manager in response to the memory allocation request.

[0147] The query request is used to request the SMKMEE manager to allocate an encrypted memory interval for the target VM.

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

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

[0150] 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 interval in the physical memory to the virtual memory interval of the target VM.

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

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

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

[0154] Step 508: The SMKMEE module sends an update request to the SMKMEE manager in response to the memory mapping success message.

[0155] The update request is used to request the SMKMEE manager to update the allocation status of the target encrypted memory interval to indicate that the target encrypted memory interval has been allocated.

[0156] Step 509: The SMKMEE manager returns an update success message (such as ok) to the SMKMEE module in response to the update request.

[0157] If the update fails, the SMKMEE manager returns an update failure message (such as error) to the SMKMEE module.

[0158] 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 execution.

[0159] Step 511: When the target VM needs to be shut down, the QEMU-KVM module sends a VM shutdown request to the SMKMEE module to instruct the target VM to be shut down.

[0160] Step 512: The SMKMEE module sends a resource release request to the SMKMEE manager in response to the target VM shutdown request, requesting to release the memory resources of the target encrypted memory interval corresponding to the target VM.

[0161] The resource release request may carry identification information of the target encrypted memory range, such as a physical address.

[0162] In specific implementation, the resource release request can be realized by calling the above release function.

[0163] Step 513: The SMKMEE manager returns a resource release success message (such as ok) to the SMKMEE module in response to the resource release message.

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

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

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

[0167] It should be noted that FIG5 focuses on illustrating requests or messages transmitted between multiple modules. The specific operations performed by each module can be found in the above text description, which is not elaborated in FIG5 .

[0168] It should be understood that the embodiments of Figures 3-5 are merely an exemplary implementation for explaining the memory management method provided in the embodiments of the present application, and do not constitute a limitation on the specific implementation of the memory management method. Based on the same technical concepts as the embodiments of the present application, those skilled in the art may also use other virtualization modules, interfaces, functions, etc. to implement memory management, and the embodiments of the present application do not limit this.

[0169] FIG6 is a schematic diagram of the structure of a memory management device provided in an embodiment 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. Referring to FIG6 , 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.

[0170] The receiving module 601 is configured to 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.

[0171] A memory information acquisition module 602 is configured to obtain, through the operating system kernel, the sizes, physical addresses, and allocation status of multiple encrypted memory intervals, wherein the allocation status indicates whether the encrypted memory interval has been allocated. The multiple encrypted memory intervals correspond to different keys.

[0172] an encrypted memory determination module 603 for selecting an encrypted memory interval from the plurality of encrypted memory intervals as a target encrypted memory interval based on the sizes and allocation conditions of the plurality of encrypted memory intervals;

[0173] The encrypted memory allocation module 604 is configured to allocate the target encrypted memory interval to the target VM based on the physical address of the target encrypted memory interval.

[0174] Optionally, the apparatus 600 further includes:

[0175] A configuration information reading module is used to read the encrypted memory configuration information in the startup firmware, where the encrypted memory configuration information indicates the number and size of multiple encrypted memory intervals;

[0176] An encrypted memory partitioning module, configured to partition a plurality of encrypted memory intervals from the physical memory based on the number and size of the plurality of encrypted memory intervals;

[0177] The memory information indication module is used to indicate the size and physical address of multiple encrypted memory intervals to the operating system kernel.

[0178] Optionally, the apparatus 600 further includes:

[0179] The memory address indication module is used to indicate the physical addresses of multiple encrypted memory intervals to the memory controller, so that the memory controller generates and stores keys corresponding to the multiple encrypted memory intervals.

[0180] Optionally, the apparatus 600 further includes:

[0181] A display module, used to display a configuration interface, which is used to instruct the user to input the number and size of multiple encrypted memory intervals;

[0182] The information writing module is used to obtain the number and size of multiple encrypted memory intervals from the configuration interface, and write the number and size of the multiple encrypted memory intervals into the startup firmware.

[0183] Optionally, the apparatus 600 further includes:

[0184] The memory information update 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.

[0185] Optionally, the apparatus 600 further includes:

[0186] The memory release module is used to release the target encrypted memory interval in response to the 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.

[0187] 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.

[0188] In an embodiment 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, the embodiment of the present application indicates the sizes and physical addresses of multiple encrypted memory intervals to the operating system kernel, so that when the operating system kernel creates a VM, it allocates a corresponding encrypted memory interval to the VM from the multiple encrypted memory intervals divided by physical memory, thereby determining the correspondence between the VM and the encrypted memory interval 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 interval, thereby reading and writing data in the corresponding encrypted memory interval in physical memory based on the physical address. This process does not require changing the hardware architecture and can be applied to different processor architectures.

[0189] It should be noted that the memory management device provided in the above embodiment manages multiple encrypted memory intervals in physical memory through the operating system kernel, and only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be 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 embodiment and the memory management method embodiment are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0190] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented 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, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. 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 one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, or a magnetic tape), an optical medium (e.g., a digital versatile disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)). It is worth noting that the computer-readable storage medium mentioned in the embodiments of the present application may be a non-volatile storage medium, in other words, a non-transient storage medium.

[0191] 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; "and / or" in this article 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 at the same time, and B exists alone. In addition, in order to facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different.

[0192] 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 used for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of this 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.

[0193] The above description is an embodiment provided for this application and is not intended to limit this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this application should be included in the scope of protection of this 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 according to 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 according to any one of claims 1 to 7 are implemented.

Images